BlackEnergy 2 (alias BlackEnergy Version 2) Live Debugging

[Patrick]

Last night I took a quick look at BlackEnergy 2, a rootkit that surfaced in 2010. BlackEnergy 2 was essentially a rewrite of its predecessor as BlackEnergy 2 contains rootkit techniques, process-injection, and encryption. Surprisingly for being a now 'dated' rootkit, there's really not too much accessible (or not buried) reverse kernel-debugging documentation for the rootkit aside from when it was first surfacing. A lot of misc. information pops up throughout very few blogs/forums that are Russian, but that's about it.

There's a lot of additional lore behind the rootkit, but I really won't go into that. If you're interested about where the rootkit core came from before it was implemented into BlackEnergy 2, BlackReleaver is the answer!

NT Corruption

First off, we can view corruption regarding ntokskrnl:

lkd> !chkimg -d -v nt  
Searching for module with expression: nt  
Will apply relocation fixups to file used for comparison  
Will ignore NOP/LOCK errors  
Will ignore patched instructions  
Image specific ignores will be applied  
Comparison image path: C:\Symbols\ntoskrnl.exe\41108004214780\ntoskrnl.exe  
No range specified  

Scanning section:  .text  
Size: 466369  
Range to scan: 804d7580-80549341  
  804ded5a-804ded5d 4 bytes - [COLOR=#ff0000]nt!KiBBTUnexpectedRange+8[/COLOR]
     [ 00 ff 09 00:6b a0 c1 01 ]  
  804e59a1-804e59a5 5 bytes - nt!KeInsertQueueApc (+0x6c47)  [COLOR=#800080]// Not malicious -- Malwarebytes.[/COLOR]
     [ 8b ff 55 8b ec:e9 e4 45 4e 77 ]  
Total bytes compared: 466369(100%)  
Number of errors: [COLOR=#ff0000]9[/COLOR]

!chkimg compares the current loaded executable with the version within the symbol store. This is a helpful command to detect corruptions with images, and especially helpful when dealing with rootkits. The -d parameter displays a summary of all mismatched areas. The -v parameter makes the information verbose. In this case, the -v parameter is optional.

As noted above, we have two out-of-range values. We're interested in disassembling nt!KiBBTUnexpectedRange+8, but not nt!KeInsertQueueApc (+0x6c47). nt!KeInsertQueueApc (+0x6c47) as I commented above is in relation to the Chameleon technology from Malwarebytes. I had MWB ARK installed on this VM for testing purposes, so that is where it was spawning from.

nt!KiBBTUnexpectedRange+8 Disassembly - Healthy

If we disassemble nt!KiBBTUnexpectedRange+8 on a system not infected with BlackEnergy 2, we should expect similar results:

lkd> u nt!KiBBTUnexpectedRange+8  
nt!KiBBTUnexpectedRange+0x8:  
804ded5a 00ff      add   bh,bh  
804ded5c 0900      or   dword ptr [eax],eax  
804ded5e 0bc0      or   eax,eax  
804ded60 58       pop   eax  
804ded61 5a       pop   edx  
804ded62 8bec      mov   ebp,esp  
804ded64 89ae34010000  mov   dword ptr [esi+134h],ebp  
804ded6a 0f8490020000  je   nt!KiFastCallEntry+0x8d (804df000)

nt!KiBBTUnexpectedRange+8 Disassembly - Corrupted

If we disassemble nt!KiBBTUnexpectedRange+8 on a system that has been infected with BlackEnergy 2, we should expect similar results:

lkd> u nt!KiBBTUnexpectedRange+8  
nt!KiBBTUnexpectedRange+0x8:  
804ded5a 6ba0c1010bc058 imul  esp,dword ptr [eax-3FF4FE3Fh],58h  
804ded61 5a       pop   edx  
804ded62 8bec      mov   ebp,esp  
804ded64 89ae34010000  mov   dword ptr [esi+134h],ebp  
804ded6a 0f8490020000  je   nt!KiFastCallEntry+0x8d (804df000)  
804ded70 8d15509b5580  [COLOR=#800080]lea   edx,[nt!KeServiceDescriptorTableShadow+0x10 (80559b50)][/COLOR]  
804ded76 8b4a08     mov   ecx,dword ptr [edx+8]  
804ded79 8b12      mov   edx,dword ptr [edx]

So, why do we have corruptions in ntoskrnl and a corrupted nt!KiBBTUnexpectedRange+8 output? It's a side effect of the rootkit creating additional 'fake' service tables. It does this by patching the ETHREAD SystemTable pointer, which allows for things such as user threads to be patched, thread creation notification and service table pointer updating by using PsSetCreateThreadNotifyRoutine, etc.

The main use behind creating fake service tables is it gives anti-rootkit software a much harder time (harder back in 2010, at least) detecting its presence. It doesn't just 'hook' and/or modify the SSDT (which as we know would be a big red flag), it instead creates its own fake service tables, and then hooks (acquires?) the following functions:

NtDeleteValueKey  
NtEnumerateValueKey  
NtEnumerateKey  
NtOpenKey  
NtOpenProcess  
NtOpenThread  
NtProtectVirtualMemory  
NtQuerySystemInformation  
NtReadVirtualMemory  
NtSetContextThread  
NtSetValueKey  
NtSuspendThread  
NtTerminateThread  
NtWriteVirtualMemory
etc...

KTHREAD Structure

Given we're adding new/fake service tables, we need applications to be able to access them. This is done by using pointers as discussed above, which is accomplished in the KTHREAD Structure. Every single thread has a pointer to a ServiceTable which is ultimately set by KeInitThread. Additionally, if the thread requires GUI functions within the Shadow SSDT, PsConvertToGuiThread is called.

We can dump the KTHREAD Structure:

lkd> dt -v nt!_KTHREAD  
struct _KTHREAD, 73 elements, 0x1c0 bytes  
  +0x000 Header      : struct _DISPATCHER_HEADER, 6 elements, 0x10 bytes  
  +0x010 MutantListHead  : struct _LIST_ENTRY, 2 elements, 0x8 bytes  
  +0x018 InitialStack   : Ptr32 to Void  
  +0x01c StackLimit    : Ptr32 to Void  
  +0x020 Teb       : Ptr32 to Void  
  [COLOR=#ff0000]+0x0e0 ServiceTable   : Ptr32 to Void [/COLOR]

At this point if you'd like to see the tables, you can use the following command:

!for_each_thread ".echo Thread: @#Thread; dt nt!_kthread ServiceTable @#Thread"

If you see anything other than KeServiceDescriptorTable or KeServiceDescriptorTableShadow, it's a new/fake ServiceTable.

Registry Hiding

In order to survive reboots, etc, it hides its registry entry. If you're using Windows' Registry Editor, it won't find the hidden entry. For example, here's our hidden service:

lkd> !ms_services  
[205] | 0x01 | | [COLOR=#ff0000]qtcst [/COLOR]| [COLOR=#ff0000]qtcst [/COLOR]| [COLOR=#800080]SERVICE_RUNNING[/COLOR] | [COLOR=#ff0000]\Driver\qtcst [/COLOR]

If we try and find qtcst with Registry Editor:

​

If we however use a 3rd party registry tool (any will probably work so long as it doesn't use Windows API calls):

​

We catch our culprit and the dropped driver red-handed. The driver renames after each reboot, so if you remove it and don't get the driver+registry entry at once, it'll just re-create with a different name.

Main.dll

.exe SYS TMP cmd.exe /C b k e r n e l p l g _ d a t a getp v e r s i o n n a m e s l e e p f r e q c m d s p l u g i n s x%s_%X C:\ a d d r t y p e s e r v e r s i c m p _ a d d r b u i l d _ 
i d str.sys \drivers\ \ \ . \ \ \ . \ G l o b a l \ %s%s { 9 D D 6 A F A 1 - 8 6 4 6 - 4 7 2 0 - 8 3 6 B - E D C B 1 0 8 5 8 6 4 A } main.dll .bdata {3D5A1694-CC2C-4ee7-A3D5-A879A9E3A623} 
POST %.2X & = bid nt %d cn ln id ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/ Content-Type: application/x-www-form-urlencoded _TEST_ .dll user32.dll advapi32.dll 
wininet.dll ws2_32.dll DispatchCommand DispatchEvent GetLastError GetCurrentProcessId ExitThread CloseHandle KERNEL32.dll wsprintfA USER32.dll CoCreateInstance CoInitializeEx ole32.dll 
OLEAUT32.dll WS2_32.dll RtlUnwind InterlockedExchange VirtualQuery main.dll ConfAllocGetTextByNameA ConfAllocGetTextByNameW ConfGetListNodeByName ConfGetNodeByName ConfGetNodeTextA 
ConfGetNodeTextW ConfGetPlgNode ConfGetRootNode DownloadFile PlgSendEvent RkLoadKernelImage RkProtectObject SrvAddRequestBinaryData SrvAddRequestStringData

Main.dll is the payload that is injected via trusted svchost. It contains as you can see a lot of readable stings, like str.sys for example. We can see str.sys in action here:

​

Overall, this rootkit was certainly a step up from most SSDT hooking/modification rootkits at the time. It can be a pain in the butt to remove if you don't kill everything properly : )

Thanks for reading.

References

Black Energy 2.1+
BlackEnergy Version 2 Analysis

 

[x BlueRobot]

Have you looked at Yara? The project page is here - YARA - The pattern matching swiss knife for malware researchers

I haven't learned to use it yet but I saw it posted on my Twitter feed.

Hashes for the binary Yara file:

For security purposes, please validate the downloaded Yara binaries by comparing the hash of your downloaded binary with the hashes below:
Yara version 3.1.0 32-bit



yara32.exe:

MD5 - fddd3831d7026c81cbd189ac567421ab

SHA256 - 865992534620d38b988df10a79a39bb12519f44aee8a56233a58cfb54a48c895

yarac32.exe:

MD5 - 87273afb970743c7eee001a3ec6a71cd

SHA256 - 94ece384cded7e35ca8d600deeea7d59776098f4e459ddab5a94b1f470e59174

Yara version 3.1.0 64-bit

yara64.exe:

MD5 - 105c05f8d789e85c36dd845b5fbb323e

SHA256 - 77c657dacac4d737c3791d284ea8c750ff7fffe88d47397e049586a1980710be
yarac64.exe:
MD5 - c9b79b1a4cf4fb9a31391a1c15bed6d6
SHA256 - 7bfcbafc1b814be1ec337fd653289c073913140325685119445afa471e65eb94

Additional Information:

Welcome to YARA?s documentation! — yara 3.0.0 documentation
https://ics-cert.us-cert.gov/alerts/ICS-ALERT-14-281-01A

 

[Patrick]

Interesting, I'll take a look.

 

[gandolf]

Yara is a great tool for malware identification and classification. I use it quite often in my work. Also, for Patrick, great article, I have a question for you, do you perform these operations on the infected machine (VM) itself, or run a remote kernel debugging session to the virtual Machine? I ask because I find it pretty odd the malware doesn't act up with the machine in a debuggable or debugging state. Although its quite evident that this particular rootkit seem to care, other malware aren't so forgiving.

regards,
gandolf

 

[Patrick]

I have a question for you, do you perform these operations on the infected machine (VM) itself, or run a remote kernel debugging session to the virtual Machine?

It depends on the malware and whether or not it's using anti-debugging techniques, and what specifically. In most if not all cases, most of the malware I reverse is done on my host machine in a network isolated VM (local kernel debugging) as stuff like Rustock and BlackEnergy 2 isn't really 'sophisticated' by today's standards. For example, I probably wouldn't reverse and/or analyze TDSS (like TDL-4) in a VM, but rather on a completely isolated machine for accurate analysis. I tried a few samples and it would just crash the VM, anyway.

 

[Jared]

Yeah, I can see what problems it would cause if rootkit escaped.
I would probably use a separate machine anyway if I'm honest.

 

[Patrick]

Yeah, I can see what problems it would cause if rootkit escaped.

It's actually not so much the chance of the malware leaving the virtual environment, it's the fact that malware like TDL-4 is still pretty new and took quite awhile to be reversed. A lot of journalists labeled it 'unstoppable', but it was eventually of course reversed and you then had tools like TDSSKiller pop up, etc. Interestingly enough however even if it was analyzed by a software company and they released a tool, a lot of tools for awhile couldn't successfully remove the rootkit. It was only detectable by a few tools for awhile. Malware really only leaves the virtual environment when the developer(s) of the malware are aware of an exploit within the VM software, and then write it into their malware. With that said, you can imagine that if malware is going to break out of a VM, the malware is most likely new.

Another reason using an isolated machine on the network is better than using an isolated VM that's disconnected from the network is because a lot of 'newer' rootkits don't do much kernel stuff until the dropper decrypts, and a lot of the dropper decryption may happen after network connectivity, etc, is confirmed. So a lot of older rootkits might just start hooking right away upon execution of the dropper, but newer ones most likely wait until the dropper is fully decrypted and does whatever else it needs to do before it starts its rootkit business.

I would probably use a separate machine anyway if I'm honest.

It's almost always better, but it doesn't even come close to the convenience that a VM offers. If you can analyze a piece of malware in a VM, chances are you probably are going to take that route as opposed to a physical machine that's isolated on the network. There's a lot of misc. reasons, but the main reason is the snapshot features of a VM. You can basically snapshot your entire analysis, so you can go back to any point in the infection. I generally do a pre-infection snapshot after everything is set up, infection snapshot after I confirm successful infection, and then a snapshot after removal.

If I'm honest, half the battle of analyzing a rootkit is finding the sample you're looking for that works, and finding what OS the rootkit is compatible with. Also in the case of TDL-4, it infects the MBR which doesn't seem to play too well with a VM.

 

[gandolf]

Another reason using an isolated machine on the network is better than using an isolated VM that's disconnected from the network is because a lot of 'newer' rootkits don't do much kernel stuff until the dropper decrypts, and a lot of the dropper decryption may happen after network connectivity, etc, is confirmed. So a lot of older rootkits might just start hooking right away upon execution of the dropper, but newer ones most likely wait until the dropper is fully decrypted and does whatever else it needs to do before it starts its rootkit business.

You're right, although this problem has also spawned some tools meant to emulate such network connectivity. One that comes to mind is FakeNet (FakeNet | Running the Gauntlet), written by the authors of an amazing book called practical malware analysis. There are plenty other tools such as ApatneDNS too. Reversing the C2 protocols can vary in sophistication though. But tools like Fakenet allow you to write your own "response servers" in order to take that analysis to the next level if the malware requires it to continue execution.

regards,
gandolf

 

[blueelvis]

Patrick which VM environment are you using? AFAIK, if you stop the Guest Services in Hyper-V, malware is not able to trace it. I don't remember the link to the article but Microsoft or some other party said that in Hyper-V , anti-virtualization techniques don't work.

You could PM me the sample (The ones which use anti-virtualization techniques) and I could have it tested on my VM on Hyper-V if you wish.


-Pranav