n1ghtw0lf

Deep Analysis of GCleaner

2023-07-15T00:00:00+00:00

Howdy! I’m finally back with another malware deep dive report. This time we are digging into GCleaner.

GCleaner is a Pay-Per-Install (PPI) loader first discovered in early 2019, it has been used to deploy other malicious families like Smokeloader, Amadey, Redline and Raccoon.

We will be working on this sample:

(SHA256: 020d370b51711b0814901d7cc32d8251affcc3506b9b4c15db659f3dbb6a2e6b)

Initial Triage

Let’s start by running the sample in Triage sandbox to get an overview of what it does.

We can see from the process tree that it drops and runs another binary out of "%APPDATA%" folder with a seemingly random name then it kills itself using "taskkill" and deletes the sample binary from disk.

The network tab shows communications to different IP addresses which are considered as C2 servers in Triage’s malware config tab. Each C2 has a different URL path, we will dig deeper to find out what each of them is responsible for.

Right when we open the sample in IDA we don’t have much to look at, there are some interesting strings and API imports but not very helpful to start with.

We can see a repeated pattern across the code where some values are pushed into the stack then xored with 0x2E, so we first need to decrypt these values.

String Decryption

Automating the decryption for stack strings in this sample can be a bit tricky, luckily I noticed a specific instruction that occurs after loading the encrypted strings into stack (cmp eax, [reg+4]).

So we can find all occurrences of this instruction then walk back to find the mov instructions and get the encrypted values. Let’s apply this to an IDA python script.

# Lowest address used in the program
addr = idc.get_inf_attr(INF_MIN_EA)

while True:
    # Search for "cmp eax, [reg+4]"
    addr = ida_search.find_binary(addr, idc.BADADDR, "3B ?? 04 00 00 00", 16, ida_search.SEARCH_NEXT | ida_search.SEARCH_DOWN)
    if addr == idc.BADADDR:
        break

    enc_bytes = b''
    # Search for possible stack strings in the previous 12 instructions
    for i in range(12):
        ea = idc.prev_head(ea)
        if (idc.print_insn_mnem(ea) == "mov" and
            idc.get_operand_type(ea, 0) == idc.o_displ and
            idc.get_operand_type(ea, 1) == idc.o_imm):
            # Get the value of the second operand
            operand_value = idc.get_operand_value(ea, 1)

The returned operand value is an integer but we need to store it as a byte array, so we first need to figure out the size of that operand to store it correctly.

            # Get the size of the second operand
            insn = ida_ua.insn_t()
            ida_ua.decode_insn(insn, ea)
            operand_size = ida_ua.get_dtype_size(insn.Op2.dtype)
            
            # Specify the correct data type
            if operand_size == 4:
                operand_bytes = struct.pack("<I", operand_value)
            elif operand_size == 2:
                operand_bytes = struct.pack("<H", operand_value)
            else:
                operand_bytes = struct.pack("<B", operand_value)
                
            enc_bytes = operand_bytes + enc_bytes

One more thing I noticed is that some strings use a combination of stack values and other values stored in the ".rdata" section (retrieved using the XMM instruction "movaps").

So we can search for this "movaps" instruction after the "cmp" instruction, if found we can read the values stored at its operand address and append it to the encrypted bytes.

    # Find possible xmmword movaps
    xmmword_addr = ida_search.find_binary(addr, addr+50, pattern2, 16, ida_search.SEARCH_NEXT | ida_search.SEARCH_DOWN)
    if xmmword_addr != idc.BADADDR:
        # Read the xmmword value
        xmmword_value = idc.get_bytes(get_operand_value(xmmword_addr, 1), 16)
        enc_bytes = xmmword_value + enc_bytes

Finally we can xor the encrypted values with 0x2E (this key has been the same for all GCleaner samples I looked at).

    # Decrypt and strip encrypted bytes
    dec_bytes = bytes(c ^ 0x2E for c in enc_bytes)
    dec_str = dec_bytes.strip(b'\x00').decode('utf-8')
   
    if len(dec_str) != 0:
        print(f"{hex(addr)} --> {dec_str}")

        # Set a comment with the decrypted string
        if dec_str and comment_addr != idc.BADADDR:
            set_comment(comment_addr, dec_str)

Here is the list of decrypted strings:

    
            Expand to see more
        
  45.12.253.56

  45.12.253.72

  45.12.253.98

  45.12.253.75/dll.php

  mixinte

  mixtwo

  B

  USERPROFILE

  CCleaner

  VLC media player

  Acrobat Reader DC

  Russian

  admin

  Shah

  testBench

  taskmgr

  Taskmgr

  wireshark

  Process Hacker

  Wireshark

  C:\Program Files

  C:\ProgramData

  C:\Temp

  C:\Program Files

  C:\ProgramData

  C:\Temp

  /advertisting/plus.php?s=

  &str=mixtwo

  &substr=

  /default/stuk.php

  /default/puk.php

  NOSUB

  chk

  /chk

  test

We can now see the C2 IPs, URL paths and some other interesting strings. Let’s keep going.

Anti Checks (or is it..?)

GCleaner is filled with host checks but weirdly enough it doesn’t do anything them, maybe they were like test features? copy-paste code? not really sure but let’s quickly go though them.

Checking username

Get the current username using "GetUserNameA()" and compare it to hardcoded names ("admin", "Shah", "testBench").

Checking foreground window

Get the title of the foreground window using "GetWindowTextA()" and compare it to hardcoded strings.

Checking desktop files

Search for Desktop files with specific strings in their name ("CCleaner", "VLC media player", "Acrobat Reader DC").

Checking locale and keyboard layout

Check if the computer locale is Russian and compare the keyboard layout against specific values (CIS countries).

Dropped Binary

Looking back at the process tree we need to figure out where does that child binary with random name comes from. "%APPDATA%\{846ee340-7039-11de-9d20-806e6f6e6963}\34LMAylZs6FixF.exe"

We can see below that the sample reads the "%APPDATA%" path using "getenv()" then creates a random directory using the GUID of the current hardware profile, if retrieving the hardware profile failed it will fall back to generating a random folder name. Other possible locations for creating the random directory are "C:\Program Files", "C:\Temp", "C:\ProgramData" (fallback locations).

Next it generates a random file name, appends ".exe" extension to it then drops it to the newly created directory and runs it from there.

The binary file is hardcoded into the parent sample.

All that binary child does is…well…sleep for 10 seconds, that’s it :|

C2 Communications

The actors behind GCleaner have been known to use BraZZZers fast flux service to hide their infrastructure, it works more like a proxy system between the victims and the real C2 server.

Before reaching out to the C2 servers, GCleaner adds hardcoded HTTP headers (could be used for a network sig) an a custom user-agent to each C2 request.

Now to figure out what each C2 request is responsible for.

First C2

IP: 45[.]12.253.56
UA: OK
PCAP:

This C2 is likely responsible for bot registration. The sample will only continue execution if the server response is "0" or "1", otherwise it goes to sleep and tries again.

The "str" and "substr" parameters in the C2 request above are possibly referring to the campaign ID, GCleaner has been known to use similar values in the past like "usone", "ustwo", "euthree", "cafive", "mixshop", …

Second C2

IP: 45[.]12.253.72
UA: OK
PCAP:

The first request to this C2 is responsible for getting an AES key.

The key length must be between 10 and 100 bytes, otherwise it breaks the execution.

The second request is responsible for getting an AES encrypted PE file (notice the filename in the response headers!), That PE file is decrypted using the key from the previous request.

The decryption routine is pretty trivial, the sample first calculates the SHA256 hash of the server key then derives the session key used for decryption (AES_128).

After that it loads the decrypted PE file into memory (without touching disk) to get the address of an export function called "GetLicInfo" which is used in the next stage.

Downloaded DLL

Before going further we first need to take a look at the downloaded PE file. To be able to analyze it we can either use the debugger to dump the decrypted file or get the encrypted response from the PCAP and decrypt it manually.

We can easily implement the decryption code in Python as follow:

import hashlib
from Crypto.Cipher import AES

enc = open("puk.php.bin", "rb").read()

key = "kvQoRqtcCyMtHmQyQXOUu".encode("utf-16le") # Important to encode!!
sha256_hash = hashlib.sha256(key)
aes_key = sha256_hash.digest()[:16]

cipher = AES.new(aes_key, mode=AES.MODE_CBC, IV=b"\x00"*16)
dec = cipher.decrypt(enc)

open("out.bin", "wb").write(dec)

Now let’s see what this export function "GetLicInfo" does.

Basically it sends an http request to the supplied C2 server then checks the response length, if the length is greater than 2048 bytes it creates a a new directory with a random name under "%APPDATA%" or "%TEMP%" folder then generates a random filename and appends ".exe" extension to it.

Finally it writes the server response to a disk file with the generated random filename and executes that file.

Third C2

IP: 45[.]12.253.75
UA: B
PCAP:

This C2 is responsible for downloading further payloads, notice the user-agent used here is the one from the decrypted strings list unlike the previous 2 C2s.

The address is supplied to the external function "GetLicInfo" which downloads and executes the payload as we stated above. GCleaner tries to get a payload from the server for 10 iterations with a sleep period of 2 seconds between every try.

If no further payload is received from the server the samples kills its process and deletes the parent file from disk.

Forth C2

IP: 45[.]12.253.98

This C2 wasn’t used in the sample we are looking at.

Config Extraction

We can use the IDA python script we used for string decryption to build a standalone config extractor as most of the interesting stuff are in the decrypted strings list.

Here’s the output of the code after extracting the useful information:

The code can be found here.

(this script is not optimized for production, it’s just for research purposes)

Hunting

Urlscan

The URL path of the first C2 request can be a good candidate to hunt for more C2s on urlscan.

I looked at more samples and found these two URL patterns:

s=NOSUB&str=...&substr=...
sub=NOSUB&stream=...&substream=...

So we can use the "page.url" field to search for the first part of these patterns.

Yara

We saw that many strings were encrypted but we can use some of the hardcoded ones to create a simple yara rule for hunting more samples.

rule GCleaner {
    meta:
        description = "Detects GCleaner payload"
        author = "Abdallah Elshinbary (@_n1ghtw0lf)"
        hash1 = "020d370b51711b0814901d7cc32d8251affcc3506b9b4c15db659f3dbb6a2e6b"
        hash2 = "73ed1926e850a9a076a8078932e76e1ac5f109581996dd007f00681ae4024baa"

    strings:
        // Kill self
        $s1  = "\" & exit" ascii fullword
        $s2  = "\" /f & erase " ascii fullword
        $s3  = "/c taskkill /im \"" ascii fullword
        // Anti checks
        $s4  = " Far " ascii fullword
        $s5  = "roxifier" ascii fullword
        $s6  = "HTTP Analyzer" ascii fullword
        $s7  = "Wireshark" ascii fullword
        $s8  = "NetworkMiner" ascii fullword
        // HTTP headers
        $s9  = "Accept-Language: ru-RU,ru;q=0.9,en;q=0.8" ascii fullword
        $s10 = "Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1" ascii fullword
        $s11 = "Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0" ascii fullword
        $s12 = "Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1" ascii fullword
    
    condition:
        uint16(0) == 0x5a4d and
        10 of them
}

References

Dotnet String Decryptor

2023-06-15T00:00:00+00:00

Welcome back! This is a short blog post about reverse engineering dotnet malware.

When working with dotnet malware samples I always come around samples with obfuscated strings which makes analysis harder.

My go to way to handle this situation was to identify the string decryption routine (through static/dynamic analysis) then use de4dot to decrypt the strings.

But sometimes you don’t want to go through every sample and find the decryption routine or you need to automate this process for a collection of different samples.

While looking around for a solution I found this cool blog, so I will be building on it to write a generic dotnet string decryptor which will hopefully make life a bit easier.

We will be working on an obfuscated sample of DCRat to test our script. c6244c8e4e4cdecd641017d52d344b1db6a23d05fd6a8ad338c8f4f77481f483

Writing the deobfuscation script

Step 1 : Importing libs and loading the .NET file

We first need to install pythonnet which allows CLR namespaces to be treated essentially as python packages.

pip install pythonnet

Then we can import the required reflection modules which we will use later to get and invoke decryption methods.

import clr
from System.Reflection import Assembly, BindingFlags, MethodInfo

We also need to add a reference to dnlib.dll which we will use to parse the .NET assemblies and modules.

clr.AddReference("./dnlib")

import dnlib
from dnlib.DotNet import ModuleDef, ModuleDefMD
from dnlib.DotNet.Emit import OpCodes
from dnlib.DotNet.Writer import ModuleWriterOptions

Now we can load our .NET file.

file_module = ModuleDefMD.Load(file_path)
file_assembly = Assembly.LoadFile(file_path)

Step 2 : Finding suspected decryption methods

Before we get any further we need to define the signatures of the suspected methods that are used for string decryption.

A method signature consists of the type of its parameters and its return type.

Below is the string decryption method in the sample we are working on:

I also found some wrapper methods that call the decryption method and they had a different signature.

So we can define our suspected method signatures as follows:

DECRYPTION_METHOD_SIGNATURES = [
    {
        "Parameters": ["System.Int32"],
        "ReturnType": "System.String"
    },
    {
        "Parameters": ["System.Int32"],
        "ReturnType": "System.Object"
    },
]

Of course there could be other methods with similar signatures which are not related to string decryption, but invoking them shouldn’t affect the end result (and you better run the script in a sandboxed environment).

Next we use the reflection modules to loop through the methods of each Type (classes, interfaces, …) and find suspected methods based on the list of signatures we defined above.

# Search for static, public and non public members
eFlags = BindingFlags.Static | BindingFlags.Public | BindingFlags.NonPublic

for module_type in file_assembly.GetTypes():
    for method in module_type.GetMethods(eFlags):

