Stuxnet shut down by its own kill switch
- By William Jackson
- Jun 26, 2012
On June 24, local time, the replication routines in Stuxnet turned themselves off, effectively halting the spread of the sophisticated cyber weapon.
According to researchers who have analyzed Stuxnet code, it was a feature, not a bug.
“The code will still run, but one of the first things it does when it starts running is check the date” of the machine in which it has been installed, said Liam O Murchu, manager of operations for Symantec Security Response. If the date is after June 24, 2012, it no longer copies itself to USB memory sticks, the malware’s preferred means of spreading.
Flame reportedly set up Stuxnet attack, was under human control
Researchers find ‘proof’ of Flame-Stuxnet link
The configuration file containing the kill date could be updated, but no signs of this were seen in any iterations of the code, O Murchu said. Once deactivated, “it would be difficult to get it to reactivate,” he added, indicating that the shutdown was planned.
Like so much else in Stuxnet — apparently the first effective weaponized malware and reportedly the product of a U.S. government cyber weapons program — the kill switch is unusual.
“We don’t see that very often in threats,” O Murchu said. Sometimes it is used in tests of new malware to keep it from spreading and drawing attention to itself, but in a finished product, “it’s very unusual.”
Duqu, a related piece of information-gathering code believed to be part of the same weapons program, had a default 30-day life span that could be extended on a case-by-case basis. “With Duqu they were more careful, and that threat effectively is dead,” O Murchu said.
Flame, a spyware program also connected to the U.S. program that reportedly shared some of its code with Stuxnet, began removing itself from infected machines after it was discovered, when its command-and-control servers sent out “suicide” commands, Symantec reported at the time.
Stuxnet, likely released in 2009 and discovered a year later, is a complex piece of code apparently intended to infiltrate Iranian industrial control systems and disrupt the country’s alleged nuclear weapons program. It apparently worked, damaging numerous centrifuges used to enrich uranium into nuclear fuel. But along the way it also infected more than 100,000 other computers around the world and attracted what surely was unwanted attention.
Because Stuxnet was carefully targeted at a specific controller that was controlling a specific piece of equipment, no other instances of damage to equipment have been reported. More significant than the worm’s effective demise is the impact of its apparently unintended spread.
Some ability to spread probably was needed in order to infect the intended systems, O Murchu said. “But it appears that the controllers could have controlled the spread more carefully,” he said. “That might have been a mistake or it might have been a choice. It’s not clear from our analysis which it was.”
Although much has been made of the wide availability of the weaponized malware code, its use to would-be attackers probably is limited, he said. Much like the U.S. drone aircraft that fell into Iranian hands, having access to a complex piece of technology does not mean it can be easily duplicated.
“It’s not that much of an advantage from a practical point of view to review the code,” O Murchu said, and it is unlikely that attackers would be able to reuse much of the complex code. But it does provide information about the processes used in the attack that could be helpful in constructing another attack. “From that point of view, it could be very useful to attacker.”
William Jackson is freelance writer and the author of the CyberEye blog.