Stuxnet — Reverse Engineering the most sophisticated Malware of its time

Asjad Athick
6 min readNov 6, 2017

Background

Let’s time travel back to January 2010. This was before the era of the whole Internet of Things (or Internet of Threats) debacle. This was when DDoS attacks peaked at around a measly 49 Gbps [1]. Before the whole WannaCry ransomware outbreak. Things were simple in 2010. Or were they really?

Around 2010, networking capabilities and internet technology was at point where its use was widespread and far reaching. Not quite IoT grade scale in terms of connected devices, but we saw more and more Operational Technology or Equipment with networking capabilities. Industrial plants, machinery and laboratories were connected, for increased productivity, remote control and monitoring, and automated or computer controlled operations.

In the non cyber security side of things, the Nuclear arms race was in full swing. Different nations all around the world working hard to establish their nuclear weapons programs (for defence of course!).

Natanz Nuclear Facility in Iran

Iran around this time saw something quite peculiar in their Natanz Nuclear Enrichment plant. Investigators working with the International Atomic Energy Agency just finished an inspection at the facility when they realised an anomaly in the cascade rooms with the thousands of centrifuges working hard to enrich uranium for the country. Natanz normally replaced around 10% of its centrifuges a year due to defects in materials and other common issues. That meant about 800 centrifuges from the fleet of 8,700 in use at the facility. On closer inspection, they found the actual figure to be 1,000 to 2,000 centrifuges every few months. That was more than 25% of the expected defect rate in less than a year.

Why?

Iran was under no obligation to disclose reasons behind the defects, as long as they reported what happened to nuclear material at the plant to the IAEA. Something was clearly damaging the equipment at the plant, jeopardizing the nation’s nuclear program. Then president Mahmoud Ahmadinejad later admitted ‘enemies of the state’ were attempting (and partially succeeded) to sabotage the country’s Uranium Enrichment Program. It would however be years before people realised how and why this was done.

A Case for IT Support

A Windows machine stuck in a reboot loop made its way to IT support. Despite efforts by the operators trying to take control, it continued shutting down and restarting repeatedly. It was infected with a virus, they realised and filed a report.

June 17, 2010. Must have been a calm morning before the storm. Sergey Ulasen of VirusBlokAda, a tiny computer security firm in Minsk, Belarus discovered the report buried in his email. Sergey’s team managed to extract the virus infecting the machine and on some quick analysis discovered it made use of a Zero Day exploit.

Us in the cyber security trade love using the term Zero day vulnerabilities, just because of the punch it delivers in a headline! It’s basically a hole in software, unknown to the vendor or manufacturer of the software, and therefore has no patch available. They’re quite rare to find and exploit; but when done properly can cause a great deal of harm to a large proportion of users.

VirusBlokAda reported the vulnerability to Microsoft like any responsible security firm for patching. Microsoft dubbed this vulnerability ‘Stuxnet’, derived from the 2 vulnerable Windows file names .stub and MrxNet.sys.

More than just IT Support

People soon realised Stuxnet was quite a professional operation. As more assessments of the malware came out, researchers found the code out in the wild as early as 2009, with different iterations and enhancements released over the years. One of the driver files used in the malware used a valid, stolen certificate from RealTek Semiconductor. A later version was also found using another valid certificate from JMicron Technology. Both compromised certificates (from Taiwan based manufacturers) were revoked by Certificate Authorities, but while in use, the malware disguised itself as genuine, trusted programs giving it the ability to fly under the radar, undetected.

Signatures Added

Well, whatever. We’ve uncovered one more piece of malware. Let’s add some signatures onto our Anti Virus detection engines and move on. Right? AV firms receive over a million malicious files every month. Stuxnet was a good find, but this was Business as Usual. Or it seemed that way. Researchers realised the malware was targeting control systems hardware made by Siemens, a German conglomerate with a business in industrial hardware and software to control drive motors, valves and switches in factories and plants.

This was rather odd. There was no clear financial gain (such as stealing credit card information, which was rather common back in the day) in the motives of Stuxnet. So it seemed like corporate espionage. An attempt to steal configurations and other information from companies running this hardware.

For the most part, everyone moved in. But there’s always that one security researcher who doesn’t quite let go. And the rest is history.

Deciphering the mind boggling madness

Liam O Murchu of Symantec found the Stuxnet report on his desk after this company created signatures for the malware for their detection engine. While most files Symantec received were known variations of malware (polymorphic viruses) and were processed automatically, sophisticated attacks such as Stuxnet warranted Murchu’s attention. Malware containing the rare zero-day exploits got examined by hand, and Murchu quickly realised there was more to Stuxnet than what meets the eye.

“Everything in it just made your hair stand up and go, this is something we need to look into.” — Liam O Murchu

Compared to the usual 10–15kb of code on traditional malware, Stuxnet was a whopping 500kb of pure code; a complex, jampacked garble of data and commands. Stuxnet was carefully and professionally created to go undetected.

Instead of loading the payload from disk (which would be a giveaway to AV software), Stuxnet stored its malicious DLLs in memory in a special kind of virtual file, almost impossible to detect. It reprogrammed the Windows API so that when a program tried to load this function from a library, it would be pulled from memory instead of disk. This was a completely different type of ghost file.

Symantec soon found the malware was phoning home to one of 2 domains; www.mypremierfutbol.com and www.todaysfutbol.com, hosted in Malaysia and Denmark. The phone home contained information on the infected machines; computer names, internal/external IPs and the version information on Step7, the Siemens software being targeted. These servers also enabled the attackers to push new functionality into the already inflected fleet of computers, or install more malicious files on the systems.

Symantec convinced the DNS providers of the 2 domains to redirect requests to a DNS sinkhole. Sinkholes enable researchers to receive, capture and analyse the payload sent in by malware to reverse engineer the attack.

“Hello, Can I have 4x Zero day exploits please?”

Fast forward into August 2010, Murchu’s team had been tearing Stuxnet apart for about a month now. 3 new zero-day exploits were found in Stuxnet, which was absolutely unheard of in previously known malware, given the rarity of finding unpatched zero-day exploits. In addition to LNK, it exploited the Windows Print Spooler, Keyboard file and Task Scheduler file for privilege escalation and spreading, in addition to a static password file in Siemen’s Step7 software.

While Stuxnet was spreading like wildfire and targeting systems that wouldn’t normally be connected to the internet, the configurations and behaviour of the malware revealed a very specific actual target. With extensive research and testing, the team discovered the malware was specifically targeting the PLC (Programmable Logic Controllers) in the Step7 software, that matched the configuration used in the Natanz Nuclear Facility. The malware was used to hijack the commands sent from Step7 to the PLCs to slightly increase and decrease the frequency of the centrifuges on a schedule, once every 27 days. The malware would otherwise quietly sit on the network doing reconnaissance and reporting back vital information to the attackers.

This change in centrifugal frequency caused subtle damage to the equipment, sabotaging Iran’s nuclear program.

The extensive planning, sophistication and resources poured into this type of Advanced Persistent Threat was the biggest takeaway from the Stuxnet attack. It infected 100,000s of computers around the world, in the hopes to make it into this one particular facility. Once it was in, it was stealthy, and swift.

Almost undetectable.

Until an ordinary, insignificant infected computer got stuck in a reboot loop. And until one security researcher at VirusBlokAda just wasn’t ready to let go.

--

--

Asjad Athick

Consulting Engineer @Elastic. Enjoy playing with security and data related things on cloud stuff. https://asjad.io