If we find a suspected method we need to store its corresponding signature and MethodInfo object which we will use later to invoke that method.

        # Check if the current method has a suspected signature
        for sig in StringDecryptor.DECRYPTION_METHOD_SIGNATURES:
            # Check number of parameters and return type
            parameters = method.GetParameters()
            if ((len(parameters) == len(sig["Parameters"])) and
                (method.ReturnType.FullName == sig["ReturnType"])):
               
                # Check parameters types
                param_types_match = True
                for i in range(len(parameters)):
                    if parameters[i].ParameterType.FullName != sig["Parameters"][i]:
                        param_types_match = False
                        break

                if param_types_match:
                    # Store the signature and MethodInfo object of the current method
                    method_name = f"{method.DeclaringType.FullName}::{method.Name}"
                    suspected_methods[method_name] = (sig, method)

Step 3 : Finding references to suspected methods

The next step is to find references to the suspected methods so we can get the required parameters.

To do this we can use dnlib modules to loop through the CIL instructions of each method and find calls to these methods.

for module_type in file_module.Types:
    if not module_type.HasMethods:
        continue

    for method in module_type.Methods:
        if not method.HasBody:
            continue

        # Loop through method instructions
        for insnIdx, insn in enumerate(method.Body.Instructions):
            # Find Call instructions
            if insn.OpCode == OpCodes.Call:
                for s_method_name, (s_method_sig, s_method_info) in suspected_methods.items():
                    # Check if the callee is one of the suspected methods
                    if str(s_method_name) in str(insn.Operand):

If we find a reference call, we need to get the required parameters (note that they are pushed to the stack in reverse order).

                                # Get method parameters in reverse order
                                params = []
                                for i in range(len(s_method_sig["Parameters"])):
                                    operand = GetOperandValue(
                                        method.Body.Instructions[insnIdx - i - 1],
                                        s_method_sig["Parameters"][-i - 1])
                                    if operand is not None:
                                        params.append(operand)

                                # Check if we got all the parameters
                                if len(params) == len(s_method_sig["Parameters"]):

Next we can invoke suspected methods to get the decrypted strings

                                    # Invoke suspected method
                                    try:
                                        result = str(s_method_info.Invoke(None, params[::-1]))
                                    except Exception as e:
                                        continue

Step 4 : Patching

If the method invoke succeeded we can safely patch the method parameters with NOPs and patch the method call itself with the decrypted string.

                                    # Patch suspected method parameters with NOPs
                                    for i in range(len(s_method_sig["Parameters"])):
                                        method.Body.Instructions[insnIdx - i - 1].OpCode = OpCodes.Nop

                                    # Patch suspected method call with the result string
                                    method.Body.Instructions[insnIdx].OpCode = OpCodes.Ldstr
                                    method.Body.Instructions[insnIdx].Operand = result
                                    decrypted_strings.append(result)

Step 5 : Saving

Finally we can save the deobfuscated file to disk.

# Add writer options to ignore dnlib errors
options = ModuleWriterOptions(file_module)
options.Logger = dnlib.DotNet.DummyLogger.NoThrowInstance

# Write cleaned module content
file_module.Write("out.bin", options)

Testing and final notes

Let’s run the script on the sample we have and see the results.

Perfect, now it’s much easier to work on the sample and analyze its functionalities.

A little something before we wrap up, you can check if a PE is a dotnet file by checking the existence of the IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR data directory (at index 14).

dotnet_dir = pefile.DIRECTORY_ENTRY['IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR'] # COM descriptor table index
if pe.OPTIONAL_HEADER.DATA_DIRECTORY[dotnet_dir].VirtualAddress == 0:
    sys.exit("[-] File is not .NET")

The full code can be found here.

Until next time, cheers!

Writing x64dbg plugins

2022-12-17T00:00:00+00:00

In the previous post we talked about writing x64dbg scripts, now let’s dive deeper and write our own plugin to do the same job (automatically dumping unpacked PE payloads in memory).

x64dbg comes with an integrated plugin SDK for creating plugins using C++.

Setup

The easiest way to create a plugin is to use the PluginTemplate to create a new repository for your plugin.

Next you can edit cmake.toml which contains the project configuration, for this tutorial we will only change the name and target values to our plugin name.

name = "EasyDump"
....
[target.EasyDump]

To build the project for 64-bit –> build64\ProjectName.sln

cmake -B build64 -A x64
cmake --build build64 --config Release

To build the project for 32-bit –> build32\ProjectName.sln

cmake -B build32 -A Win32
cmake --build build32 --config Release

Plugin structure

A plugin must have an exported function called pluginit, this is the first function that gets called when the plugin is loaded and where the plugin data is initialized.

Other optional exports are:

plugstop:

called when the plugin is about to be unloaded and where the plugin data cleanup occurs.

plugsetup:

called when the plugin initialization was successful, here you can register menus and other GUI-related things.

SDK functions

Before we go any further we need to know what functions exported by the plugin SDK we can use, you can find some of these functions in the official docs but many of them are not documented.

To view the full list you can explore the SDK header files.

For me plugin SDK functions are divided into 4 main categories:

_plugin_ functions @_plugins.h:

Helper functions for plugin setup, initialization and logging.
bridge functions @bridgemain.h:

Bridge is the communication library for the DBG and GUI part of x64dbg.
scriptapi functions @_scriptapi_*.h:

It is intended to be used by plugins. It provides easy scripting experience for developers.
TitanEngine functions @TitanEngine.h:

Titan is the debugging engine for x64dbg.

Most functions are self explanatory or documented in the official docs, for TitanEngine functions you can find its docs here or you can check the markdown version for better readability I uploaded here.

Ok enough talk let’s get our hands dirty.

Implementation

Your code should go into plugin.cpp file, let’s start with the plugin main components.

// Initialize your plugin data here.
bool pluginInit(PLUG_INITSTRUCT* initStruct)
{
    _plugin_logputs("[" PLUGIN_NAME "] Loaded successfully!");

    if (!_plugin_registercommand(pluginHandle, "EasyDump", cbEasyDump, true))
        return fail("Failed to register command");

    return true; // Return false to cancel loading the plugin.
}

// Deinitialize your plugin data here.
void pluginStop()
{
    _plugin_unregistercommand(pluginHandle, "EasyDump");
}

First we need to register a command that we can use in the command prompt using _plugin_registercommand function, The definition for this function is:

bool _plugin_registercommand(
	int pluginHandle,          // Plugin handle
	const char* command,       // Command name
	CBPLUGINCOMMAND cbCommand, // Callback function
	bool debugonly             // Restrict the command to debug-only
);

And of course don’t forget to unregister this command inside pluginStop using _plugin_unregistercommand.

Now let’s implement the callback function.

static bool cbEasyDump(int argc, char* argv[]) {
    // Delete All BPs
    DbgCmdExec("bpc");

    // Set BP on VirtualAlloc ret
    if (!SetAPIBreakPoint("kernelbase.dll", "VirtualAlloc", UE_BREAKPOINT, UE_APIEND, cbVirtualAlloc))
        fail("Failed to set a Breakpoint on VirtualAlloc");

    // Set BP on VirtualProtect start
    if (!SetAPIBreakPoint("kernelbase.dll", "VirtualProtect", UE_BREAKPOINT, UE_APISTART, cbVirtualProtect))
        fail("Failed to set a Breakpoint on VirtualProtect");

    _plugin_logprint("[" PLUGIN_NAME "] Starting the program...\n");
    DbgCmdExec("run");

    return true;
}

Callback arguments are passed in argv starting at index 1, but our command doesn’t need any arguments.

We will start with deleting all breakpoints to let the plugin run without interruption using DbgCmdExec to execute bpc command (breakpoint clear).

Next we set our breakpoints using SetAPIBreakPoint function which is defined as:

bool __stdcall SetAPIBreakPoint(
    char* szDLLName,   // DLL name
    char* szAPIName,   // API name
    DWORD bpxType,     // UE_BREAKPOINT or UE_SINGLESHOOT
    DWORD bpxPlace,    // UE_APISTART or UE_APIEND
    LPVOID bpxCallBack // Callback function
);

For VirtualAlloc we need to set the breakpoint at return so we will use UE_APIEND as the bpxPlace value.

Next we do some logging and run the program.

// VirtualAlloc BP callback
static void cbVirtualAlloc() {
    mem_addr = Script::Register::GetCAX();
    // auto x = GetFunctionParameter(DbgGetProcessHandle(), UE_FUNCTION_STDCALL_RET, 2, UE_PARAMETER_DWORD);
    mem_size = DbgEval("arg.get(1)");

    _plugin_logprintf("[" PLUGIN_NAME "] VirtualAlloc addr: %x\n", mem_addr);
    _plugin_logprintf("[" PLUGIN_NAME "] VirtualAlloc size: %x\n", mem_size);
}

When reach the VirtualAlloc callback the allocated memory address would be stored at EAX/RAX, we can use the scriptapi register function GetCAX to read this value (remember x64dbg provides special registers for architecture-independent code).

To get the memory size stored at the second argument we can use DbgEval to evaluate arg.get(1) command and get its result.

// VirtualProtect BP callback
static void cbVirtualProtect() {
    auto header = Script::Memory::ReadWord(mem_addr);
    // Check for MZ header
    if (header == 0x5a4d) {
        _plugin_logprintf("[" PLUGIN_NAME "] Found a PE file at addr: %x\n", mem_addr);

        // Build dumping path
        char path[MAX_PATH];
        Script::Module::GetMainModulePath(path);
        sprintf(path, "%s\\memdump_%X_%zx_%zx.bin", getParentPath(path), DbgGetProcessId(), mem_addr, mem_size);

        // Dump payload to disk
        if (DumpMemory(DbgGetProcessHandle(), (LPVOID)mem_addr, mem_size, path))
            _plugin_logprintf("[" PLUGIN_NAME "] Dumped payload at %s\n", path);
        else
            fail("Failed to dump the payload");
    }
}

When we hit VirtualProtect we can read the first 2 bytes from the allocated memory address to check for the MZ header.

To build a dumping path similar to :memdump: from savedata command we need to get the current module path using GetMainModulePath, get the current process ID using DbgGetProcessId and append the memory address and size to them.

Finally to dump the payload to disk we can use DumpMemory passing it the current process handle using DbgGetProcessHandle, memory address, memory size and file path.

Trying our plugin

After building the plugin we need to move the plugin files which end with .dp32 or .dp64 depending on the build configuration to x64dbg\release\(x32|x64)\plugins.

To load the the plugin we can restart x64dbg and it will be loaded automatically or just use loadplugin command passing it the plugin name like this loadplugin EasyDump.

Finally we can run EasyDump (the command we registered in pluginInit) and watch the magic happen…again.

source code: https://github.com/N1ght-W0lf/EasyDump

Updates

Some notes from Duncan Ogilvie @mrexodia

As a general rule I’d avoid using the TitanEngine APIs directly. They can cause some weird scenarios where x64dbg doesn’t know about a breakpoint for example. Unfortunately the plugin API isn’t very strong on this front though, so it’s a lot more work to do the same…

Also something worth exploring is the C# scripting plugin: https://github.com/x64dbg/DotX64Dbg

And confusingly DbgCmdExec (queues a command asynchronously) causes a race condition in your example. Likely you want DbgCmdExecDirect instead (executed the implementation of the command directly)

Final words

The goal of this tutorial was to learn more about x64dbg not write the best dumping plugin :)

This tutorial wouldn’t be possible without the help of the official x64dbg docs and blog, you can check them out for more in depth info.

You can also find many cool x64dbg plugins here that can make your life easier.

Special thanks to @mrexodia (creator of x64dbg and many other projects) for his awesome work, you can support him here.

I hope you learned something new, until next time.

Writing x64dbg scripts

2022-12-16T00:00:00+00:00

x64dbg is an open-source x64/x32 debugger for windows, it has dozens of features that make the life of reverse engineers and malware analysts easier.

One of the coolest features of x64dbg is that it’s extendable, it comes with a debuggable scripting language and a software development kit for writing your own plugins.

In this post we will talk about x64dbg scripting and in the next one we will talk about plugins.

Scripts are just a sequence of commands, you can see all the available commands here.

To execute a command you can simply type it in the command prompt and check the result in the Log window.

For this tutorial we will write a simple script to automatically dump unpacked PE payloads in memory.

The unpacking workflow (how I usually do it) is to set a breakpoint at VirtualAlloc and VirtualProtect, run the program and follow the memory allocations in dump waiting for the MZ header to appear then dump that memory region. Let’s use the power of scripting to automate this process.

First we will define two variables to hold the address and size of allocated memory regions using var command.

var mem_addr
var mem_size

Next we can set our breakpoints.

bp VirtualAlloc
SetBreakpointCommand VirtualAlloc, "scriptcmd call cb_virtual_alloc"

bp VirtualProtect
SetBreakpointCommand VirtualProtect, "scriptcmd call cb_virtual_protect"

We can use SetBreakpointCommand to set a command to execute when the breakpoint is hit.

The command we need here is call which will jump to a callback function defined by a label, we also have to use scriptcmd to execute the call in the context of a running script (not in the context of the debugging loop).

cb_virtual_alloc:
    rtr
    set mem_addr, cax
    log "Allocated memory address: {x:mem_addr}"
    set mem_size, arg.get(1)
    log "Allocated memory size: {x:mem_size}"

When we reach this callback we first need to use rtr command (run till return) to let VirtualAlloc does the memory allocation.

Next we can get the returned memory address stored at eax/rax and store that value in mem_addr variable.

x64dbg provides the following registers: cax , cbx , ccx , cdx , csp , cbp , csi , cdi , cip which are mapped to 32-bit registers on a 32-bit platform, and to 64-bit registers on a 64-bit platform. This gives you the ability to write architecture-independent code, so we will use cax to get the return value.

