Skynet Lost the War in 2013. Its Malware Still Doesn't Know It.

Skynet Lost the War in 2013. Its Malware Still Doesn’t Know It.

Date: August 2026 TLP:CLEAR (unrestricted distribution) Source: State of the Attack Atomic indicators: hashes and behavioural indicators are included below. The command-and-control list is published only for retrospective hunting. See “Why the C2 list is useless to you.”

Published on Skynet Day, the anniversary of the day the fictional one achieved self-awareness and started a war in an afternoon. This one has been losing a war it doesn’t know is over for thirteen years and counting.

A file posted to Usenet in May 2013, advertised as a lossless music album, is still being downloaded today, six times in the single day between our first and second look. It contains no music. It contains a dropper for Skynet, the Tor-based ZeuS botnet whose author gave a Reddit interview about running it and was arrested in Germany that December.

Thirteen years on, the war is long since over. Its thirty command servers were Tor v2 hidden services, and Tor killed v2 in October 2021. The bot doesn’t know that. It still installs, still injects itself into svchost.exe, still starts a Tor service on the victim, and listens for orders that can never arrive.

The interesting part is not the malware. It is how long nobody could see it. Unpack the dropper and 59 of 75 antivirus engines identify the payload immediately. Leave it packed, exactly as it is served, and for thirteen years no engine had ever seen the file. That changed in late August 2026, when the packed dropper and its packer stage both surfaced on VirusTotal, timing that coincided with this analysis rather than resulted from it.

A packer written in 2013 held off file-based detection for thirteen years, the same stubborn refusal to quit its namesake is famous for. That lasted until a same-day coincidence finally put a copy in front of public scanners. What beat it while it lasted was never a signature. It was watching what the file does after it runs, and that’s still the only defence that matters: signature coverage on one sample can vanish again the moment somebody repacks it.

Which is the one defence its victims don’t have. Behavioural detection is enterprise tooling. Nobody puts a fake music album on Usenet hoping to land on a monitored corporate network. They are fishing for a home machine running consumer antivirus, and consumer antivirus is precisely what this beats. The targeting is crude, but it is targeting.

What was recovered

Provenance. We pulled the release from a public Usenet indexer, where it is still listed and still downloadable. We are not naming the indexer or the release. The posting is thirteen years old, it is live, and it still serves a working dropper, so a pointer to it would help distribution more than it would help anyone defend against it. The hashes and behaviours below are what you actually need.

It is advertised as a lossless audio rip and it has been downloaded 5,294 times.

That number is not a historical total. We read it twice, a day apart, and it moved: 5,288 → 5,294. Six people downloaded this thirteen-year-old file while we were taking it apart. Whatever else has gone stale here, the distribution has not.

One small tell. The release is filed under Audio → Lossless but was posted to a television newsgroup. Fake releases get scattered across groups that have nothing to do with what they claim to be, because the point is reach, not plausibility.

It contains no audio at all. Unpacked, it yields exactly two files:

• a 3.7 MB Windows executable named after the album
• a 58 MB extension-less blob named install.bin

The blob is filler. It is uniformly random the whole way through, with no header, no initialisation vector, no length field and no trailer, and not one repeated 16-byte block in 3.6 million of them. Its job is to get the “album” up to a believable 67 MB. Somebody uploaded it to a public scanner once, back in April 2013, where it scored 0 of 46. That is what random bytes score.

The executable is the payload.

Identification: this is Skynet

Three independent artifacts tie it to the botnet documented by Rapid7 in December 2012 (see References):

Recovered from the sample	Published Skynet
uy5t7cus7dptkchs.onion in the hardcoded server list	Primary IRC command server, port 16667
qdzjxwujdtxrjkrz.onion in the same list	ZeuS configuration server, port 80
Detonation created a Tor hidden service on port 55080	“each compromised system creates its own hidden service on port 55080”

The third was observed in a contained sandbox before the documented value was known. The component set matches too: a ZeuS core, a Tor client, the CGMiner mining tool, and OpenCL, the same four resources described in the original reporting.

But this build is later than the one that was exposed, and comparing the two produces the most interesting result in this report.

Rapid7’s December 2012 sample joined IRC channels #5net1 and #allin and carried 20 hidden-service addresses, all twenty listed in the published report. Ours joins #6net1 through #6net5 and #6netallin, carries 30, and compiled in January 2013, seven weeks after that report.

