Posted
A look into BlackEnergy malware and using ThreatConnect to aggregate and memorialize the identified intelligence.
As workers prepared to head home on December 23, 2015, an attack against Ukraine’s energy sector left 230,000 without electricity (or heat) for six hours. The attackers demonstrated a variety of capabilities, including spearphishing emails and variants of the BlackEnergy 3 malware to gain a foothold into the Information Technology (IT) networks of the electricity companies. The December 2015 incident was the first known instance where a cyber attack disrupted electric grid operations. And BlackEnergy 3 malware was key to enabling it.
This blog post will:
- Examine how we used the ThreatConnect platform as part of the intelligence cycle when reviewing the BlackEnergy malware.
- Review the BlackEnergy malware, related incidents, and methods for gathering indicators related to the malware.
- Discuss how researchers can use ThreatConnect to sort through and pull these indicators together.
This graphic captures how we incorporated ThreatConnect into the intelligence cycle to aggregate and memorialize intelligence on BlackEnergy. We started off by identifying background information on BlackEnergy and the actors behind it, which ultimately drove our later research efforts.
Planning and Direction – BlackEnergy Background
Since it was first found in the wild in 2007, the BlackEnergy malware family has grown to include three variants, the third of which was used in the Ukraine cyber attacks. The first variant is a simple Trojan that runs distributed denial of service (DDOS) attacks against targeted servers. The second variant –also known as BlackEnergy 2– marked a major change to the malware’s capabilities and an almost complete code rewrite from the first variant. BlackEnergy 2 added support for 64 bit drivers and implemented UAC Bypass Installers to give the malware elevated code execution privileges on Windows. The third variant (BlackEnergy 3) was also a big change from BlackEnergy 2 with the addition of a wider variety of plugins and anti-analysis techniques.
The Russian APT Sandworm Team, also known as Quedagh and BE2 APT, is associated with BlackEnergy attacks targeting various organizations in Ukraine. Since at least 2009, Sandworm Team has also previously attacked government, telecommunications, defense, and energy organizations.
The consistent use of BlackEnergy malware against the energy and industrial sectors means those organizations should consider BlackEnergy an intelligence requirement. Identifying and memorializing strategic intelligence on when BlackEnergy was used, what it targeted, what it can do, and how it has evolved can ultimately inform those organizations’ higher level defensive efforts. The next step in the intelligence cycle is to collect intelligence on the threat itself.
Intelligence Collection
OSINT Baseline
One method ThreatConnect uses when researching a threat, is collecting indicators from openly available sources. These collections often include network and file indicators including hashes, hostnames, IP addresses, and email addresses. ThreatConnect also has a free intelligence feed collecting over 75 cybersecurity reports and blogs that automatically captures indicators so organizations and researchers can incorporate them into their investigative and defensive efforts.
One good starting point was a 2014 Kaspersky report detailing BlackEnergy use that contained five MD5 hashes associated with the BlackEnergy 3 malware. After identifying these openly available reports and indicators, we imported them into ThreatConnect and associated them with their respective BlackEnergy Incidents.
Another method that can be used to identify and gather indicators is hunting using YARA rules. We used the ThreatConnect YARA hunting integration to deploy a YARA ruleset of five BlackEnergy signatures and identified samples submitted to a public malware scanning site that matched those YARA rules. The matching file results identified all three variants of the malware and associated the file indicators with YARA signature groups in the Platform.
Above is an image of the output from hunting for BlackEnergy using ThreatConnect. The YARA hunting integration automatically imports file indicators that match deployed YARA rules. These indicators are organized into groups based on the date of identification, the associated rule, and sample. This integration helped us identify hundreds of files related to this specific threat. Additionally, it helped us organize the data so that it can be enriched and associated with other BlackEnergy intelligence in the platform.
Processing and Exploitation – Building Out Intelligence With ThreatConnect
After we’ve collected intelligence from a variety of sources, we can leverage ThreatConnect’s various integrations, Spaces apps, and investigation links to build out our understanding of the identified activity. This iterative process helps organizations identify tactical intelligence that may inform their incident response efforts in the wake of experienced activity.
For example, we can use our investigation links for a BlackEnergy 3 malware hash identified in an RSA forum to query VxStream for the given file.
We can then use VxStream to find similar samples to the queried hash. Many public malware scanning sites associate similar files to the sample being scanned, which researchers can use to find associated samples related to the incident they are investigating.
These similar samples have already been scanned, making it easier for us to identify the variant of the malware. This decreases the amount of time an analyst needs to spend analyzing the sample.
This newly identified information that augments findings from intelligence collection efforts, is then imported into ThreatConnect and associated with the BlackEnergy threat to further increase visibility into the malware activity.
Analysis and Production – Using ThreatConnect to Associate Indicators
Next we began grouping the indicators according to the three variants of BlackEnergy in ThreatConnect, where we can easily and efficiently associate indicators and show relationships using incidents, threats, and campaigns. Here’s how:
BlackEnergy Threat
The first thing that we did to start pulling BlackEnergy indicators together was create a BlackEnergy malware threat. Threats in the Platform are made up of incidents and activity groups defined by common infrastructure, common malware, and carried out by a common adversary or team. Our BlackEnergy Threat captured the information we learned about BlackEnergy during the prior phases of the intelligence cycle.
We also applied a few relevant tags such as the names of the malware variants, targeted industry, and type of activity, and then associated the BlackEnergy malware threat group to the preexisting Sandworm threat actor group. Tags provide another useful way to pivot through information of interest in ThreatConnect.
BlackEnergy Incidents
After building the BlackEnergy threat, we began compiling incidents for each variant of the malware. These incidents have indicators associated to them, and allow us to organize our work as we enrich those indicators. We started with a BlackEnergy 2 Malware Samples incident, BlackEnergy 3 Malware Samples incident, and a BlackEnergy Malware incident. Shortly thereafter we pulled together a Ukraine BlackEnergy 3 Attacks incident so that we could move all of the indicators of compromise from that attack into one group.
We also associated two incidents that were already associated with the Sandworm threat actor and the CVE-2014-4114 vulnerabilities, as they had similar indicators and characteristics to the BlackEnergy 3 malware. From there, we began gathering BlackEnergy related indicators to associate to each incident.
BlackEnergy 3 Campaign
After building the Threat and Incidents, we created a BlackEnergy 3 Campaign to organize all of the BlackEnergy 3 related Incidents including the Ukraine BlackEnergy 3 Attacks, and BlackEnergy 3 Samples Incidents. We chose to create a campaign for this variant because we found several reports with different indicators, that we felt needed individual Incidents. Generally, the purpose of creating a campaign in ThreatConnect is to associate together related incidents, or other campaigns.
Dissemination and Integration
Information and data you found in ThreatConnect can be shared out to other users and other communities that you have access to. This includes our Common Community, which is available to all of our wonderful users as well as the ThreatConnect Intelligence source, reserved for our paying customers. You can also download your Incidents, Indicators, and Threats as a PDF and copy other incidents to your research organization using the “Copy to My Org” function to show to individuals that may not have access to ThreatConnect, so that they can make informed decisions using ThreatConnect data. You are also able to follow incidents from other organizations and get immediate or summarized reports on changes made to those incidents.
Making it Actionable
Now that we have identified and pulled all of this information together in ThreatConnect and shared with appropriate parties, what happens next? As we like to say, intelligence doesn’t exist for its own sake: it exists to inform decisions. Using the ThreatConnect Platform, the information gathered can be used to make informed decisions about the threat posed by BlackEnergy, and prevent and respond effectively to incoming threats. ThreatConnect has numerous integrations that make it easy to take action on information pulled together in the Platform. The added functionality of ThreatConnect Playbooks further simplifies these processes allowing users to quickly send indicators to be blocked, further analyzed by an automated malware analysis service, or even assigned to an analyst.
Looking beyond ThreatConnect, recommendations like these from the ICS-CERT are other ways to protect ICS (Industrial Control Systems) and energy sector systems:
- Minimize network exposure for all control system devices. Control system devices should not directly face the Internet.
- Locate control system networks and devices behind firewalls, and isolate them from the business network
- If remote access is required, employ secure methods, such as Virtual Private Networks (VPNs), recognizing that VPN is only as secure as the connected devices.
- Remove, disable, or rename any default system accounts wherever possible.
- Apply patches in the ICS environment, when possible to mitigate known vulnerabilities
- Implement policies requiring the use of strong passwords.
- Monitor the creation of administrator level accounts by third-party vendors.
- Limiting remote systems or unmanned stations with sensitive information or computer systems.