As all good developers know the best debugging technique is print-based debugging :)

So we can use the log command to print some logging messages.

The log command takes one argument which is a format string, you can read about the string formatter here. We only need the basic syntax which is {?:expression} where ? is the optional type of the expression (x for hex value).

Next we need to get the size of the allocated memory which is passed to VirtualAlloc as the second argument.

To get an argument at a given index we can use the expression function arg.get(index) which gets the argument at a given index (zero-based). Note that you should be inside the function boundaries to get the correct value.

With that done let’s define the next callback.

cb_virtual_protect:
    log "New protection: {x:arg.get(2)}"
    cmp word(mem_addr), 5a4d
    jne main
    savedata :memdump:, mem_addr, mem_size

First we log the third argument of VirtualProtect which is the new memory protection, this can be used to check for protection changes which might indicate unpacking but we won’t use it here.

Next we use another expression function word to read the first 2 bytes from the previously allocated memory address and compare them to 0x5a4d (the MZ header). Note that all numbers are interpreted as hex by default.

If the check is false we jump to the main label and continue execution, if not we save that memory region to disk.

The first argument of savedata command is the filename, if we use :memdump: as a name it will save the file as memdump_pid_addr_size.bin in the x64dbg directory.

Finally we use run command to run the program and watch the magic happen. you can use Tab to step into the script or Space to run the script.

Simple as that.

Full script:

// define a variable to hold allocated mem address
var mem_addr
// define a variable to hold allocated mem size
var mem_size

// set breakpoint on VirtualAlloc
bp VirtualAlloc
// set callback on breakpoint hit
SetBreakpointCommand VirtualAlloc, "scriptcmd call cb_virtual_alloc"
// set breakpoint on VirtualProtect
bp VirtualProtect
// set callback on breakpoint hit
SetBreakpointCommand VirtualProtect, "scriptcmd call cb_virtual_protect"

// go to main label
goto main

// define VirtualAlloc callback label
cb_virtual_alloc:
    // run until return (stepout)
    rtr
    // set mem_addr value to cax value (return value)
    set mem_addr, cax
    // log memory address
    log "Allocated memory address: {x:mem_addr}"
    // set mem_size value to VirtualAlloc's second arg value (region size)
    set mem_size, arg.get(1)
    // log memory size
    log "Allocated memory size: {x:mem_size}"
    // go to main label
    goto main

// define VirtualProtect callback label
cb_virtual_protect:
    // log VirtualProtect's second arg value (new protection)
    log "New protection: {x:arg.get(2)}"
    // compare the first 2 bytes at mem_addr address to "MZ"
    cmp word(mem_addr), 5a4d
    // if not equal, jump to main label
    jne main
    // dump data at mem_addr address to disk
    savedata :memdump:, mem_addr, mem_size

// define main label
main:
    // run the program
    run

// end the script
ret

YARA for config extraction

2022-08-08T00:00:00+00:00

YARA is a tool aimed at helping malware researchers to identify and classify malware samples. It’s considered to be the pattern matching swiss knife for malware researchers.

If you are not familiar with writing YARA rules, the official docs would be a great start.

In this blog I will go through how YARA rules can be used for malware config extraction.

YARA has come a long way since its original release and it now has some awesome modules for writing better and more complex rules.

What is a YARA module

A YARA module is like a plugin for extending YARA features, it allows you to define data structures and functions which can be used in your rules.

To use a YARA module you simply import it using import "module_name", you can refer to the docs to learn about the available functions of each module.

Example:

import "pe"

rule test {
    condition:
        pe.number_of_sections == 1
}

With that said let’s now jump into malware land, I will demonstrate on two variants of RedLine Stealer which is a very popular dotnet stealer.

RedLine Stealer Variant1

The first variant stores the config in plaintext, we are only interested in two fields (C2 and BotnetID).

To read these fields we need to understand how ldstr instruction works. The instruction’s opcode is 0x72 followed by 4 bytes which represent the string token.

A token is a DWORD value that represents a table and an index into that table. For example, the EntryPointToken 0x0600002C, references table 0x06 (MethodDef) and its row 0x2C. The table index is 1 byte and the row index is 3 bytes.

In the following instruction for example, the string token is 0x7000067B (little-endian) and the row index is 0x67B.

727B060070   // ldstr "87.251.71.4:80"

The dotnet module already has the functionality to retrieve all user strings from a dotnet sample.

import "dotnet"
import "console"

rule Test {
    condition:
        for all i in (0..dotnet.number_of_user_strings-1): (
            console.log(dotnet.user_strings[i])
        )
}

Notice that I used sed to remove null characters because dotnet user strings are stored as an array of unicode strings.

This is cool but we need to get the user strings using the row index from the string token.

To achieve this we need to make a couple of changes to the dotnet module source file at libyara/modules/dotnet/dotnet.c.

This will index the user strings array by row index (offset from the start of the strings table).

To compile and install yara you need to run these two scripts for the first time only:

$ ./bootstrap.sh
$ ./configure

Then you build YARA with your changes:

$ make
$ sudo make install

We can now write a simple rule to read the config fields.

import "dotnet"
import "console"

rule Redline {
    strings:
        $get_conf_v1 = {
            72 ?? ?? ?? 70      // IL_0000: ldstr     "87.251.71.4:80"
            80 ?? ?? ?? 04      // IL_0005: stsfld    <IP>
            72 ?? ?? ?? 70      // IL_000A: ldstr     "lyla"
            80 ?? ?? ?? 04      // IL_000F: stsfld    <ID>
            72 ?? ?? ?? 70      // IL_0014: ldstr     ""
            28 ?? ?? ?? ??      // IL_0019: call      set_Message(string)
            2A                  // IL_001E: ret
        }

    condition:
        $get_conf_v1
        and console.log("[+] C2: ",
            dotnet.user_strings[int32(@get_conf_v1+1) & 0xffffff]
        )
        and console.log("[+] Botnet: ",
            dotnet.user_strings[int32(@get_conf_v1+11) & 0xffffff]
        )
}

@get_conf_v1: address of the first match of $get_conf_v1

int32: reads 4 bytes (string token) from an offset, I used 0xffffff bit mask to only get the row index.

Cool, Let’s move to the second variant.

RedLine Stealer Variant2

This variant stores the config in an encrypted form.

The decryption algorithm looks as follows:

Currently YARA doesn’t have a module to do base64 and xor operations in conditions, so why not write our own module :)

Writing our own YARA module

Modules are written in C and built into YARA as part of the compiling process.

I will explain briefly how to write a YARA module, for more details refer to the official docs.

YARA modules reside in libyara/modules, it’s recommended to use the module name as the file name for the source file. Here I created a new module directory named malutils and inside it is the source file named malutils.c, now let’s go through the source code.

First we need to include the required headers to be able to use YARA’s module API.

Next we define the required functions:

Xor decryption function which takes a buffer and a key and returns the decrypted string buffer.

Base64 decoding function which takes a base64 encoded string and returns the decoded value.

Helper function to convert dotnet user strings from wide to ascii.

Then comes the declaration section where we declare the functions and data structures that will be available for our YARA rules.

After that we have 2 pairs of functions, the first pair is module_initialize & module_finalize.

These functions allow you to initialize and finalize any global data structure you may need to use in your module, and both functions are invoked whether or not the module is being imported by some rule.

The second pair is module_load & module_unload.

The module_load function is invoked once for each scanned file (only if the module is imported in your rule). It’s is where your module can inspect the file being scanned, parse or analyze it in the way preferred, and then populate the data structures defined in the declarations section.

For each call to module_load there is a corresponding call to module_unload. This function allows your module to free any resource allocated during module_load.

Final Touches

Before we test our module there’s a nasty bug we need to take care of.

When writing a YARA module, instead of using the C return statement in your declared functions you must use return_string(x), return_integer(x) or return_float(x) to return from a function.

The problem occurs when we return from base64d function, the decoded string might contain null bytes so return_string won’t return the full buffer.

As you can see below, return_string uses strlen to determine the length of the returned string so it will stop at the first null byte.

As a workaround, I defined a new return macro called return_sized_string which enables us to set the length of the returned string rather than relying on strlen.

Building our module

To include our module in the compiling process of YARA we must follow two further steps:

Add our module name to the module_list at libyara/modules/module_list

MODULE(malutils)

Add our module source file to the must compiled modules at libyara/Makefile.am

MODULES += modules/malutils/malutils.c

Finally we build YARA with our module:

$ make
$ sudo make install

With everything in place, let’s now test our module.

Testing our module

Below is the final YARA rule that handles both RedLine variants.

import "dotnet"
import "console"
import "malutils"

rule Redline {
    meta:
        date = "2022-08-08"
        author = "Abdallah 'n1ghtw0lf' Elshinbary"
        description = "Extracts Redline config (educational)"

    strings:
        $get_conf_v1 = {
            72 ?? ?? ?? 70      // IL_0000: ldstr     "87.251.71.4:80"
            80 ?? ?? ?? 04      // IL_0005: stsfld    <IP>
            72 ?? ?? ?? 70      // IL_000A: ldstr     "lyla"
            80 ?? ?? ?? 04      // IL_000F: stsfld    <ID>
            72 ?? ?? ?? 70      // IL_0014: ldstr     ""
            28 ?? ?? ?? ??      // IL_0019: call      set_Message(string)
            2A                  // IL_001E: ret
        }
        $get_conf_v2 = {
            72 ?? ?? ?? 70      // IL_0000: ldstr     "CyYOXysPAwUnB1NQCxtdWioxKUInBC5QCDNUUw=="
            80 ?? ?? ?? 04      // IL_0005: stsfld    <IP>
            72 ?? ?? ?? 70      // IL_000A: ldstr     "FzcNJDEOEDw7O1Y/FEM/IQ=="
            80 ?? ?? ?? 04      // IL_000F: stsfld    <ID>
            72 ?? ?? ?? 70      // IL_0014: ldstr     ""
            80 ?? ?? ?? 04      // IL_0019: stsfld    <Message>
            72 ?? ?? ?? 70      // IL_001E: ldstr     "Baying"
            80 ?? ?? ?? 04      // IL_0023: stsfld    <Key>
        }

    condition:
        dotnet.is_dotnet and
        (
          (
            $get_conf_v1
            and console.log("[+] C2: ",
              malutils.wtoa(dotnet.user_strings[int32(@get_conf_v1+1) & 0xffffff])
            )
            and console.log("[+] Botnet: ",
              malutils.wtoa(dotnet.user_strings[int32(@get_conf_v1+11) & 0xffffff])
            )
          )
          or
          (
            $get_conf_v2
            and console.log("[+] C2: ",
              malutils.base64d(
                malutils.xord(
                  malutils.base64d(
                    malutils.wtoa(dotnet.user_strings[int32(@get_conf_v2+1) & 0xffffff])    // enc c2
                  ), malutils.wtoa(dotnet.user_strings[int32(@get_conf_v2+31) & 0xffffff])  // xor key
                )
              )
            )
            and console.log("[+] Botnet: ",
              malutils.base64d(
                malutils.xord(
                  malutils.base64d(
                    malutils.wtoa(dotnet.user_strings[int32(@get_conf_v2+11) & 0xffffff])   // enc botnet
                  ), malutils.wtoa(dotnet.user_strings[int32(@get_conf_v2+31) & 0xffffff])  // xor key
                )
              )
            )
            and console.log("[+] Key: ",
              malutils.wtoa(dotnet.user_strings[int32(@get_conf_v2+31) & 0xffffff])
            )
          )
        )
}

Running the rule on a list of samples produces the following output:

Beautiful right!

You can pull the code and try it yourself at https://github.com/N1ght-W0lf/yara/tree/malutils.

It was just for learning purposes so not the best code :)

Samples

fed976b2d134008fd6daec8edc00099935df756beb721034f71db33e4d675a6e e4f7246b103d9bda3a7604bea12dc5ac1064764c0f3691617c9829c4e5d469b5 2d3503d8540e319851a67e55f06ed9e5ba060e821eec6dbc83960a5947ad1310 a8c498f5129af0229081edf1e535ac9dab6ad568befcbcecbfc7cc4c61e0a8eb c19938f0b9648dc1f6b95d0e767164da832b9a92f8128ab47dcb81c5e1ceb31a e94d48e09cace8937941fbf81d1a466fa2b2b6acfd0d6142fc3443c70e067294 f343005539a589ec5512559e0bdc824c1069196ae39d519e5b1f3257f4a6660b

References

https://yara.readthedocs.io/en/stable/index.html

https://www.ntcore.com/files/dotnetformat.htm

Qiling For Malware Analysis: Part 1

2020-07-25T00:00:00+00:00

Background

Qiling is an advanced binary emulation framework written in python and based on Unicorn engine.

It supports multiple platform (Windows, MacOS, Linux, BSD, UEFI) and multiple architectures (X86, X86_64, Arm, Arm64, MIPS).

Qiling is designed as a higher level framework, that leverages Unicorn to emulate CPU instructions, but Qiling understands OS as it has executable format loaders (for PE, MachO & ELF at the moment), dynamic linkers (so we can load & relocate shared libraries), syscall & IO handlers. For this reason, Qiling can run executable binaries that normally runs in native OS.

Installation

Due to distribution restrictions, Qiling doesn’t bundle Microsoft Windows DLL files and registry.

So for smooth installation, jump to a 64-bit windows machine and execute the following:

git clone https://github.com/qilingframework/qiling
cd qiling
examples\scripts\dllscollector.bat        # DLLs collector (requires admin privileges)

Sometimes the emulated program requires additional DLLs, you can copy them manually to "qiling/examples/rootfs/x8664_windows/Windows/System32" or "qiling/examples/rootfs/x86_windows/Windows/SysWOW64/" depending on the program architecture.

