DISMANTLING BLACKENERGY, PART2 – “THE MARK”

I will not make a speech on what a BlackEnergy framework is since a lot was written about it already and without me, however I want to refer to information from this particular review:

The cybercriminal group behind BlackEnergy, the malware family that has been around since 2007 and has made a comeback in 2014, was also active in the year 2015. ESET has recently discovered that the BlackEnergy Trojan was recently used as a backdoor to deliver a destructive KillDisk component aimed at destruction of files on the hard disks in attacks against Ukrainian news media companies and against the electrical power industry…

Everyone, meet the Flashplayer!

During the investigation of the attack on our infrastructure we have detected various malware samples and among them Flashplayerapp.exe (https://www.virustotal.com/ru/file/c787166ad731131c811d1a63080ac871ec11f10bcd77b9a1e665f1c9bbaa9a54/analysis/)

Briefly, flashplayerapp extracts main_light.dll into its own memory space and transfers control to it. This library is a light version of BlackEnergy and is used for C&C communication to download the main payload with functionality depending on the goals pursued by the attacker. It creates a file: C:\Users\user\Appdata\Adobe\cache.dat

blackenerfy-shtamp_2

While encrypted this file contains various information including the build version (such as 2015lstb), address of command and control center from which it can retrieve various payloads (such as hxxps://188.40.8.72/l7vogLG/BVZ99/rt170v/solocVI/eegL7p.php) etc. As I was examining this sample, I switched focus from C&C as one particular part of the code caught my attention, as it was an obvious sign of using a technique called code permutation. Let me translate a quote from this source http://hacks.clan.su/publ/11-1-0-481:

…Permutation is the transformation of already complete code. The most advancements in this technique to the date were made by Z0MBiE. However, even the older engine versions credited someone called Lord_ASD. The next advancements in this technique after him were made by Vecna and SBVC. So what is a permutation? The core algorithm for permutation engines is the disassembly of the code followed by its mutation and reassembly. Let us have a look at the most simple algorithm used in permutation engine:
All code instructions are disassembled by length, conditional and unconditional jumps are marked.
Instructions are substituted with the synonymous ones and in-between garbage instructions are inserted. All jumps are re-calculated.
This kind of polymorphism is most promising due to following reasons:
Flexibility (not ease) of engine coding
High level of mutations
Requirement for emulation of all instructions
Despite this type of polymorphism being known or quite a while, it did not become mainstream due to difficulty of implementation…
So here is how the code fragment looked like (the instructions added by the permutation engine are highlighted in red and they do not affect functionality at all, they just make code more difficult to understand):

blackenerfy-shtamp_3

By removing the unnecessary strings, we get a mechanism that processes all function names in kernel32.dll

blackenerfy-shtamp_4

by turning them their (names) into some form of hash that it later compares with some value:

blackenerfy-shtamp_5

Let us recreate this mechanism using C as example. As a result, we receive a utility that can produce for us a “dictionary” that contains names of all functions in kernel32.dll library and hash-values of these names. Let us try searching the hash values that we obtained during the code reverse analysis in our new “dictionary”. First, we seek the value from the EAX register (0x5147F60F), and then compare it to the reference value:

blackenerfy-shtamp_6

Our theory is working: our sample has processed the name of the first function, created the hash and is now comparing it with reference value that is contained in buffer (0xC8AC8026). We search for this value and behold… we get the LoadLibraryA function!

blackenerfy-shtamp_7

To skip another wall of text example I will just mention that our “sample” uses the same approach to search for another function called GetProcAdress.

blackenerfy-shtamp_8

By using these two functions our “sample” can load other libraries and extract the addresses for the functions it requires.

The tracks left by the Engine

The technique of making static code analysis difficult via function call based on some hash value rather than its name is not new. However it lead me to the following thought: despite of how the malicious code is processed, we know the algorithm of functions’ name hashing and thus we can confidently look for these two functions (LoadLibraryA and GetProcAdress) in the code. Thus, I started searching them internetz for the mentions of this hash (0xC8AC8026) to see if someone has used the same engine from our example before and to my surprise, I did find something:

This hash is mentioned for the first time during 2006 (the article can only be found at the archive.org): https://web.archive.org/web/20060614030412/http://osix.net/modules/article/?id=789

blackenerfy-shtamp_9

Later, in 2008, a potential author of the algorithm makes an appearance on the forum:
https://exelab.ru/f/index.php?action=vthread&forum=6&topic=11845

blackenerfy-shtamp_10

Afterwards, in 2009 an analysis article about shellcode MS08-067 is published at blogs.technet.com:  http://blogs.technet.com/b/srd/archive/2009/06/05/shellcode-analysis-via-msec-debugger-extensions.aspx

blackenerfy-shtamp_11

Then in 2013, the “XAKEP” magazine (one of biggest Russian media on IT and Information Security) publishes article https://xakep.ru/2011/06/23/55780/ where they mention the exact same algorithm which creates the same hash (!):

blackenerfy-shtamp_12

Hold on just second, the situation we got here is that the same algorithm that generates the same hash-values is in use for more than 10 years and yet nobody has noticed this? Should this be otherwise, then for the flashplayerapp.exe (https://www.virustotal.com/ru/file/c787166ad731131c811d1a63080ac871ec11f10bcd77b9a1e665f1c9bbaa9a54/analysis/) being the same as it appears now, it would be impossible to stay unnoticed by anti-virus solutions while we already live in a year of 2016:

blackenerfy-shtamp_13

There is a clear “mark” that is left by this concrete permutation engine that was used in our analyzed sample and it looks like a valid signature to me. Moreover, it is rather easy to track directly in the clear text:

blackenerfy-shtamp_14

Well, we got our assumptions and the theory is straightened out so let us proceed to practice and try transforming our conclusions into a Yara signature / rule:

rule API_Hash

{meta: description = “Hash of LoadLibrary that is {26 80 ac c8} and GetProcAddres {ee ea c0 1f}”

strings:

$a = {26 80 ac c8}

$b = {ee ea c0 1f}

condition: $a and $b

}

The only thing left to do now is to test it against multiple various samples (for example of an antivirus laboratory) in order to find out exactly how much of malicious code was packed by this engine for real?
At this point, I can only state that it was possible for me to conduct the experiment on a very small amount of samples in one of the antivirus companies, yet results are well worth it! Among the caught samples, we have:

Win32/Spy.Bebloh (banking trojan) — http://www.virusradar.com/en/Win32_Spy.Bebloh/detail
Win32/PSW.Fareit (Trojan for stealing passwords) — http://www.virusradar.com/en/Win32_PSW.Fareit/detail
Win32/Rustock (Backdoor) — http://www.virusradar.com/en/Win32_Rustock/detail
Win32/TrojanDownloader.Carberp (Dropper that installs banking Trojan  Carberp) — http://www.virusradar.com/en/Win32_TrojanDownloader.Carberp/detail
Win32/Kelihos (Spam sender) — http://www.virusradar.com/en/Win32_Kelihos/detail

This list contains only well-known families. These two hash values also appear in other malware families including Ransomware / file encryptors (Win32/Filecoder.HydraCrypt), a Bitcoin miner (CoinMiner.LC), a WinLocker (LockScreen.AQT) and others.

So far, I can also add that this rather simple looking Yara rule did not lead to a single false-positive to the date, but the testing was conducted only on few dozen computers. Therefore, I really express my hopes that after publishing of this research, You (!) and the ones who have read this far will share their feedback that will be big enough to prove or disprove this rule’s precision! Of course, using just eight bytes for a signature is exceptionally small and the rule will very likely catch some “legit” files. Nevertheless, this lightweight Yara rule can live in a sandbox as part of a more complex analysis logic.

Conclusions

The goal of this article is not the reverse engineering of the BlackEnergy malware but I rather want to highlight the fact that Tools used during assembly of one or another malware code leave their traces and can lead to the appearance of useful indicators that can be utilized for the defense. And those indicators can live unnoticed for a rather long time…

Aleksey Yasinskiy

Aleksey Yasinskiy

ex CISO | StarLightMedia
director of ISSP Labs
Aleksey Yasinskiy

Translated from original by Andrii Bezverkhyi | CEO SOC Prime