June seems to be historically rich in important events relating to the security of industrial systems.

For example, June 17th, 2010, may be considered the day that Stuxnet was discovered, the malware behind the very first cyberattack to target critical infrastructure, while in June 2014, there were reports of attacks against a number of companies using Havex, a remote access trojan that collects data from ISC/ SCADA (Industrial Control System/Supervisory Control and Data Acquisition) systems.

And, more recently, in June 2017, ESET published its analysis of Industroyer, another big threat to ICS systems.

Stuxnet: First ever and unequalled in complexity

Stuxnet was a computer worm that was discovered by the Belarus IT security company VirusBlokAda on June 17th 2010 (the day they dated their description of the malware – at the time under another name).

This malware had a key part in what is considered the most sophisticated cyberattack ever: an operation against the Iranian nuclear program. Despite several pitfalls in the attack and a few errors in the Stuxnet malware itself, the attack slowed down the process of enriching uranium at Natanz (a Iranian nuclear facility) and eventually delayed the process of creating nuclear weapons by Iran.

Stuxnet was the first discovered malware targeting industrial systems and the first to include a programmable logic controller rootkit – a stealth technique used in malware based on falsifying information about the presence of the code in order to hide itself. In Stuxnet’s case, it was able to camouflage its interference with motor rotational speed from monitoring systems.

The Stuxnet attack had several stages. In the first one, Stuxnet, itself a computer worm, indiscriminately spread across networks. Exploiting four previously unknown – so called zero-day – vulnerabilities, it delivered a specialized payload targeting specific SCADA systems, which was able to reprogram the devices.

It’s widely known that the Stuxnet operation damaged the centrifuges used in the uranium enrichment process by altering their rotor speed. Vibrations and distortions caused by large and sudden changes in their speed destroyed – according to published estimates – approximately 1,000 centrifuges. As Iranians were not able to replace them swiftly, they ended up producing less enriched uranium than they otherwise would.

Underestimated in the descriptions of the Stuxnet operation is another phase of the attack. Before the attackers resorted to altering the centrifuges’ speed, they had tried to damage their rotors through overpressure.

Gas centrifuges for uranium enrichment are extremely sensitive to process pressure. Normally, they operate under a near-vacuum pressure. Any increase lowers the enrichment efficiency, with bigger increases leading to changes in the process that puts higher mechanical stress on the rotor. The attackers leveraged this vulnerability, and the payload of this early Stuxnet variant took over control completely.

Acting as a man-in-the-middle, the attackers manipulated the process values inside the controller. As a result, the legitimate code runs based on fake input values to arrive at desired outcome: the pressure in the centrifuges was much higher than it should have been while the system reported standard values to its operators.

Why the damage was not as high as the attackers had hoped, making them design payload number two – the speed-altering one – is beyond the scope of this article. As for why the attackers gradually loosened their focus on staying under the radar and eventually let the malware evade the targeted environments – maybe we will never know.

Whether or not the Stuxnet operation was successful from a geopolitical point of view remains to be fully evaluated (given the fact that the details remain hidden in the secret services’ archives, such an evaluation must wait until their declassification).

From the cybersecurity point of view, Stuxnet was a breakthrough event that should have served as a wake up call for all those involved in security of industrial systems. As Ralph Langner wrote in his famous paper To Kill a Centrifuge: “While the attack was highly specific, attack tactics and technology are not; they are generic and can be used against other targets as well”.

Four years after Stuxnet: The Havex intelligence-gathering attacks

In June 2014, another malware designed to attack industrial systems was detected as attacking a number of companies in Europe. Manufacturers of industrial applications and machines in Europe and USA were targeted by Havex, a remote access trojan that collects data from ISC/SCADA systems.

The attack, which can be labeled as a watering hole attack, was apparently an attempt to harvest intelligence needed for further attacks on infrastructures built using hardware by the targeted manufacturers.

While no such subsequent attack was detected, the 2014 Havex attack reminds us that cybercriminals – whether state-sponsored (as apparently in the case of Stuxnet) or financially motivated – have tools and information available to attack industrial systems.

Seven years after Stuxnet: Power shut down by malware

On June 12th, 2017, ESET published its analysis of Industroyer, the biggest threat to industrial control systems since Stuxnet.

Industroyer was most probably the malware that shut down the power grid in Kiev, Ukraine’s capital, in December 2016. More importantly, Industroyer is the first ever malware capable of attacking power grids automatically (in comparison to BlackEnergy, which was also used to attack the Ukrainian power grid but the actual power outage had to be executed manually). With minor adjustments, it is capable of doing significant harm to electric power systems in the EMEA region and potentially in other parts of the world, including the USA. It could also be refitted to target other types of critical infrastructure like water or gas utilities or transportation control systems.

Industrial systems need protection

A full understanding of the Stuxnet-introduced methods (see our comprehensive whitepaper Stuxnet under the Microscrope for more details) is necessary for assessing the risks industrial systems are faced with. Their underlying technologies were not meant to be connected to the internet and were designed without appropriate security in mind.

Also, mitigation strategies that might work well in IT security – air gaps, anti-malware technologies or security patches – are a lot more difficult to deploy in these types of environments.

All that leaves us with a worrisome conclusion: the sophistication of these ICS-targeting threats combined with the skill level of their authors and/or operators stands in great contrast with the (in)security level of some areas of ICS infrastructure.