As we come to the start of the new decade, lets look back at one of the single biggest events in Operational Technology (OT) / Industrial Control Systems (ICS) security of the last ten years – Stuxnet. Stuxnet is credited with being one of the first custom pieces of malware to target very specific conditions within operational environments, with the aim of altering the running processes.
Haven’t we come a long way as a community since 2010? OT and ICS security has gone from relative obscurity, to a main presence at international security conferences worldwide.
Understanding (or at the very least appreciating) Stuxnet, how it operated and what it did, helps to provide context to the nuances, and significance of OT and ICS security – and provide insight into how we will need to keep developing our approach to security in these environments.
The most complex malware written
In 2010 a highly complex piece of malware was discovered by researchers; believed to be the first pieces of custom malware used in a targeted attack against an Operational Technology environment – Stuxnet.
There are a lot of misconceptions and sensationalism around Stuxnet. The actual way the Stuxnet attack played out is more fascinating than the stories, due to the way the malware navigated the networks, targeted a key procedure, and caused the mechanical process to subtly undermine and erode itself.
To date the Stuxnet malware is considered to be one of the most complex ever developed. The malware’s target was the Iranian refinement facility in Natanz, with the objective of causing physical damage to the centrifuges at the heart of the facility.
The Iranian government have never released any information on the attack. However, experts have speculated that the malware damaged up-wards of 1,000 centrifuges and was responsible for reducing the operational capacity of the facility by 30%.
Key takeaways from Stuxnet:
- You cannot stop a motivated, well-funded attacker – you can only slow them down.
- Critical National Infrastructure are more widely connected than you think to outside networks – air gapping isn’t security and doesn’t exist.
- An attack doesn’t need to be verbose to be effective. Small changes made in operational environments can have a significant impact.
- We are overly reliant on the role of automation, and don’t always know what is actually happening in our operational environments.
500KB that changed the world
The Stuxnet malware is still considered by many to be one of the most complex pieces of malware creased, and at just over 500kb. Although exact attribution has never been achieved, the complexity of the malware and the resources required to develop this capability, as well as the political nature of the target, lead many to believe that this attack was perpetuated by a nation stage actor.
The ultimate goal of the attack was to alter the Programmable Logic Controllers (PLC) governing the rotational speed of the centrifuges, in order to cause damage to them, and impact the refinement process at the site.
Below is an image (courtesy of IEEE) that nicely represents the process behind the attack
Infiltration
The malware is believed to have been introduced to the Natanz facility network through an infected USB device in the first instance. To facilitate movement through the network, as well as to avoid detection, the Stuxnet malware contained a number of “zero day” exploits, stolen certificates, as well as default access credentials. This allowed the malware to spread through the network without drawing attention to itself.
Navigating the network
Operational Environments are often heavily segregated from the enterprise system, to provide a level of security. To get around this, the malware replicated itself to systems, and removable media to propagate further into the facilities networks. If after a number of hops the malware had not reached its ultimate target (The controlling PLCs), it would cease propagating to avoid triggering security controls.
A unique feature of the malware was its ability to communicate back to its command and control servers, even without direct internet access. The malware communicated through computers it had already compromised on the network, finding a route to the internet and passing information back to, and allowing the attackers to modify their code even within the facility.
Targeting
The malware was specifically targeting the Siemens s7-300 PLC, controlling specific physical assets that maintained and monitored the rotation of the centrifuges. To ensure that the malware reached its intended target but didn’t draw attention to its presence on the network, the malware would spread to three machines before deleting itself from the infected USB or initial machine
The attack
Once both the hardware and the operating conditions were identified, the malware inserted malicious function blocks into the targeted PLC. The purpose of this function block was to increase the spin rate of the centrifuges at pre-determined times, effectively causing components to fail and the centrifuges to destroy themselves over time.
The changes made by this maliciously introduced function were extremely minute. The change increased the centrifuges’ spin rate to Hz for 15 minutes, followed by the centrifuges being slowed down for 50 minutes. After this period, they returned to normal operations while the malicious code remained dormant for 27 days. This alteration over a sustained period of time was able to enough physical damage to the centrifuges that they had to be continuously replaced.
Covering tracks
To avoid raising suspicion amongst the operators, the malware spoofed signals back to the operators, to mask the actual actions of the centrifuges. So, while the centrifuges were being slowed down and sped up, the operators were shown normal rotational speed on their displays. This technique is commonly referred to as a “Man in the middle” (MITM) attack. The attacker is able to modify the data being sent to the operator, providing false information.
The cyber fallout
Before the Stuxnet attack, operational environments, and CNI systems, were believed to be effectively isolated, disconnected, and obscure enough to be shielded from the attention of cyber-attacks.
Whilst the attack had a direct impact on the operations of the Iranian nuclear refinement facility, Stuxnet has been credited with showcasing the ability for cyber based attacks to have a direct impact upon physical systems and processes.
The real impact of the Stuxnet attack is slightly mundane compared to popular perceptions of the attack. Stuxnet did not result in explosions at the facility, nor was it a quick process. The attack took significant time and resources to develop and deploy. The impact was to slowly cause damage to over 1000 centrifuges at the nuclear facility in Natanz by adjusting the manner they operated marginally. No explanation was offered for the operational shut down, but it is suspected that this was to review the controls and systems affected following the discovery of the malware.
The malware was discovered when it started to spread out from the targeted facility, and researchers discovered it. No explanation has been given to why changes were made to the malwares code to cause this breakout affect.
What did it teach us?
Stuxnet showed us that there are organisations, groups, and nations that are actively developing capabilities to disrupt critical national infrastructures. The age of security through obscurity is well and truly over.
After Stuxnet became publicly available, the malware was reverse engineered and re-purposed. This has provided the platform for copycat attacks, and the blueprint for future attacks and targeted engagements. It doesn’t take long for a nation state cyber weapon, to become a tool for anyone with internet access to get.
Simply, Stuxnet showed the world that the Critical National Infrastructure networks we all depend on are more vulnerable than we originally believed. Whether this incident was caused by mis-configuration, accidental infection, or targeted attack, it brought a sense of urgency to the global ICS and OT communities, and arguably provided the catalyst for the developments, and approaches that we use today to secure these critical environments.
Want to find out more…..
If you’d like to find out more about our experience in the design, development and deployment of devices, simply click on the link below.