Detricking TrickBot Loader

Date of publication: 05/02/2019, Michał Praszmo


    TrickBot (TrickLoader) is a modular financial malware that first surfaced in October in 20161. Almost immediately researchers have noticed similarities with a credential-stealer called Dyre. It is still believed that those two families might’ve been developed by the same actor.

    But in this article we will not focus on the core itself but rather the loader whose job is to decrypt the payload and execute it.

    Samples analyzed

    • preloader b401a0c3a64c2e5a61070c2ae158d3fcf8ebbb51b33593323cd54bbe03d3de00
    • loader 8d56f6816f24ec95524d6b434fc25f9aad24a27dbb67eab0106bbd7b4160dc75
    • core-32b cbb5ea4210665c6a3743e2b7c5a29d10af21efddfbab310035c9a14336c71de3
    • core-64b 028e29ef2543daa1729b6ac5bf0b2551dc9a4218a71a840972cdc50b23fe83c4
    • core-64b-loader 52bc216a6de00151f32be2b87412b6e13efa5ba6039731680440d756515d3cb9

    Original binary

    While the binary has two consecutive loaders, the first one will be glossed over because of low level of complexity:

    first stage

    Original binary’s entry point, observed symbols were embedded in the binary

    Functions buffer

    The first thing we notice after loading the RC4-decrypted payload from the previous stage is that IDA hasn’t automatically recognized a single valid function.

    start_addr

    The binary’s entry point

    This section’s permissions are also looking quite suspicious, because section needs to be readable, executable and writable.

    Function that starts just after the chunks lengths’ last entry (begins at 0x40108C), is responsible for calculating the starting offset for each function (or binary chunk) and storing it into an array stored on stack.

    calculate_addresses.png

    Function used for calculating addresses

    The functions’ objective is pretty straight-forward:

    • Iterate over the null-terminated chunks lengths array
    • If a length is larger than or equal to 0xFFF0, fetch the full length from a second buffer located further in the data (+0xCDFA in this sample)
    • Add the current function’s length to the accumulator
    • Push the accumulator onto stack

    The final array of pointers looks as follows (remember that since values are pushed onto stack, the pointers are reversed relatively to their position in the lengths array):

    pointers_on_stack.png

    The pointer to the array is stored in EBP register and passed between almost all functions in the future

    Code encryption

    The previously mentioned code encryption is done using a standard repeating xor cipher:

    The xor key seems to be located around the base64-encoded strings:

    encryption_key

    In this sample, the key is equal to FE9A184E408139843FA99C45943D

    Detricking

    All we really have to do is iterate over all functions, decrypt their body with xor and mark the functions.

    Wrapper function

    As seen in previous screenshots, all function calls are performed using a function wrapper that:

    • Accepts index of the function to execute
    • Grabs the function’s address from the global table
    • Decrypts the function code
    • Calls the decrypted function
    • Encrypts the function code back again

    wrapper_args

    Example function wrapper call

    Detricking

    In order to simplify our analysis we’ll patch the binary and replace the wrapper calls with direct function calls.

    Almost every wrapper call is exactly the same, which will be very helpful:

    XX is a single unsigned byte that determines the index of the wrapped function.

    YY YY YY YY is a 32-bit, relative, little-endian integer that marks the address of the wrapper function.

    Our plan is to patch the whole call blob to:

    where ZZ ZZ ZZ ZZ is the relative address of the wrapped function.

    To do that, we’ll use an idapython script:

    Before:

    After:

    Imports

    All imports are loaded into a static location in memory using a hash lookup:

    hash_function

    Function used to calculate strings hash

    C decompilation:

    api_hashes

    Function hash list

    Detricking

    We can find the correct API function table using different methods but we are going to focus on doing it manually by looking for the correct function name.

    Start off by rewriting the hash function to Python:

    We’ll also need a list of functions exported by windows DLLs. We’ve found that scraping http://www.win7dll.info/ actually works pretty well for that purpose.

    Now we need to iterate over all hashes and find a correct function name for each one:

    All that’s left now is to create an IDA struct that contains the function names and set the global array to the proper type:

    api_before

    Before

    api_after

    After

    Now, it looks much better!

    String encoding

    All strings are encoded using base64 with a custom alphabet, it’s explained pretty well in several blog posts already 23

    The custom charset is a permutation of the default base64 charset, e.g. JTQ2czLo5NfrsUjZFSkgOlYRB6yKhva/uA83d4GiteMwn17xmIEVX+qP0W9DbHCp.

    base64_decode

    Function used to fetch a decrypted base64 string with a given index

    Detricking

    After de-wrapping the function calls, the assembly actually looks quite similar to the previous iteration (notice the nops that are result of our earlier patches):

    Which means we can reuse some of our previous code. But instead of patching the call instructions to mov instructions, we’re just going to add comments in assembly to annotate the original string:

    Overview

    After applying all of the described anti-anti-analysis patches, we end up with a pretty decent-looking binary.

    Main function:

    Anti-debugging/sandbox checks

    DLL checks

    The binary iterates over DLL names stored in strings and checks if any of them is present in the PEB InMemoryOrderModuleList linked list:

    DLLs checked:

    • pstorec.dll
    • vmcheck.dll
    • dbghelp.dll
    • wpespy.dll
    • api_log.dll
    • SbieDll.dll
    • SxIn.dll
    • dir_watch.dll
    • Sf2.dll
    • cmdvrt32.dll
    • snxhk.dll

    Antimalware services

    A series of checks is performed using QueryServiceStatusEx in order to detect any anti-malware services currently running on the system. If a service is detected, the loader tries to disable it accordingly:

    • WinDefend
      • cmd.exe /c sc stop WinDefend
      • cmd.exe /c sc delete WinDefend
      • TerminateProcess MsMpEng.exe
      • TerminateProcess MSASCuiL.exe
      • TerminateProcess MSASCui.exe
      • cmd.exe /c powershell Set-MpPreference -DisableRealtimeMonitoring $true
      • RegSetValue SOFTWARE\Policies\Microsoft\Windows Defender DisableAntiSpyware
      • RegSetValue SOFTWARE\Microsoft\Windows Defender Security Center\Notifications DisableNotifications
    • MBAMService
      • ControlService MBAMService SERVICE_CONTROL_STOP
    • SAVService
      • TerminateProcess SavService.exe
      • TerminateProcess ALMon.exe
      • cmd.exe /c sc stop SAVService
      • cmd.exe /c sc delete SAVService
      • Checks IEFO4. key for ‘MBAMService’,’SAVService’,’SavService.exe’,’ALMon.exe’,’SophosFS.exe’,’ALsvc.exe’,’Clean.exe’,’SAVAdminService.exe’ and sets Debugger registry key to kjkghuguffykjhkj if a match is found

     

    Loading binary

    The binaries embedded in the loader are encrypted using the same xor cipher method as the functions, however they are also compressed using MiniLZO 2.

    The methods of executing the payload differ for 32 and 64-bit binaries. While the former is pretty straight-forward, the latter integrated a more sophisticated code injection technique.

    Firstly, a new suspended process is created (in this sample with process name equal to “svchost”), then the execution transfers to a dynamically-generated shellcode that performs a switch from 32-bit compatibility mode to 64-bit using a trick called Heaven’s Gate5.
    Finally, the shellcode performs a call to the decrypted 64-bit helper shellcode which then finally jumps to the 64-bit core.

    The included shellcode deassembles to

     

    Modules

    As of today, TrickBot is distributing following modules:

    • domainDll32.dll
      • bf50566d7631485a0eab73a9d029e87b096916dfbf07df4af2069fc6eb733183
    • importDll32.dll
      • f9ebf40d1228fa240c64d86037f2080588ed67867610aa159b80a553bc55edd7
    • injectDll32.dll
      • a515f4f847e8d7b2eb46a855224c8f0e9906435546bb15785b6770f2143bc22a
    • mailsearcher32.dll
      • 46706124d4c65111398296ea85b11c57abffbc903714b9f9f8618b80b49bb0f3
    • networkDll32.dll
      • c8c789296cc8219d27b32c78e595d3ad6ee1467d2f451f627ce96782a9ff0c5f
    • outlookDll32.dll
      • 9a529b2b77c5c8128c4427066c28ca844ff8ebbd8c3b2da27b8ea129960f861b
    • pwgrab32.dll
      • fe0f269a1b248c919c4e36db2d7efd3b9624b46f567edd408c2520ec7ba1c9e4
    • shareDll32.dll
      • af5ee15f47226687816fc4b61956d78b48f62c43480f14df5115d7e751c3d13d
    • squlDll32.dll
      • b8b757c2a3e7ae5bb7d6da9a43877c951fb60dcb606cc925ab0f15cdf43d033b
    • systeminfo32.dll
      • dff1c7cddd77b1c644c60e6998b3369720c6a54ce015e0044bbbb65d2db556d5
    • tabDll32.dll
      • 479aa1fa9f1a9af29ed010dbe3b080359508be7055488f2af1d4b10850fe4efc
    • wormDll32.dll
      • 627a9eb14ecc290fe7fb574200517848e0a992896be68ec459dd263b30c8ca48

     

    References

    1 https://blog.malwarebytes.com/threat-analysis/2016/10/trick-bot-dyrezas-successor/

    1 https://sysopfb.github.io/malware/2018/04/16/trickbot-uacme.html

    2 https://blog.malwarebytes.com/threat-analysis/malware-threat-analysis/2018/11/whats-new-trickbot-deobfuscating-elements/

    4 https://blog.malwarebytes.com/101/2015/12/an-introduction-to-image-file-execution-options/

    5 http://rce.co/knockin-on-heavens-gate-dynamic-processor-mode-switching/