![[Stuxnet] Ep. 1: The Natanz Mystery](/_next/image?url=%2Fmedia%2Fcover%2Fimage.webp%3Fpath%3Dorg_01KB11FNVFKQ28576CGFP6B05G%252Fimage-1790114565969.jpeg&w=3840&q=75&dpl=dpl_2vw5zc3WNoYoA6sAARj5BPKBDwL8)
[Stuxnet] Ep. 1: The Natanz Mystery
This opening episode covers how researchers uncovered Stuxnet in 2010 and traced the strange Siemens infections toward Iran’s Natanz enrichment plant.
Show Notes
Wired (public reporting): https://www.wired.com/2014/11/countdown-to-zero-day-stuxnet/
Kaspersky (public writeup): https://eugene.kaspersky.com/2011/11/02/the-man-who-found-stuxnet-sergey-ulasen-in-the-spotlight/
Chapter 1
The Minsk Anomaly
Alex Rivera
June 17, 2010. A small antivirus firm in Minsk, VirusBlokAda, receives a routine help desk ticket from a partner firm near Tehran. The client's machines were stuck in endless crash cycles. Specifically, as the report noted, a customer in Iran reported arbitrary BSODs and computer reboots.
Alex Rivera
System administrators had tried reformatting. They did fresh reinstalls of Windows. Nothing stopped the blue screens. Belarusian security analyst Sergey Ulasen took the ticket. He remote connected into the Iranian network, expecting a broken application or driver conflict. Instead, he pulled a thread that unveiled the most sophisticated cyberweapon in history.
Alex Rivera
What Ulasen and his team found in lab triage was... well, it was completely unheard of. The malware was hiding behind kernel mode rootkit drivers. But here is the kicker. Those drivers were digitally signed. They carried valid, genuine digital signatures from two major Taiwan hardware vendors, Realtek and JMicron.
Alex Rivera
Windows Driver Signature Enforcement usually blocks unsigned kernel code from loading. By abusing stolen private certificates from those vendors in Hsinchu Science Park, the malware bypassed Windows security silently. No warnings. No prompts. It loaded straight into the kernel.
Alex Rivera
Then came the infection vector. The malware was spreading via ordinary USB flash drives, exploiting a zero day Windows Shell shortcut vulnerability later designated CVE 2010 2568. You, um, you did not even have to click an executable. Simply plugging in the thumb drive and opening the folder in Windows Explorer to view the file icons triggered execution.
Alex Rivera
The vulnerability resided in how Windows parsed LNK files to render custom icons. The moment Explorer tried to display the shortcut icon, the malicious code executed inside memory. Zero user interaction required. An air gapped network was no longer safe if someone walked a flash drive across the threshold.
Alex Rivera
I want to pause on what it felt like in malware analysis labs during those late June days. As researchers unpacked the binary, the payload looked completely alien. There was no keylogger. No credit card scraper. No ransomware screen demanding Bitcoin. No banking botnet code. It was half a megabyte in size, written in C and C++, packed with multiple zero days.
Alex Rivera
Whoever built this spent millions of dollars in zero day exploits and burned stolen corporate certificates. Yet they were not stealing money. They were searching for something exceedingly specific. And the lab analysts realized they were looking at state sponsored sabotage.
Chapter 2
The Path to Natanz
Alex Rivera
By July 2010, the global reverse engineering community was dismantling the sample piece by piece. German researcher Frank Boldewin decoded hardcoded string references buried deep in the binary. He uncovered hooks explicitly targeting industrial control software: Siemens WinCC and STEP 7.
Alex Rivera
The malware was actively replacing a crucial dynamic link library, s7otbxdx.dll. That specific library handles communications between Siemens Step7 software running on Windows and the underlying Programmable Logic Controllers, or PLCs, connected over a data cable.
Alex Rivera
By intercepting s7otbxdx.dll, the malware created a classic man in the middle framework inside the industrial control console. It could inject malicious code directly into the PLC while feeding fake, completely normal telemetry back to the human operators monitoring the screens.
Alex Rivera
Then, in August 2010, global telemetry data came in from Symantec. The spatial distribution confirmed what researchers suspected. The infection was not random. Telemetry showed that 60 percent of the infected computers worldwide were in Iran.
Alex Rivera
Investigative journalist Brian Krebs, along with detailed research from Kaspersky Lab and Symantec, connected the final dots. The malware, now dubbed Stuxnet, was tailored specifically to subvert the enrichment cascades at Natanz, Iran's primary uranium enrichment plant.
Alex Rivera
Subsequent investigative reporting identified the operation as Operation Olympic Games, widely reported to be a joint covert effort between the United States and Israel. The goal was to physically destroy the fast spinning IR 1 gas centrifuges without alerting the plant technicians.
Alex Rivera
Stuxnet was not just code that lived on screen. It was code designed to reach out into the physical world and tear heavy machinery apart. Over one thousand centrifuges were degraded or destroyed at Natanz while operator screens showed everything was running smoothly.
Alex Rivera
Which brings us to the ultimate question. How exactly did code written in C and C++ alter rotor frequencies to shatter aluminum centrifuges, all while hiding from the supervisory monitoring systems? That operational deep dive is what we will unpack next.
Alex Rivera
Zero Daze is brought to you by Jellypod AI, the generative media creation studio. Thanks for tuning in, and I will catch you in the next episode.