Now you can copy "qiling" folder to any machine you want (Windows, Linux, …) and complete the installation.

pip3 install -r requirements.txt    # sudo for Linux
python3 setup.py install            # sudo for Linux

Emulating a File

Emulating a binary file is as simple as that:

from qiling import *

# initialize emulator (x86-64 linux)
ql = Qiling(filename=["qiling/examples/rootfs/x8664_linux/bin/x8664_hello"], 
            rootfs="qiling/examples/rootfs/x8664_linux")
# start emulation
ql.run()

Qiling initialization constructor can take multiple arguments:

filename: binary file and its arguments, example: filename=[“test”,”-argv1”,”argv2”]
rootfs: virtual “/” folder, this is a “jail” file system when executing Qiling (target architecture)
env: environment variables, example: env={“SHELL”:”/bin/bash”,”HOME”:”/tmp”}
output: “default”, “debug”, “disasm”, “dump” where dump=(disam + debug)

The run() function can also take multiple arguments:

begin: start address of emulated code
end: end address of emulated code
timeout: emulation timeout (in microseconds)
count: maximum instruction count to be emulated

Now let’s run our first script:

........
brk(0x0)
brk(0x555555779000)
write(1,555555758260,14) = 0
Hello, World!

As you can see, Qiling outputs strace logs by default. You can disable them using filters.

# disable strace logs
ql.filter = []
# display only "open" logs
ql.filter = ["open"]

Emulating a Shellcode

To keep things simple, we will use this tiny shellcode:

shellcode = b"\x41\x4a" # inc ecx; dec edx

Next, let’s initialize Qiling.

# initialize emulator (x86 linux)
ql = Qiling(shellcoder=shellcode, 
            rootfs="qiling/examples/rootfs/x86_linux/",
            ostype="linux",
            archtype="x86",
            output="disasm")

Emulating shellcode is a little different than binary files, the initialization constructor takes additional arguments:

shellcoder: shellcode in binary format
rootfs: explained above
env: explained above
ostype: “linux”, “macos”, “windows”, “uefi”, “freebsd”
archtype: “x8664”, “x86”, “arm”, “arm64”, “mips”
output: explained above

Here we set the output to "disasm" to see the executed instructions.

The shellcode modifies the values of ECX and EDX registers, so let’s write some values to them before emulating.

# set machine registers
ql.reg.ecx = 0x3
ql.reg.edx = 0x7
# start emulation
ql.run()
# read machine registers
print("ecx = 0x{:x}".format(ql.reg.ecx))
print("edx = 0x{:x}".format(ql.reg.edx))

Let’s see the results:

[+] 0x11ff000      41          inc ecx
[+] 0x11ff001      4a          dec edx
ecx = 0x4
edx = 0x6

Hooking

Qiling supports a wide range of hooks such as hooking specific instructions and hooking memory read/write actions.

Let’s implement a basic disassembler with the help of Capstone and Qiling hooks.

Capstone is a multi-architecture disassembly framework, we can setup a code hook using Qiling to hook every instruction then use Capstone to disassemble the instructions.

from capstone import *
from qiling import *

# initialize emulator (x86 ARM)
ql = Qiling(["qiling/examples/rootfs/arm_linux/bin/arm_hello"],
             "qiling/examples/rootfs/arm_linux")
# hook every instruction
ql.hook_code(hook_callback)
# start emulation (timeout in microseconds)
ql.run(timeout=1000)

We can add a code hook by simply calling hook_code() with a callback function.

def hook_callback(ql, address, size):
    # read current instruction bytes
    data = ql.mem.read(address, size)
    # initialize Capstone
    md = Cs(CS_ARCH_ARM, CS_MODE_ARM)
    # disassemble current instruction
    for i in md.disasm(data, address):
        print("[*] 0x{:08x}: {} {}".format(i.address, i.mnemonic, i.op_str))

The callback function takes three arguments:

ql: our emulator object
address: the address of the current instruction
size: the size of the instruction in bytes

We can disassemble the current instruction using disasm() which takes two arguments (data to disassemble and a base address), here we are printing the instruction address, instruction mnemonic and instruction operands.

Let’s see the results:

[*] 0x047ba9e0: ldr sl, [pc, #0x94]
[*] 0x047ba9e4: ldr r4, [pc, #0x94]
[*] 0x047ba9e8: mov r0, sp
[*] 0x047ba9ec: bl #0x47bb154
[*] 0x0001030c: mov fp, #0
[*] 0x00010310: mov lr, #0
[*] 0x00010314: pop {r1}
..........

Conclusion

In this part we learned the basics of Qiling and how to emulate code for different architectures.

I really encourage you to read through Qiling Documentation to learn more about it’s amazing capabilities.

Code snippets can be found on my Github.

Qiling For Malware Analysis: Part 2

2020-07-25T00:00:00+00:00

In the first part we talked about the basics of Qiling, you can find it here.

Now it’s time for some real world stuff, we will go through two scenarios where Qiling shines.

Fetching KSLØT Dynamic Imports

Dynamic Imports or Dynamic API resolving is a common technique used by many malware samples to make static analysis harder. Instead of importing all needed APIs, the malware can store the APIs names or hashes then import them dynamically at runtime.

The most common way to do this is by using LoadLibrary() and GetProcAddress(), and that’s what we are KSLØT uses.

According to MSDN, the second argument toGetProcAddress() is the function name ("lpProcName"). So we can hook GetProcAddress() and dump the second argument each time it’s called.

Now you might be thinking, why don’t we just use a debugger and trace the execution flow of the malware ?

I can think of three problems about that approach:

The malware might be implementing Anti-Debugging/Anti-Analysis tricks to waste your time
The malware might run on a different architecture that you don’t have access to.
You might want to automate the whole process (Scalability)

Let’s start writing the script.

from qiling import *
from qiling.const import *

# initialize emulator (x86_64 windows)
ql = Qiling(["kSLØT_Keylogger.dll"], "qiling/examples/rootfs/x8664_windows")

The malware sample used here is distributed as a DLL file.

Similar to the main function in typical executables, DLLs have their DllMain function that is executed automatically when they are loaded into memory.

BOOL WINAPI DllMain(
    HINSTANCE hinstDLL,  // handle to DLL module
    DWORD fdwReason,     // reason for calling function
    LPVOID lpReserved    // reserved
)

As we can see, the function takes 3 arguments. The first one (hinstDLL) is a handle to the memory area where the DLL has been loaded. The second one stores a value that indicates the reason why the DllMain has been triggered. Read more here.

So to emulate the DLL properly, we need to set these arguments first (for x64 calling convention, paramerts are passed in RCX, RDX, R8, R9).

DLL_MAIN = 0x1800019a0     # Adress of DLLMain function
# hinstDLL
ql.reg.rcx = 0x180000000   # Address where Qiling loads the DLL
# fdwReason
ql.reg.rdx = 0x1           # DLL_PROCESS_DETACH
# lpvReserved
ql.reg.r8 = 0x0

Next, we can use set_api() function to hook GetProcAddress() on exit.

#FARPROC GetProcAddress(
#  HMODULE hModule,
#  LPCSTR  lpProcName
#)
def hook_GetProcAddress(ql, addr, params):
    print("[*] Import: {}".format(params["lpProcName"]))

# hook GetProcAddress() on exit
ql.set_api("GetProcAddress", hook_GetProcAddress, QL_INTERCEPT.EXIT)

# disable logging
ql.filter = []
# start emulation
ql.run(begin=DLL_MAIN)

Let’s see the results:

[+] Initiate stack address at 0x7ffffffde000 
[+] Loading kSLØT_Keylogger.dll to 0x180000000
[+] PE entry point at 0x180006118
[+] TEB addr is 0x6030
[+] PEB addr is 0x60b8
[+] Loading qiling/examples/rootfs/x8664_windows/Windows/System32/ntdll.dll to 0x7ffff0000000
[+] Done with loading qiling/examples/rootfs/x8664_windows/Windows/System32/ntdll.dll
[+] Loading qiling/examples/rootfs/x8664_windows/Windows/System32/kernel32.dll to 0x7ffff01e1000
[+] Done with loading qiling/examples/rootfs/x8664_windows/Windows/System32/kernel32.dll
[*] Import: GetProcAddress
[*] Import: LoadLibraryA
[*] Import: GetProcessImageFileNameW
[*] Import: GetForegroundWindow
[*] Import: GetWindowThreadProcessId
[*] Import: GetWindowTextW
[*] Import: GetKeyboardState
...........

Perfect! Knowing the imports of a malware sample can help in profiling it, BTW this malware is a keylogger.

Decrypting QBot Strings

It’s common to see malware encrypting its strings to make the analysis process more challenging.

Recently I was analyzing QBot which implements this same technique and it only decrypts required strings on demand.

In my analysis, I reverse engineered the decryption routine as it was simple. But imagine if it was a complicated algorithm with lots of mathematical operations and obfuscated instructions, that’s where Qiling comes in handy.

As you can see, the decryption function takes one argument in EAX which is an index and the returns the required string decrypted.

We can combine the power of Qiling and IDAPython to decrypt the strings and add them as IDA comments.

First we need to get all cross references to the decryption function and then extract the index (second operand) from the previous instruction (as shown above).

# start/end of the decryption function
DEC_START = 0x4065B7
DEC_END   = 0x406655

# xrefs to the decryption function
xrefs = idautils.CodeRefsTo(DEC_START, 0)
# indexes of requested strings to decrypt
indexes = {}

for x in xrefs:
    # address of previous instruction where "eax" is set
    ea = idc.prev_head(x)
    # type of the second operand of "mov"
    t = idc.get_operand_type(ea, 1)
    # check if the second operand is an immediate (not dynamic value)
    if t == idc.o_imm:
        # get the index value (second operand)
        idx = idc.get_operand_value(ea, 1)
        indexes[ea] = idx

Next we initialize Qiling emulator object and loop through collected indexes. At each iteration we set EAX to the index value and run the decryption function.

Finally we read the decrypted string from EAX (return value) and set it as IDA comment.

# initialize emulator (x86 windows)
ql = Qiling(["qbot.exe"], rootfs="qiling/examples/rootfs/x86_windows")

# loop through collected indexes
for ea, idx in indexes.items():
    # set function parameter @eax
    ql.reg.eax = idx
    # run decryption function
    ql.run(begin=0x4065B7, end=0x406654)
    # set decrypted string as ida comment
    idc.set_cmt(ea, readString(ql, ql.reg.eax), 1)

Reading a string from memory address is simply reading bytes one by one until we reach a null byte.

# read string from memory address
def readString(ql, addr):
    res = ""
    while True:
        # read one byte at a time
        c = ql.mem.read(addr, 1).decode()
        if c == '\x00':
            break
        res += c
        addr += 1
    return res

Let’s see the results:

Viola! we managed to decrypt most of the strings without reversing the decryption function.

Conclusion

Qiling is a great project for malware analysis and binary emulation. Although it’s still new but it has lots of capabilities and a lot more to come.

Code snippets can be found on my Github.

Don’t forget to star the Project to support the devs :)

Deep Analysis of QBot Banking Trojan

2020-07-15T00:00:00+00:00

QBot is a modular information stealer also known as Qakbot or Pinkslipbot. It has been active for years since 2007. It has historically been known as a banking Trojan, meaning that it steals financial data from infected systems.

Infection Flow

QBot can be delivered in various different ways including Malspam (Malicious Spam) or dropped by other malware families like Emotet.

The infection flow for this campaign is as follows:

First, the victim receives a phishing email with a link to a malicious zip file.

The zip file contains a very obfuscated VBS file which downloads and launches Qbot executable.

The VBS file tries to download Qbot from different places:

http://st29[.]ru/tbzirttmcnmb/88888888.png
http://restaurantbrighton[.]ru/uyqcb/88888888.png
http://royalapartments[.]pl/vtjwwoqxaix/88888888.png
http://alergeny.dietapacjenta[.]pl/pgaakzs/88888888.png
http://egyorg[.]com/vxvipjfembb/88888888.png

Notice the misleading URL, it looks like it’s downloading a PNG image but the raw data says something else.

Unpacking

QBot is packed with a custom packer, but the unpacking process is really simple. It allocates memory for the unpacked code using VirtualAlloc() and changes memory protection using VirtualProtect(). So we just need 2 breakpoints at VirtualAlloc() and VirtualProtect().

Encrypted Strings

Most of QBot strings are encrypted (stored in a continuous blob) and they are decrypted on demand. The decryption routine accepts one argument which is the index to the string then it XORs it with a hardcoded bytes array until it encounters a null byte.

We can use IDAPython to decrypt the strings and add them as comments.

import idc
import idautils

dec_routine = 0x4065B7
enc_strings = 0x40B930
bytes_arr = 0x410120

def decrypt_string(idx):
    if idx >= 0x36F4:
        return    # out of bounds
    res = ""
    while True:
        c = idc.get_wide_byte(enc_strings+idx) ^ idc.get_wide_byte(bytes_arr + (idx&0x3F))
        if c == 0: break
        res += chr(c)
        idx += 1
    return res

xrefs = idautils.CodeRefsTo(dec_routine, 0)
for x in xrefs:
    ea = idc.prev_head(x)
    t = idc.get_operand_type(ea, 1)
    if t == idc.o_imm:
        idx = idc.get_operand_value(ea, 1)
        dec = decrypt_string(idx)
        idc.set_cmt(ea, dec, 1)

And here is the result, that’s much easier to work with.

This should take care of most of the strings, the rest of strings indexes are calculated dynamically at runtime.

We decrypt all strings by looping through the encrypted blob and decrypt strings one by one.

idx = 0
while idx < 0x36F4:
    dec = decrypt_string(idx)
    idx += len(dec)+1
    print(dec)

Anti-Analysis

QBot spawns a new process of itself with the "/C" parameter, this process is responsible for doing Anti-Analysis checks.

The parent process checks the exit code of this spawned process. If the exit code is not 0, it means that QBot is being analyzed (and so it exits).

So let’s go over the anti-analysis techniques.

Checking VM

In VMWare, communication with the host is done through a specific I/O port (0x5658), so QBot uses the in assembly instruction to detect VMWare by reading from this port and checking the return value in ebx if it’s equal to VMXh (VMware magic value).

If we are outside VMWare, a privilege error occurs and this code will return 0.

Another Anti-VM trick is to check hardware devices against known devices names used by VMs and Sandboxes.

Here is the list of devices names.

    
            Expand to see more
        
  VMware Pointing

  VMware Accelerated

  VMware SCSI

  VMware SVGA

  VMware Replay

  VMware server memory

  CWSandbox

  Virtual HD

  QEMU

  Red Hat VirtIO

  srootkit

  VMware VMaudio

  VMware Vista

  VBoxVideo

  VBoxGuest

  vmxnet

  vmscsi

  VMAUDIO

  vmdebug

  vm3dmp

  vmrawdsk

  vmx_svga

  ansfltr

  sbtisht

Checking Processes

QBot loops through running processes and compares their executable names against known analysis tools.

    
            Expand to see more
        
  Fiddler.exe

  samp1e.exe

  sample.exe

  runsample.exe

  lordpe.exe

  regshot.exe

  Autoruns.exe

  dsniff.exe

  VBoxTray.exe

  HashMyFiles.exe

  ProcessHacker.exe

  Procmon.exe

  Procmon64.exe

  netmon.exe

  vmtoolsd.exe

  vm3dservice.exe

  VGAuthService.exe

  pr0c3xp.exe

  CFF Explorer.exe

  dumpcap.exe

  Wireshark.exe

  idaq.exe

  idaq64.exe

  TPAutoConnect.exe

  ResourceHacker.exe

  vmacthlp.exe

  OLLYDBG.EXE

  windbg.exe

  bds-vision-agent-nai.exe

  bds-vision-apis.exe

  bds-vision-agent-app.exe

  MultiAnalysis_v1.0.294.exe

  x32dbg.exe

  VBoxService.exe

  Tcpview.exe

Checking DLLs

Sandbox detection can be done by enumerating loaded DLLs and comparing them against known DLLs used by sandboxes. Here it’s just using 2 of them.

ivm-inject.dll     # Buster Sandbox Analyzer
SbieDll.dll        # SandBoxie

Checking Filename

Some sandboxes may change the sample file name. So QBot checks if its process name contains one of these strings.

sample
mlwr_smpl
artifact.exe

Checking CPU

The last check is done using CPUID instruction. First it is executed with EAX=0 to get the CPU vendor and compares it with GenuineIntel (Intel processor).

Then it is executed with EAX=1 to get the processors features.

On a physical machine the last bit will be equal to 0. On a guest VM it will equal to 1.

Back To Parent

After the Anti-Analysis checks, QBot drops a copy of itself along with a configuration file at "%APPDATA%\Microsoft\<random_folder_name>".

Finally, QBot starts the dropped copy in a new process and overwrites itself with a legitimate executable, here it’s "calc.exe".

Configuration File

The dropped configuration file is accessed frequently by Qbot, this file is RC4 encrypted. By setting a breakpoint before the contents of the file gets encrypted I got the following data:

Field	Description
10=spx143	Campaign ID
11=2	Number of hardcoded C2
1=13.59.00-24/06/2020	Date of Qbot install in HH:MM:ss-dd/mm/yyyy
2=1592996340	Victim Qbot install
50=1	N/A
5=VgBCAE8AWABTAFYAUgA7ADIA	Victim network shares
38=1593047244	Last victim call to C2 (Unix time)
45=187.163.101.137	C2 IP
46=995	C2 port
39=45.242.76.104	Victim external IP
43=1593006172	Time of record (Unix time)
49=1	N/A

Persistence

QBot achieves persistence by creating a new registry value under the key "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run". It also registers a scheduled task that runs every 5 hours.

Process Injection

QBot tries to inject its unpacked code in one of these processes ("explorer.exe", "mobsync.exe", "iexplorer.exe") and it uses Process Hollowing technique to achieve that.

It first starts a new suspended process with CreateProcessW() then it writes the injected code into the target process using ZwCreateSection(), ZwMapViewOfSection() and ZwWriteVirtualMemory().

Finally it sets the thread context to jump to the injected code and resume execution with ResumeThread().

Core Module

The injected code loads and decrypts one of its resources "307" . After dumping it, I found out that it’s a DLL (this is the core module).

From now on, we will be analyzing the core DLL of QBot.

The core module has 2 resources both RC4 encrypted.

The first resource gets loaded into memory then RC4 decrypted.

The contents of the decrypted resource are:

10=spx143 (Campaign ID)
3=1592482956 (Timestamp)

After some digging, I found out how the resources are decrypted. The first 20 bytes of each resource are the RC4 key of this resource, and the rest are the actual encrypted data.

So by using this find, we can decrypt the other resource "311".

Great!!! Now we have the list of C2 servers (150 servers!).

The reason there is many controllers is that these are actually just proxies of infected bots acting as intermediate nodes between the victim and the real C2 and thus hiding the backend infrastructure of the attacker.

So it works like this:

C2 Communication

QBot obfuscates its communication with the C2 server by encrypting the payloads using RC4 and encoding the result using Base64.

The communication is also done over SSL, you can notice that the traffic has unusual certificate issuer data.

We can use Fiddler to intercept and decrypt the HTTPS traffic.

The RC4 key for encrypting the payload is the SHA1 hash of the first 16 bytes of the Base64-decoded payload + a hardcoded salt (The salt is stored as an encrypted string).

Here is an implementation of the decryption algorithm:

HARDCODED_SALT = b"jHxastDcds)oMc=jvh7wdUhxcsdt2"    # decrypted string

def decrypt_payload(encrypted_blob):
    b64_decoded = base64.b64decode(encrypted_blob)
    decryption_key = b64_decoded[:0x10] + HARDCODED_SALT
    sha1hash = hashlib.sha1()
    sha1hash.update(decryption_key)
    decryption_key_hash = sha1hash.digest()
    rc4 = ARC4(decryption_key_hash)
    return rc4.decrypt(b64_decoded[0x10:])

The decrypted payload is in JSON form.

Decrypted C2 Request: {“8”:9,”1”:17,”2”:”pnmfcq111232”}
Decrypted C2 Response: {“8”:5,”16”:770897804,”39”:”V4UnoDQSEblewhh63UfUqAns”,”38”:1}

Commands List

After establishing communication, the C2 server will send commands indexes to be executed.

Here is the list of commands and their corresponding indexes (I have renamed the important commands).

It’s worth mentioning that dynamic imports of the core DLL are stored in the same format as commands "<address, API_index, DLL_index>", the API and DLL indexes are passed to the string decryption routine which returns their corresponding names then it uses LoadLibrary and GetProcAddress to resolve the imports.

Let’s go through some of the interesting commands.

Command 13: Lateral Movement

QBot can spread through the network by enumerating network shares using WNetOpenEnumW() and WNetEnumResourceW() then it drops a copy of Qbot into the shared folders.

Then the dropped executable is registered as an auto-start service on the target machine. The names for the service and the dropped file are randomly generated strings.

Finally, Qbot deletes the created service and dropped file from the target machine (as it’s successfully infected).

Command 21: Collecting Installed Applications

QBot can collect installed applications by enumeration subkeys of the registry key "HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall".

The collected data is appended to the end of a string containing additional information about the victim’s machine and time of collection.

t=i1 time=[<time_of_collect>] ext_ip=[<external_IP>] dnsname=[?] hostname=[<computer_name>] user=[] domain=[] is_admin=[<YES/NO>] os=[<windows_ver>] qbot_version=[<qbot_ver>] install_time=[<qbot_install_time>] exe=[<injected_process>] prod_id=[NULL] iface_n=[<interface_IP>/<interface_IP>] UP] soft=[<app1;ver>|<app2;ver>|...]

