The trigger for this build was a CloudSEK report. They disclosed internal details on a group tracked as Aurora (Aur0ra): researchers got into a misconfigured server and pulled the attack tooling, records of the group planning operations with the help of an AI coding assistant (Cursor), and the admin panel used to negotiate ransom. The ransomware itself was written in Zig, with Windows and Linux/ESXi variants, staged in a public Cloudflare R2 bucket and pushed to victim hosts over SCP. The group has been active since April, and by July it had hit more than 20 organizations across 9 countries.
I'm not going to editorialize about attackers using AI to plan. What caught my attention as a builder is more mundane: every one of those disclosures is a bag of indicators — file paths, hashes, bucket URLs, protocol artifacts — and if you're on a small security team, you spend real time triaging that kind of dump by hand. So I used it as the concrete need for a weekend build: a small tool that ingests leaked IOCs, scores them, clusters related ones, and gives an analyst somewhere to search and review. I built the whole thing on VicroCode and kept it honest about what the platform can and can't do.
What the tool actually does
Three moving parts. A Python backend parses a raw IOC dump into typed records. A vector store clusters indicators so related ones surface together during retrieval. And a hosted HTML page lets an analyst search, filter, and mark things as reviewed. Nothing exotic — the value is in the plumbing being fast to stand up and easy to hand off.
The Python parser and scoring pass
I started with the parser because it's where the messiness lives. A disclosure like the Aurora one doesn't arrive as clean JSON; it's prose with hashes, IPs, and URLs sprinkled through it. I wrote extraction with plain regex plus a few type heuristics — is this a SHA-256, an IPv4, a bucket URL, an ESXi-specific path?
Each extracted indicator gets a lightweight score based on type and context: a hardcoded C2 URL weighs more than a generic Windows path that shows up in half the world's binaries.
Being able to run Python online meant I could iterate on the parser against real pasted text without setting up a local environment or fighting dependency versions. That matters more than it sounds — most of my time on this went into tuning the extraction rules, and a tight edit-run loop is the difference between finishing in an afternoon and giving up.
One honest trade-off here: the Aurora ransomware was written in Zig, and the payloads were staged in an external object store. My tool does not touch either. It doesn't compile or analyze Zig, and it doesn't reach into Cloudflare R2 or any other external cloud storage — that's outside what VicroCode does, and pretending otherwise would just build a dead code path. The tool works on the *text* of the indicators, not the binaries or the buckets they came from. If you need actual malware detonation or bucket enumeration, this isn't that, and you'd wire those steps somewhere else.
Clustering with a vector store
The reason a flat IOC list gets tedious is that related indicators scatter. Three paths that all belong to the same ESXi variant, two URLs pointing at the same staging pattern — an analyst has to notice those connections manually. So I embedded each indicator's text plus its context and pushed it into a LanceDB knowledge base so that a search for one artifact pulls back its neighbors by similarity, not just exact string matches.
In practice this is what makes triage feel less like grep. Search "esxi" and you get the whole cluster of related host-side artifacts, ranked, instead of one literal match. I kept a SQLite table alongside it for the structured fields — type, score, first-seen, reviewed flag — because vector similarity is great for "what's related" and terrible for "show me everything I haven't triaged yet, sorted by score." Using both, each for what it's actually good at, kept the design simple.
The analyst dashboard
The front end is deliberately plain: a search box, a results list with score and type badges, and a review toggle that writes back to SQLite. I served it as a hosted HTML page and pointed it at the Python backend through an in-platform endpoint, so there's no separate server to babysit. Standing up the web app hosting took less effort than the parser did, which is the right ratio for a tool like this.
A security note I won't gloss over: as I built it, the dashboard had no authentication. For a scratch tool that's fine, but the moment real indicators go into it, an unauthenticated page is a liability — you'd be publishing your triage state to anyone with the link. Add access control before this holds anything you care about. That's not a VicroCode limitation, it's just a thing that's easy to forget when a prototype starts feeling useful.
What I'd tell a peer
The build held together because I matched each need to something the platform actually does: Python for parsing and scoring, a vector store for clustering, SQLite for structured queries, and a hosted page for the human. The places I had to say no — Zig analysis, external bucket access — were clean boundaries, not workarounds I had to hack around. Whether this actually speeds up a real analyst's triage is unverified; I built it against one disclosure, not a production caseload. But as a reproducible pattern for turning a messy indicator dump into something searchable, it's a solid afternoon's work, and the parts you'd reuse next time are obvious.