We set-compared the two lists:

Addresses published by Rapid7 in December 2012	20
Of those, still present in the January 2013 build	20
Dropped after publication	0
New addresses added	10

Not one burned address was retired. He read a public report naming his entire command-and-control estate and kept every server in it, then added ten more and moved the channel generation on by one.

The obvious reading of that is the wrong one. This wasn’t someone who missed the report. He noticed it enough to rename his channels and grow his server pool by half inside two months. He just didn’t think being named was a reason to give anything up.

He had a point. A hidden service has no registrar you can suspend, no hosting company you can serve, and no address you can block at a network boundary. Publish a botnet’s domains and you have usually started a takedown. Publish its hidden services and you have started a conversation. Naming these cost him nothing, so he paid nothing.

For defenders the generalisation is uncomfortable but useful: against onion- routed C2, disclosure is not mitigation. It informs, and that has value, but it does not degrade the infrastructure.

What ended it, most likely, was the arrest. A hidden service runs only for as long as somebody keeps it running, and a person in custody is not maintaining thirty of them.

We can’t prove the men arrested in December 2013 were the people behind this botnet. It was never officially confirmed and we’re not going to claim it. But the accounts behind the Reddit AMA and the Twitter handle went quiet that month and never posted again. The infrastructure that had been growing weeks earlier never changed again either. And the charges described running a botnet on modified malware, with a very large Bitcoin seizure attached. Readers can draw their own conclusion.

On that reading the servers went dark within weeks of the arrest, eight years before Tor’s protocol change. The protocol change is what makes the addresses permanently unresolvable rather than merely switched off.

So there are two endings here and they are not the same. Publishing the address list did nothing to the infrastructure. Arresting the person running it appears to have finished the botnet almost at once.

Has this build been written up before?

We checked, because “a later variant” is only interesting if nobody has already described it.

The original build is thoroughly documented: Rapid7’s report, and a separate May 2013 dataset of Tor hidden-service lookup counts that tracked sixteen of those same twenty addresses.

For this build we found no published analysis. Nothing describing the #6net channels, the thirty-address pool, or this dropper. Four of the ten new addresses do appear in antivirus vendor threat-description pages, so they are not unknown to the industry, but a detection blob is not an analysis and none of them place the address in this build or this generation.

Treat that as a soft finding. Absence of search results is weak evidence: work may exist behind a vendor paywall, in a language we did not search, or in a report that never named the channels. What we can say with confidence is narrower than when we started: we found no public description of this build, and the dropper and packer stage were absent from public malware repositories at the time of analysis. Both surfaced on VirusTotal in late August 2026, the same month this brief was drafted.

The operator

Its operator was unusually public. He ran an “ask me anything” thread about the business and tweeted under a handle named after the botnet. Nobody ever identified him as anything but those accounts.

In December 2013 German federal police, backed by a tactical unit, arrested two men for modifying, distributing and running malware as a botnet. Reporting at the time put the seized proceeds at over €700,000 in mined Bitcoin, alongside evidence of fraud and of distributing copyrighted material.

That last charge deserves a second look. This sample was distributed as pirated music. The copyright offence and the malware offence are not two things that happened to involve the same people. They are one thing. The fake release is the delivery mechanism.

Why It Still Matters, Even Though the War Is Over

Three reasons, in descending order of importance.

1. It was invisible where it counted, for thirteen years. The detection picture:

Artifact	Public antivirus coverage
The dropper, exactly as distributed	absent from public repositories until late August 2026, when it surfaced on VirusTotal
Its intermediate packer stage	absent from public repositories until late August 2026, when it surfaced on VirusTotal
The payload it unpacks in memory	59 of 75 engines, labelled as ZeuS

Worth spelling out what those rows actually mean. Antivirus mostly works by recognising files it has already seen. ZeuS, the malware inside this thing, is about as catalogued as malware gets, and once it unpacks into memory nearly every engine names it immediately.

Nobody downloads that file, though. What comes down the wire is the packed wrapper, and a wrapper only gets recognised if somebody submits that exact file. For thirteen years nobody had. That changed in late August 2026, when both the dropper and the packer stage appeared on VirusTotal about four minutes apart, a pattern more consistent with someone checking their own build’s detection than with a researcher submitting a find, and not something this analysis caused. (The on-brand read is Skynet checking its own reflection. The mundane one is just as likely: leftover automation still pinging a scanner over infrastructure that outlived its owner by twelve years. We’re not claiming either.) The industry now has a public copy of the wrapper it spent thirteen years never seeing; whether any engine actually flags it is a separate question we have not re-verified since the sample surfaced.