Example of collected data:

Then the data is RC4 encrypted and written to "wdqlxw32.dll" at the same directory of QBot.

Finally, "wdqlxw32.dll" is Zlib compressed and RC4 encrypted again then it’s saved to "cwdqlxw32.dll" and the original "wdqlxw32.dll" is deleted.

The compressed file is then transfered to the C2 server (RC4 encrypted and Base64 encoded) in the key "36" and the compressed file "cwdqlxw32.dll" is also deleted.

Command 31: Fetching Plugins

As we said before, QBot is known to be a modular malware. It can load additional plugins received from the C2 server (plugins are RC4 encrypted and Base64 encoded).

QBot tries to inject the received plugin in 3 different processes depending on the machine architecture.

It creates a new suspended process then writes the plugin to the process memory using WriteProcessMemory() and then resumes the injected process.

At the time of writing this, Qbot has 3 different plugins (“Password grabber”, “Cookie grabber”, “UPnP module”).

Conclusion

QBot is considered to be a sophisticated malware, it’s receiving regular updates from time to time and it’s not likely to go away anytime soon.

There is still more features that I didn’t cover such as WebInjects so maybe I will come back to Qbot later I guess :)

IOCs

Hashes

VBS File: b734caf792c968ca1870c3ec7dda68ad5dc47fef548751afb8509752c185a756

QBot: 112a64190b9a0f356880eebf05e195f4c16407032bf89fa843fd136da6f5d515

URLs

http://st29[.]ru/tbzirttmcnmb/88888888.png

http://restaurantbrighton[.]ru/uyqcb/88888888.png

http://royalapartments[.]pl/vtjwwoqxaix/88888888.png

http://alergeny.dietapacjenta[.]pl/pgaakzs/88888888.png

http://egyorg[.]com/vxvipjfembb/88888888.png

C2 Domains

39.36.254.179:995

24.139.132.70:443

24.202.42.48:2222

72.204.242.138:443

172.242.156.50:995

72.204.242.138:20

68.174.15.223:443

74.193.197.246:443

96.56.237.174:990

64.19.74.29:995

70.168.130.172:443

189.236.166.167:443

68.4.137.211:443

76.187.8.160:443

76.86.57.179:2222

73.226.220.56:443

67.250.184.157:443

75.183.171.155:3389

173.172.205.216:443

173.3.132.17:995

172.78.30.215:443

207.255.161.8:32103

75.137.239.211:443

68.49.120.179:443

206.51.202.106:50003

82.127.193.151:2222

207.255.161.8:2222

207.255.161.8:2087

24.152.219.253:995

187.19.151.218:995

197.37.48.37:993

188.241.243.175:443

72.88.119.131:443

89.137.211.239:443

108.30.125.94:443

187.163.101.137:995

100.19.7.242:443

45.77.164.175:443

80.240.26.178:443

66.208.105.6:443

207.246.75.201:443

199.247.22.145:443

199.247.16.80:443

95.77.223.148:443

68.60.221.169:465

5.107.220.84:2222

41.228.212.22:443

86.233.4.153:2222

68.200.23.189:443

201.146.127.158:443

79.114.199.39:443

87.65.204.240:995

71.74.12.34:443

217.162.149.212:443

195.162.106.93:2222

75.165.112.82:50002

201.248.102.4:2078

96.41.93.96:443

89.247.216.127:443

84.232.238.30:443

103.238.231.40:443

174.34.67.106:2222

98.115.138.61:443

91.125.21.16:2222

84.247.55.190:443

193.248.44.2:2222

74.135.37.79:443

78.96.190.54:443

86.126.97.183:2222

2.50.47.97:2222

68.39.160.40:443

96.232.203.15:443

86.144.150.29:2222

71.220.191.200:443

24.231.54.185:2222

80.14.209.42:2222

24.164.79.147:443

70.183.127.6:995

47.153.115.154:993

184.180.157.203:2222

50.104.68.223:443

67.165.206.193:995

200.113.201.83:993

47.153.115.154:465

24.42.14.241:995

189.160.203.110:443

188.27.76.139:443

207.255.161.8:32102

49.207.105.25:443

71.210.177.4:443

117.242.253.163:443

50.244.112.106:443

69.92.54.95:995

41.34.91.90:995

72.204.242.138:53

41.97.138.74:443

72.29.181.77:2078

71.88.168.176:443

2.50.171.142:443

67.83.54.76:2222

86.125.145.90:2222

47.153.115.154:995

24.122.157.93:443

47.146.169.85:443

72.181.9.163:443

187.155.74.5:443

71.209.187.4:443

74.75.216.202:443

24.44.180.236:2222

24.43.22.220:993

108.188.116.179:443

100.4.173.223:443

76.170.77.99:443

70.95.118.217:443

134.0.196.46:995

68.225.56.31:443

72.204.242.138:32102

72.204.242.138:50001

108.190.151.108:2222

72.204.242.138:465

50.244.112.10:443

173.22.120.11:2222

24.43.22.220:995

24.43.22.220:443

92.17.167.87:2222

72.209.191.27:443

72.204.242.138:80

72.204.242.138:443

71.187.170.235:443

96.56.237.174:32103

71.187.7.239:443

184.98.104.7:995

70.124.29.226:443

137.99.224.198:443

73.23.194.75:443

151.205.102.42:443

64.224.76.152:443

72.204.242.138:32100

173.187.101.221:443

72.179.13.59:443

208.93.202.49:443

70.174.3.241:443

96.37.137.42:443

76.111.128.194:443

67.209.195.198:3389

61.3.184.27:443

24.42.14.241:443

74.56.167.31:443

5.193.61.212:2222

117.216.177.171:443

References

Demystifying QBot Banking Trojan - BSides Belfast

https://www.virusbulletin.com/virusbulletin/2017/06/vb2016-paper-diving-pinkslipbots-latest-campaign

