How we test our cures

The short version

1. Capture. Our own decoy servers record attacks and keep the programs attackers leave behind.
2. Identify. We work out what a program is and what it does to a server.
3. Test on a sealed machine. We run the cure on a test machine that can't reach any network, then scan again.
4. Human approval. A person reviews the evidence and approves the cure in writing.
5. Ship. The cure goes into the next Minaki Scan release.

Today Minaki Scan has seven cures. One was tested on a real sample we caught ourselves. Six were tested on planted test copies. The rest of this page explains what that difference means.

1. Capture

We run decoy servers, sometimes called honeypots. They look like ordinary servers to attackers, so attackers break in and try to install their programs. The decoys record what happens and keep a copy of each program. Those copies never run on the decoys, and we never publish them or the addresses they came from.

2. Identify

For each program we work out which malware family it belongs to and what it does to a server: where it hides its files, and how it makes itself start again after a restart. AI helps us with this work, alongside the published research from security companies and researchers. Every sign we record has to come from a source we actually read, or from our own test.

We label a sample only as far as the evidence goes. The one real sample behind a cure today shares markers with both the Mirai and Gafgyt botnet families, and nothing in it is unique to either. So we call it "Mirai-lineage", not Mirai.

3. Test on a sealed machine

We test each cure on a throwaway test machine that's cut off from every network. Before each test we check, from inside the machine, that it has no route out, can't reach the internet or our own network, and can't look up web addresses. After each test the machine is reset to a clean copy, and it's destroyed when the work is done.

A test passes only when the scan afterwards comes back clean: the cure removed every sign of the malware, and nothing it shouldn't have touched was changed. In the planted-copy tests we also include decoys, such as a harmless program with the same name as the malware, or a legitimate login key, to check that the cure leaves them alone.

There are two kinds of test:

• A real sample. We run the actual program we captured, let it install itself, then run the cure.
• A planted test copy. We build the malware's known footprint on the test machine: its files, startup entries and login keys, with a harmless program standing in for the malware. This proves the cure finds and removes those signs. It doesn't prove the cure would work against the real program.

4. Human approval

Nothing ships automatically. A person reviews the cure, the evidence for each sign it looks for, and the test results, then approves it in writing. The approval records who approved it, when and where.

All seven of our cures carry that written approval. Outlaw, our first cure, came before we added the written approval step; we have since reviewed and approved its record too, so every cure now carries it.

5. Ship

An approved cure goes into the next Minaki Scan release. On your server it acts only on a confirmed finding, such as a file whose exact fingerprint matches, and only after you type yes. See what the scanner does.

What the labels mean

Every page in the threat wiki carries one of these labels:

How each cure was tested

The real sample, step by step

Our decoy server in San Jose caught the program on 14 October 2026 at 13:16 UTC. It's a 64-bit Linux program of 193,352 bytes. Its fingerprint (SHA-256) is:

3674a103804cac96027fe1cf62aaab4948c1d547d1c885542177a263103b4260

On the sealed test machine, it copied itself to a hidden file in /var/tmp, added a script at /var/tmp/.sys_recovery.sh that restarts it, and set up three separate ways to start again after a restart:

• a scheduled task, /etc/cron.d/netupd;
• a system service, netd.service;
• an older-style startup script, /etc/init.d/sys_daemon.

The cure removes all three startup methods first, so nothing can bring the program back mid-cleanup. Then it stops the processes and deletes the files. Then it scans again. The scan came back clean, with no processes left.

The restart test

We then ran a restart test. We set off each of the program's own startup methods the way a restart would: started its service, ran its startup script and ran its scheduled task. Nothing came back, and no process from the sample was left running.

Our first cure for it missed two of three

Our first version of this cure removed the scheduled task and reported the machine clean. It wasn't. The program had also set up the system service and the startup script, and both survived.

We caught it before the cure shipped. A closer look at the text inside the program pointed to the other two startup methods. We extended the cure to find and remove all three, tested it again on a clean copy of the test machine, and added a test so the same miss can't come back unnoticed.

The same testing caught a second mistake: an early version flagged the scanner's own output file as malware. We fixed that before shipping too.

It's also why we say plainly which cures were tested on a real sample and which on a planted test copy.

What we don't claim

• We don't claim a cure works against versions of a threat we haven't tested. Malware changes, and new versions can hide in new places.
• We don't claim any server is clean after a cure. A clean scan means these checks found nothing. It isn't proof.
• We don't try to clean threats that hide inside the system. For those, the advice is to back up and rebuild.