How hackers exploit critical infrastructure

The traditional focus of most hackers has been on software, but the historical focus of crime is on anything of value. It should come as no surprise, therefore, that as operational technology (OT) and industrial control system (ICS) infrastructure have become much more prominent components of national critical infrastructure, that malicious hacking activity would be increasingly targeted in this direction.

It also stands to reason that the salient aspects of hacking – namely, remote access, automated tools, and weak attribution – would extend naturally to malicious targeting of critical OT/ICS infrastructure. These attributes are particularly attractive in this context, because criminals interested in disrupting factories, production systems, and other tangible infrastructure, previously had to establish physical presence or compromise some group with local access.

The new approach to OT/ICS hacking involves a combination of traditional techniques with domain expertise of the systems being targeted – although little expertise might be required to trigger damage to an ICS/OT system. The most powerful issue here is the ability for attackers to target tangible systems such as power plants and refineries, without having to step foot into the local facility. This is a major departure from historic norms.

It is instructive to review the details of some previous OT/ICS attacks with emphasis on how malicious actors adapted familiar hacking methods with the specifics of the targeted ICS system. In the sections below, we examine two of the more well-known example hacks that have occurred in the past few years – namely, the Stuxnet worm of 2010 and the Ukrainian Power attack of 2015.

Stuxnet attack

Stuxnet consisted of worm functionality operating in the upper layers of the Purdue Model that was designed to locate and attack OT resources in the lower layers. Specifically, the worm was propagated by unknowing humans with malware-infected USB sticks transported and used across critical infrastructure sites. Once resident on a Windows computer, the worm searched for the presence of Siemens control-system software used to control electromechanical devices.

If the Stuxnet search on a given Windows machine located the desired Siemens control software, the toolkit would propagate throughout all of the computers in the Siemens control system, through firewalls and across IP networks. When the Stuxnet malware found the responsible computers, then a powerful rootkit was downloaded into what is known as a programmable logic controller (PLC), as found in Layer 1 of the Purdue Model. PLCs control many types of physical systems.

While many questions remain as to the origin of the attack, the security community generally agrees that Stuxnet was developed to target gas centrifuges in Iran’s uranium enrichment facilities. The consensus opinion is that the worm used its rootkit payload to send special destructive commands to Iran’s enrichment infrastructure as an alternative to conventional forms of attack. The attack forced changes in the rotor speed of the gas centrifuges to cause permanent damage to these devices – all done remotely.

Stuxnet attack progression

Understanding how Stuxnet might have been prevented offers useful hints about OT/ICS security. First, one would likely point fingers at the Microsoft and Siemens software, both of which provided a friendly environment for the USB worm. Four zero-day vulnerabilities in Microsoft Windows, for example, were used to infect target systems. So, it is reasonable to recognize the impact of platform vulnerabilities as a root cause in present and future OT/ICS attacks. This is not a problem that will ever go away – all software has defects, and some of those defects are vulnerabilities, known and unknown.

Second, one would recognize the ease with which the worm was able to propagate from higher levels of the architecture to lower levels. This suggests that OT/IT interfaces require at least the same levels of gateway protection one finds in a typical enterprise gateway. This implies that the lower layers of the Purdue Model should not implicitly trust software operating at the higher levels.

This is easier said than done, but the way, because the worm demonstrated the functional ability to automatically jump through firewalls across encrypted, authenticated connections. Imposing new cyber security requirements such as two-factor authentication between processes communicating across the OT/IT interface would have done little to slow down Stuxnet.

Ukrainian power hack

In December of 2015, hackers compromised electric power distribution to citizens of Ukraine. Three energy companies – all with names too long to repeat here – were targeted and the bottom line is frightening: Nearly a quarter of a million people had no electricity for several hours. The origin and motivation of the attack have been debated, but would seem less relevant than the question of how to prevent such a thing from occurring in the future.

Analysis of the attack reveals use of a multitude of different SCADA cyberattack methods including the following components:

• Trojan Malware – Advanced Windows-executable malware called BlackEnergy was identified, but was not implicated in the outage. Instead, standard hacktivist remote control methods were most likely used.
• Spear Phishing – Attackers used email spear phishing with spoofed sender identity (Ukrainian Parliament) and malicious attachments.
• Remote Control – The attack resulted in remote operation of power company substation equipment and systems.
• Destructive Action – The KillDisk utility delivered as part of the attack destroyed files on substation servers and devices.
• Denial of Service – Power company customer support centers experienced DDOS attacks to degrade their ability to provide service to affected customers.

This coordinated attack suggests that the IT/OT interface for these Ukrainian power companies was largely unprotected. Each of the components in the attack are well-known to the cyber defense community, and while no cyberattack risk can be reduced to zero in any case, the protections here seemed much too ineffective for users and systems in an electric power grid environment.

Perhaps the greatest lesson from the Ukrainian attack is that critical infrastructure providers must develop and maintain higher cyber security standards than purveyors of more mundane systems and services. The idea that such an extensive collection of attacks might be successfully engaged with these companies should sound alarms across the entire industry segment – and this includes power companies in larger countries such as the United States.

A basic notion that such companies might consider involves separation enclaves around power substation or related functions. This might be best accomplished using separate physical communications infrastructures. These separate physical enclaves would also benefit from powerful gateway solutions implementing unidirectional communications flow. This would ensure that hacks to the IT portion of a power company would not cascade to OT substations.

IT/OT substation protection using advanced separation technology

Regardless of the specific types of cyber security technologies being used, the idea that substations might be separated into physically discrete domains across power company infrastructure provides powerful protection against the types of cascading attacks so commonly found in advanced attacks, especially from nation-state actors.

Lessons for OT/ICS security

Designers and operators of OT/ICS infrastructure should recognize that incidents such as the Stuxnet worm and the Ukrainian Power Company attack offer clear hints as to the best security solutions for the sector. First, it should be clear that standard IT-based cyberattacks can and will be launched at their OT systems. This suggests that a role will exist for traditional security vendors who can adapt their approaches to work across OT/IT interfaces.

Second, they must recognize that exploitable ICS vulnerabilities will always exist in OT infrastructure, and that malware is being designed to specifically target these weaknesses. It is no longer an acceptable security solution to simply presume that because technology differences might exist between IT and OT-based systems, that cyberattacks will not cross the boundary. Recent evidence clearly suggests the contrary.

Finally, these recent attacks suggest that this presumed technology gap between IT and OT systems is certainly shrinking. The idea that malware might seek, find, and destroy SCADA capabilities in a worm launched using conventional IT social engineering (e.g., dropping memory sticks in parking lots) should create chilling prospects for OT/ICS security engineers. Let’s hope the community pays attention and takes protective action immediately.

Articles in this series

• Article One Provides an overview of the OT landscape, including an outline of the influential Purdue model
• Article Two offers an insight into how hackers have had success to date breaking into operational systems
• Article Three outlines the SCADA vulnerabilities associated with typical industrial control system architectures
• Article Four covers how innovations such as unidirectional gateways can be used to separate industrial networks from Internet-exposed IT networks
• Article Five provides a glimpse into the future of OT and SCADA systems in critical infrastructure.

The insights offered in these articles are intended to provide guidance for both traditional IT security experts, as well as OT engineers who might be new to cyber protection solutions. The optimal staff arrangement in any OT/ICS environment would optimize the OT experience and expertise of the engineers with the cyber security insights of the traditional enterprise IT security expert. These articles are intended to help both types of expert.

Contributing author: Andrew Ginter, Vice President of Industrial Security at Waterfall Security.