https://www.fortinet.com/blog/threat-research/deep-analysis-qbot-campaign

https://www.vkremez.com/2018/07/lets-learn-in-depth-reversing-of-qakbot.html

https://www.hexacorn.com/blog/2016/07/01/enter-sandbox-part-12-the-library-of-naughty-libraries/

https://www.cyberbit.com/blog/endpoint-security/anti-vm-and-anti-sandbox-explained/

Deep Analysis of Anubis Banking Malware

2020-07-04T00:00:00+00:00

Introduction

Anubis is a well known android banking malware. Although it hasn’t been around for long (since 2017), it had a higher impact than many older banking malwares due to its large set of capabilities.

As most malware families these days, this sample of Anubis is riding on the “COVID-19” pandemic to trick victims into installing it. This campaign seems to be targeting Turkey and the app can be downloaded from "http://sosyalkampanya2[.]ml/pandemi/Pandemi-Destek.apk"

Anubis can spread in two different ways, either by malicious websites (like this one) where it downloads the malicious app directly or it can spread over google play store (where it appears as a legitimate app) then download and install the next stage payload (the malicious app).

Behavioral Analysis

After installation, Anubis forces the user to grant it Accessibility permissions so it can run in the background and receive callbacks by the system when AccessibilityEvents are fired (such as window change and input focus).

Anubis also hides its icon from the app launcher to make it more difficult to remove.

Going inside

After decompiling the APK, we can see that it’s asking for lots of permissions, which means lots of capabilities.

Capabilities

Anubis has a large set of capabilities such as (Keylogging, Sound Recording, SMS Spam, VNC, File Encryption, …).

C2 servers

A quick search for “http/https” reveals some interesting things. First, Anubis has a hardcoded C2 server "http://sosyalkampanya2[.]tk/dedebus/", it’s also used as a VNC client.

To get new C2 servers, Anubis uses a twitter account for this purpose.

Interestingly enough, the twitter account used here was registered back in 2007.

The way this technique works is that it queries the twitter page (containing Chinese tweets) and searches for the text in between those two tags ( “ 苏尔的开始” , “ 苏尔苏尔完” ).

Next it replaces each Chinese character with a corresponding English character.

Finally, the result is Base64-decoded then it’s decrypted using RC4.

Here is the RC4 implementation:

The RC4 key is not dynamically generated, instead it’s using a hardcoded one "zanubis".

Data Exfiltration

Anubis has a list of php endpoints to exfiltrate collected data, each endpoint corresponds to a different log type (keystrokes, running processes, …).

It sends a POST request to the C2 server containing the data in an encrypted form.

The data is encrypted using RC4 with the same key mentioned before then it’s Base64-encoded before it’s exfiltrated.

Receiving Commands

Anubis can receive RAT commands (encrypted):

opendir
downloadfile
deletefilefolder
startscreenVNC
stopscreenVNC
startsound
startforegroundsound
stopsound

Additionally, it can receive a long string of commands separated by "::" to enable/disable certain functionalities, edit configs or send logs.

    
            Expand to see more
        
  startinj

  Send_GO_SMS

  nymBePsG0

  GetSWSGO

  telbookgotext

  getapps

  getpermissions

  startaccessibility

  startpermission

  ALERT

  PUSH

  startAutoPush

  RequestPermissionInj

  RequestPermissionGPS

  ussd

  sockshost

  stopsocks5

  spam

  recordsound

  replaceurl

  startapplication

  killBot

  getkeylogger

  startrat

  startforward

  stopforward

  openbrowser

  openactivity

  cryptokey

  decryptokey

  getIP

Keylogging

Anubis is listening for accessibility events in the background, if the event is "TYPE_VIEW_TEXT_CHANGED", this means that the user is typing something so it gets records.

The keystrokes are written to a file called "keys.log", this file is sent to the attacker on demand along with the victim’s device info. The file’s contents can be erased if the C2 response contains the word "clear".

File Encryption

Anubis can also behave like a ransomware and encrypt files at /mnt, /mount, /sdcard, /storage.

The encryption/decryption key is received from the C2 server along with the required amount to decrypt the files.

The encryption process itself is just RC4 using the received key. Then it writes the encrypted data to a new file with the .AnubisCrypt extension and deletes the original file.

Screen VNC

This feature was recently added to Anubis (according to underground forums), it can start a VNC server using MediaProjection APIs available from Android 5.

Due to Android API restrictions, the attacker can only see the screen of an Android 5+ device but cannot control it.

As mentioned before, Anubis uses the hardcoded C2 server "http://sosyalkampanya2[.]tk/dedebus/" as a VNC client.

Intercepting Calls and SMS

Anubis can intercept and forward phone calls to the attacker (which can be used for bank verification for example), it also tries to mute the phone for android 6.0 and lower.

SMS messages are intercepting using a broadcast receiver that listens for incoming SMS and sends it to the C2 server in clear text.

Targeted Apps

Anubis loops through installed applications and compares them against hardcoded packages names (mostly banking apps). Once it determines that one of these apps is being used, it can carry out an overlay attack.

Overlay attack works by loading a WebView on top of the legitimate app that looks very similar to the original one. It can be used to steal payment data or used as an attack vector for phishing.

The loading of the WebView is almost instant so that the victim doesn’t get suspicious.

Attempting to Remove Anubis

Anubis can utilize accessibility events to prevent the victim from uninstalling it.

It checks if the current open view contains these strings:

current app name (malware app)
"com.android.settings" which is the settings app
"uninstall" or "to remove"

If that’s the case, the victim is sent back to the home screen.

Conclusion

Anubis is a very rich banking malware with lots of features and capabilities. Although there are rumors that Maza-In (the actor behind Anubis) had been arrested by the Russian authorities, we can see that it’s getting new updates (currently 2.5) and it’s still a common choice of criminals when it comes to Android banking malware.

I have also written a small script for fetching new C2 domains + decrypting sent/received data: https://github.com/N1ght-W0lf/MalwareAnalysis/blob/master/Anubis/c2_emulator.py

IOCs

APKs

Pandemi-Destek.apk: 8cb941658ed8340b67a38a47162ab8850b89a14eee2899f0761fadd4f648fd5e

http://sosyalkampanya2[.]tk/dedebus/

https://twitter[.]com/qweqweqwe/

Targeted Apps

at.spardat.bcrmobile

at.spardat.netbanking

com.bankaustria.android.olb

com.bmo.mobile

com.cibc.android.mobi

com.rbc.mobile.android

com.scotiabank.mobile

com.td

cz.airbank.android

eu.inmite.prj.kb.mobilbank

com.bankinter.launcher

com.kutxabank.android

com.rsi

com.tecnocom.cajalaboral

es.bancopopular.nbmpopular

es.evobanco.bancamovil

es.lacaixa.mobile.android.newwapicon

com.dbs.hk.dbsmbanking

com.FubonMobileClient

com.hangseng.rbmobile

com.MobileTreeApp

com.mtel.androidbea

com.scb.breezebanking.hk

hk.com.hsbc.hsbchkmobilebanking

com.aff.otpdirekt

com.ideomobile.hapoalim

com.infrasofttech.indianBank

com.mobikwik_new

com.oxigen.oxigenwallet

jp.co.aeonbank.android.passbook

jp.co.netbk

jp.co.rakuten_bank.rakutenbank

jp.co.sevenbank.AppPassbook

jp.co.smbc.direct

jp.mufg.bk.applisp.app

com.barclays.ke.mobile.android.ui

nz.co.anz.android.mobilebanking

nz.co.asb.asbmobile

nz.co.bnz.droidbanking

nz.co.kiwibank.mobile

com.getingroup.mobilebanking

eu.eleader.mobilebanking.pekao.firm

eu.eleader.mobilebanking.pekao

eu.eleader.mobilebanking.raiffeisen

pl.bzwbk.bzwbk24

pl.ipko.mobile

pl.mbank

alior.bankingapp.android

com.comarch.mobile.banking.bgzbnpparibas.biznes

com.comarch.security.mobilebanking

com.empik.empikapp

com.empik.empikfoto

com.finanteq.finance.ca

com.orangefinansek

com.orangefinanse

eu.eleader.mobilebanking.invest

pl.aliorbank.aib

pl.allegro

pl.bosbank.mobile

pl.bph

pl.bps.bankowoscmobilna

pl.bzwbk.ibiznes24

pl.bzwbk.mobile.tab.bzwbk24

pl.ceneo

pl_pl.ceneo

pl.com.rossmann.centauros

pl.fmbank.smart

pl.ideabank.mobilebanking

pl.ing.mojeing

pl.millennium.corpApp

pl.orange.mojeorange

pl.pkobp.iko

pl.pkobp.ipkobiznes

com.kuveytturk.mobil

com.magiclick.odeabank

com.mobillium.papara

com.pozitron.albarakaturk

com.teb

ccom.tmob.denizbank

com.tmob.denizbank

com.tmob.tabletdeniz

com.vakifbank.mobilel

com.vakifbank.mobile

tr.com.sekerbilisim.mbank

wit.android.bcpBankingApp.millenniumPL

com.advantage.RaiffeisenBank

hr.asseco.android.jimba.mUCI.ro

may.maybank.android

ro.btrl.mobile

com.amazon.mShop.android.shopping

com.amazon.windowshop

com.ebay.mobile

ru.sberbankmobile

ru.sberbank.spasibo

ru.sberbank_sbbol

ru.sberbank.mobileoffice

ru.sberbank.sberbankir

ru.alfabank.mobile.android

ru.alfabank.oavdo.amc

by.st.alfa

ru.alfabank.sense

ru.alfadirect.app

ru.mw

com.idamob.tinkoff.android

ru.tcsbank.c2c

ru.tinkoff.mgp

ru.tinkoff.sme

ru.tinkoff.goabroad

ru.vtb24.mobilebanking.android

ru.bm.mbm

com.vtb.mobilebank

com.bssys.VTBClient

com.bssys.vtb.mobileclient

com.akbank.android.apps.akbank_direkt

com.akbank.android.apps.akbank_direkt_tablet

com.akbank.softotp

com.akbank.android.apps.akbank_direkt_tablet_20

com.fragment.akbank

com.ykb.android

com.ykb.android.mobilonay

com.ykb.avm

com.ykb.androidtablet

com.veripark.ykbaz

com.softtech.iscek

com.yurtdisi.iscep

com.softtech.isbankasi

com.monitise.isbankmoscow

com.finansbank.mobile.cepsube

finansbank.enpara

com.magiclick.FinansPOS

com.matriksdata.finansyatirim

finansbank.enpara.sirketim

com.vipera.ts.starter.QNB

com.redrockdigimark

com.garanti.cepsubesi

com.garanti.cepbank

com.garantibank.cepsubesiro

biz.mobinex.android.apps.cep_sifrematik

com.garantiyatirim.fx

com.tmobtech.halkbank

com.SifrebazCep

eu.newfrontier.iBanking.mobile.Halk.Retail

tr.com.tradesoft.tradingsystem.gtpmobile.halk

com.DijitalSahne.EnYakinHalkbank

com.ziraat.ziraatmobil

com.ziraat.ziraattablet

com.matriksmobile.android.ziraatTrader

com.matriksdata.ziraatyatirim.pad

de.comdirect.android

de.commerzbanking.mobil

de.consorsbank

com.db.mm.deutschebank

de.dkb.portalapp

com.de.dkb.portalapp

com.ing.diba.mbbr2

de.postbank.finanzassistent

mobile.santander.de

de.fiducia.smartphone.android.banking.vr

fr.creditagricole.androidapp

fr.axa.monaxa

fr.banquepopulaire.cyberplus

net.bnpparibas.mescomptes

com.boursorama.android.clients

com.caisseepargne.android.mobilebanking

fr.lcl.android.customerarea

com.paypal.android.p2pmobile

com.wf.wellsfargomobile

com.wf.wellsfargomobile.tablet

com.wellsFargo.ceomobile

com.usbank.mobilebanking

com.usaa.mobile.android.usaa

com.suntrust.mobilebanking

com.moneybookers.skrillpayments.neteller

com.moneybookers.skrillpayments

com.clairmail.fth

com.konylabs.capitalone

com.yinzcam.facilities.verizon

com.chase.sig.android

com.infonow.bofa

com.bankofamerica.cashpromobile

uk.co.bankofscotland.businessbank

com.grppl.android.shell.BOS

com.rbs.mobile.android.natwestoffshore

com.rbs.mobile.android.natwest

com.rbs.mobile.android.natwestbandc

com.rbs.mobile.investisir

com.phyder.engage

com.rbs.mobile.android.rbs

com.rbs.mobile.android.rbsbandc

uk.co.santander.santanderUK

uk.co.santander.businessUK.bb

com.sovereign.santander

com.ifs.banking.fiid4202

com.fi6122.godough

com.rbs.mobile.android.ubr

com.htsu.hsbcpersonalbanking

com.grppl.android.shell.halifax

com.grppl.android.shell.CMBlloydsTSB73

com.barclays.android.barclaysmobilebanking

com.unionbank.ecommerce.mobile.android

com.unionbank.ecommerce.mobile.commercial.legacy

com.snapwork.IDBI

com.idbibank.abhay_card

src.com.idbi

com.idbi.mpassbook

com.ing.mobile

com.snapwork.hdfc

com.sbi.SBIFreedomPlus

hdfcbank.hdfcquickbank

com.csam.icici.bank.imobile

in.co.bankofbaroda.mpassbook

com.axis.mobile

cz.csob.smartbanking

cz.sberbankcz

sk.sporoapps.accounts

sk.sporoapps.skener

com.cleverlance.csas.servis24

org.westpac.bank

nz.co.westpac

org.westpac.banknz.co.westpac

au.com.suncorp.SuncorpBank

org.stgeorge.bank

org.banksa.bank

