1. #1

    BlackEnergy 2 (alias BlackEnergy Version 2) Live Debugging

    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:


    Code:
    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 - nt!KiBBTUnexpectedRange+8
         [ 00 ff 09 00:6b a0 c1 01 ]  
      804e59a1-804e59a5 5 bytes - nt!KeInsertQueueApc (+0x6c47)  // Not malicious -- Malwarebytes.
         [ 8b ff 55 8b ec:e9 e4 45 4e 77 ]  
    Total bytes compared: 466369(100%)  
    Number of errors: 9
    !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:

    Code:
    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:

    Code:
    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  lea   edx,[nt!KeServiceDescriptorTableShadow+0x10 (80559b50)]  
    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:

    Code:
    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:

    Code:
    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  
      +0x0e0 ServiceTable   : Ptr32 to Void 
    At this point if you'd like to see the tables, you can use the following command:

    Code:
    !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:

    Code:
    lkd> !ms_services  
    [205] | 0x01 | | qtcst | qtcst | SERVICE_RUNNING | \Driver\qtcst 
    If we try and find qtcst with Registry Editor:

    BlackEnergy 2 (alias BlackEnergy Version 2) Live Debugging-registry-u00252beditor-u00252bhidden-png

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


    BlackEnergy 2 (alias BlackEnergy Version 2) Live Debugging-hidden-u00252bregistry-png

    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

    Code:
    .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:


    BlackEnergy 2 (alias BlackEnergy Version 2) Live Debugging-str-png

    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
    blueelvis says thanks for this.


    • Ad Bot

      advertising
      Beep.

        
       

  2. #2
    x BlueRobot's Avatar
    Join Date
    May 2013
    Location
    Minkowski Space
    Posts
    1,749

    Re: BlackEnergy 2 (alias BlackEnergy Version 2) Live Debugging

    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/...ERT-14-281-01A
    Patrick says thanks for this.
    Machines Can Think

    Oxygen, Nature's paradox.

  3. #3

    Re: BlackEnergy 2 (alias BlackEnergy Version 2) Live Debugging

    Interesting, I'll take a look.

  4. #4

    Re: BlackEnergy 2 (alias BlackEnergy Version 2) Live Debugging

    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 says thanks for this.

  5. #5

    Re: BlackEnergy 2 (alias BlackEnergy Version 2) Live Debugging

    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.
    gandolf, blueelvis and Jared say thanks for this.

  6. #6
    Jared's Avatar
    Join Date
    Feb 2014
    Age
    20
    Posts
    1,568
    • specs System Specs
      • Manufacturer:
        Custom
      • Motherboard:
        ASUS Maximus VII Ranger
      • CPU:
        i7 4790K @ 4.4GHz
      • Memory:
        Corsair Vengeance 16GB 1866MHz
      • Graphics:
        MSI Gaming 4G GTX 980
      • Sound Card:
        Creative Soundblaster ZxR
      • Hard Drives:
        Samsung 850 SSD 250GB
      • Disk Drives:
        Western Digital Black Caviar 2TB
      • Power Supply:
        Corsair RM650 Modular 650 Watts
      • Case:
        Fractal Design Define R5 Window
      • Cooling:
        Corsair H100i GTX
      • Display:
        Dell U2515H 25inch 2560x1440 + LG Flatron M2262D 22inch 1920x1080
      • Operating System:
        Windows 10 Professional x64

    Re: BlackEnergy 2 (alias BlackEnergy Version 2) Live Debugging

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

  7. #7

    Re: BlackEnergy 2 (alias BlackEnergy Version 2) Live Debugging

    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.
    Last edited by Patrick; 11-04-2014 at 02:44 PM.

  8. #8

    Re: BlackEnergy 2 (alias BlackEnergy Version 2) Live Debugging

    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

  9. #9
    Forum Moderator, BSOD
    BSOD Kernel Dump Expert
    Contributor
    blueelvis's Avatar
    Join Date
    Apr 2014
    Location
    India
    Age
    22
    Posts
    969
    • specs System Specs
      • Manufacturer:
        Toshiba
      • CPU:
        Intel Core i5 @ 2.4 GHz 2nd Generation
      • Memory:
        8 GB @ 1600MHz Dual Channel B)
      • Graphics:
        Intel HD 3000 B)
      • Hard Drives:
        Hitachi 1TB 7200 RPM & WD 500 GB
      • Cooling:
        There is some fan inside but it keeps whirring <_<
      • Display:
        1366x768
      • Operating System:
        Windows 8.1 Embedded Industry Pro

    Re: BlackEnergy 2 (alias BlackEnergy Version 2) Live Debugging

    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
    Ever wanted to learn to debug BSODs? PM me now!

    Feel free to PM me in case I haven't replied within 48 Hours ^_^. Anything else? Still feel free to PM me :thumbsup2:

Similar Threads

  1. Rustock.B Live Debugging
    By Patrick in forum BSOD Kernel Dump Analysis Debugging Information
    Replies: 5
    Last Post: 11-03-2014, 11:57 PM
  2. DPC_WATCHDOG_TIMEOUT Debugging
    By Jared in forum BSOD Kernel Dump Analysis Debugging Information
    Replies: 0
    Last Post: 09-14-2014, 08:49 AM
  3. Debugging TV
    By Shintaro in forum BSOD Kernel Dump Analysis Debugging Information
    Replies: 1
    Last Post: 09-12-2012, 10:03 AM
  4. Debugging TV
    By Shintaro in forum BSOD, Crashes, Kernel Debugging
    Replies: 1
    Last Post: 09-12-2012, 10:03 AM

Log in

Log in