# Analyzing a New Variant
 of BlackEnergy 3
## Likely Insider-Based Execution

### By Udi Shamir

**EXECUTIVE SUMMARY**

_Note – While writing this report (1/26/2016) a new attack has just been detected, targeting a Ukranian power_
_facility. The attack vector appears to the be the same variant analyzed in this report. We’ll provide more details in a_
_subsequent analysis._

BlackEnergy was first reported in 2007 (named BlackEnergy 1) and at the time was a relatively simple form of
malware that generated random bots to support Distributed Denial of Service (DDoS) attacks. A few years later,
in 2010, BlackEnergy 2 emerged with some significant capabilities that extended beyond DDoS – most notably a
new plugin architecture that allowed BlackEnergy to subvert system resources and perform other activities such as
data exfiltration, and network traffic monitoring. It was at this time that many began to associate BlackEnergy with
crimeware. Our analysis of a new BlackEnergy 3 sample has led us to conclude that this latest rootkit is in fact the
byproduct of a nation-sponsored campaign, and likely the work of multiple teams coming together. It should be
noted that iSight Partners has already validated a link between BlackEnergy and the Sandworm Team. Therefore,
this conclusion in and of itself is not necessarily noteworthy, rather it’s the discover of a new tactic that’s now been
employed targeting specific individuals running Microsoft Office.

In this particular sample the actor appears to have advanced a method used back in 2014 against Industrial Control
Systems systems deployed in NATO countries, and more broadly across the European Union. At that time the
actor used a vulnerability, CVE-2014-4114, in the OLE packager 2 (packager.dll) in the way it parses INF files. Each
binary was compiled using different compiler versions, which led us to conclude that different groups are in fact
directly involved in this campaign – much like a typical R&D project supported by different engineering teams who
each follow their own unique development characteristics. These different characteristics have established unique
fingerprints that ID each of the individual group’s traits.

Traditional antivirus software vendors would have a difficult time detecting this particular type of attack given the
constantly changing attack vectors even though they are still rooted to the same core components. For example,
the actor can choose to drop the same binaries packed with different FUD (Fully undetected) using different Excel
documents.

It’s expected that this particular sample is already resident in many systems across the Ukraine, and likely other
nations in Europe which could lead to more blackouts and “mysterious” malfunctions within major utilities,
transportation systems, and even healthcare institutions. There may be different variants of BlackEnergy used
within each of these environments, but they all originate from the same common core.

**INTRODUCTION**

Execution of this particular BlackEnergy 3 attack vector is likely the work of an internal actor, especially in the case
of SCADA systems. This is due to the fact that Office 2013 has already been patched against CVE-2014-4114. The
only two options then to carry out the attack is – target a victim’s machine that was not patched, or get an internal
employee to either accidentally or deliberately execute the infected Excel documents causing the malware to
propagate inside the network. At this point it would be highly unlikely that organizations have not deployed the
patch against CVE-2014-4114, thus the most likely conclusion is use of an internal actor.


-----

crucial during the development cycle and assists the debugger with finding the following:

- Private, public, and static function addresses

- Global variables

- Parameters and local variable names

- Frame pointer omission

- Source file names and lines

Within the Visual Studio community, it’s common to say – love, hold and protect your PDBs! The path was
structured from drive E:\ and was under a recursive releases parent directory. The PDB pointed to the winpcap
version 4_1_0_2001, which suggests that the author probably wanted to implement RAW sockets and to actively
tap the network.

By nature of the sample operation, and its diversity, it appears that this toolkit/s was authored for the purposes
of ‘black ops’ and likely being used by multiple groups in parallel. For example, used to steal banking credentials
while in parallel used against Georgia in the conflict with Russia. This is an assumption as the time overlaps with the
BlackEnergy discover, and can see some of the same unique fingerprints.