au.com.newcastlepermanent

au.com.nab.mobile

au.com.mebank.banking

au.com.ingdirect.android

MyING.be

com.imb.banking2

com.fusion.ATMLocator

au.com.cua.mb

com.commbank.netbank

com.cba.android.netbank

com.citibank.mobile.au

com.citibank.mobile.uk

com.citi.citimobile

org.bom.bank

com.bendigobank.mobile

me.doubledutch.hvdnz.cbnationalconference2016

au.com.bankwest.mobile

com.bankofqueensland.boq

com.anz.android.gomoney

com.anz.android

com.anz.SingaporeDigitalBanking

com.anzspot.mobile

com.crowdcompass.appSQ0QACAcYJ

com.arubanetworks.atmanz

com.quickmobile.anzirevents15

at.volksbank.volksbankmobile

it.volksbank.android

it.secservizi.mobile.atime.bpaa

de.fiducia.smartphone.android.securego.vr

com.isis_papyrus.raiffeisen_pay_eyewdg

at.easybank.mbanking

at.easybank.tablet

at.easybank.securityapp

at.bawag.mbanking

com.bawagpsk.securityapp

at.psa.app.bawag

com.pozitron.iscep

com.pozitron.vakifbank

com.starfinanz.smob.android.sfinanzstatus

com.starfinanz.mobile.android.pushtan

com.entersekt.authapp.sparkasse

com.starfinanz.smob.android.sfinanzstatus.tablet

com.starfinanz.smob.android.sbanking

com.palatine.android.mobilebanking.prod

fr.laposte.lapostemobile

fr.laposte.lapostetablet

com.cm_prod.bad

com.cm_prod.epasal

com.cm_prod_tablet.bad

com.cm_prod.nosactus

mobi.societegenerale.mobile.lappli

com.bbva.netcash

com.bbva.bbvacontigo

com.bbva.bbvawallet

es.bancosantander.apps

com.santander.app

es.cm.android

es.cm.android.tablet

com.bankia.wallet

com.jiffyondemand.user

com.latuabancaperandroid

com.latuabanca_tabperandroid

com.lynxspa.bancopopolare

com.unicredit

it.bnl.apps.banking

it.bnl.apps.enterprise.bnlpay

it.bpc.proconl.mbplus

it.copergmps.rt.pf.android.sp.bmps

it.gruppocariparma.nowbanking

it.ingdirect.app

it.nogood.container

it.popso.SCRIGNOapp

posteitaliane.posteapp.apppostepay

com.abnamro.nl.mobile.payments

com.triodos.bankingnl

nl.asnbank.asnbankieren

nl.snsbank.mobielbetalen

com.btcturk

com.ingbanktr.ingmobil

tr.com.hsbc.hsbcturkey

com.att.myWireless

com.vzw.hss.myverizon

aib.ibank.android

com.bbnt

com.csg.cs.dnmbs

com.discoverfinancial.mobile

com.eastwest.mobile

com.fi6256.godough

com.fi6543.godough

com.fi6665.godough

com.fi9228.godough

com.fi9908.godough

com.ifs.banking.fiid1369

com.ifs.mobilebanking.fiid3919

com.jackhenry.rockvillebankct

com.jackhenry.washingtontrustbankwa

com.jpm.sig.android

com.sterling.onepay

com.svb.mobilebanking

org.usemployees.mobile

pinacleMobileiPhoneApp.android

com.fuib.android.spot.online

com.ukrsibbank.client.android

ru.alfabank.mobile.ua.android

ua.aval.dbo.client.android

ua.com.cs.ifobs.mobile.android.otp

ua.com.cs.ifobs.mobile.android.pivd

ua.oschadbank.online

ua.privatbank.ap24

com.Plus500

com.Plus500(Crypt)+

eu.unicreditgroup.hvbapptan

com.targo_prod.bad

com.db.pwcc.dbmobile

com.db.mm.norisbank

com.bitmarket.trader

com.bitmarket.trader(Crypt)+

com.plunien.poloniex

com.plunien.poloniex(Crypt)+

com.mycelium.wallet

com.mycelium.wallet(Crypt)+

com.bitfinex.bfxapp

com.bitfinex.bfxapp(Crypt)+

com.binance.dev

com.binance.dev(Crypt)+

com.btcturk(Crypt)

com.binance.odapplications

com.binance.odapplications(Crypt)

com.blockfolio.blockfolio

com.blockfolio.blockfolio(Crypt)

com.crypter.cryptocyrrency

com.crypter.cryptocyrrency(Crypt)

io.getdelta.android

io.getdelta.android(Crypt)

com.edsoftapps.mycoinsvalue

com.edsoftapps.mycoinsvalue(Crypt)

com.coin.profit

com.coin.profit(Crypt)

com.mal.saul.coinmarketcap

com.mal.saul.coinmarketcap(Crypt)

com.tnx.apps.coinportfolio

com.tnx.apps.coinportfolio(Crypt)

com.coinbase.android

com.coinbase.android(Crypt)+

com.portfolio.coinbase_tracker

com.portfolio.coinbase_tracker(Crypt)+

de.schildbach.wallet

de.schildbach.wallet(Crypt)

piuk.blockchain.android

piuk.blockchain.android(Crypt)+

info.blockchain.merchant

info.blockchain.merchant(Crypt)+

com.jackpf.blockchainsearch

com.jackpf.blockchainsearch(Crypt)

com.unocoin.unocoinwallet

com.unocoin.unocoinwallet(Crypt)+

com.unocoin.unocoinmerchantPoS

com.unocoin.unocoinmerchantPoS(Crypt)+

com.thunkable.android.santoshmehta364.UNOCOIN_LIVE

com.thunkable.android.santoshmehta364.UNOCOIN_LIVE(Crypt)

wos.com.zebpay

wos.com.zebpay(Crypt)+

com.localbitcoinsmbapp

com.localbitcoinsmbapp(Crypt)+

com.thunkable.android.manirana54.LocalBitCoins

com.thunkable.android.manirana54.LocalBitCoins(Crypt)+

com.thunkable.android.manirana54.LocalBitCoins_unblock

com.thunkable.android.manirana54.LocalBitCoins_unblock(Crypt)+

com.localbitcoins.exchange

com.localbitcoins.exchange(Crypt)+

com.coins.bit.local

com.coins.bit.local(Crypt)+

com.coins.ful.bit

com.coins.ful.bit(Crypt)+

com.jamalabbasii1998.localbitcoin

com.jamalabbasii1998.localbitcoin(Crypt)+

zebpay.Application

zebpay.Application(Crypt)+

com.bitcoin.ss.zebpayindia

com.bitcoin.ss.zebpayindia(Crypt)

com.kryptokit.jaxx

com.kryptokit.jaxx(Crypt)

References

https://info.phishlabs.com/blog/bankbot-anubis-telegram-chinese-c2

https://blog.trendmicro.com/trendlabs-security-intelligence/anubis-android-malware-returns-with-over-17000-samples/

https://eybisi.run/Mobile-Malware-Analysis-Tricks-used-in-Anubis

Deep Analysis of SmokeLoader

2020-06-21T00:00:00+00:00

SmokeLoader is a well known bot that is been around since 2011. It’s mainly used to drop other malware families. SmokeLoader has been under development and is constantly changing with multiple novel features added throughout the years.

Sample SHA256: fc20b03299b8ae91e72e104ee4f18e40125b2b061f1509d1c5b3f9fac3104934

Stage 1

This stage starts off by allocating memory for shellcode using LocalAlloc() (not VirtualAlloc), then it fills this memory with the shellcode (86 KB).

Next, it changes the protection of the allocated memory region to PAGE_EXECUTE_READWRITE using VirtualProtect(), then it writes the shellcode and executes it.

Shellcode

The shellcode starts by getting the addresses of LoadLibraryA and GetProcAddress to resolve APIs dynamically, but first let’s see how it does that.

First it passes some hash values to a sub-routine that returns the address of the requested function.

After some digging, I found out that the algorithm for calculating the hashes is pretty simple.

int calc_hash(char* name) {
    int x, hash = 0;
    for(int i=0; i<strlen(name); i++) {
        x = name[i] | 0x60;
        hash = 2 * (x + hash);
    }
    return hash;
}

The shellcode uses PEB traversal technique for finding a function.

Process Environment Block (PEB) is a user-mode data structure that can be used by applications (and by extend by malware) to get information such as the list of loaded modules, process startup arguments, heap address among other useful capabilities.

The shellcode traverses the PEB structure at FS[:30] and iterating through loaded modules to search for the requested module (kernel32 in this case). It hashes the name of each module using the algorithm above and compares it with the supplied hash.

Next, it iterates over the export table of the module to find the requested function, similar to the previous step.

The next step is to resolve APIs using LoadLibraryA and GetProcAddress, the shellcode uses stack strings to complicate the analysis.

Here is the list of imported functions:

    
            Expand to see more
        
  ntdll.dll

      NtUnmapViewOfSection

      NtWriteVirtualMemory

  kernel32.dll

      CloseHandle

      CreateFileA

      CreateProcessA

      ExitProcess

      GetCommandLineA

      GetFileAttributesA

      GetModuleFileNameA

      GetStartupInfoA

      GetThreadContext

      ReadProcessMemory

      ResumeThread

      SetThreadContext

      VirtualAlloc

      VirtualAllocEx

      VirtualFree

      VirtualProtectEx

      WaitForSingleObject

      WinExec

      WriteFile

      WriteProcessMemory

  user32.dll

      CreateWindowExA

      DefWindowProcA

      GetMessageA

      GetMessageExtraInfo

      MessageBoxA

      PostMessageA

      RegisterClassExA

Process Hollowing

The shellcode creates a new processes of SmokeLoader in a suspended state.

Next, it hollows out the memory at 0x400000 using ZwUnmapViewOfSection() and then allocates it again using VirtualAllocEx() with RWX permissions.

Finally, it writes the next stage executable to the allocated memory region using two calls to ZwWriteVirtualMemory(), the first one to write the MZ header and the other for the rest of the executable.

Stage 2

