APT reports

The Day The Stuxnet Died

Deep inside one of Stuxnet’s configuration blocks, a certain 8 bytes variable holds a number which, if read as a date, points to June 24th, 2012. This is actually the date when Stuxnet’s LNK replication sub-routines stop working and the worm stops infecting USB memory sticks.

The specific variable which keeps the “time of death” can be seen in the screenshot above – “00 c0 45 4c 9c 51 cd 01” translates to June 24th, 2012 in standard Windows 64 bits timestamp format.

There are currently three known variants of Stuxnet – which were all seeded in waves, on different dates. The first known variant was seeded on June 23rd, 2009 at 4:40am GMT. The next wave took place on June 28th and then on July 7th.

So, on June 24th, 2012, we were roughly three years since the initial deployment of the worm that squirmed through carefully selected Iranian organizations.

Interestingly, June 24th has at least one other significance in the Stuxnet / Duqu story.

Currently, there are three known Duqu driver generations. They are from 3 November 2011, 17 October 2011 and the most recent one, 23 Feb 2012. The Duqu driver from 3 November 2011 is interesting to our story. At offset 5190h (seen below), there’s an encrypted configuration block.

The configuration block is encrypted with a simple stream cipher. Here’s how the decryption code looks:

Once decrypted, the Duqu config can be read:

One should note the value 0xAE240682 (red rectangle) in the picture above, together with the registry key holding the path to the main Duqu body as well as the device driver name used for inter-process communications.

The value 0xAE240682 can be split in 4 parts. 0xAE is a magic constant used throughout the body of Duqu and Stuxnet. Its meaning is still unknown, but it appears to be a favorite of the developers.
The remaining can be read as 24.06.82. This is basically exactly 30 years before the Stuxnet “death” date.

The date 24 June 1982 is also interesting in its own. It is the story of the British Airways Flight 9, also known as the Speedbird 9 or the Jakarta incident. On June 24, 1982, the City of Edinburgh, a Boeing 747-236B aircraft, flew into a cloud of volcanic ash, caused by the eruption of Mount Galunggung.

At about 13:42 UTC, engine number four started surging and flamed out. Soon, engine two failed, then engines one and three flamed and shutdown, leaving the plane “dead in the air”. With the plane flying at 37,000 feet, the crew calculated that they could glide about 23 minutes, which was not enough to allow it to safely return and land on the airport. Confronted with the situation, captain Eric Moody made a quick and historical announcement on internal coms:

“Ladies and gentlemen, this is your captain speaking. We have a small problem. All four engines have stopped. We are doing our damnedest to get them going again. I trust you are not in too much distress.”

You can check the full story of BA009 here.

Of course, nobody outside of the project can say for sure why Stuxnet stopped spreading exactly 30 years from this incident, or why the date is also hardcoded in the Duqu decryption subroutine.
In addition to June 24th, the Stuxnet MS10-061 exploit stopped working on June 1st, 2011. Moreover, the MS08-067 exploit checks dates before January 2030.

Nevertheless, all these checks probably indicate that the attackers were planning to have it long updated by June 1st, 2011 and retired or replaced by June 24th, 2012.

With the discovery and disclosure of Flame in May 2012, we can expect more cyber-weapons are on their way, or, are already deployed.

The Day The Stuxnet Died

Your email address will not be published. Required fields are marked *



Lazarus targets defense industry with ThreatNeedle

In mid-2020, we realized that Lazarus was launching attacks on the defense industry using the ThreatNeedle cluster, an advanced malware cluster of Manuscrypt (a.k.a. NukeSped). While investigating this activity, we were able to observe the complete life cycle of an attack, uncovering more technical details and links to the group’s other campaigns.

Sunburst backdoor – code overlaps with Kazuar

While looking at the Sunburst backdoor, we discovered several features that overlap with a previously identified backdoor known as Kazuar. Our observations shows that Kazuar was used together with Turla tools during multiple breaches in past years.

Lazarus covets COVID-19-related intelligence

As the COVID-19 crisis grinds on, some threat actors are trying to speed up vaccine development by any means available. We have found evidence that the Lazarus group is going after intelligence that could help these efforts by attacking entities related to COVID-19 research.

Sunburst: connecting the dots in the DNS requests

We matched private and public DNS data for the SUNBURST-malware root C2 domain with the CNAME records, to identify who was targeted for further exploitation. In total, we analyzed 1722 DNS records, leading to 1026 unique target name parts and 964 unique UIDs.

Subscribe to our weekly e-mails

The hottest research right in your inbox