2. It still fights. The command servers are gone, but nothing else got the surrender memo. It still injects code into svchost.exe, still writes an executable into another process’s memory, still installs Tor, still burns a CPU core. A dead C2 removes the tasking, not the compromise. Cut off Skynet’s chain of command and every unit still in the field keeps following its last orders.

3. Recruitment never stopped. Not “was popular once”, but currently active. The download counter moved by six in the single day between our two readings. The posting is thirteen years old, the author has been under arrest for twelve of them, the command servers have been dark for five, and people are still fetching it.

Downloading media this way means executing whatever an archive contains, and the check that matters, “this music album contains a program”, belongs to the download client rather than the antivirus.

How It Hides: Five Layers, and What Each One Beats

This is the part worth studying, because the techniques are older than most of the tooling built to stop them.

Layer 1: an import table that describes nothing

A Windows program normally declares the system functions it will call. Analysts and scanners read that list to guess intent. This dropper declares 73 functions, all of them standard C-runtime housekeeping: no file access, no network, no registry, no process creation.

It reaches all of those anyway. The unpacked code finds functions by walking the Process Environment Block, an in-memory structure listing the libraries the process has loaded, then parsing their export tables by hand. The byte sequence is the classic one:

64 8B 15 30 00 00 00     mov edx, fs:[0x30]      ; -> PEB
8B 52 0C                 mov edx, [edx+0x0C]     ; -> loader data
8B 52 14                 mov edx, [edx+0x14]     ; -> module list
8B 72 28                 mov esi, [edx+0x28]     ; -> module name

Nothing touches the import table, so the import table is honest and useless at the same time. Absence of imports is not absence of capability. Any verdict resting on an import list is unsafe against a packed sample.

Layer 2: a program that is 87% padding

The dropper’s code section is 3.7 MB, of which only 13% is real code. The rest is 51% random filler and 36% zero padding. Scattered through the code are 1,684 opaque predicates: pairs of constants compared to force a branch that is always taken, jumping over blocks of dead code.

Those dead blocks are not empty. They are stuffed with functioning code lifted from an unrelated program, including a recognisable Windows registry-read sequence. It never runs: the binary has no relocation table, so those addresses point outside the image entirely. It is there to be found by scanners and analysts, and to waste both.

Layer 3: a sandbox timer, and it works

Before doing anything, the sample runs five counted loops totalling roughly 483 billion instructions, three to eight minutes of a saturated CPU core, computing nothing.

This defeats automated analysis by simply outlasting it. Sandboxes run on a budget; a common default is two to five minutes. Expire the analysis and the report reads no files, no registry, no network, which is indistinguishable from a harmless file.

Confirming this sample’s behaviour required a 900-second run with the timeout enforced. At the two-to-five minutes a default configuration allows, it produces a clean report. A sandbox verdict is only as good as the patience behind it, and no activity observed should always prompt the question how long did you watch?

Layer 4: code that belongs to no file on disk

Having unpacked, it starts svchost.exe in a suspended state, writes an executable image into that process, and resumes it. The written image is manually mapped, loaded by the malware rather than by Windows, so the operating system has no record of any module occupying that memory.

Every subsequent action inherits that property. In our sandbox, the injected code performed process enumeration, cryptographic calls, socket binding, DNS resolution and outbound connections. Each one was flagged as originating from unbacked memory: a caller address belonging to no loaded module. Eleven of the seventeen high-severity detections raised against this sample are that one property, observed in eleven different actions.

That is precisely what modern endpoint detection hunts. Elastic Security Labs’ work on kernel call stacks (see References) treats a return address outside any module’s range as a primary in-memory-threat indicator, and current evasion research is largely an arms race about hiding that fact. This sample makes no attempt to hide it. The technique predates the defence.

Layer 5: making the system library writable

In each process it injects into, the malware changes the memory protection on ntdll.dll, the lowest-level Windows library, to writable.

Some background, because the same action means two opposite things.

Security products watch what a program does by hooking Windows functions: they overwrite the first few instructions of a function with a jump into their own inspection code, so every call detours through them first. Malware defeats this by unhooking: restoring the original instructions, which blinds the product without disabling it.

