Shedding Light on BlackEnergy With Open Source Intelligence
March 3, 2016 • Zach Flom
If you’re like me, you don’t have access to the malware samples that infected the Ukrainian ICS (industrial control system) networks. You also don’t have packet captures or event logs to try to recreate the series of events that lead to over 200,000 people losing power in late December of last year.
What I do have, however, is access to a couple of open source intelligence tools and a penchant for nerding out over high-profile cyber events.
Chances are, if you’re reading this blog, you’re familiar with BlackEnergy and its spot in the limelight due to the recent attacks on Ukrainian infrastructure. For anyone just joining us, I’ve included a timeline illustrating BlackEnergy’s evolution from a “relatively simple” DDoS tool to the multi-capable APT tool it has grown into today.
In 2014, shortly after being picked up by APT groups and becoming more modular, we see a large spike in references to the malware and its increasing usage in European countries, namely Ukraine.
Coincidentally (or maybe not) this spike parallels the growing Russia-Ukraine political tensions of the time and brings us right up to the moment the community as a whole took notice: the power outage of December 23, 2015.
There is dissention among those reporting on the incident as to the exact role BlackEnergy had in the attack, the other malicious binaries involved, and, rightfully so, where attribution should lie. It is not my intention to provide the smoking gun that answers any of those points; but rather, offer a path other analysts can follow to build upon the information they do have and draw those conclusions for themselves.
Also, whatever the specifics of those questions may be, the implication remains the same: an unauthorized remote user can gain access to a critical infrastructure system and cause far reaching effects in the physical world.
Indicators of Compromise (IOC) Analysis
Shortly after the attack, the experts at ESET1 published an excellent article that provided the information used as the jump off point for my analysis. The article abounds with indicators for follow on analysis to include: build ids, command and control (C2) nodes, and hashes for every component from the macro-embedded XLS to the drivers for the malware it dropped. Chief among them (and the avenue that proved most valuable for supplemental intelligence) was the list of C2 nodes*.
In most cases, IP addresses are too fickle for any lasting intelligence to be garnered from them, especially when the analysis is days or weeks post-event. However, because the C2s were hard coded into the exploit, it can be assumed that information about these particular IPs has a little more staying power and is worth pursuing.
*It should be noted that BlackEnergy has been seen using binaries masquerading as legitimate system processes, so the hashes of the malicious executables are very important for mitigation and system integrity purposes.
Contrasting Mix of Hardcoded IPs and Tor Nodes
The first course of action was to see what kind of historical information I could surface. Recorded Future data shows five of the six IPs characterized as running Tor services and some appearing on block lists.
The combination of hardcoded IPs and Tor exit nodes seems almost counterintuitive. Perhaps the goal was to further the perception of volatility of the IP, or to obfuscate the real purpose of the C2.
“A subnet with only 32 IPs that is part of an attack is immediately more suspicious as a whole than one with 65,536 IPs.”
One IP (188.8.131.52) however, did not appear in Recorded Future data at all (previous to the ICS attack). A general Google search also yielded very little results, none meaningful. This got me curious as to the owner of the IP and the services it was setup to run. I took to DomainTools and Shodan for the answers to my questions.
DomainTools didn’t reveal much in the way of registrar information, but that was to be expected. They were leasing the address through a major German service provider. I did find two things interesting about the results though.
First, the unusually small subnet that the IP resided within. Usually we see malware beaconing back to an IP that is part of a large /16 or similar sized subnet to try and get lost in the noise. A subnet with only 32 IPs that is part of an attack is immediately more suspicious as a whole than one with 65,536 IPs. Queries for the other 31 IPs returned as few results as the first, but I would be wary of any traffic originating from that subnet.
The second thing of note is the static subdomain. Static subdomains are used to reliably serve static content to other hosts on a network. Another useful characteristic of static subdomains is that they can be hosted on content delivery networks (CDN) such as CloudFlare or BitTorrent, providing high performance and availability of content. Although not malicious in and of itself, we have seen many examples of malware using this practice in the past.
Now I wanted to find out what services were running on this box, so I utilized Shodan (a tool used to fingerprint Internet-connected devices). Shodan revealed that the node was running OpenSSH on a Debian platform.
According to the ESET article, a previously unknown backdoor in the DropbearSSH protocol was utilized. This box may have been used for development and testing of the exploit. We were also able to gain insight into the structure of the network, which technologies and software versions were present, and possibly what types of files we could expect to be hosted on the machine.
I followed the same workflow for the other command and control nodes listed in the article. The registrar information once again didn’t give me much, although we do see another /27 subnet and static subdomain (184.108.40.206). Two of the five remaining IPs were running HTTP and HTTPS (80 and 443) when I fingerprinted them (220.127.116.11 and 18.104.22.168). Two were not responding (22.214.171.124 and 126.96.36.199). The last host (188.8.131.52) however, was interesting.
184.108.40.206 had several open ports for remote administration services including: NetBIOS (135, 137, 139, and 445), Microsoft RDP for virtual machines (2179), WS-Management and Powershell (5985), multiple ephemeral ports, and most notably port 2223. Port 2223 is the assigned port for the protocol “Rockwell CSP2”, which is the client/server protocol used by Rockwell Automation for their ICS devices.
It’s possible this host was used to test the exploits used for, or issue commands to, the compromised ICS devices. If neither were the case, and no devices running Rockwell CSP were involved, it is still at least noteworthy that the host was listening on that port, especially given the modular nature of the malware.
While an analysis of the attack details is fun and interesting, it won’t change the important implications we can draw from this case, namely:
- Whether or not the attack was nation state sponsored, the source code for most of the components that were used is available for purchase and download on the open Web.
- It’s no longer far fetched that a similar attack could be conducted by non-nation state sponsored groups for criminal purposes.
- Whatever the events subsequent to the malware being utilized, it was still a method decades old that won the day and enabled the infection: spear phishing.
- User education and, given the ability to erase data with the KillDisk component, data backup and offsite storage practices are still crucial.
- This is yet another proof of concept that malware can have tangible effects beyond the cyber landscape.
Mitigation and Other Interesting Finds
The open source community is not only fantastic for gathering information about a malware event; it’s also a great resource for finding ways to mitigate that malware. Running a simple search in Recorded Future we can quickly uncover a YARA rule that was created shortly after the attack (January 4, 2016) and also one in mid February designed to catch the KillDisk component.
Applying the same process to historical indicators of compromise attributed to the BlackEnergy malware surfaced a few other notable finds. Among a myriad of hostnames, registrars, and services running, two stood out:
220.127.116.11 which was running a Cisco PIX firewall, secure mail services, and whose hostname resolved to mail1.mil.ru.
And 18.104.22.168 which aside from HTTP, DNS, and SSH server ports open, was set up to receive traffic on port 2222, another port assigned to handle Rockwell CSP traffic (among other services such as EtherNetI/IP I/O).
What You Should Do
As an analyst with a background rooted in network defense, these findings would prompt me to implement and reiterate multiple core concepts:
- End-user education remains paramount to the prevention of unauthorized access to your networks.
- Disallow emails with embedded macros entirely.
- Know what your network is supposed to look like and the processes running on it.
- Conduct regular audits to ensure the integrity of those processes.
- Utilize IP and port whitelisting and blacklisting.
- Adhere to data redundancy and offsite storage best practices.
- And finally, continue to monitor the open Web for new developments and stay abreast of mitigations for any changes in the malware.
1 ESET is an IT security company headquartered in Bratislava, Slovakia that was founded in 1992.