March 17, 2016
Breaking Down the Malware Behind the Ukraine Power Outage
Security researchers recently discovered that the power outage in the Ukraine in December was caused by a malware and identified as an evolved version of BlackEnergy. This Trojan, dating back to 2007, was a popular malware that was previously sold in Russian underground sites. However, its design and architecture changed from performing simple HTTP DDos attacks to modular functional strategy implementation. The latest version of this Trojan is now capable of dropping rootkits, performing stealthy approaches and backdoor commands via a CnC server. It is also worth noting that it is highly speculated to be utilized by a group of attackers that are against the government of Ukraine. Since Stuxnet, this BlackEnergy cyberattack is another of its kind since it also managed to sabotage an industrial sector and that the group responsible for the power outage was also linked to the Trojan found in the mining and railway sector of Ukraine.
Industrial systems typically electrical, power, oil or water uses Industrial Control Systems (ICS), which are used for control, supervision and data collection. Usually, the ICS are on an isolated network and, although still part of the network, rarely have limited access to the internet. It is interesting how BlackEnergy managed to get inside these systems. Later during our analysis, we gain insight on what happened and how the group managed to infiltrate the network from the initial stage of the attack via a phishing email.
This blog will focus on the analysis of BlackEnergy, parts of its core components, as well as how ThreatTrack’s ThreatAnalyzer and ThreatSecure provide us the information needed for data intelligence gathering. We’ll leave the analysis of the plugins that BlackEnergy utilized for another separate blog.
This research also aims to provide information on (1) how to emulate the attack by dissecting each stage of the process and (2) show how to utilize ThreatTrack’s newest line of threat identification products to mitigate and lessen the probability that these types of outbreaks might happen to you or your company. We’ll begin the analysis using the two samples that we have.
Md5: 97b7577d13cf5e3bf39cbe6d3f0a7732
Type: XLS (Microsoft Excel file)
First seen: 8/16/2015
Md5: e15b36c2e394d599a8ab352159089dd2
Type: DOC (Microsoft Document file)
First seen: 1/22/2016
BlackEnergy’s method of arrival is via a spear-phishing email containing a malicious attachment. We can emulate this by attaching the samples that we have on an email and send it inside our network. There has been a lot of debate as to how the attachment(s) was/were executed since, for this version of BlackEnergy, no exploits of Office have been seen. The only thing we know is that somehow a person inside executed the document file(s), whether by social engineering or an insider.
Using ThreatTrack’s ThreatSecure Network and ThreatSecure Email, we can see that it was identified as something malicious when entering the network and also via email. The system changes that it will be performing can be seen under behaviors. The IP entry indicates the IP address of a remote server that it is trying to beacon to. Since this sample is already a few months old, and news of this attack has already been widespread, it only makes sense that the server is already down.
Fig 1: TSN catching the XLS attachment
Fig 2: TSN catching the DOC file
Fig 2.1: ThreatSecure Email (TSE)
Fig 2.2: Submit for Remediation
A cool feature of ThreatSecure Network is that, once a threat has been identified, any connection made to the target computer will be monitored and can be seen in the ThreatSecure Network UI called ThressionsTM. Using these Thressions, users will be alerted that an attack is happening or has happened and, depending on their settings, will be able to block a said network session. Fig 2.1 and Fig 2.2 above show that the file we are analyzing was caught by ThreatSecure Email, and upon user’s request can be submitted for remediation to remove the system changes done by the malware.
It is a good practice to Finding out what the malware does in overview prior to getting deep in the assembly breakdown is a good practice during an analysis. There are a couple of ways we can do this. You can use an infected machine and the tools available on the net to see what the malware does upon execution. But this would take time and effort to set up, and there’s a much faster and easier way we can do this: Use a sandbox.
ThreatTrack’s dynamic malware analysis sandbox ThreatAnalyzer reveals the behaviors not normally seen on normal programs.
We started with the DOC file (e15b36c2e394d599a8ab352159089dd2) and the XLS (97b7577d13cf5e3bf39cbe6d3f0a7732), and both showed the same behavior:
Dropped the following files
%Temp%\vba_macro.exe
LNK file (windows shortcut) pointing to the DOC file
%Application Data%\FONTCACHE.DAT
%User%\NTUSER.LOG
%Common Startup%\.LNK file
Creates a named pipe
Pipe\{AA0EED25-4167-4CBB-BDA8-9A0F5FF93EA8}
Executed the following processes, some of the spawned multiple times
Vba_macro.exe
Cmd.exe
Attrib.exe
Ping.exe
Rundll32.exe %Application Data%\FONTCACHE.DAT, #1
%Program Files%\iexplore.exe
A screenshot showing what the document looks like when opened (DOC and XLS)
Created/Modified the following registry
Software\Microsoft\Internet Explorer\Main Check_Associations
Software\Microsoft\Internet Explorer\InformationBar FirstTime
Software\Microsoft\Internet Explorer\New Windows PopupMgr
Software\Microsoft\Internet Explorer\PhishingFilter Enabled
Software\Microsoft\Windows\CurrentVersion\Internet Settings\Cache Persistent
Software\Microsoft\Internet Explorer\TabbedBrowsing WarnOnClose
Software\Microsoft\Internet Explorer\TabbedBrowsing WarnOnCloseAdvanced
Software\Microsoft\Internet Explorer\Main DisableFirstRunCustomize
Software\Microsoft\Internet Explorer\Recovery NoReopenLastSession
Software\Microsoft\Internet Explorer\Main NoProtectedModeBanner
Software\Microsoft\Internet Explorer\TabbedBrowsing
Software\Microsoft\Internet Explorer\Recovery
Attempted to connect to a remote server
5.149..254.114
Usage of RPCRT4.DLL
Fig 2.3: ThreatAnalyzer showing processes spawned by the DOC file
Looking a bit deeper
Now that we have an overview of what the samples are doing, we want to do some classic reverse-engineering.
Although the two samples have different hashes and file formats (the one is a word document file and the other an excel sheet) they are, in basic sense, the same.
Both have a malicious macro script embedded in them and both are trying to deceive the user from disabling the macro security settings that is enabled by default. A fake Microsoft Office message appears in Russian, stating “This document was created by a newer version of Microsoft office. Macros must be enabled to display the content of the document.”
Depending on the security settings of Microsoft Office (high, medium or low), the image on Fig 4 will be displayed. If a user somehow chose to disable the macro security or is on a low security level, the malicious scripts previously mentioned will be executed immediately.
Fig 3: Security on medium settings
Looking inside the VB macro, the codes are fairly straightforward:
Declares a series of byte array
Save it in a file located in the %TEMP% directory
Execute the said file using the function SHELL
Fig 4: Byte array declaration (MZ)
Fig 5: Byte array declaration (PE)
Fig 4 shows the value 77, 90 in array a (1). Converted to hex, that is 0x4D, 0x5A (MZ), which is a strong indicator that these sequence of array is an executable. This is further verified in Fig 6, where we see 80, 69 that, when converted to hex, results in 0x50, 0x45 (PE).
Automatic execution is achieved by doing the following:
Fig 6: Byte array declaration (PE)
Fig 7: Byte array declaration (PE)
To put it simply, Fig 7 tells us that it will save the byte array into a file named vba_macro.exe located in %TEMP% directory and execute it using the Shell function.
Vba_macro.exe
According to the results from ThreatAnalyzer, Vba_macro.exe will spawn a file named FONTCACHE.DAT and several other processes. Looking inside the vba_macro executable, it seems it is heavily obfuscated at its entry point. It is posing as a file with an original name of packet.dll and is exposing several functions similar to that of being used by WinPCap. The weird thing is that although the function names are similar to that of a legit packet.dll located at the system directory (assuming WinPCap is installed), the assembled codes is garbage, except for the first function, which is probably the deobfuscator codes.
Fig 8: Note the similarities and the difference between the two.
The primary purpose of this file is to stage the next part of the infection process, which is to execute FONTCACHE.DAT.
Upon execution, this file reconstructs its code in an allocated part of memory and writes parts of itself in a separate file, the FONTCACHE.DAT, in the Application data folder. The GetAdaptersInfo API is used to get the name of the network card in use, use that as a file name for the .LNK, which is a windows shortcut file that will execute another program indicated on its path. On this case, it uses this method to ensure that the program it points to %windir%\System32\rundll32.exe “C:\Documents and Settings\Administrator\Local Settings\Application Data\FONTCACHE.DAT” will always get started upon boot up.
It deletes the credential named MCSF_Config before executing FONTCACHE.DAT using rundll32 with #1, indicating to execute the first ordinal function. This version of BlackEnergy uses the said credential to store its configuration, and in order to ensure that it will have the latest config, it deletes it prior to executing FONTCACHE.DAT.
Fig 9: CredDeleteA and ShellExecute
It will call the following command line shell commands
cmd /s /c “for /L %i in (1,1,100) do (del /F “%TEMP%\vba_macro.exe” & ping localhost -n 2 & if not exist “%Application Data%\FONTCACHE.DAT” Exit 1)
cmd /s /c “for /L %i in (1,1,100) do (attrib +h “%TEMP%\vba_macro.exe” & del /A:h /F “%TEMP%\vba_macro.exe” & ping localhost -n 2 & if not exist “%Application Data%\FONTCACHE.DAT” Exit 1)
FONTCACHE.DAT
Fontcache.dat is executed using rundll32, a way for Windows to run compiled libraries. It has an argument of #1, which means to run the first ordinal in its exported functions.
In an attempt to make a researcher’s life more difficult and in order to slow down the time to fully analyze the malware, the authors decided to obfuscate, again, this piece of malware.
We’ll get a bit deeper by trying to unpack the malware using old methods. It is common knowledge for malware analysts to set a break point to common memory allocating APIs, such as VirtualAlloc and LocalAlloc, and see whether the malware is trying to unpack part of itself in memory; however, this particular sample uses RtlAlloc and HeapAlloc to copy parts of itself little by little.
After decryption and some initializations, it will enter its main loop.
10: Chart of main function of FONTCACHE.DAT
(A) Attempts to read the current user’s credential named MCSF_Config using CredReadA API. The one that will be read is actually an encrypted buffer that will be written by the malware in function (B). This encrypted buffer will be decrypted twice and will contain information like the CnC server URL, bot version, build type and some other strings that will be appended to locally gathered data.
(B) Reads the data in the .CDATA section of FONTCACHE.DAT and overwrites the current user’s credential with that blob. This is achieved via CredWriteA API. This part also gathers local information about the target system and saves it for later use.
(C) Responsible for modifying the settings for Internet Explorer in the registry.
Software\Microsoft\Internet Explorer\Main Check_Associations
Software\Microsoft\Internet Explorer\InformationBar FirstTime
Software\Microsoft\Internet Explorer\New Windows PopupMgr
Software\Microsoft\Internet Explorer\PhishingFilter Enabled
Software\Microsoft\Windows\CurrentVersion\Internet Settings\Cache Persistent
Software\Microsoft\Internet Explorer\TabbedBrowsing WarnOnClose
Software\Microsoft\Internet Explorer\TabbedBrowsing WarnOnCloseAdvanced
Software\Microsoft\Internet Explorer\Main DisableFirstRunCustomize
Software\Microsoft\Internet Explorer\Recovery NoReopenLastSession
Software\Microsoft\Internet Explorer\Main NoProtectedModeBanner
Software\Microsoft\Internet Explorer\TabbedBrowsing
Software\Microsoft\Internet Explorer\Recovery
The function also creates a separate thread that initiates the RPC communication over named pipes. The mentioned named pipe is the method of communication of different BE 3 plugins over the same network.
Pipe\{AA0EED25-4167-4CBB-BDA8-9A0F5FF93EA8}
(D) Creates a file named NTUSER.LOG. Currently, due to the way it was programmed, it only creates a 0 byte file.
(E) Forms the message that will be sent over to its CnC server. It contains the following information:
B_id : BotID, comprises of _
B_gen : generation of bot, on this case “release”
B_ver : Bot version, “2.2”
Os_v : target system OS version, “2600” (Build version of Windows XP)
Os_type: OS type, “0”
Using CryptBinaryToString, it “encrypts” the data that will be sent over the network and sent to its CnC server as POST data as the body parameter
(F) Creates an instance of Internet Explorer in the background using CoCreateInstance API. Since the settings of IE were already modified, no GUI will be seen, and it will be running under svchost.exe.
D30C1661-CDAF-11D0-8A3E-00C04FC9E26E using this GUID, an empty instance of IE will be called as it is the default handler of IWebBrowser2 interface.
Connects to http://5.149.254.114/Microsoft/Update/KC074913.php as an RPC client to send the information to a remote server.
(G) Assuming a connection to the remote server has been made, it accepts 4 basic commands:
Delete – deletes a specified file
Ldplg – loads a plugin
Unlplg – unload a plugin
Dexec – download and execute a binary file
Using this, it has made itself modular as it can download and execute different plugin based on what type of attack will be performed. BlackEnergy has already been linked to several found plugins that also uses the named pipe mentioned above as inter-process communication, locally or even over the local network.
It is believed that these backdoor commands are the ones responsible for the attack that happened. The authors would upload new plugins, execute them and, after the damage has been done, delete the traces. These are (but not limited to):
Input/Output (IO) operations, deleting files and wiping away traces
Gathering system information
Keyloggers
Password stealers
Taking of screenshots
Remote access, SSH or RDP
After which, it will sleep for X number of seconds, depending on the one indicated on its configuration data and attempt to send the information and accept new commands from the CnC server.
Summary
Fig 11: Simplified overall flow of BlackEnergy 3
Point of entry is using a targeted spear-phishing email with a malicious attachment. Once it has been executed, the malware would be able to download and install new plugins. Communication between the core malware module and plugins are achieved through RPC communication. This is employed since most ICS are on an isolated network. Even if the target systems are on a network that does not have internet connection, the malware would still be able to ex-filtrate the data, install new plugins and control the systems using RPC named pipes over SMB. Simplified diagram on Fig 11.
hreatSecure advanced threat detection and remediation platform, ThreatAnalyzer malware behavioral analysis sandbox, ThreatIQ real-time threat intelligence service, and VIPRE business antivirus endpoint protection. Learn more about ThreatTrack Security.
No comments:
Post a Comment