I picked up malwareconfig.com after the registration lapsed. Watching it accumulate junk inbound links from generic web directories felt worse than letting someone with a stake in the original workflow give the domain a useful afterlife. The site is no longer a configuration-extraction service. The Yara rule manager is gone, the upload form is gone, the per-family stat pages are gone. What’s here now is editorial: notes on the same kinds of questions the original service answered, and pointers to the projects that filled the gap.

This is the first of those notes. The point is to write down what I actually use in 2026 when I want to go from “I have a sample” to “here is its config”, and to be honest about where each step works and where it falls over.

what malwareconfig.com used to do

For anyone arriving from a footnote: between roughly 2014 and 2019, this domain hosted a web app built around Kevin Breen’s RATDecoders project. You uploaded a sample, the back end ran a Yara rule match against a curated rule set, dispatched the sample to a family-specific Python decoder if the rule fired, and returned the embedded config: C2 hosts, mutex names, RC4 keys, version strings, the kind of fields that make detection content writeable. At its peak the index sat at 25,473 configs across families that included njRat, DarkComet, Xtreme RAT, adWind, NanoCore, Pony, Dridex, and a handful of macro droppers.

It was a useful service for two reasons that are easy to forget now. First, sandbox dynamic analysis was slower and more expensive in 2014 than it is in 2026, and a free static-extraction service was a cheap way to triage a sample before deciding whether it earned a sandbox slot. Second, the rule + decoder pairs were public, so a CERT analyst could read the actual extraction logic and adapt it for an internal pipeline, which mattered in environments where uploading samples to a third party was not allowed.

The service shut down quietly in 2019. Kevin moved on to other work. The codebase is still readable on GitHub. The domain went dormant, the registration eventually lapsed, and it sat unregistered for a stretch before I picked it up.

what filled the gap

Roughly five things took over the parts of the workflow this site used to cover.

Sandboxes absorbed the upload-and-triage step. Triage (now Recorded Future) and Hatching both ship configuration extractors as a first-class output of detonation. You upload a sample, and within a couple of minutes you have the dropper chain, the runtime artifacts, and for several dozen families a structured config block with the same fields the old service used to return. ANY.RUN does the same thing with a more interactive UI. VirusTotal Intelligence retro-hunts on the same field set if you have access. None of these are free in any meaningful sense for sustained use, but the free tiers are useful for one-off samples.

CAPE Sandbox is the closest direct successor to the malwareconfig.com workflow philosophically. It’s open source, runs on your infrastructure, ships with maintained extractors for a long list of families, and the community module repo is where new extractors land. If you want the static-extraction-as-a-service workflow on your own hardware in 2026, CAPE is what you build it on.

MalwareBazaar and YARAify at abuse.ch picked up the public-corpus role. MalwareBazaar is the sample acquisition layer; YARAify is where you submit a Yara rule and have it scanned against the corpus, which is what you used to do by hand against the malwareconfig.com config index when you wanted to find related samples. abuse.ch runs both for free, with rate limits, and the API is well-documented.

Malpedia at Fraunhofer FKIE became the citation-grade family encyclopedia. Per-family pages with curated reference papers, IOC sections, and links to public detection content. If I’m trying to ground a current sample in the literature, I start there.

ATT&CK absorbed the actor- and campaign-level cross-referencing. The old “what is this family used by” question that you used to answer by reading three blog posts is now a single click on the relevant Group page.

The honest summary is that the original service tried to solve a fragmented problem with one web app, and the post-2019 ecosystem solved the same problem by splitting it across five projects, each of which is better at its slice than the original could have been. The trade is operational: you used to upload one file and get a config; you now reach for two or three of these tools depending on what you actually need.

what I reach for first in 2026

Concretely, my own pipeline for a fresh sample looks roughly like this. Other analysts run different orderings; this is mine.

Hash the sample, then check VirusTotal and MalwareBazaar for prior intel. If either has a config-extractor result already, that’s free work I don’t need to redo. If the sample is a maldoc, run olevba (or oledump.py) against it for a static look at the macro before anything else; if it’s an LNK or ISO, walk it manually first to understand the dropper chain.

Detonate in Triage or Hatching for the dynamic view, and look specifically at the configuration extractor output if one fires. For families those sandboxes don’t cover, drop to CAPE on a local instance.

If none of the above produced a config and the sample looks like it’s worth the time, that’s where the static-extraction work begins. Open the binary in IDA or Ghidra (Ghidra has caught up to a degree that I do most config-blob work in it now), find the loader, dump the encrypted blob, identify the cipher, write the decoder. The historical RATDecoders Python implementations are still useful here as a reference for what config layouts looked like for the families they covered, even when the families have evolved past the original blob structure.

Cross-reference against Malpedia and the relevant ATT&CK Group page before writing anything up, because half the time the family has been renamed or merged into a cluster I wasn’t tracking, and the Malpedia entry has the citations that update my mental model.

That’s the workflow. It’s slower than uploading a file to malwareconfig.com used to be. It’s also far more reliable, covers a much wider range of families, and tends to produce output that is actually usable for detection work because the modern sandboxes carry far better runtime context than a static-extraction service alone could.

what this archive will and won’t do

This site won’t bring back the upload form. The right place to upload a sample in 2026 is one of the sandboxes above, not a static archive run by one person on a small VPS.

It won’t republish working Yara rules. There are better-maintained homes for those: Florian Roth’s signature-base , the YARA-Rules collective project, and the YARAify corpus. Adding a fourth public Yara rule mirror would just create a maintenance gap I can’t promise to fill.

What it will do is occasional writeups on the same kinds of technical questions the original service answered: how a current family stores its config, what the static-extraction process looks like end to end, how the modern tooling stack actually composes. The cadence is roughly one post every four to six weeks. RSS is at /index.xml if you want to follow without checking back.

The historical subdomains have their own pages now: aptnotes.malwareconfig.com points at the canonical APTnotes archive, viper.malwareconfig.com points at the live Viper framework, and dridex.malwareconfig.com points at RATDecoders and oletools. If you arrived here from a citation that referenced one of those subdomains, follow it through to the canonical project; that’s where the original work lives.

Mail goes to [email protected]. Read, not always replied to.

• Maren / halt0p