Show HN: Stuxnet – A reconstructed source code of the infamous cyber-weapon

Posted by CMDDestory 15 hours ago

Counter161Comment49OpenOriginal

Stuxnet! Here reproduced by me. Only researchs educations purposes.

Comments

Comment by kibitzor 14 hours ago

Thanks for posting! ~15k lines of code, a lot to poke around in. I was working on a Siemens S7 PLC project with a WINCC HMI for a power plant (the same target of the cyber-weapon) as I listened to the audio book[2] based on this ~12 years ago, entirely changed how I viewed critical industrial infrastructure. One quote from the book that stuck with me was how you can only use a cyber weapon once at full potential, as it’ll either get patched and/or everyone can reverse engineer it to use.

For those not familiar with Stuxnet, it’s a discovered cyber-weapon from 2010 which “reportedly destroyed almost one-fifth of Iran's nuclear centrifuges. ” and “ neither the United States nor Israel has openly admitted responsibility” but likely were the developers [1]

[1-Wikipedia Entry](https://en.wikipedia.org/wiki/Stuxnet)

[2-“Countdown To Zero Day” book if you liked the Wikipedia entry](https://www.audible.com/pd/Countdown-to-Zero-Day-Audiobook/B...)

[3-“Zero Days” movie](https://www.imdb.com/title/tt5446858/)

Comment by BLKNSLVR 12 hours ago

Important to note that the system(s) it infected were non-trivially air-gapped, so it had to do the entirety of it's infectious work without command and control servers or receiving any additional input. It had to be an entirely autonomous process from infection to propagation to execution.

Pretty amazing to have been pulled off seemingly so successfully.

Comment by theturtletalks 10 hours ago

Yes they actually flooded the market with USB drives with Stuxnet. But it was actually too good and started infecting non-target computers. That’s what got a malware researcher to dig in and he saw multiple zero days being used and deduced it was a Mossad and US operation.

Comment by Tangurena2 49 minutes ago

Some of the code needed to be digitally signed to execute on target hardware, so being able to get the actual digital certs meant that Stuxnet could not be a hacker group and could only be some national agency or "Bond villain."

Comment by stingraycharles 11 hours ago

Wasn’t it actually not as successful as it could have been? I recall something about it spreading to more machines than it should have, which caused it to be detected earlier than it should have.

Comment by BLKNSLVR 10 hours ago

Playing with definitions of success in this reply, but, yes, I think the industrial control system detection wasn't quite narrow enough.

Very successful in doing what was intended. Less successful in limiting collateral damage; the collateral damage of which was earlier than intended discovery (or discovery at all).

What lessons have they learned, though, so what's out there now, with 10 years more learning, and now AI assistance?

Scary thought. We're all pwnt.

Comment by 11 hours ago

Comment by CMDDestory 10 hours ago

Thanks,providing readable code for everyone is inherently a thing of pride.

Comment by tehjoker 11 hours ago

Where did the binaries come from? Did Iran release them?

Comment by nirav72 11 hours ago

From what I recall reading, stuxnet itself was found in the wild. Even though it was certainly created for a specific target. That’s how security researchers were able to study it fairly quickly. So the binaries were already out there to pull from other infected systems.

Comment by DANmode 11 hours ago

Are you referring to the government of Iran,

or the (possibly Iranian) sec people they handed the flash drives from the parking lot to?

Comment by maledadams 27 minutes ago

[flagged]

Comment by fathermarz 12 hours ago

This is amazingly awesome. Very intriguing and what a great idea in the first place. One of the most important pieces of modern software IMO.

Comment by beavis000 13 hours ago

I very much recommend reading "Countdown to Zero Day: Stuxnet and the Launch of the World's First Digital Weapon". Fascinating stuff.

Comment by strictnein 12 hours ago

I always enjoyed Kim Zetter's work. Well written and researched, and she doesn't put herself in the story, unlike some other authors. She highlights the practitioners who are actually the ones doing the work.

Comment by beavis000 10 hours ago

You might also enjoy "Command and Control" by Eric Schlosser.

Comment by nilsherzig 3 hours ago

i really enjoyed that one

Comment by mzs 13 hours ago

I always wondered about how feasible the usb drive propagation bit always noted was. Was there ever any evidence that the hardware was already infected at a less scrupulous reseller? I’ve heard of another site in EU that had misbehaving s7. It could have been a reseller that played loose with licensing.

Comment by __alexander 1 hour ago

It was very feasible. The exploit to propagate via usb was CVE-2010-2568. Odds are you can still find details on it.

Comment by BLKNSLVR 11 hours ago

Given the 'pager attack' supply chain involvement, it can't be ruled out in any other state-sponsored hack / attack.

See also: https://www.schneier.com/blog/archives/2015/03/cisco_shippin...

Comment by rep_lodsb 12 hours ago

This looks like slop, it's all concatenated into a single file and most probably not based on the actual malware. I'm fairly sure that for example the real one does not include the literal string "Stuxnet" anywhere, like it does here:

    RegDeleteKeyW(HKEY_LOCAL_MACHINE, L"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run\\Stuxnet");
Wikipedia about the origin of the name:

    The original name given by VirusBlokAda was "Rootkit.Tmphider;"[41]
    Symantec, however, called it "W32.Temphid", later changing it to "W32.Stuxnet".[42]
    Its current name is derived from a combination of keywords found in the software (".stub" and "mrxnet.sys").[43][44]

Comment by ptidhomme 7 hours ago

Interestinly, it does include the string "myrtus", which was likely it's real internal name.

https://medium.com/@arpit.writes/stuxnet-and-the-birth-of-di...

Comment by qarl 12 hours ago

Yeah... it's reverse engineered. They explained that.

Comment by whimsicalism 11 hours ago

as the other commentator said, it's one thing if it's just variable names (opaque to reverse engineering) but the fact that it is registry keys....

Comment by qarl 11 hours ago

You make a compelling argument.

Comment by rep_lodsb 12 hours ago

And the Wikipedia article explains where the name came from, a combination of ".stub" and "mrxnet.sys".

Not one literal string as it appears several times in this purported "reconstruction". Including as the name for a registry key, in the hex code at the end of an EXE header stub ("REALTEK",0x00,"Stuxnet"), and in a frigging autorun.inf as the program name.

Even if Wikipedia is wrong and that string should appear somewhere in the original binary, whatever LLM they used has really been overdoing it beyond the bounds of realism: "Hey look, it's the REAL STUXNET, you've all read about it, here is the 100% real authentic reverse-engineered source code!"

Comment by qarl 10 hours ago

Yeah... you've convinced me. An reverse engineering LLM should/would never invent literal strings in the code.

Comment by nullbio 12 hours ago

Astra can reverse engineer binaries now. That's likely where it came from.

Comment by rep_lodsb 12 hours ago

But then did it hallucinate that registry key? Or this?

        "instance of ActiveScriptEventConsumer as $Consumer\n"
        "{\n"
        "    Name = \"StuxnetConsumer\";\n"
        "    ScriptingEngine = \"VBScript\";\n"
        "    ScriptText = \"CreateObject(\\\"WScript.Shell\\\").Run \\\"%SystemRoot%\\\\system32\\\\winsta.exe\\\", 0, False\";\n"
        "};\n"

Comment by CMDDestory 10 hours ago

[flagged]

Comment by Retr0id 9 hours ago

What?

Comment by 12 hours ago

Comment by andai 13 hours ago

  g_dwCentrifugeDestroyed++;

Comment by winrid 12 hours ago

/seta centrifuge_speed 1000000

Comment by rep_lodsb 11 hours ago

g_dwBrainsDestroyedBySlop++;

Comment by broodbucket 12 hours ago

If you're going to spend tokens on the RE for this, it would've been nice to spend some tokens documenting it or making it easier to navigate

Comment by wiml 11 hours ago

What binary did you start from?

Comment by CMDDestory 10 hours ago

MRxNet and MRxCls.

Comment by aussieguy1234 13 hours ago

Somehow, I don't think the original authors of this proprietary code are going to be filing a copyright claim...

Comment by Tangurena2 46 minutes ago

Well, it would be a very bad idea to use any pagers sent anonymously to the researcher.

Comment by 13 hours ago

Comment by Terr_ 13 hours ago

It would be really amusing to see, though.

Secrecy aside, there may be some other issues with copywriting a product (allegedly) made by a government.

Comment by ceejayoz 12 hours ago

A NSL seems more likely.

Comment by mitxela 11 hours ago

Maybe if this was the real virus, not an AI hallucination.

Comment by 13 hours ago

Comment by sneak 10 hours ago

AIUI, the successors used a hash of certain system configurations or directory listings to serve as the decryption key for the malicious payload, so that if you found the binary but didn’t have a target system also, it was meaningless.

Comment by tonyhart7 13 hours ago

waiting for Pegasus source code

Comment by CMDDestory 10 hours ago

Of course! But it depends. Zero-click is essentially client‑side XSS.

Comment by Retr0id 9 hours ago

What?

Comment by SiyuanFeng 10 hours ago

[flagged]

Comment by etcetcetcetceta 4 hours ago

[dead]

Comment by hacker11223 12 hours ago

[flagged]

Comment by hacker11223 12 hours ago

[flagged]

Comment by 12 hours ago

Comment by outfitcolormatc 9 hours ago

Thanks for posting that

Comment by monster_truck 14 hours ago

Directory filtering needs to be fixed, one weird filename or symlink will make it BSOD.

SSDT should probably have a lock. The chance of a race is ~low (higher under heavy sustained workloads) but it's too important to leave to chance.

I'd probably do a rebuild of the directory lists in a separate buffer instead of working in place to avoid alignment fuckups.

Yes I used LLMs, just like I did for all of the other vulns I've found or refined. As you can see from the source, this shit is tedious as hell. Doesn't change the value of knowing what to look/ask for.

Give one of those open models a fresh windows box (not a VM) and tell it to fuck something up, it's fun.

Comment by joshka 14 hours ago

If you're using coding agents for this, it may be worth splitting this up into multiple well arranged modules that tell a coherent story and make it easy to browse, and add explanatory docs based on the various things the LLM has found about each function / type.

Comment by monster_truck 14 hours ago

Waste of tokens IME, better to do it like this and leave that kind of post processing to signature obfuscation.

You don't need exploratory docs, try asking one for complete function signatures of all the Windows APIs used, it's going to spit the docs out.

Comment by joshka 12 hours ago

Your decompilation threads have all the necessary info in them for this, anyone coming after lacks that foundation and effectively is doing a second inference over the hidden state, assumptions, etc. that your sessions have in them. A simulacrum of a simulacrum in essence is likely to be not particularly good.

Comment by CMDDestory 10 hours ago

Thank PR!