While there have been numerous high profile cyberattacks on industry over the past few years, their consequences have primarily been to steal information (Dragonfly, Flame, Duqu) or interrupt business operations (Shamoon). Stuxnet and the attack on the German steel mill were rare cases where a control system was disrupted as a result of a malware infection.

That is, up until the end of last year. On December 23, 2015 a significant power outage occurred in the Western area of Ukraine including the regional capital of Ivano-Frankivsk. Up to 700,000 homes went without electricity for three to six hours. Malware known as BlackEnergy was a component of the attack, though whether it was a causal element or not is still being investigated and discussed (more on this later).

This may be a unique case where a hacking incident involving an industrial control system has affected ordinary citizens. As such, it is important to understand the Ukrainian incident and what it means for SCADA and ICS security. Let’s review the outage and see what lessons it provides for operators of critical infrastructure systems.

Cyberattack-on-Urkaine-Causes-Power-Outage-in-Ivano-FrankivskThe city of Ivano-Frankivst in Western Ukraine had a power outage on Dec 23, 2015 related to a hacking attack on its regional power distribution companies.

What Happened at Ukrainian Electric Utilities?

On December 23, 2015 power went out for a high number of customers (reports range from 80,000 customers to 700,000 homes) in the Western region of the Ukraine that is served by regional power distribution companies. These companies are supplied by thermal power generation stations (the Ukraine also has a large amount of power generated from nuclear facilities, though not in this region).

One of the companies indicated in emails to customers that power was disrupted at 15:30 local time and was fully restored at 18:56 local time.

Reports about the incident in local media were picked up by the international community by the end of the year and analysis and discussion amongst Western industrial cyber security interest groups began. While that discussion is ongoing, a picture has become clear that a coordinated attack involving multiple components took place.

Here are the components of the attack, as they are known today:

1. BlackEnergy Malware Infects Utility Company’s’ Computer Networks

BlackEnergy (also known as DarkEnergy) is malware that has existed since 2008 and its modular components have morphed over time. In this incident, the third variant of BlackEnergy is believed to be a key vector that provided the attackers with access to the utilities’ computer networks and the ability to remotely communicate with them. (This compromise and the resulting remote communications were probably NOT within the ICS networks.)

One BlackEnergy component, known as KillDisk, has a wiping functionality that may have denied the use of the SCADA system, delayed restoration and covered the perpetrators’ tracks. The actual hosts affected by KillDisk have yet to be disclosed.

2. Utility Company Phone Systems are Overloaded

An attack on phone systems, possibly a Denial of Service (DoS) attack, prevented the utilities from receiving calls from customers reporting outages.

3. Power Services Are Disrupted

The electricity went out and was restored the same day by field staff manually reclosing breakers at affected substations. The speed of the recovery was impressive. The fact that field staff performed manual actions at this point should not be construed as an indication of ICS compromise, but rather that the Ukraine power transmission and distribution networks are not completely automated for remote management.

The actual cause of the power outage is being debated. On Jan 9, SANS stated:

“After analyzing the information that has been made available by affected power companies, researchers, and the media it is clear that cyberattacks were directly responsible for power outages in Ukraine.”

Later in the same article SANS states:

“We assess currently that the malware allowed the attackers to gain a foothold at the targeted utilities, open up command and control, and facilitate the planning of an attack by providing access to the network and necessary information. The malware also appears to have been used to wipe files in an attempt to deny the use of the SCADA system for the purposes of restoration to amplify the effects of the attack and possibly to delay restoration.”

SANS’ belief on Jan. 9 seemed to be that the role of the cyberattack was to provide network access that resulted in the power outage. [Jan 28 End of Text Revision]

New call-to-actionIs Malware Really the Cause of the Ukrainian Power Outages?

ICS security expert Joel Langill has a different perspective:

It is technically possible, but highly improbable, that the BlackEnergy3 malware was used as the direct cyber threat that led to any denial of service or other consequences to the industrial control systems associated with the Ukrainian power systems.