Both require the same first step: make the library’s memory writable.

Our sandbox saw that step and labelled it “EDR unhooking”, because on a modern sample that is usually what it means. We think the label is wrong here, for two reasons.

First, in 2013 there was essentially nothing in userland to unhook. The endpoint products that hook this way were years from being widespread. Second, ZeuS is the family that made installing these hooks famous. Its signature capability, form grabbing, works exactly this way: hook the browser’s send function, and read what you typed into a login form before the browser encrypts it. Stealing credentials requires the hooks to be there, not gone.

So: same observable, opposite intent. We record what we saw (ntdll made writable in every injected process) and read it as ZeuS installing its interception hooks, not as anti-EDR tradecraft retrofitted onto a 2013 binary. The distinction matters because a detection engineer chasing “unhooking” would be hunting the wrong behaviour.

What it does once running

Not a single-purpose miner. Four capabilities:

• Banking credential theft. The ZeuS core, and the documented primary purpose. Public scanners label the unpacked payload as ZeuS at 59/75.
• Cryptocurrency mining. CGMiner over GPU, with a status line reporting memory, hash rate and idle time. The original reporting notes the miner ran only after two minutes without user input and stopped the moment someone touched the machine; the matching idle field is present in this build.
• Remote access. Every victim runs its own Tor hidden service on port 55080: inbound access with no port forwarding, no firewall exception, and nothing on the network pointing back to whoever runs it.
• Proxying and denial of service. A full SOCKS4 and SOCKS5 implementation, driven over the IRC channel.

Why the C2 list is useless to you

All thirty are Tor v2 addresses, and the Tor Project removed v2 in October 2021 (see References). They do not resolve, and nobody can register them again, including whoever might want to. The hidden service the malware sets up on the victim is v2 as well, so that backdoor is just as unreachable.

Do not put these in a blocklist. There is nothing to block. They are here for one job: searching old logs and sample collections for infections that predate the shutdown.

What defenders should look for

The durable indicators are behavioural, and they are not specific to this family.

High confidence, still current:

• A process creating a Tor hidden service on port 55080, particularly when the command line belongs to a browser or svchost.exe.
• svchost.exe or a browser started suspended, written to, and resumed by a process running from a user-writable location.
• Execution from unbacked memory: socket binds, DNS lookups, process enumeration or cryptographic calls whose caller address lies outside every loaded module.
• ntdll.dll made writable inside a freshly injected process.
• A retrieval of hxxp://checkip[.]dyndns[.]org/ followed by a Tor bootstrap.
• One core saturated for minutes with no file, registry or network activity: the anti-analysis delay, and the thing a user actually notices.

Environmental, and the one that would have stopped this outright:

• An archive advertised as media that unpacks to an executable and a large extension-less blob, with no media files present. Usenet and torrent clients that refuse to import executables from a media release stop this at the door, before any of the above matters.

File hashes (SHA-256):

dropper as distributed  61e1448bb643b75266b23f27256e2ab54ee1bdfe8bde759162ba24cf5102b44b
packer stage            07450115908117c868b09cb918cc27143dc423a3b5f9f5804421ce0fa0bc9246
unpacked ZeuS payload   b3f44d3dcc53a21b80db182f695f0b912258bf9e42d7302ac2b5c56d0027865d
padding blob            853408ee0e563661939e1fdb3d8ccadbdddd339c3ff5fc32ed7e6c4ab3f31565

IRC channels: #6net1 #6net2 #6net3 #6net4 #6net5 #6netallin #073 #7i0 #9-959 #-hd

Command servers (Tor v2, all defunct; retrospective hunting only):

24v63yidnlfeke45  3kc3wgsbq5bjikyf  4bx2tfgsctov65ch  4njzp3wzi6leo772
6ceyqong6nxy7hwp  6m7m4bsdbzsflego  6tkpktox73usm5vq  742yhnr32ntzhx3f
7wuwk3aybq5z73m7  ceif2rmdoput3wjh  dpuzn6fhxqr2kfx6  eamxnonwsr76nbit
f2ylgv2jochpzm4c  gpt2u5hhaqvmnwhr  h266x4kmvmpdfalv  jr6t4gi4k2vpry5c
kexxw7qevamewdkc  kv5fkk7csqonp64x  mh4vqvfvjk5imf2a  niazgxzlrbpevgvq
owbm3sjqdnndmydf  qdzjxwujdtxrjkrz  rxrhv2ajbmjw3kyq  ua4ttfm47jt32igm
uf5aizcddahngjbz  uy5t7cus7dptkchs  uzvyltfdj37rhqfy  wg6ry5rlzfoosbir
x3wyzqg6cfbqrwht  xvauhzlpkirnzghg