It’s expected that this same group is also responsible for the “shut down” of the Estonian internet and government
[web sites that began in 2007. Many associated this attack to a retaliatory statement against Estonian’s desire](https://en.wikipedia.org/wiki/2007_cyberattacks_on_Estonia)
for independence. However, these actions could also be related to testing of new “tools” before conducting or
establishing a much bigger ops campaign.

As mentioned, BlackEnergy began supporting plugins in 2007 which we observed different versions.

As for the similarities and code reuse, an interesting finding shows that some mutex shares the exact same name:
__Satori_81_MutexObject with the Sality malware variants. It appears some other variants are also utilizing the_
[exact same name. Additional similarities can be found in Operation Potato Express, covered by ESET, that targets](http://www.welivesecurity.com/2015/07/30/operation-potao-express/)
government and military officials.

We’re confident that a particular government is well aware of this new attack and are likely actively participating in
the development of its core code / plugins.

During 2014, samples started to show up (discovered) and were detected as BlackEnergy, targeting specific
Ukrainian government facilities. The version was more current than the samples detected in 2007. The 2014
samples were designed to perform exfiltration, and lateral movement, sending data to servers deployed in different
major ISP’s including one of the largest across Europe.

**MALICIOUS.XLS**

**TYPE** XLS

**SHA256** 052ebc9a518e5ae02bbd1bd3a5a86c3560aefc9313c18d81f6670c3430f1d4d4

**SHA1** aa67ca4fb712374f5301d1d2bab0ac66107a4df1

**MD5** 97b7577d13cf5e3bf39cbe6d3f0a7732

**DETECTED** 33/55

**UPLOADED** First: 2015-08-03 Last: 2016-01-15


-----

creation of custom user interface elements that then allow different objects from different applications to add
different data types such as images.

Microsoft Office supports execution of macros (thanks to the OLE format) allowing the document’s author to easily
embed macros and Visual Basic code that can then get executed by anybody who opens the document.

Malicious actors began abusing this “fancy” feature and started to introduce this vector more often, and in the
process gain much success. Microsoft in response added protection methods such as the ability to disable macros
and any external content by default, and to warn the user when content such as a macro is about to be executed.
The the warning the user needs to specifically approve or deny the use.

The second vector involves exploiting a vulnerability found inside OLE, parsers and handlers, and executes the
malicious content without the user’s awareness.

As mentioned above, in 2014 Microsoft Office 2013 was vulnerable to an OLE bug which allowed an attacker to gain
remote code execution by utilizing the vulnerable packager components.

The Microsoft Excel in this case will not execute its malicious code without explicitly having macro content
permitted.

**_Fig 2._**

When checking the Document OLE structure we can immediately spot Visual Basic code attached as macro:

**M 609230 ‘_VBA_PROJECT_CUR/VBA/Workbook________’**

**_Fig 3. Visual Basic Macro_**


-----

reassembled using the for loop which saves the binary and then executes it.

The macro contains portable executable (PE32), by checking a(1) Array we see the first two decimal values
77, 90 that when converted to Hex we will have 4d 5A that is a PE executable. The executable will be saved
on the Windows TMP directory under the name vba_macro.exe, the VB script finds the tmp directory by calling
[ENVIRON(‘TMP’) and when it saves the PE to disk it will execute the binary: vba_macro.exe using the Shell function.](https://support.office.com/en-us/article/Shell-Function-ff2e4b1b-712d-4e34-aea6-6832eadd3c63)

**_Fig 4. PE Decimal Values_**

**_Fig 5. Saving the binary and executing_**

**VBA_MACRO.EXE**

**TYPE** PE32

**SHA256** 07e726b21e27eefb2b2887945aa8bdec116b09dbd4e1a54e1c137ae8c7693660

**SHA1** 4c424d5c8cfedf8d2164b9f833f7c631f94c5a4c

**MD5** abeab18ebae2c3e445699d256d5f5fb1

**DETECTED** 41 / 54

**UPLOADED** First: 2015-03-24 Last: 2016-01-15

**SIZE** 96k (rounded)

**ENTROPY** 6.82694518574

**COMPILER** Visual Studio C/C++ 6.0


-----

right code section. This is due to dead code, and the obfuscated code that reconstructs the sections and imports
them at run time.

As mentioned before, BlackEnergy was written in modular fashion and this binary drop’s two different executables
(modules) while each perform different tasks.

**_Fig 6. Most of the code is useless_**

A much faster approach would be to use a debugger. This step requires several iterations over the Crypter stages
while installing breakpoint on key Functions API and then executing.


-----

**_Fig 8. VirtualAlloc_** **_Fig 9. Finding portable executable_**

As mentioned above, the main executable being dropped from the Excel Spreadsheet (vba_macro.exe) executes an
additional two binaries that it creates: FONTCACHE.DAT and runndll32.exe, then it deletes the original executable (vba_

**macro.exe).**

This binary creates / drops 4 files:

- **FONTCACHE.DAT (Network sniffer based on WinPcap)**

- **rundll32.exe (Original Microsoft load dll) was dropped in case its not exist**

- **NTUSER.LOG (an empty file)**

- **desktop.ini (default ini file)**

The FONTCACHE.DAT (the Network component) is the most interesting dropped file as this particular file behaves as
network sniffer.

Before creating the files, the binary retrieves the following information:

- APPDATA using csidl (1Ch)

- <Drive>:\Windows\System32 by calling the GetSystemDirectory() function

**_Fig 10. Retrieve APPDATA directory path using csidl 1Ch_**


-----

**_Fig 11. Create Files_**

Since FONTCACHE.DAT is a dll (shared library) that cannot be executed directly (rather being loaded by the
LoadLibrary() function) the malware uses the rundll32.exe dll loader in order to execute the Malware.

**_Fig 12. The file name is a GUID (globally unique identifier) format that is a_**
_unique reference number_

The binary gets executed by the following command from the startup menu lnk:

**rundll32.exe FONTCACHE.DAT #1.**

Lnk is a propriety Microsoft Windows shortcut, a metadata file which is interpreted by the Windows shell.

**_Fig 13. Lnk Metadata, execute rundll32.exe in order to load the Malicious dll_**


-----

**_Fig 14. Possible Anti-Debugging Technique_**

The Binary is utilizing a second anti-debugging technique that uses the SetUnhandledExceptionFilter function API.
The third method is to check if the kernel debugger is attached, and the last one (and simplest to bypass) is the
IsDebuggerPresent API.

_NOTE: The binary executes FONTCACHE.DAT by calling the ShellExecute() and doesn’t wait for the machine to boot._

The process will constantly appear in the taskmgr as rundll32.exe.

As mentioned earlier, FONTCACHE.DAT is the network module that operates as a network sniffer extracting
crucial information for lateral movement, as well as other information related to the network structure and MAC
modification.

The lnk shortcut that will execute FONTCACHE.DAT needs to provide parameters such as the network adapter that
the sniffer will hook (attached). In order to gather this information, the binary calls the GetAdaptersInfo() function
API that returns the network information for the local computer. This will be part of the startup routine.


-----

**_Fig 15. Extract startup menu and network adapter information_**

**_Fig 16. Preparing the lnk file_**

The next step will be executing the lnk shortcut which creates a new process with specific parameters that
includes deleting the vba_macro.exe (the file that was dropped from the Excel sheet) and terminate itself by calling
ExitProcess().

**_Fig 17. Executing the Sniffer and cmd.exe_**


-----

**_Fig 18. CreateProcess from Debugger_**

The loop will be executed 100 times and will try to duplicate itself - in case it does not exist, it will try to recreate
itself.

_NOTE: The cmd.exe will not be visible to the user._

Registry:

The sample register the binary to the startup shell using the RegSetValueExw()

**Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders**

**FONTCACHE.DAT (packet.dll)**

**TYPE** PE32/DLL

**SHA256** f5785842682bc49a69b2cbc3fded56b8b4a73c8fd93e35860ecd1b9a88b9d3d8

**SHA1** 315863c696603ac442b2600e9ecc1819b7ed1b54

**MD5** cdfb4cda9144d01fb26b5449f9d189ff

**DETECTED** 39 / 55

**UPLOADED** First: 2015-07-27 Last: 2016-01-15

**SIZE** 55k (rounded)

**ENTROPY** 7.5080540306

**COMPILER** Visual Studio C/C++

This binary seems to embed WinPcap version 4.1.0_2001. This is interesting because Microsoft provides Winsock
API in order to deal with the network stack. The only reason that comes to mind is the use of RAW sockets. The
Packet.dll provides the binary support for capturing (sniffing), sending packets and alerting the source address. This
is very similar to the FP_PACKETS sockets in Linux, and the BPF driver on the BSD systems.

RAW sockets allow the developer to intercept, modify (craft), and build socket headers - writing new protocols,
spoof source IP address and MAC address.

WinSock2 API does support RAW sockets but in a limited way. Microsoft deliberately blocked some of its
functionalities in order to prevent Malicious operations originating from their OS. For instance, Microsoft prevents
the change of the source IP address in the UDP protocol if its not equal to the network interface the computer it
[connects to. This is to prevent DDoS attacks. Full Microsoft Documentation.](https://msdn.microsoft.com/en-us/library/windows/desktop/ms740548(v=vs.85).aspx)

**_Fig 19. Microsoft MSDN RAW_SOCKET Limitation_**


-----

The malware repeats the same evading technique as the vba_macro.exe by attempting to detect if its checksum was
changed during run time (detect non HW breakpoints) in order to make the debugging process harder.

**_Fig 21. The binary is probably opening a backdoor by starting an RPC server_**
_and listening for incoming traffic_

**_Fig 20. Possible Anti-Debugging Technique_**

When executing, it will first attempt to call OpenSCManagerA(), OpenServiceA(), and StartServiceA() in an attempt
to start the WinPcap service “NPF” on the victim machine. In case it fails then it will load the WinPcap library (dll)
directly by calling the LoadLibraryA().

The binary seems to be encrypted with an RC4 variant, base64, and probably compressed with LZMA. It executes
iexplore.exe and will initiate communication with the C2 server. Launching iexplore.exe might be for decoy, as
previous variants were opening an empty Word document.

**_Fig 22. Delay Execution_**


-----

**_Fig 23. Getting the Keyboard layout_**

The binary is packed with very high entropy. Most of the data is encrypted and encoded using base64:

**_Fig 24. Base64 string_**

**_Fig 25. Calling Internet Explorer Server_**

**_Fig 26. Calling Internet Explorer_**


-----

**_Fig 27. DLL Exports_**

The binary is capable of subverting and sniffing the network interfaces, including wireless adapters utilizing the
PacketGetAirPcapHandle() function. All the information gathered will be sent to the C2 server (information
regarding the C2 server could be gathered under Network Activity).

**NETWORK ACTIVITY**

The binary connects to its C2 using HTTP protocol:

**hxxx://5.149.254.114/Microsoft/Update/KC074913.php**

**hxxx://5.149.254.114/favicon.ico**

The IP address 5.149.254.114 points to
FORTUNIX-NETWORS.

**_Fig 28. The IP address 5.149.254.114 points to FORTUNIX-NETWORS_**


-----

**162.246.22.74** new_jersey_international_internet_exchange

**64.235.52.31** las_vegas_nv_datacenter

Both appear to be large data providers.

When communicating with its C2 server the bot POST the following parameters:

**B_ID** Bot id

**B_GEN** Bot Generation

**B_VER** Bot Version

**OS_V** Operating System Version

**OS_TYPE** Operating System Type


-----