I do believe however, that other unrelated cyber events such as communication buffer overflows, network issues, and potential software bugs were in fact key factors that led to the inability of the industrial control system to perform as intended, resulting in the widespread outage.

A report by the Energy Industry Research Center describes the Ukrainian electrical utility infrastructure as a ‘… rather old network, thus having a need to renovate.’ This leads me to believe that the primary attack vector was most likely against networks and not end-devices. Networks are not typically the primary objective when using BlackEnergy malware.

It is unlikely that these organizations could have restored key ICS/SCADA components and stabilized the power generation facilities in such a short period of time if there was either a storage media erasure or installation of malware and rootkits. This signifies that the attack most likely did not actually penetrate the ICS architectures. This is not to say that BlackEnergy malware was not found within the ICS, as reports have in fact confirmed this, but rather that BlackEnergy was not responsible for disruption of normal ICS functions.

It is reasonable for one to confuse the fact that even though a particular company may have been breached by a cyber threat; the ICS architecture, networks, and components could have been completely isolated from the event and all components unaffected. This was in fact the case with Dragonfly and Shamoon.

The misinterpretation of data that we see in many open sourced incident reports is not uncommon. If we recall the sequence of events during the Dragonfly campaign of 2014, malware was in fact found within a very small number of energy organizations. It was never actually found in the industrial system components and networks of these organizations during the ICS phase of the attack.

What Does This Incident Mean for ICS and SCADA Security?

Whether you work for a utility or not, this attack raises alarm bells that we hope will cause you to review your cyber defenses, systems and processes.

If your organization has not already done so, you should check your business and industrial networks for BlackEnergy using an incident response tool such as Yara.

Then think about your ability to know what is normal for your network so you can rapidly detect abnormalities. This includes monitoring and logging communications that occur between industrial networks and external (office) / public (Internet) networks. In the Dragonfly malware campaign, for example, simply blocking outgoing unauthorized http traffic originating from the industrial control network would have mitigated the impact of the attack.

When was the last time you reviewed, updated and rehearsed your incident response plan (IRP)? You do have a site-specific IRP in place, don’t you? In the case of the Ukraine disruptions, the speed with which the affected utilities re-energized their systems was notable. Especially since their call centers and SCADA systems were offline or not visible. Could your organization react as quickly in similar circumstances? Do you have a solid understanding of how you could “disconnect” or “isolate” some or all of your industrial networks and maintain plant operation?

While you’re at it, when was the last time you updated your risk assessments? Should you be including threats from Offense in Depth coordinated attacks with cyber and physical components? How well are your critical systems protected from insiders or someone posing as a trusted individual using stolen assets?

What is the current state of your cyber defenses? Are you following up-to-date best practice policies and industrially focused security technologies? 

For your benefit, below is a sample of recommend best practices. Download the white papers offered with this article and review the resources listed in the Related Links section for more information.

Effective-ICS-Security-DefensesTable 1 – Partial list of effective defenses against Offense in Depth malware campaigns. Download the white paper Defending Against the Dragonfly Cyber Security Attacks for a more detailed list.

In short, even if you’re not working for a utility, this event is a good opportunity to stand back and assess your cyber security defenses and processes.   For critical infrastructure providers, it’s vitally important to keep following the analyses of the Ukrainian power outage and learn the lessons it teaches us.

What are your thoughts on the Ukraine power outage? Does its occurrence impact your security strategy?

Joel-Langill-Security-Expert   

Joel Langill | @SCADAhacker    

Joel Langill is an independent security researcher, consultant, educator  and creator of the website SCADAhacker.com.

 

He approaches cyber security in a fashion similar to industrial functional safety and his services help companies improve the security and reliability of their automation and SCADA systems. His successful book “Industrial Network Security – 2nd ed” provides a comprehensive look at ICS security.

Related Links

Ukraine Power Outage Security Incident

Cyber Security Resources

Belden / Tripwire Products for ICS Security