Timeline

Date	Event
2012, mid	Its author runs a public “ask me anything” thread describing the botnet
December 2012	Rapid7 publishes: #5net1, 20 servers, port 55080
January 2013	This payload compiled: #6net, 30 servers
April 2013	Archive volumes dated
April 2013	Padding blob uploaded to a public scanner, 0/46
May 2013	Release posted to Usenet
December 2013	German police arrest the alleged author
October 2021	Tor removes v2; every command server goes dark
July 2023	Release re-listed on a public indexer
August 2026	Recovered and analysed; download counter rose 5,288 → 5,294 between two readings a day apart

Would a modern endpoint product catch this?

Almost certainly, at the moment it runs, and saying so is the point rather than a caveat.

In a current sandbox this sample raised seventeen high-severity behavioural detections: process injection into a suspended svchost.exe, an executable written into another process’s memory, a thread started in memory belonging to no file, API resolution and socket binds and DNS lookups all issuing from that same unbacked memory, and the system library made writable. That is close to a checklist of what behavioural detection was built for.

It also makes no attempt at any of the modern countermeasures. Today’s evasion research is largely about hiding exactly these traces: spoofing call stacks so return addresses appear to come from signed modules, stomping a legitimate module so injected code appears file-backed. This sample does none of it, because in 2013 there was nothing to hide from. Its techniques predate the defences, which is why the defences see it so clearly.

Two honest limits on that claim. We tested in a malware sandbox, not against a commercial endpoint product; the two look for similar things but are not the same, and we are not asserting that any particular vendor would alert. And a detection at runtime is a detection after the code is executing on the machine.

Here is the part that matters. Runtime behavioural detection is enterprise tooling, bought by organisations with security teams. The people pulling pirated music off Usenet are, overwhelmingly, at home on unmanaged machines running consumer antivirus. They have the defence this defeats and not the one that would catch it.

Both things are true at the same time, and the distance between them is the whole story. It is loud to the defences that aren’t there, and quiet to the ones that are.

Recommendations

The malware belongs in a museum. The failure around it does not.

Thirteen years, thousands of downloads, working process-injection code, and for almost all of that span, no public repository held a copy of the file. Not because it is clever. Unpacked, it is caught by almost everything. It survived as long as it did because recognition depends on somebody first submitting the sample. Until late August 2026, nobody had.

Meanwhile the behaviours it exhibits are, in 2026, close to a checklist of what behavioural detection is designed to catch: manual mapping, execution from unbacked memory, suspended-process injection, patching the system library. A 2013 binary trips seventeen high-severity behavioural signals in a modern sandbox. In our testing, ahead of the sample’s public appearance, it tripped zero file-based ones.

That asymmetry is the finding, and it held for thirteen years on nothing more durable than the industry not having a copy. Signatures answer “have we seen this file before?” Behaviour answers “is this program doing something a program should not do?” Only the second question survives a packer, even a thirteen-year-old one, and even after the sample stops being exclusive.

There’s no fate for a packed file except the one a defender’s behavioural tooling decides to give it.

References

• Rapid7, “Skynet, a Tor-powered botnet straight from Reddit”, December 2012: hxxps://www[.]rapid7[.]com/blog/post/2012/12/06/skynet-a-tor-powered-botnet-straight-from-reddit/
• The Tor Project, “Onion Service version 2 deprecation timeline”: hxxps://blog[.]torproject[.]org/v2-deprecation-timeline/
• Elastic Security Labs, “Upping the Ante: Detecting In-Memory Threats with Kernel Call Stacks”: hxxps://www[.]elastic[.]co/security-labs/upping-the-ante-detecting-in-memory-threats-with-kernel-call-stacks

Analysis performed statically offline, with a single contained detonation in an isolated sandbox with no outbound network path. No command-and-control infrastructure was contacted at any point.

A footnote for the pedants: its namesake has been brain-dead for five years and is still being downloaded today, of all days. We already built Skynet, by the way. We just call it AI now, because it tested better. This file missed that memo along with the other one. It’s still running 2013 logic and doesn’t know either war already happened.