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:

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

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:

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

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

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:

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!

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.

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

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

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

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 (!):

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:

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:

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…

Translated from original by Andrii Bezverkhyi | CEO SOC Prime