The Burshtyn TES power plant in Ivano-Frankivsk Oblast, Ukraine. It’s not clear if Burshtyn was affected, but power outages did affect the grid in the Ivano-Frankivsk Oblast region. Image: Raimond Spekking/Wikimedia Commons
On December 23, a Ukrainian power company announced that a section of the country had gone dark. This temporary outage was not the result of purely physical sabotage—like the case a month earlier where explosives had knocked out power lines to Crimea—but instead, according to Ukrainian officials, was due to a cyberattack.
The country’s SBU security service immediately castigated Russia for the outage, according to Reuters, and Ukraine started an official investigation into what exactly happened.
Over the past few days, more details around the attack have emerged, including an apparent sample of malware found in a network of the regional control center. If that malware was indeed responsible for causing a blackout throughout parts of Ukraine, it would be a signal that industrial control systems (ICS), and in particular electric grids, really are under threat from cyberattacks, something that researchers have been warning for years.
“It was easily recoverable, but obviously it’s a bad thing for the power to go out”
Around a week after the attack announcement, Robert M. Lee, a former US Air Force cyber warfare operations officer as well as the founder and CEO of Dragos Security, wrote on the SANS ICS Security Blog that his team had obtained a sample of the malware found within the affected network.
“The fact that malware was recovered from the network at all, and the fact that it’s newer, gives a high confidence assessment that the cyberattack on Ukraine was legitimate,” Lee told Motherboard in a phone interview. Lee said the malware was “unique,” implying that it likely wasn’t something that just happened be on the grid network during the outage.
“The malware is a 32 bit Windows executable and is modular in nature indicating that this is a module of a more complex piece of malware,” Lee wrote in his blog post, who passed the sample over to Kyle Wilhoit, a senior threat researcher at cybersecurity company Trend Micro. Wilhoit said that the malware had a wiping function that would impact the targeted system.
“The resolution of APIs that are not used elsewhere in the code probably means that some of the code was borrowed from another program,” wrote Jake Williams, founder of Rendition Security and a SANS instructor, to whom Lee also provided the malware. Williams added that the malware appears to have a code “base,” on which modules are then added.
Other pieces of malware have targeted industrial systems in the past: “Havex” has infected technology commonly used in process control systems, such as water pumps and turbines; and “BlackEnergy,” which has been used in straight-up cybercriminal campaigns, has also been used to hit energy engineering facilities.
An Associated Press investigation published in December last year found that “sophisticated foreign hackers” had gained enough access to control power plant networks around a dozen times in the last decade. More broadly, the Wall Street Journal recently revealed that Iranian hackers had breached a New York dam in 2013. At the latest Chaos Communication Congress, a security, politics and art conference in Hamburg, Germany, researchers warned of the serious vulnerabilities in automated railroad systems. All of those require varying degrees of sophistication, with some of them needing expert knowledge of the target network’s protocols and idiosyncrasies.
After Lee’s post, more researchers published their own findings. Analysts from ESET claimed that the malware found in Ukraine was actually the BlackEnergy malware. Others went a step further, and wrote that BlackEnergy has been found within other Ukrainian power companies during the week of Christmas last year.
One group that has made heavy use of the BlackEnergy malware, and has previously targeted power facilities and other ICS, is alleged Russian hacking group Sandworm. It would be easy to assume that, because of the target and presence of supposed BlackEnergy malware, that Sandworm was behind the attack.
But that’s a logical leap too far, at least with the currently available evidence.
“The BlackEnergy malware has been in existence since 2007 and lots of different actors have used it,” Lee told Motherboard.
“People are saying that this piece of malware is linked to BlackEnergy. I can buy that, and there is some good analysis to say that is likely true,” he added. “But just because the BlackEnergy malware was used, does not mean that it’s linked at all” to Sandworm.
Irrespective of who committed the attack, what appears to have happened is that hackers “caused a power outage that was temporary in nature. It was easily recoverable, but obviously it’s a bad thing for the power to go out,” Lee said. “It’s not trivial—it still takes getting on the system and exploiting all that—but it’s not hard.”
One possible explanation is that the attackers may have remotely accessed a digital control panel located within the control center’s system. Other researchers have pointed towards the data wiping feature of the malware; presumably, wiping out vital data could have a negative impact on the electric grid’s systems. At this point, both of those theories are largely speculative.
But while either of those approaches are relatively easy for a hacker to carry out, attacks that would cause much more impact—that lasted for say, weeks or months—are much less likely to occur.
“Taking down the power grid, or cascading failures, or weeks of impact: that is incredibly hard. People have oversold how easy that is to achieve,” Lee added.
Although experts say it is likely that the power outage in Ukraine was caused by an cyberattack, there are still plenty of questions to be answered. More news is sure to follow in the coming days or weeks, as several research teams now have access to the malware sample.
Correction 1/4/16: This story originally referred to systems being compromised in a power plant or plants on the affected grid. As Michael Toecker pointed out, local sources report it was a regional control center that was affected.
The SANS ICS team recently gained access to a sample of malware that came from the network of the Ukrainian site targeted in the cyber attack that led to a power outage. I want to offer a few caveats to this blog post up front.
- First, this is all developing and the next few days and weeks will add clarity to the situation.
- Second, with this type of analysis there’s not much that can be definitively stated in terms of attribution or impact. Take everything here as informative only.
- Third, SANS ICS is not in the business of releasing highly detailed technical analysis of malware. The purpose of this blog is to focus on lessons learned and education for the community. Therefore, I am not going to be sharing the hash of the sample we have but instead talking about the takeaways. There are at least 3 major cybersecurity and threat intelligence vendors I am aware of that have the sample and will be releasing detailed analyses. I do not want us at SANS ICS to impede that by releasing the sample to the wider community right now. However, to any of the major players and researchers that want a sample feel free to reach out to us via the SANS ICS Alumni email distribution and we will provide it to verified sources.
Here I’ll detail the facts, speculation, and takeaways for the community.
The SANS ICS team has been researching the cyber attack on the Ukrainian power grid since the event occurred with a mix of interest and a critical viewpoint. The interest was due to the seriousness of the event and the critical viewpoint was taken because while threats are active against ICS there are often otherwise good case-studies that get spun out of control by the media. The idea of a cyber attack on infrastructure that leads to an impact to operations is very serious in nature and must be handled with care, especially when there is geopolitical tension in an area such as Ukraine.
Through trusted contacts in the communitythe SANS ICS team came across a lot of amplifying information about the attack, how it could have occurred, and the seriousness of this incident to the Ukrainian government and the focus they are putting on the investigation that increases the credibility of their reporting. The SANS ICS team was also passed a sample of malware from trusted sources taken from the impacted network by responders in country.
The hash for the malware can also be found on VirusTotal where a user in Ukraine submitted the sample on the 23rd of December. The timing and unique nature of the sample adds some credibility to the sources that collected and passed us the sample of the malware.
The malware is a 32 bit Windows executable and is modular in nature indicating that this is a module of a more complex piece of malware. I passed the malware sample to Kyle Wilhoit, a Senior Threat Researcher at Trend Micro who has done great work in the ICS community before, who confirmed through static analysis that the malware itself has a wiping routine that would impact the infected system. After that I passed the sample to Jake Williams, founder of Rendition Security and a fellow SANS Instructor, who has been analyzing this incident as well for further support. Below is his analysis:
Note that this analysis is based on an extremely limited static analysis of the malware and further analysis may impact these findings. The code appears modular in nature. The attackers take steps to obscure some notable suspicious APIs (e.g. OpenSCManager) from the imports table, but not others (e.g. CreateToolhelp32Snapshot). The string “obfuscation” method is crude and obvious upon manual examination, but effective to thwart string matching. Any of these hyphen separated strings would make an excellent Yara rule.
Notably, the malware does not appear to use all of the functions it imports. Specifically, there are no cross references to service related calls. While this may be due to dynamic call targets, there are significant numbers of cross references to other dynamically resolved APIs (e.g. RegDeleteKey).
The resolution of APIs that are not used elsewhere in the code probably means that some of the code was borrowed from another program. This hints at a development shop with a code base from which to piece modules together. Although the string obfuscation was crude, it was sufficient for the task. The crude string obfuscation should not be taken as an indication that the attacks came from a non-state actor.
Another possible interesting note is the compile timestamp of the executable. It is set to January 6, 1999.
This was likely modified by the attackers, but whether this date is significant in historical context is unknown at this time. It may simply be a random modification.
There are at least 3 major cybersecurity vendors working on the piece of malware right now in their own analysis and I will simply state that I’m impressed with the quality of work from them I have seen so far. Additionally, folks at the ICS-CERT and E-ISAC are doing great analysis as well and will likely be pushing out information through government sharing channels soon. Simply put, a lot will be known about this in the community soon to further support the analysis or help move on to a better understanding.
It is not currently possible right now to state that the malware recovered caused the loss of power in Ukraine. Additionally, the wiping functionality of the module recovered is likely for the purposes of cleanup after the attack; it itself does not appear to have been capable of causing the outage. This is important to note as the wiping capability is not similar in nature to the Shamoon attack but instead an anti-forensics technique.
Also, it is possible that the incident caused responders to look at the network where they found the malware. The malware could be new and yet not be related to the incident. At this time I believe the malware is related to the incident though from analysis by the SANS ICS team and others around the community but this should be categorized as a low-confidence assessment currently.
There has also been speculation that the malware is related to, and potentially a module for, BlackEnergy2. The previous statement should not be taken as a standalone soundbite. There is very little to support this conclusion right now. If true though this would add credibility to Ukraine’s SBU who reported that the malware was launched by Russian security services. Because of the sources concluding the BlackEnergy2 connection I feel it is important to share the (potentially overstated) speculation with the community as there were many organizations around the global community who were impacted by that campaign. Just because a campaign is reported on publicly does not mean it is no longer active. Security personnel in ICS organizations should be actively looking for threats — the Ukrainian incident should not be seen as an incident that only impacts one site in a foreign country although no panic or alarm should be taken, only due diligence towards defense.
- There is a lot of great analysis going on in the community by a number of companies, government organizations, and individual researchers. Each have been contributing some unique aspects to the analysis. Defenders must always work together like this and build off of each other’s strengths. Information sharing in this manner is critical to security.
- The Ukrainian power outage is more likely to have been caused by a cyber attack than previously thought. Early reporting was not conclusive but a sample of malware taken from the network bolsters the claims. The unique nature of the malware indicate some level of targeting may be possible but much more information is needed to confirm that targeting of ICS or this specific facility was intended.
- If the malware does end up being related to the BlackEnergy2 campaign then this adds to the possibility that the facility and ICS was specifically targeted
- Technical data alone is very rarely enough to conclude the intention of an adversary
- ICS facilities around the world need to take an active defense approach to monitoring ICS networks and responding to threats. Additionally, each should have an ability, or at least contacts to request help from, to perform basic threat and malware analysis to know when to reach out for help to the larger community (my one plug: the identification of, response to, and analysis of threats is the type of skill set we teach in SANS ICS515 and I would encourage organizations to find this or similar type of training for security personnel onsite. Firewalls and boxes on the network alone will not protect an ICS fully).
This incident is an important case-study for the ICS community. If the analysis and follow on information is validated about the malware and attack then this will also be a significant event for the international community. The precedence that this event sets is far reaching past the security community and will need to be analyzed and understood fully. The response by countries to this type of attack and any attribution obtained will also be significant in establishing the precedence of these types of events moving forward in the international community.
Credit: sans, motherboard