After dumping the second stage from memory, I got a warm welcome from SmokeLoader :(

This stage is full of anti-analysis tricks, so let’s dive in.

Opaque Predicates

The first anti-analysis trick is Opaque Predicates, it’s a commonly used technique in program obfuscation, intended to add complexity to the control flow. There are many patterns of this technique so I will stick with the one used here.

This obfuscation simply takes an absolute jump (JMP) and transforms it into two conditional jumps (JZ/JNZ). Depending on the value of the Zero flag (ZF), the execution will follow the first or second branch.

However, disassemblers are tricked into thinking that there is a fall-through branch if the second jump is not taken (which is impossible as one of them must be taken) and tries to disassemble the unreachable instructions (often invalid) resulting in garbage code.

The deobfuscation is so simple, we just need to patch the first conditional jump to an absolute jump and nop out the second jump, we can use IDAPython to achieve this:

import idc

ea = 0
while True:
    ea =  min(idc.find_binary(ea, idc.SEARCH_NEXT | idc.SEARCH_DOWN, "74 ? 75 ?"),  # JZ / JNZ
              idc.find_binary(ea, idc.SEARCH_NEXT | idc.SEARCH_DOWN, "75 ? 74 ?"))  # JNZ / JZ
    if ea == idc.BADADDR:
    	break
    idc.patch_byte(ea, 0xEB)	# JMP
    idc.patch_byte(ea+2, 0x90)	# NOP
    idc.patch_byte(ea+3, 0x90)	# NOP

Anti Debugging

This stage first checks OSMajorVersion at PEB[0xA4] if it’s greater than 6 (Windows Vista and higher), it’s also reading BeingDebugged at PEB[0x2] to check for attached debuggers.

What’s interesting here is that these checks are used to calculate the return address. If the OSMajroVersion is less than 6 or there’s an attached debugger, it will jump to an invalid memory location. That’s clever.

Another neat trick is that instead of using direct jumps, the code pushes the jump address stored at eax into the stack then returns to it.

Encrypted Functions

Most of the functions are encrypted. After deobfuscating the opaque predicates, I found the encryption function which is pretty simple.

The function takes an offset and a size, it XORes the chunk at that offset with a single byte (0xA6).

We can use IDAPython again to decrypt the encrypted chunks:

import idc
import idautils

def xor_chunk(offset, n):
	ea = 0x400000 + offset
	for i in range(n):
		byte = ord(idc.get_bytes(ea+i, 1))
		byte ^= 0xA6
		idc.patch_byte(ea+i, byte)

xor_chunk_addr = 0x401294	# address of the xoring function
for xref in idautils.CodeRefsTo(xor_chunk_addr, 0):
	mov_addr = list(idautils.CodeRefsTo(xref, 0))[0] - 5
	n = idc.get_operand_value(mov_addr, 1)
	offset = (xref + 5) - 0x400000
	xor_chunk(offset, n)

After the decryption:

One thing to note here, SmokeLoader tries to keep as many encrypted code as possible. So once it’s done with the decrypted functions, it encrypts it again.

Anti Hooking

Many Sandboxes and Security Solutions hook user-land functions of ntdll.dll to trace system calls. SmokeLoader tries to evade this by using its own copy of ntdll. It copies ntdll.dll to "%TEMP%\<hardcoded_name>.tmp" then loads it using LdrLoadDll() and resolves its imports from it.

Custom Imports

SmokeLoader stores a hash table of its imports, it uses the same PEB traversal technique explained earlier to walk through the DLLs’ export table and compare the hash of each API name with the stored hashes.

The hashing function is an implementation of djb2 hashing algorithms:

int calc_hash(char *api_name) {
	int hash=0x1505;
	for(int i=0; i<=strlen(api_name); i++)	// null byte included
		hash = ((hash << 5) + hash) + api_name[i];
	return hash;
}

Here is a list of imported functions and their corresponding hashes:

    
            Expand to see more
        
  ntdll.dll

      LdrLoadDll                  (0x64033f83)

      NtClose                     (0xfd507add)

      NtTerminateProcess          (0xf779110f)

      RtlInitUnicodeString        (0x60a350a9)

      RtlMoveMemory               (0x845136e7)

      RtlZeroMemory               (0x8a3d4cb0)

  kernel32.dll

      CopyFileW                   (0x306cceb7)

      CreateEventW                (0xfd4027f2)

      CreateFileMappingW          (0x5b3f901c)

      CreateThread                (0x60277e71)

      DeleteFileW                 (0xb7e96d0f)

      ExpandEnvironmentStringsW   (0x057074bb)

      GetModuleFileNameA          (0x8acccaed)

      GetModuleFileNameW          (0x8acccdc3)

      GetModuleHandleA            (0x9cbd2a58)

      GetSystemDirectoryA         (0xaebc5060)

      GetTempFileNameW            (0x9a376a33)

      GetTempPathW                (0x7e28b9df)

      GetVolumeInformationA       (0xf25ce6a4)

      LocalAlloc                  (0xeda647bb)

      LocalFree                   (0x742c61b2)

      MapViewOfFile               (0x4db4c713)

      Sleep                       (0xd156a5be)

      WaitForSingleObject         (0x8681d8fa)

      lstrcatW                    (0x2ab51a99)

      lstrcmpA                    (0x2abb9b4b)

  user32.dll

      EnumChildWindows            (0x9a8897c9)

      EnumPropsA                  (0x8f0f57cf)

      GetForegroundWindow         (0x5a6c9878)

      GetKeyboardLayoutList       (0x04e9de30)

      GetShellWindow              (0xd454e895)

      GetWindowThreadProcessId    (0x576a5801)

      SendMessageA                (0x41ecd315)

      SendNotifyMessageA          (0xc6123bae)

      SetPropA                    (0x90bc10d3)

      wsprintfW                   (0x0bafd3f9)

  advapi32.dll

      GetTokenInformation         (0x696464ac)

      OpenProcessToken            (0x74f5e377)

  shell32.dll

      ShellExecuteExW             (0xf8e40384)

And here is the list of the imported functions from the copied ntdll (for anti-hooking):

    
            Expand to see more
        
  4DD3.tmp

      NtAllocateVirtualMemory     (0x5a0c2ccc)

      NtCreateSection             (0xd5f23ad0)

      NtEnumerateKey              (0xb6306996)

      NtFreeVirtualMemory         (0x2a6fa509)

      NtMapViewOfSection          (0x870246aa)

      NtOpenKey                   (0xc29efe42)

      NtOpenProcess               (0x507bcb58)

      NtQueryInformationProcess   (0xd6d488a2)

      NtQueryKey                  (0xa9475346)

      NtQuerySystemInformation    (0xb83de8a8)

      NtUnmapViewOfSection        (0x8352aa4d)

      NtWriteVirtualMemory        (0x546899d2)

      RtlDecompressBuffer         (0xdeb36606)

      towlower                    (0xf7660ba8)

      wcsstr                      (0xbb629f0b)

Anti VM

SmokeLoader enumerates all the subkeys of these keys:

System\CurrentControlSet\Enum\IDE
System\CurrentControlSet\Enum\SCSI

Then it transforms them into lowercase and searches for these strings in the enumerated keys names:

qemu
virtio
vmware
vbox
xen

If one of them is found, the binary exits.

Process Injection

SmokeLoader uses PROPagate injection method to inject the next stage into explorer.exe.

First it decompresses the next stage using RtlDecompressBuffer().

Then there is a call to NtOpenProcess() to open explorer.exe for the injection.

The injection process starts by creating two shared sections between the current process and explorer process (one section for the modified property and the other for the next stage’s code), then SmokeLoader maps the created sections to the current process and explorer process memory space (so any changes in the sections will be reflected in explorer process).

Note that both sections have "RWX" protection which might raise some red flags by security solutions.

We can see that explorer got a handle to these two sections (this is similar to classic code injection but with much more stealth).

SmokeLoader then writes the next stage to one of the sections and the modified property (which will call the next stage’s code) to the other section.

Finally, it sets the modified property using SetPropA() and sends a message to explorer window using SendNotifyMessageA(), this will result in the injected code being executed in the context of explorer.exe.

Stage 3

This is the final stage of SmokeLoader, it starts by doing some anti-analysis checks.

Checking Running Processes

This stage loops through the running process, it calculates each process name’s hash and compares it against some hardcoded hashes.

Here is the algorithm for calculating the hash of a process name:

uint ROL(uint x, uint bits) {
	return x<<bits | x>>(32-bits);
}
int calc_hash(char *proc_name) {	
	int hash = 0;
	for(int i=0; i<strlen(proc_name); i++)
		hash = (proc_name[i] & 0xDF) + ROL(hash ^ (proc_name[i] & 0xDF), 8);
	return hash ^ 0xD781F33C;
}

A quick guess and I could get the processes names:

0xD384255C  →  Autoruns.exe
0x76BDCBAB  →  procexp.exe
0xA159E6BE  →  procexp64.exe
0x7E9CCCA5  →  procmon.exe
0xA24B8E63  →  procmon64.exe
0x63B3D1A4  →  Tcpview.exe
0xA28974F3  →  Wireshark.exe
0xA9B5F897  →  ProcessHacker.exe
0x6893EBAB  →  ollydbg.exe
0xF5FD94B7  →  x32dbg.exe
0xCBFD99B0  →  x64dbg.exe
0x8993DEE5  →  idaq.exe
0x8993D8CF  →  idaw.exe
0x8C083960  →  idaq64.exe
0xB6223960  →  idaw64.exe

If one of these processes is found to be running, explorer.exe will exit.

Encrypted Strings

All strings of this stage are encrypted using RC4 and they are decrypted on demand. The RC4 key = 0xFA5F66D7.

The encrypted strings are stored continuously in a big blob in this form:

Here is a small script for decrypting these strings (I used Go because it has native support for RC4).

package main
import (
	"fmt"
	"io/ioutil"
	"encoding/hex"
	"crypto/rc4"
)
var RC4_KEY, _ = hex.DecodeString("FA5F66D7")

func rc4_decrypt(data []byte) {
	cipher, _ := rc4.NewCipher(RC4_KEY)
	cipher.XORKeyStream(data, data)
	fmt.Printf("%s\n", data)
}
func main() {
	data, _ := ioutil.ReadFile("dump")
	for i := 0; i < len(data); {
		n := int(data[i])	
		rc4_decrypt(data[i+1:i+n+1])
		i += n+1
	}
}

And here is the decrypted strings:

    
            Expand to see more
        
  http://www.msftncsi.com/ncsi.txt

  Software\Microsoft\Internet Explorer

  advapi32.dll

  Location:

  plugin_size

  \explorer.exe

  user32

  advapi32

  urlmon

  ole32

  winhttp

  ws2_32

  dnsapi

  svcVersion

  Version

  &lt?xml version="1.0"?&gt&ltscriptlet&gt&ltregistration classid="{00000000-0000-0000-0000-00000000%04X}"&gt&ltscript language="jscript"&gt&lt![CDATA[GetObject("winmgmts:Win32_Process").Create("%ls",null,null,null);]]&gt&lt/script&gt&lt/registration&gt&lt/scriptlet&gt

  S:(ML;;NW;;;LW)D:(A;;0x120083;;;WD)(A;;0x120083;;;AC)

  %s\%hs

  %s%s

  regsvr32 /s %s

  regsvr32 /s /n /u /i:"%s" scrobj

  %APPDATA%

  %TEMP%

  .exe

  .dll

  :Zone.Identifier

  POST

  Content-Type: application/x-www-form-urlencoded

  runas

  Host: %s

  PT10M

  1999-11-30T00:00:00

  NvNgxUpdateCheckDaily_{%08X-%04X-%04X-%04X-%08X%04X}

  Accept: */*

  Referer: %S

Encrypted C2 Domains

The C2 domains are encrypted using simple XOR operations.

They are stored in a in this form:

We can easily decrypt the domains:

def decrypt_c2(enc, key):
	enc, key = bytes.fromhex(enc), bytes.fromhex(key)
	dec = ""
	for c in enc:
		for i in key: c = c ^ i
		dec += chr(c ^ 0xE4)
	print(dec)

# decrypt_c2("E7FBFBFFB5A0A0E2E0FCFBEAFCFBA2FCEAFDF9E6ECEABFBEBDBABFBAA1FDFAA0", "EFC11A5F")
# http://mostest-service012505.ru/

C2 Communications

SmokeLoader sleeps for 10 seconds (1000*10) before connecting to the Internet.

First it queries http://www.msftncsi.com/ncsi.txt (This URL is usually queried by Windows to determine if the computer is connected to the Internet).

If there’s no response, it sleeps for 64 ms and queries it again until it receives a response.

Then SmokeLoader sends a POST request to the C2 server. The payload is encrypted using RC4 before sending it.

The POST request returns a "404 Not Found" response but it contains a payload in the response body.

Unfortunately most of the C2 domains are down so I couldn’t proceed with the analysis, but I think that’s enough with SmokeLoader :)

IOCs

Hashes

SmokeLoader fc20b03299b8ae91e72e104ee4f18e40125b2b061f1509d1c5b3f9fac3104934

Files

%TEMP%\4dd3.dll

C2 Domains

http://alltest-service012505[.]ru/
http://besttest-service012505[.]ru/
http://biotest-service012505[.]ru/
http://clubtest-service012505[.]ru/
http://domtest-service012505[.]ru/
http://infotest-service012505[.]ru/
http://kupitest-service012505[.]ru/
http://megatest-service012505[.]ru/
http://mirtest-service012505[.]ru/
http://mostest-service012505[.]ru/
http://mytest-service01242505[.]ru/
http://mytest-service012505[.]ru/
http://newtest-service012505[.]ru/
http://proftest-service012505[.]ru/
http://protest-01242505[.]tk/
http://protest-01252505[.]ml/
http://protest-01262505[.]ga/
http://protest-01272505[.]cf/
http://protest-01282505[.]gq/
http://protest-01292505[.]com/
http://protest-01302505[.]net/
http://protest-01312505[.]org/
http://protest-01322505[.]biz/
http://protest-01332505[.]info/
http://protest-01342505[.]eu/
http://protest-01352505[.]nl/
http://protest-01362505[.]mobi/
http://protest-01372505[.]name/
http://protest-01382505[.]me/
http://protest-01392505[.]garden/
http://protest-01402505[.]art/
http://protest-01412505[.]band/
http://protest-01422505[.]bargains/
http://protest-01432505[.]bet/
http://protest-01442505[.]blue/
http://protest-01452505[.]business/
http://protest-01462505[.]casa/
http://protest-01472505[.]city/
http://protest-01482505[.]click/
http://protest-01492505[.]company/
http://protest-01502505[.]futbol/
http://protest-01512505[.]gallery/
http://protest-01522505[.]game/
http://protest-01532505[.]games/
http://protest-01542505[.]graphics/
http://protest-01552505[.]group/
http://protest-02252505[.]ml/
http://protest-02262505[.]ga/
http://protest-02272505[.]cf/
http://protest-02282505[.]gq/
http://protest-03252505[.]ml/
http://protest-03262505[.]ga/
http://protest-03272505[.]cf/
http://protest-03282505[.]gq/
http://protest-05242505[.]tk/
http://protest-06242505[.]tk/
http://protest-service01242505[.]ru/
http://protest-service012505[.]ru/
http://rustest-service012505[.]ru/
http://rutest-service01242505[.]ru/
http://rutest-service012505[.]ru/
http://shoptest-service012505[.]ru/
http://supertest-service012505[.]ru/
http://test-service01242505[.]ru/
http://test-service012505[.]com/
http://test-service012505[.]eu/
http://test-service012505[.]fun/
http://test-service012505[.]host/
http://test-service012505[.]info/
http://test-service012505[.]net/
http://test-service012505[.]net2505[.]ru/
http://test-service012505[.]online/
http://test-service012505[.]org2505[.]ru/
http://test-service012505[.]pp2505[.]ru/
http://test-service012505[.]press/
http://test-service012505[.]pro/
http://test-service012505[.]pw/
http://test-service012505[.]ru[.]com/
http://test-service012505[.]site/
http://test-service012505[.]space/
http://test-service012505[.]store/
http://test-service012505[.]su/
http://test-service012505[.]tech/
http://test-service012505[.]website/
http://test-service012505[.]xyz/
http://test-service01blog2505[.]ru/
http://test-service01club2505[.]ru/
http://test-service01forum2505[.]ru/
http://test-service01info2505[.]ru/
http://test-service01land2505[.]ru/
http://test-service01life2505[.]ru/
http://test-service01plus2505[.]ru/
http://test-service01pro2505[.]ru/
http://test-service01rus2505[.]ru/
http://test-service01shop2505[.]ru/
http://test-service01stroy2505[.]ru/
http://test-service01torg2505[.]ru/
http://toptest-service012505[.]ru/
http://vsetest-service012505[.]ru/

References

https://www.cert.pl/en/news/single/dissecting-smoke-loader/

https://research.checkpoint.com/2019/2019-resurgence-of-smokeloader/

https://docs.microsoft.com/en-us/windows/win32/api/winternl/ns-winternl-peb

https://www.aldeid.com/wiki/PEB-Process-Environment-Block

http://www.hexacorn.com/blog/2017/10/26/propagate-a-new-code-injection-trick

https://modexp.wordpress.com/2018/08/23/process-injection-propagate/

https://docs.microsoft.com/en-us/windows/win32/api/winhttp/nf-winhttp-winhttpconnect#examples

https://www.crowdstrike.com/blog/maze-ransomware-deobfuscation/