0161 513 0960Jack O'Sullivan
March 22 2021
"Kinetic Cyber refers to a class of cyber attacks that can cause direct or indirect physical damage, injury or death solely through the exploitation of vulnerable information systems and processes. Kinetic cyber attacks are a real and growing threat that is generally being ignored as unrealistic or alarmist." [ccdcoe.org]
Going kinetic is the nightmare scenario that we all dread: it’s the day when cyber attacks have tangible, real-life consequences, causing large scale physical damage and putting life at risk. Despite what the media might say, that day isn’t here yet, but it’s drawing closer. So how did we get here, what does it mean, and what can we do to protect ourselves?
In order to understand how we got to this point, we need to go back to where it all began. To the attack that essentially implied that it was acceptable to attack Industrial Control Systems (ICS).
The attack was called Stuxnet.
It’s 2009, Obama is in the Whitehouse. In the Middle East, tensions are high. Iran has been enriching uranium and has made little effort to hide its ambitions to become a nuclear power. Sanctions and controls have been put in place. Its main enrichment plant at Natanz is visited by agents of the International Atomic Energy Agency twice a month (IAEA). Samples and readings are taken to ensure that Iran is staying within its agreed limits, enriching to degrees suitable for medical purposes or energy production, and not the large scale production highly-enriched uranium needed for nuclear weapons.
However, not all is well. Some of the figures do not match up, some of the readings are higher than expected, and suspicion has grown that Iran is pursuing an atomic bomb. Although it can’t be proven, America - potentially in cooperation with the state of Israel - decides something must be done.
It’s now 2010. Virusblokada, a company providing cybersecurity solutions to many Iranian clients, receives reports that some computers are stuck in a perpetual boot up loop, which persists even if the operating system is reinstalled. Symantec analyses the code and immediately sees that it is malware; but this malware is something special:
- It’s sophisticated
- Parts of it are encrypted
- It’s modular
- It infects widely but seems to be waiting to land somewhere very specific before it does anything
- It makes use of one, then two, then three, then four zero days
Strangely though, what it does when it finally infects its desired target remains a mystery.
What was notable about Stuxnet was the number of zero days it used and how they were combined.
Earlier versions of it used an old vulnerability, MS08-067, to enter systems. This vulnerability is present in the Windows SMB protocol. Interestingly, the recent WannaCry infection used a newer vulnerability in the same Windows protocol leaked from a dump of NSA tools. In its final form, Stuxnet used multiple zero days to achieve its aims.
Zero days are the gold standard of vulnerabilities, by their very nature they exploit unknown flaws in a system. Thus zero days are a prized commodity: highly effective and almost undetectable. A shadowy underworld exists where hackers can use brokers to sell zero day exploits, which are then sold to nation states for whatever purposes they wish to put them to.
Though this is ethically unsound, it is more profitable for a hacker to sell a vulnerability this way than it is to disclose the problem ethically to a vendor (for a much lower amount of money in the form of a bug bounty reward).
These are the zero days used to infect a PC in an air-gapped network, and then spread within that network:
- Microsoft Windows Shortcut ‘LNK/PIF’ Files Automatic File Execution Vulnerability
- Microsoft Windows Print Spooler Service Remote Code Execution Vulnerability
- Microsoft Windows Server Service RPC Handling Remote Code Execution Vulnerability
The first vulnerability is associated with removable media, such as a USB drive. Put simply, the code is hidden in the icon associated with a file and executes automatically. This allows it to target a system which might be traditionally ‘air gapped’, moving via USB drives. The second enables it to spread through a LAN by exploiting the print spooler service, exploiting default functionality. The third allows it to spread through a network via SMB. The code copies itself onto computers connected to network shares.
Put together it suggests that it was designed to infect via a USB, spread through a given LAN via the print spooler, and then spread out into the network via SMB - no doubt eventually reaching users with higher admin privileges, and gaining a hold over a whole network with relative ease.
However, this is only half the story. Because although Stuxnet found a way to spread across networks, large parts of it remained encrypted, as though it was waiting for something very specific before it went to its next stage.
It was looking for Industrial Control System software.
Only under certain circumstances did Stuxnet unlock its inner secrets and advance. Once it had gained control it lay dormant, updating itself via a peer to peer network. When it found the right computer with the right software, it activated. The software it was looking for was WinCC databases and Siemens Step 7 control software - because this allows for the control and programming of Programmable Logic Controllers (PLCs).
PLCs are used in industrial operations. They provide central control over devices such as valves, pumps and, in the case of Stuxnet, variable frequency drives to control motors. The Siemens Step 7 software allows such devices to be programmed, the instructions are then uploaded to a main Siemens system via a data cable, and from there control the various elements of a given system.
Once Stuxnet found itself on a computer with the requisite software installed, it used its last zero day exploit to take control of the WinCC/SCADA software. Once there, it infected all Step 7 projects with a final portion of encrypted code.
Slowly Stuxnet was giving up its secrets, but its final goal remained elusive. We knew how it had infected systems, but the end goal - the final payload - remained a mystery. To understand this, we must make a brief diversion into the world of nuclear physics.
Enriching uranium is a difficult process. First the uranium ore is mined, then through a series of processes it is turned into a powdery form known as yellowcake. After further processing it is converted into a gaseous form called uranium hexafluoride. This contains pure uranium isotopes suspended in the gas.
As uranium is a heavy metal, the gas is pumped into a series of tubes with motors attached. These tubes, known as centrifuges, spin the gas under pressure, forcing the heavier uranium isotopes closer to the internal wall of the tube. This richer gas is syphoned off and passed to the next tube and the weaker gas is returned to the start of the system to run through again.
The term used for this arrangement is a cascade; a series of hundreds of such tubes constantly spinning, enriching the uranium past medical grade, through the grade required for nuclear power, finally to the purity required for nuclear weapons.
The plant at Natanz consisted of several hundred of these centrifuges. The IAEA, amid concerns and suspicions about the plant, installed cameras to monitor the doors of the main centrifuge hall in Natanz and noted the worrying fact that the centrifuges seemed to be failing and being replaced with disturbing frequency. Initially put down to the inexperience and lack of expertise in managing this process, we now know this was the kinetic effect of Stuxnet’s final payload.
Stuxnet had a very precise set of rules to it. Though indiscriminate in its spread, it only triggered its payload if:
- It was in Iran
- It was on a Windows computer with Step 7 software
- It was transferred to a Siemens S7-300 SCADA system
- That system was controlling variable-frequency drives
- Those drives were manufactured by Vacon based in Finland and Fararo Paya based in Iran
- The motors were programmed to spin between 807 Hz and 1,210 Hz
Only if those condition were met would Stuxnet unpack the final payload, taking control of a block of memory in the Profibus element of the Siemens system. For context, there were 30 million Profibus nodes installed worldwide by the end of 2009.
From there it periodically modified the frequency to 1410 Hz and then to 2 Hz and then to 1064 Hz; then waited, and then began repeating this pattern. This physically destroyed the centrifuge, which had to be replaced, rendering the uranium enrichment process useless. In a world first, it also installed a persistent rootkit to the control system and fed information to the main monitoring system, tricking it into thinking that operations were proceeding normally.
It is estimated that the Stuxnet attack put Iran’s nuclear capabilities back by up to five years. The sophistication of the code was staggering and only achievable with the level of resources that a nation state would have. It marked the dawn of the era of kinetic attacks, and sent a signal to other nations that not only were such attacks possible, but that they would be actively carried out.
Stuxnet has many similarities to the Conflicker worm of 2008, which infected machines using the same MS08-067 vulnerability that the first iteration of Stuxnet used. Like Stuxnet it infected other machines but lay dormant, counting down to a date where thousands of machines would reach out online for commands.
Conflicker was ultimately defeated only by a heroic international effort to ‘sinkhole’ every command and control domain it could recognise... which was thousands of them. Was this a dry run? Or a nation state testing a proof of concept for this attack vector?
Stuxnet lives on in viruses like Duqu (2011), a virus nearly identical which stole system information and logged keystrokes; and Flame (2012), which propagated via USB using the same method as Stuxnet. Even some of the files in these viruses follow the same naming convention as Stuxnet.
By opening the world to the reality of Stuxnet, it is not surprising that suspicions are growing that aggressive nation states are attacking Critical National Infrastructure (CNI) sectors such as energy production.
Industrial control malware such as Industroyer is on the rise. Recent attacks such as WannaCry and Petya are using leaked NSA exploits to deliver ransomware. And though they are less sophisticated, they’re taking a Stuxnet style approach by getting into a system and then spreading through a network.
Defence against such threats requires a holistic, in-depth approach to security. Concerns over the security of a single SCADA system can no longer be dismissed with “It’s ok, that’s not connected to the Internet”. Companies need to look at their systems as a whole, train their staff comprehensively, patch their systems in a timely manner, and be able to monitor their systems and know how to respond.
The only proper response to such a threat is: plan for the worst, test your systems, and know how to respond.
Are you looking to improve your ICS security?
We know that ICS security is a growing concern and improving security should be a top priority. However, for many organisations there are a number of key issues that need to be addressed in order to start this process.
So, what issues are stopping you improving your ICS security?
