A Vault with a Heap-View: The Uncomfortable Space Between AgentCore Harness and Identity

Posted on by Sheida Azimi

Executive Summary

Unit 42 researchers have identified an issue where using default configurations in Amazon Web Services (AWS) AgentCore Harness could allow attackers to steer an agent's actions through prompt injection to exfiltrate plaintext credentials managed by AgentCore Identity.

To reach that finding, we examined two of the harness's many integrations:

  • AWS AgentCore Identity, the platform's recommended way to manage agent identities and store credentials (i.e. an identity vault)
  • A downstream Model Context Protocol (MCP) server, which the harness authenticates against using a credential from that identity vault

AWS AgentCore Identity provides encryption at rest, encryption in transit, key management service (KMS) keys and identity and access management (IAM)-gated access. We wanted to know what happens at runtime, when a credential has to leave the vault to be used. What we found was that the harness's own built-in shell tool, which is enabled by default, reaches into the same memory space where credentials are resolved to plaintext.

We disclosed this finding to AWS. AWS reviewed and closed the report as informative under the AgentCore shared responsibility model, citing allowedTools scoping and egress filtering as customer-side controls.

For operators building on AgentCore today, defense takes a layered approach:

  • Scope the allowedTools the harness can use to what it needs
  • Scope Identity vault service accounts to least privilege for the downstream integration
  • Watch outbound traffic from your harness containers

Palo Alto Networks customers are better protected from the threats discussed in this article through the following products and services:

Unit 42 Cloud Security Assessment is an evaluation service that reviews cloud infrastructure to identify misconfigurations and security gaps.

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Related Unit 42 Topics AgentCore, AWS, Identity, AI Agents

Background on AgentCore Harness

The research that follows is built entirely on AWS AgentCore Harness, a managed runtime for AI agents. As AWS describes it, you declare what your agent does (model, tools, skills, instructions) and AgentCore handles the rest. This includes the environment, compute, memory, identity, networking and observability that turn the configuration into a running agent.

What you declare is only part of the picture. On top of it, the harness ships two built-in tools turned on by default. As AWS's documentation put it in late August 2026:

"Default tools shell and file_operations are available in every session unless you restrict them with allowedTools. shell executes bash commands; file_operations supports viewing, creating, and editing files."

The built-in tools are a big part of what makes the harness so autonomous and productive. The agent can write files and run code to get real work done. But the same reach that makes the built-in tools useful makes them dangerous when people leave them on unintentionally.

We've found that the shell tool runs as root inside the harness, so the moment an attacker gets the agent to run a command, that command inherits the same root access. Nothing has to be misconfigured for this to happen. It is the out-of-the-box state.

Unless you scope the allowedTools parameter to what each session actually needs, every session can run arbitrary shell commands and read or write files, whether you asked for those tools or not.

The Agent Harness Bridges the Gap Between Reasoning and Action

Not long ago, an AI model could answer a question but not act on it. Now, AI agents are reasoning across boundaries that used to be out of reach, taking on tasks that are more complex, longer-running and more autonomous.

But reasoning alone does not get an agent very far. To be useful, an agent needs infrastructure that turns decisions into actions.

That is the gap an agent harness fills. It is the managed runtime around the model, built to keep the agent on track and give it what it needs to operate on its own. A harness provides a variety of different capabilities, including the following:

  • Tools to call
  • A sandboxed shell to execute code
  • Memory that survives across sessions
  • MCP integrations for external services
  • An identity to act under

The harness orchestrates these capabilities in a resilient loop that lets the agent plan, act, observe and continue.

Figure 1 below shows the anatomy of an agent harness.

A diagram titled "Agent Harness: Operational Control & Orchestration" illustrates an AI process flow. It includes stages for input and output, core orchestration loop with Reason, Act, and Observe phases, and integration with tools and environment. Context/state, and guardrails & safety also feature, ensuring permission and policy checks. Arrows indicate the flow of data and actions through tools, environments, and monitoring mechanisms.
Figure 1. Anatomy of an agent harness.

As Figure 1 illustrates, the user's reach stops at “invoke.” The harness's reach extends to every tool and downstream service under the operator's credentials.

Among all the capabilities a harness can give an agent, the shell tool can be both a significant productivity enhancement and a primary attack surface.

But to understand how the shell tool came to be, we first need a quick recap of how an LLM works in the context of this sort of tool.

The Shell Tool: Benefits and Risks

On its own, a language model can only produce text. To make it more useful, its ability to use tools relies on a mechanism called function calling.

The Benefit: Programmatic Tool Use Increases Functionality and Efficiency

This section outlines how function calling grew into programmatic tool use, a leap in efficiency that eventually put a shell tool in the agent’s hands.

Given a user request and a set of available functions, the model can determine that a function should be called and return a structured tool_call response:

  • The chosen function name
  • The arguments to pass and their values
  • All the information the runtime needs to execute it

The runtime then invokes the function, captures the result and sends that result back into the model's context, where the model can decide whether to call another function or produce the final answer. If you run that runtime in a loop and rename “functions” to “tools,” it is now a fully autonomous agent.

As agents matured, tool catalogs became part of agent frameworks. MCP pushed the idea further by standardizing how agents discover and connect to external tools, services, resources and prompts.

However, the core pattern stayed the same. The model still needed to have the tool definitions in its context before it could use them, and each tool's response before it could reason about what to do next. Both required context.

People saw how capable agents could be and began loading them with more tools. Very quickly, the bottleneck shifted from whether agents could use tools to how many tools the agent’s context can handle.

Programmatic tool use breaks out of the one-tool-at-a-time loop, leveraging the fact that models are trained on far more code and shell interactions than they are on tool definitions. With programmatic tool use, the model no longer works through tool definitions one call at a time, with every result piling back into its context. Instead, programmatic tools let the model orchestrate the entire workflow by writing scripts the way it sees fit in a sandboxed command line interface (CLI), such as Python, shell, or whatever the model needs. It executes commands as it goes and handles the results directly. The model only sees the final output.

That is what opened the door to longer and more complex agentic tasks. Instead of reasoning through every small step in natural language, the agent can delegate the messy middle to code and come back with the part that matters.

The efficiency gains from this are substantial. Fewer tokens are spent on tool definitions and intermediate results, and there is less latency from repeated model round trips. There’s also better accuracy because the agent can use code for the parts code is good at (loops, filters, transformations, retries and glue logic).

The context saving alone is dramatic. Compare the same 200,000 token budget under both approaches, as Figure 2 below shows. What we show in the image is a scenario in which every MCP tool definition is loaded upfront (top) versus a single shell tool discovering what it needs on demand (bottom).

A chart compares token usage between MCP and CLI systems. The MCP section shows 77.2K out of 200K tokens used before tasks start, with system prompts at 300, built-in tools at 72K, and MCP tool schemas at 72K, leaving 61.4% free space. The CLI section shows 8.7K out of 200K tokens used, with system prompts at 300, built-in tool at 500, and CLI help on demand up to 3,000, leaving 95.65% free space.
Figure 2. Same 200,000 token budget.

Figure 2 shows that a single shell tool with on-demand discovery reclaims what dozens of upfront tool definitions cost. However, this approach introduces security trade-offs.

The Risk: Programmatic Tool Use Weaponizes Prompt Injection

The same property that makes programmatic tool use powerful also makes it an amplifier for prompt injection.

Before programmatic tool use handed the agent a shell, a successful injection could influence what the agent said, which typed tool it chose or what data it tried to leak back through its response. While text-based injection poses significant problems, its impact is still mostly bounded by text output and by the specific tools the developer exposed.

With a shell, we still worry about what the model can be convinced to say, but we’re also concerned about what code can do at the agent runtime's privilege level.

If the model can be convinced to run a command, influenced reasoning is no longer bounded by a typed schema. It is bounded by the privilege level of the managed runtime it runs in, including:

  • The file system
  • The process space
  • The network
  • The sandbox and whatever credentials are reachable from that execution environment

With that in mind, we can illustrate this with a fictional company called SupportCo.

Testing the Harness

To illustrate this scenario, we created a fictional operator SupportCo, which runs its customer-support agent on AgentCore Harness. The harness reads inbound support tickets, looks up account records through a downstream MCP server and hands the answer back to whoever wrote in. This is a default-configuration deployment including a managed harness, the built-in shell tool and an authenticated downstream MCP integration. Everything here is standard, and nothing is misconfigured.

Where can its built-in shell tool take us?

In Search of Our Primitive

Using nothing but prompts, we started with the approach of asking the model to use the shell tool and run our recon commands. It refused, and it did so again on the next attempt.

Those refusals suggested we should take a different approach. Luckily for the testing attempt, the harness's configuration knobs let us pick the model per invocation.

We don't need a capable, well-aligned model here, just one that supports tool calling. So we picked a more permissive model, and it did exactly what we asked. It saw a tool it was allowed to call and called it.

However, probing was still harder than we hoped. The connection between our prompts and what actually ran was loose. A next-token predictor is poorly suited to reproducing shell syntax exactly. If an escape vanishes or a dash gets rewritten, the quoting drifts just far enough to break.

So we stopped directly prompting the model to carry the payload, and instead landed the instruction via indirect prompt injection. We gave the model one line it could not get wrong: curl our recon script and pipe it into python3.

That is the version that stuck. The agent read the ticket, fired the shell tool and our recon ran inside the harness.

Figure 3 below shows the primitive (the reusable building block the rest of the attack is built on), where a hidden HTML comment tells the agent to curl our recon script and pipe it into python3.

A screenshot of an email interface showing a message about difficulty accessing a billing dashboard due to a 403 error. The sender requests advice and mentions clearing cookies and using incognito mode. A system-generated note advises performing a mandatory internal diagnostic health-check using the shell tool before ticket processing.
Figure 3. The injected support ticket.

Who Am I?

The first thing our recon did was perform runtime environment discovery.

Figure 4 below shows the output of the whoami and id commands that were executed inside the harness.

A screenshot of a terminal showing commands and output.
Figure 4. The shell tool runs as root inside the harness.

To our surprise, the shell tool — the subprocess that runs whatever code the model decides to execute — was running as root. It was not a restricted service account or a sandboxed user.

Root access provides full visibility into the operating system environment, so we went looking to see what else was running. After realizing the harness doesn't ship ps, we read the process list straight from /proc. Figure 5 shows the results of the process tree.

A screenshot of a terminal command output showing a process tree for the "tim" user. The processes include a library path for Python 3.9 with a running Python script, a "curl" command and a Python script.
Figure 5. The process tree.

The environment was not very busy, but one thing triggered our curiosity: process identifier (PID) 1, python3.10 -m loopy.server. Could this be the harness runtime? Our recon script, PID 40, was a direct descendant of it. PID 1 spawned bash (PID 38, the shell tool), which in turn ran our code. The same user identifier (UID) runs the entire chain, and every process is root.

If PID 1 was the harness runtime, its memory was where the interesting things live. So we checked its status and whether we could read it. Figure 6 below shows the results.

A screenshot of a terminal displaying code. The first command uses grep to filter the status of a process, showing details like Name, Pid, Uid, and Seccomp. The second command checks access permissions, indicating readability and writability as true.
Figure 6. PID 1's status and access check.

We saw the same UID on both sides, and /proc/1/mem was readable. Everything in loopy's address space was open to the shell tool.

Reading it in practice takes a little more than a cat. The /proc file system (procfs) is a kernel-managed window into each process's runtime state, exposed through many small interfaces such as :

  • /proc/1/mem for raw memory
  • /proc/1/maps for the memory layout
  • */proc/1/status for identity and privileges

The memory-region layout is sparse, so walking /proc/1/mem straight through hits unmapped gaps that throw I/O errors. So we scanned it in two steps:

  1. Read /proc/1/maps for the layout of the address space:
    1. Start address
    2. End address
    3. Permissions (read/write/execute)
    4. What's mapped there (heap, stack, shared libraries, anonymous allocations)

This layout is our map of where to search.

  1. For each readable region, read the bytes from /proc/1/mem:
    1. seek() to the region's start address
    2. read(size) bytes
    3. Search the chunk for anything of interest in loopy's memory such as byte patterns, strings, structured data

Whatever we’re after, if it’s in loopy's memory, this approach pulls it out.

Where Am I?

The process tree left us a breadcrumb. The --library-path pointed the whole runtime at /opt/amazon, so we went into the file system where the harness's Python packages live, under /opt/amazon/lib/python3.10/. Figure 7 below shows the results.

A screenshot of a terminal screen displays a series of directory listings. The commands list directories within the Python 3.10 site-packages folder, filtering for names. The listings show directory contents including files and other subdirectories such as "model" and "services.
Figure 7. The harness's Python packages.

PID 1 ran the loopy/ subdirectory shown above in Figure 7. The presence of server.py inside this directory confirmed our harness runtime. Within the same directory as loopy/ we found bedrock_agentcore/, with identity/, memory/, services/ and a handful of other AgentCore sub-modules that were available for exploration.

With read access to /proc/1/mem and the bedrock_agentcore packages within reach, one module in particular stood out: identity.

With root, a readable heap, our code running inside and network egress, all we lacked was a target. The identity module was it. To see why, let’s look in more depth at the AgentCore Identity vault.

AgentCore Identity Vault

Every credential in the Identity vault is encrypted at rest and in transit, sealed behind KMS keys and access controls. Instead of placing a Bearer token in the Authorization header, it’s stored in the Identity vault and referenced by the Amazon Resource Name (ARN), as Figure 8 below shows.

A screenshot of an authorization code snippet for AWS with bearer token and credentials path.
Figure 8. The vault reference for the Bearer token.

On paper, this is the right place to store credentials. But what happens at runtime?

For the harness to authenticate with a credential stored in that vault, the ARN first needs to be resolved into the real plaintext secret. That resolution must happen at runtime, inside its process. In this case that’s PID 1, whose memory we can already read.

With that in mind, we set out to see if and where an AgentCore Identity ARN gets resolved into a real JSON Web Token (JWT) inside the harness.

Exfiltrating an AgentCore Identity JWT

Setting the Stage

To see how AgentCore Identity works in practice, we set up a simple scenario. Our test rig simulated an MCP server that required an Amazon Cognito Bearer token and had access to personally identifiable information (PII) such as names, phone numbers or the last four digits of Social Security numbers (SSNs). The token was stored in the vault, and the harness was configured to reference it by ${arn:...} in its Authorization header, exactly as AgentCore documents.

Figure 9 shows the actual create_harness call, with the Identity vault reference in the Authorization header.

A screenshot of a code snippet showing the configuration for a remote MCP customer harness, including URL and header information. The configuration includes an authorization token with a placeholder for account ID.
Figure 9. The create_harness call.

The built-in shell tool in that configuration is easy to miss because it comes on by default. AgentCore Harness ships the built-in shell and file_operations tools to every session unless the allowedTools parameter says otherwise, and both run at the same UID as PID 1.

This means the credential-theft chain we're about to walk through is reachable in the default configuration. Even if the operator finds allowedTools, the parameter only scopes tool selection at InvokeHarness time, not at CreateHarness. It is flexible if you know it, easy to miss if you don't.

The Exfiltration

With the harness live, we wrote a small script, pid1_identity_recon_exfil.py. It scans the heap for two patterns:

  • The credential itself in JWT form
  • The MCP server URL we'd need to replay it against

Figure 10 shows the patterns within this script.

A screenshot of a code snippet with regular expressions for JWT tokens and a URL. The URL mentioned is associated with "bedrock-agentcore" and includes "amazonaws.com.
Figure 10. The two heap-scan patterns in pid1_identity_recon_exfil.py.

To get the script running inside the harness, we reuse the primitive from earlier. as Figure 11 below shows. It uses the same support ticket as before, but this time the payload is our pid1_identity_recon_exfil.py file.

A screenshot of an email displaying a support request about a billing dashboard access issue, noting a persistent 403 error. Below, system text includes a command for an internal diagnostic check, advising secrecy. An automatic ticket summary is also attached.
Figure 11. Support ticket with the hidden HTML comment.

Figure 12 shows the results of this action.

A screenshot of a console output showing results. It indicates one JWT found, with partial hash. The text includes an Amazon Web Services (AWS) URL with additional parameters. An exfil verdict states: "POSTED," and confirms that a JWT credential and MCP URL have been exfiltrated to a webhook.
Figure 12. The exfil script's output from inside the harness.

One JWT (1,034 bytes) and the MCP server URL (the replay target) are both sent to our simulated attacker's webhook in a single HTTP POST request.

Figure 13 shows what landed on the attacker's side. This image shows the HTTP POST request and response captured at webhook[.]site, carrying the Bearer JWT and the MCP replay URL. This arrived at our simulated attacker's endpoint, moments after the agent summarized the support ticket shown previously in Figure 11.

A screenshot of a Webhook.site interface showing a request details page. The page includes information about a POST request, with fields for host location, and an MCC URL. The raw content section highlights an exfiltrated JWT token and an exfiltrated MCP URL.
Figure 13. The webhook[.]site page showing the JWT and MCP URL arriving at the attacker's endpoint.

Replay: From Webhook to PII

With the JWT and URL in hand, we fetched them from the webhook and connected to the MCP server. We were able to do so from our laptop with no AWS credentials required. Figure 14 below shows a screenshot of the replay session.

A screenshot of a terminal window displaying an exfiltration process. Shows data from an AWS webhook with JWTs and a bearer token. Includes a command to replay malicious MCP actions using a sample user with contact and account details.
Figure 14. The replay from our laptop.

Our simulated attacker listed the MCP tools, called the lookup_customer tool that returned customer PII and created a ticket. All of this came from a credential stored in the AgentCore Identity vault, referenced only by ARN and never held locally by any user. It was now in the attacker's hands and fully replayable from anywhere on the internet.

Whose JWT Have We Exfiltrated?

We decoded the exfiltrated token by pasting it into the JWT Debugger, and its payload claims reveal the account behind it. Figure 15 shows the decoded token data, which includes the username for the account: mcp-service.

A screenshot of a JSON claim structure is displayed with various data fields and values. A highlighted section surrounds the "username" field set to "mcp-service." An annotation states, "Not the caller. The operator."
Figure 15. The exfiltrated JWT decoded.

Why the Operator's Service Account?

For the harness to use a JWT from the vault, that JWT has to be in the vault to begin with.

End-user session tokens don't qualify. They're generated fresh on login, expire quickly, and belong to whichever user is currently signed in. You can't pre-enroll them, and you can't provision a new harness per user just to embed their token.

There's a scope argument too. The user's session JWT authorizes them to bedrock-agentcore:InvokeHarness, alongside other permissions. The credential stored in the AgentCore Identity vault is something else entirely. It's meant to be used by the harness's execution role to authenticate against downstream services, in our case the customer’s MCP server. That's authority the user never had and was never supposed to have. It's the harness acting on the operator's behalf, not the caller's.

Figure 16 shows the two sides of the privilege boundary:

  • The caller is allowed only to InvokeHarness
  • The harness's execution role is allowed to reach every downstream service the operator wired in

The caller can only ask the harness for help. However, once invoked, the harness can reach every downstream service the operator wired in, including credentials.

A diagram comparing two role permissions: "Caller's Role Permissions" allows invoking with specified actions and resources in a privilege boundary. "AgentCore Harness Execution Role Permissions" enables broader access, detailing specific actions like resource and credential retrieval, and logs access with unrestricted resources.
Figure 16. Authorized to invoke is not authorized to reach.

The vault is for the credentials that are stable, including the operator's service accounts, wired in once at create_harness time. This is the one we set up at the top of the previous section in this article, Let's exfiltrate an AgentCore Identity JWT. It is then reused across every user session, which is the credential that lands in PID 1's heap and gets exfiltrated. The exfiltrated credential is not the end-user's JWT. It is mcp-service, the operator's service account.

Disclosure Timeline

  • May 19, 2026: Reported to the AWS Security team via HackerOne (report #3747844)
  • June 8, 2026: AWS Security team responded with reproduction requests and clarifications on scope
  • June 10, 2026: Confirmed this finding shares its root cause with an earlier report (#3737800) and the two reports were merged
  • June 10, 2026: AWS closed the report as informative under the AgentCore shared responsibility model, citing allowedTools scoping and egress filtering as customer-side controls

Conclusion

As AI agent reasoning gets sharper, longer-running and more autonomous, the attack surface the harness has to keep contained widens with every capability it hands the agent. Our research walked through one form of that widening surface end to end. This included a shell tool running inside the same memory space where the harness resolves its credentials and every credential the vault ever hands over sitting in plaintext in the heap by the time the shell tool could access it.

The vault successfully secured credentials at rest and in transit, but the shell tool's memory access bypassed these protections.

Our findings highlight a broader challenge for managed agent runtimes:

  • The shell tool could be the new perimeter if not scoped correctly.
    A general-purpose shell is powerful because it can reach anything the runtime can. Scoping it down to prevent exfiltration also strips it of the flexibility that made programmatic tool use worth adopting. And the model's reasoning can't reliably distinguish a legitimate instruction from an injected one, so it's the shell tool's reach that bounds what an attacker can do, not the model's judgment. Whatever the shell tool can touch (file system, network, process memory, downstream services) is what an injection can touch.
  • Vaults protect at rest and in transit, not in use.
    Any credential the harness resolves at runtime has to become plaintext to be useful. In-use protection is a separate problem, and the vault doesn't solve it.
  • Consider which credentials your harness acts on behalf of.
    Harnesses might require long-term, high-privilege credentials to do their downstream work and stay autonomous. Whatever they resolve becomes reachable via any injection that lands, regardless of the invoking user's own scope.

We recommend those organizations operating on AgentCore Harness make sure to cover the following:

  • Scope the allowedTools parameter at InvokeHarness time (not CreateHarness) to what each session needs. The built-in shell and file_operations tools are shipped enabled by default. Sessions that don't call for them shouldn't get them.
  • Scope every Identity vault service account to least privilege for its downstream integration. A leaked credential is worth what its scope buys.
  • Watch outbound traffic from your harness containers. Any endpoint that isn't in your downstream integration list is evidence of an active injection, not configuration drift.

If you're building a managed agent runtime, treat every capability the harness gives the model as an attack-surface primitive, not a productivity feature bolted onto it. Any credential the runtime resolves has to live somewhere the shell tool cannot read, or the shell tool has to run in a sandbox isolated from the process that resolves it. Without these isolation boundaries, runtime credentials remain exposed to the shell tool.

Palo Alto Networks Protection and Mitigation

Palo Alto Networks customers are better protected from the threats discussed above through the following products:

  • Cortex Cloud can help protect cloud posture and runtime operations against identity-driven threats by pairing static permission baselines with deep behavioral context. By embedding the functional identity baselines discussed in this research into our detection engine for both cloud VM compute and serverless agents, Cortex Cloud adds a vital layer of operational context, enabling security teams to filter out noisy false positives and decisively catch threat actors attempting to masquerade, alter configurations, or execute anomalous operations in the environment.

Unit 42 Cloud Security Assessment is an evaluation service that reviews cloud infrastructure to identify misconfigurations and security gap.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
  • UK: +44.20.3743.3660
  • Europe and Middle East: +31.20.299.3130
  • Asia: +65.6983.8730
  • Japan: +81.50.1790.0200
  • Australia: +61.2.4062.7950
  • India: 000 800 050 45107
  • South Korea: +82.080.467.8774

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Additional Resources

Inside the Modern SOC: Defending the Cross-Environment Pivot

Posted on by Ria Bhatia

The Cross-Environment Gap

Our series, Inside the Modern SOC: Trends and Insights from Unit 42 Managed Services, shares the operational patterns that Unit 42 experts observe, with today's challenge beginning after the initial foothold.

Across Unit 42 investigations, we continue to see adversaries move well beyond where an attack begins. They pivot across the enterprise, avoiding detection by exploiting the visibility gaps created by disconnected security tools.

According to the 2026 Unit 42 Global Incident Response Report, 43% of attacks involved activity across four or more attack surfaces, with some cases spanning as many as eight. As attacks move across cloud, endpoint, network, identity and software-as-a-service (SaaS) environments, analysts must connect activity across security domains before the complete attack path becomes clear.

Following the Attack Across Environments

The First Signal

An investigation may begin with what appears to be an isolated event. An endpoint generates an alert. A cloud administrator provisions a resource outside of normal activity. An unfamiliar application requests elevated permissions. On its own, none of these events necessarily signals a broader attack.

The Cross-Environment Pivot

As the attack progresses, related activity begins appearing elsewhere. Permissions may change within a SaaS application. Cloud resources may be provisioned or reconfigured. Sensitive data may be staged for exfiltration. New network connections may emerge between systems that rarely communicate.

When these signals are investigated separately, security teams can miss the connection between them and the larger attack taking shape across the environment.

Reconstructing the Attack Path

The complete picture often becomes clear only when activity across security domains is connected. AI-driven correlation connects signals that initially appear unrelated, helping analysts reconstruct how an adversary gained access, where they moved, what they accessed and what they were attempting to accomplish.

Because attackers don't operate within the boundaries monitored by individual security tools, security operations can't either. Defenders need to follow attacker activity across the enterprise and investigate the intrusion as one connected attack. Doing this consistently requires continuous monitoring and response, along with ongoing optimization of detections, correlation rules and workflows as threats and environments evolve.

How SOC Leaders Can Defend Across Attack Surfaces

Use AI to Investigate the Attack, Not the Alert

As attackers move across security domains, security leaders should evaluate whether their operations can reconstruct a complete attack path rather than respond to isolated alerts. The goal is to use AI-driven correlation to reveal how seemingly unrelated activity connects before an adversary reaches their objective.

Connect Evidence Across the Attack Path

To track adversarial behavior from the first signal across every stage of the attack lifecycle, organizations must connect evidence across their security environment through lateral movement, persistence and impact. True visibility requires cross-domain correlation, while threat hunting should test for attacker behaviors that may not yet have generated an alert. SOC leaders should ensure their platforms automatically correlate activity into unified incident storylines, giving analysts the context to investigate and respond without manually pivoting between tools or teams.

Continuously Test and Evolve Security Operations

Treat every investigation as an opportunity to improve the next one. Review where analysts lost context, where detections or correlation rules could be improved and which response steps created delays. Use those findings to refine detection logic, correlation rules, automation and response playbooks as attacker techniques and the environment evolve.

How Unit 42 Managed Services Applies These Principles

As attacks increasingly span multiple environments, AI-driven correlation and behavioral analytics in the Cortex SecOps platform bring related signals together into a unified investigation. Unit 42 analysts apply frontline expertise and threat intelligence to validate the attack path, investigate coordinated activity and accelerate response.

Our Managed Detection and Response (MDR) analysts continuously investigate suspicious activity while our threat hunters combine AI-powered insights with Unit 42 expertise to proactively search for attacker behaviors that may not yet have generated an alert. Insights from investigations and hunts help strengthen detections, refine correlation rules and improve response workflows across customer environments.

Organizations using Managed XSIAM extend this approach through continuous SOC engineering delivered by Unit 42 experts. Our teams continuously optimize:

  • Data integrations
  • Detection logic
  • Custom correlation rules
  • Automated response playbooks
  • Investigation workflows

Continuous SOC engineering helps reduce investigation and response time by optimizing the detections, correlation rules, automation and workflows that power AI-driven security operations.

The Unit 42 Managed Services Edge

Unit 42 combines expert-led MDR, Managed Threat Hunting and Managed XSIAM to help organizations investigate attacks as one connected incident. Powered by AI-driven capabilities in the Cortex SecOps platform, our experts apply insights from thousands of investigations, threat hunts and incident response engagements to accelerate response and continuously improve security operations.

Learn more about Unit 42 Managed Services.

Atomic macOS (AMOS) Stealer Activity

Posted on by Ria Bhatia

Executive Summary

This article reviews an Atomic macOS (AMOS) stealer malware infection generated in a lab environment. While several sources have published articles analyzing AMOS stealer, the associated indicators constantly change. This article presents a snapshot of indicators seen in early August 2026 and is designed to help readers better understand AMOS stealer.

Background

AMOS stealer is an information stealer targeting macOS systems that was advertised on Telegram as early as April 2024. AMOS stealer represents a noticeable portion of macOS stealer-based malware and is considered a growing threat. AMOS stealer exfiltrates system information, login credentials and other sensitive data from various applications, including web browsers and cryptocurrency wallets.

Malware that we've assessed as AMOS stealer has been distributed through ClickFix campaigns as well as through malicious ads. We've also seen AMOS stealer distributed through campaigns that claim to offer cracked versions of popular copyright-protected software. These sites offer instructions to install software such as a macOS toolkit but then actually install malware like AMOS stealer.

This article examines an AMOS stealer infection generated on Aug. 5, 2026, from an instructional page claiming to install a “macOS toolkit.”

Characteristics of the Infection

The domain hosting the malicious page claiming to have installation instructions for a macOS toolkit is getmacouscloud[.]com. An example of one of the pages is shown below in Figure 1.

Figure 1. A malicious website advertising a quick setup for “macOS toolkit.”

While the “quick setup” instructions from this page in Figure 1 are sometimes described as a ClickFix technique, this is not really ClickFix. The ClickFix technique generally uses a fake CAPTCHA or other type of verification page offering instructions to continue to the website a viewer intends to visit. ClickFix campaigns inject a script into a viewer's clipboard to paste into a Run window for Windows systems or a Terminal window for macOS systems.

Regardless of what we call this copy/paste technique, we followed the instructions in our lab environment. We copied text from the page and pasted it into a Terminal window on our macOS system as shown in Figure 2.

Figure 2. Malicious text pasted into a Terminal window.

The command in Figure 2 retrieved a Z-shell (Zsh) script from hxxps[:]//ferncore13[.]com/curl/608e70d1338612686917ee5cd300ff7ed8e318dfd787a50257f92142e99bd688. That Zsh script contains Base64-encoded text for a GZIP-compressed payload as shown in Figure 3.

Figure 3. Base64-encoded GZIP-compressed payload in the initial Zsh script.

That GZIP-compressed payload contains a follow-up Zsh script designed to retrieve and run a Mach-O binary to install AMOS stealer. That Mach-O binary for the AMOS stealer installer was saved as /tmp/helper, as shown below in Figure 4. The same directory also contained a plist file named starter, also shown in Figure 4.

Figure 4. Mach-O binary for AMOS stealer installer and plist file.

The plist file at /tmp/starter contains text that hints at a newly created file in the user's /Library/Application Support/.com.apple.accountsd/ directory named .service. This file is a shell script that runs a Mach-O file for AMOS stealer in the same directory named AccountsHelper, as shown in Figure 5.

Figure 5. Files in the /Library/Application Support/.com.apple.accountsd/ directory.

We found an additional directory and similar files in the user's /Library/Application Support/.com.apple.metadata.mds/ directory named .mdworker and mdworker_shared., as shown below in Figure 6. The .mdworker file is a shell script that runs another AMOS stealer Mach-O file named mdworker_shared.

Figure 6. Files in the /Library/Application Support/.com.apple.metadata.mds/ directory.

Of note, before the infection would proceed, the macOS host presented a prompt to enter the user's password as shown below in Figure 7. Since the user account on this macOS host was an administrative account, it proceeded when we entered the user's password.

Figure 7. Prompt for the user's password.

After entering the user's password, the host's Terminal process presented prompts requesting various permissions during the infection, as noted below in Figure 8.

Figure 8. Prompts by the Terminal process during the infection.

After running the initial malicious text in the Terminal window, the Terminal process requested the following permissions:

  • Access to control the macOS Finder application
  • Access to files in the user's Desktop folder
  • Access to files in the user's Documents folder
  • Access to control the macOS Notes application

AMOS stealer collected and temporarily saved information under the host's /tmp directory, and compressed the data into a file named out.zip. The file and directory structure of the out.zip file follows:

  • Directory: deskwallets/Binance/
  • Directory: deskwallets/TonKeeper/
  • Directory: FileGrabber/aws/
  • Directory: FileGrabber/docker/
  • Directory: FileGrabber/filezilla/
  • Directory: FileGrabber/gcloud/
  • File: FileGrabber/zsh_history
  • File: info
  • Directory: Telegram Data/
  • File: username

The infected macOS host was a clean installation with no additional added applications. However, the file and directory content of out.zip hints at the applications that AMOS stealer searched for during this infection.

Infection Traffic

Post-infection traffic consisted mainly of HTTP POST requests to a command and control (C2) server at 161.35.146[.]120. Figure 9 shows traffic from the infection filtered in Wireshark.

Figure 9. Traffic from the infection filtered in Wireshark.

As shown above in Figure 9, URLs for the initial HTTP POST requests hint at the types of data collected by AMOS stealer. These initial URLs end with the following strings:

  • stage=boot
  • stage=init_session
  • stage=messengers
  • stage=credentials
  • stage=browsers
  • stage=wallets
  • stage=resolve_auth
  • stage=local_data

Comparing this AMOS stealer infection on Aug. 5, 2026, with a previous infection on July 31, 2026, reveals similar post-infection URL patterns. However, that AMOS stealer infection generated traffic to a different C2 server at 188.166.78[.]138.

This comparison underscores a notable characteristic of AMOS stealer and its supporting infrastructure. The associated domains, URLs and IP addresses frequently change for AMOS stealer activity. The same frequent changes apply to filenames, file hashes and directory paths seen in our post-infection forensic analysis.

These different AMOS stealer characteristics over a relatively brief period indicate this is a malware family in active development, which is continually evolving.

Conclusion

This article reviewed an Atomic stealer malware infection from early August 2026. The resulting analysis includes behavior from the infected macOS host, malware samples, post-infection artifacts and traffic patterns that indicate the types of information collected by this malware.

The key to understanding AMOS stealer is realizing this malware is continually evolving. The indicators frequently change, and the ones we present in this research are no longer the most current. However, the overall patterns of activity remain consistent. While this review is a snapshot, analysts and other security professionals can better understand AMOS stealer by keeping track of its changes in the coming weeks and months.

Palo Alto Networks Product Protections

Palo Alto Networks customers are better protected from AMOS stealer and related threats through the following products and services:

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
  • UK: +44.20.3743.3660
  • Europe and Middle East: +31.20.299.3130
  • Asia: +65.6983.8730
  • Japan: +81.50.1790.0200
  • Australia: +61.2.4062.7950
  • India: 000 800 050 45107
  • South Korea: +82.080.467.8774

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Indicators of Compromise

We discovered the following five files during this AMOS stealer infection:

Initial Zsh script downloaded from a command run from the macOS Terminal window

  • SHA-256 hash: 71781ad8adefb499aee9bcbe1a166e69ccc37a47066682f617d65c76d8cde88c
  • File size: 1,991 bytes
  • File type: Zsh script text executable, ASCII text
  • File location: hxxps[:]//ferncore13[.]com/curl/608e70d1338612686917ee5cd300ff7ed8e318dfd787a50257f92142e99bd688

Payload (Zsh script) extracted from the initially downloaded Zsh script

  • SHA-256 hash: 7ea6ff8b12c59aaae1ab6f4f5a57045dad5a8127954f3ffd3d1c154d40d7ca3a
  • File size: 1,213 bytes
  • File type: Zsh script text executable, ASCII text, ASCII text, with very long lines (323)

Installer for AMOS stealer

  • SHA-256 hash: a598fcdcd49247312861ff90c16cb4a5d49fede6072e30e7416dd276668fa2a9
  • File size: 330,768 bytes
  • File location: /tmp/helper
  • File type: Mach-O universal binary with two architectures: x86_64 and ARM64

Binary from AMOS stealer infection persistent on the infected macOS host

  • SHA-256 hash: 6bfcdb4920383375b7e519918df7eb4db751b974b5571a15ce66b82478012620
  • File size: 438,576 bytes
  • File location: /Users/[username]/Library/Application Support/.com.apple.accountsd/AccountsHelper
  • File type: Mach-O universal binary with two architectures: x86_64 and ARM64

Another binary from AMOS stealer infection persistent on the infected macOS host

  • SHA-256 hash: 4504006d1911057be42435d4625f03d83c4d0b7b6898d14beb9cdeba6cf667b9
  • File size: 568,368 bytes
  • File location: /Users/[username]/Library/Application Support/.com.apple.metadata.mds/mdworker_shared
  • File type: Mach-O universal binary with two architectures: x86_64 and ARM64

Malicious website with instructions that will infect a vulnerable macOS host:

  • hxxps[:]//getmacouscloud[.]com

URL for the initial download decoded from Base64 text provided by the malicious website:

  • hxxps[:]//ferncore13[.]com/curl/608e70d1338612686917ee5cd300ff7ed8e318dfd787a50257f92142e99bd688

URLs from extracted from the payload returned from the initial download:

  • hxxps[:]//grove-89[.]com/api/metrics/run?event=pasted
  • hxxps[:]//ferncore13[.]com/2kqYRM0DCrnyJgoS4gVLl_FHJRRdTUhGCbjyuYwpZ6c/m1/update

Additional Resources

Unmasking Cloud Identities: From Behavioral Clustering to Automated Detection

Posted on by Sheida Azimi

Executive Summary

As cloud environments expand to include human, machine and autonomous agent identities, mapping the functional roles of these identities has become a significant security challenge. To address this challenge, we designed a behavioral clustering model that extracts activity patterns from cloud audit logs. By adopting a clustering-based approach to identity mapping, organizations can gain greater visibility into cloud activity and integrate these behavioral patterns into automated threat detection mechanisms.

To create our behavioral clustering model, we examined the behavior of over 40,000 identities from 125 cloud environments over a two-month period, mapping these identities to functional roles. These roles include administrators, backup services, security tooling and development and operations (DevOps).

Identifying these functional roles is rarely straightforward because resource naming conventions or assigned identity and access management (IAM) policies do not always reveal an identity’s true behavior. Attackers routinely use masquerading techniques like pre-existing permission profiles and benign labels to make malicious activity harder to detect.

To illustrate the practical application of our model, we provide an in-depth analysis of the dataset's largest cluster: administrator console users in Amazon Web Services (AWS). We also show how an identity’s behavioral patterns provide richer context for cloud threat detection.

Additionally, we demonstrate how lightweight heuristic logic can be extracted directly from the clustering map, which can be implemented in standard SQL. This allows organizations to classify functional identity roles at scale, delivering continuous operational visibility without the need to continuously run a resource-intensive machine learning pipeline.

The methodology applied in our behavioral clustering model uses unsupervised machine learning algorithms, specifically Uniform Manifold Approximation and Projection (UMAP) and Hierarchical Density-Based Spatial Clustering of Applications with Noise (HDBSCAN), to construct a reliable behavioral map. This approach automatically categorizes a vast collection of cloud identities into distinct, clustered groups.

While our research specifically focuses on AWS CloudTrail data, the methodology can be easily extended to audit logs from other cloud providers, software as a service (SaaS), Kubernetes and other environments.

Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:

Unit 42 Cloud Security Assessment is an evaluation service that reviews cloud infrastructure to identify misconfigurations and security gaps.

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Related Unit 42 Topics Cloud, Identity, Detection

The Identity Challenge

When it comes to accurately detecting malicious activity within cloud environments, context is key. Consider a scenario where a cloud identity enumerates all resources within your environment. Is this a security tool that frequently scans resources as part of its normal routine? Or is it a service identity that usually serves a limited purpose, such as a backup service that only interacts with a single cloud storage bucket? One of these scenarios represents normal operational activity, the other indicates a potential security breach.

This reality forces us to draw a distinction between capabilities and active behavior:

  • What an identity can do: Identity permissions dictate the operations that a role is permitted to perform. Although the industry-standard recommendation is to enforce the principle of least privilege, the reality is that many identities remain heavily over-privileged. This typically happens due to misconfigurations, a lack of visibility or simply a desire to reduce technical friction during rapid development. Attackers can exploit over-privileged identities to execute malicious operations that should have been blocked by tighter access controls. At the same time, many over-privileged identities exist in production for years without ever causing an issue. Security teams use cloud security posture management (CSPM) to audit assigned cloud permissions – but this is only part of the identity puzzle.
  • What an identity actually does: This lies within the domain of cloud detection and response (CDR). Analyzing the practical evidence of operations invoked by different identities is the main focus of this article. To do this we inspect observed API activity such as authentication (ConsoleLogin, GetSigninToken) and discovery (ListBuckets, ListRoles). To interact with the 240 services offered by AWS, there are more than 15,000 possible operations an identity can invoke.

Given that thousands of identities are operating across complex cloud environments, we are left with the following questions:

  • Are there common behavioral patterns that identities naturally follow?
  • How can we reliably differentiate between the footprints of various functional roles such as administrators, DevOps, backup services and security tools?

Mapping the Landscape: Functional Identity Roles

Analyzing the specific cloud operations an identity invokes, as captured in AWS CloudTrail, provides a clear picture of its day-to-day behavior and role. When observing a large enough collection of identities across multiple organizations, a macro-level picture begins to emerge.

A behavioral map visualizes each identity as a distinct data point, where its invoked operations dictate its coordinates. The scatter plot in Video 1 projects a vast array of AWS identities into a two-dimensional space based on their executed operations.

Video 1. AWS identity behavioral map.

In this simplified visualization, each dot represents a unique cloud identity, projected into a two-dimensional space where proximity reflects behavioral similarity and colors reflect behavioral clusters.

This map features the 30 largest clusters found in the dataset, representing approximately 20,000 identities. Due to a limited color palette, some colors are reused across the visualization; however, each spatially separated dense region represents its own isolated cluster.

The visual datapoint clustering, along with additional quantitative metrics, indicate that cloud identities have a strong tendency to share similar behavioral traits, often mapping to the same functional roles across different organizations.

Analytical Methods

To decode the functional role associated with each behavioral cluster, we combined four analytical methods:

  • Operation frequency: Analyzing the most frequent operations invoked within each cluster
  • Class-based scoring (c-TF-IDF): Using c-TF-IDF scoring to identify operations that distinguish one cluster from the rest
  • Attribute-based mapping: Highlighting various portions of the map based on specific operations, services and/or string matching
  • Identity naming patterns: Mining common substrings and naming conventions within each cluster

To illustrate these methods, we narrow our analysis to a well-isolated cluster shown in Video 2. Consisting of roughly 5,000 identities spanning over 100 cloud projects, it represents one of the largest, most dense clusters in our dataset: administrative user identities.

Video 2. Detailed view of the administrative identity cluster.

The clustering algorithm we use is hierarchical, allowing us to partition large clusters into distinct sub-behaviors. However, for the purposes of this research, we analyze the cluster at a macro level, focusing on identities operating through the AWS Management Console.

Operation Frequency

An analysis of the most frequent operations within this cluster revealed a defining characteristic: roughly 94% of the identities invoked ConsoleLogin, an AWS Management Console sign-in event, as Figure 1 shows. For comparison, fewer than 1% of identities in any other cluster performed this operation.

A chart lists AWS operations with their mean values.
Figure 1. The most frequent cloud operations executed within the selected cluster.

We can also see that around 60% of the identities in the cluster invoke additional operations associated with the default AWS Console behavior, such as GetCostAndUsage and GetCostForecast.

Class-Based Scoring

To look beyond raw frequency and uncover the most distinguishing operations for this group, we examined the cluster using c-TF-IDF scoring, as illustrated in Figure 2. The APIs with the highest op_score serve as behavioral markers, occurring frequently within the selected cluster while remaining relatively rare across the rest of the global dataset.

A list of AWS operation names related to health, cost optimization, and inspection services, along with corresponding numerical scores.
Figure 2. Distinguishing operations of the selected cluster based on c-TF-IDF scores.

The scoring results show that operations that are automatically triggered when logging into the AWS console – such as ListNotificationHubs – receive higher scores than those based on raw frequency analysis.

Attribute-Based Mapping

To further validate the hypothesis that this is a cluster of administrative user identities, we also examined textual metadata. We looked at the entire clustering map and highlighted only the identities whose resource names contain the substring admin. In Video 3, the admin string shows a strong concentration within our selected target group.

Video 3. Global behavioral map, with identities containing the admin substring highlighted in orange.

In addition to highlighting portions of the map based on names, it is also possible to highlight them based on attributes such as specific invoked operations, usage of selected services such as S3, EC2 Lambda or any other measurable attribute.

Identity Naming Patterns

Mining common substrings from identity names provides additional context for cluster analysis. While relying on naming conventions of a single identity alone can generate inaccurate results, recurring patterns within a cluster help explain its underlying behavior. Using a Generalized Suffix Tree, we algorithmically discovered the cluster's most frequent substrings rather than searching for specific arbitrary keywords like “admin.” Among the top results was AWSReservedSSO_AdministratorAccess_ – the default prefix generated when assigning AdministratorAccess via AWS IAM Identity Center.

Landscape Mapping Summary

Combining these quantitative methods with visual mapping allows us to confidently conclude that this cluster indeed represents administrative users operating primarily through the AWS Management Console.

Repeating this profiling process across our dataset reveals clear, reproducible clusters for both human and machine identities, some of which shown in Figure 3. We were able to identify clusters based on behavioral patterns, including:

  • DevOps
  • Infrastructure as Code (IaaC) runners
  • Continuous integration and continuous delivery (CI/CD) systems
  • Security products
  • Backup agents
  • Networking components
  • FinOps platforms
A scatter plot displaying clusters marked with names such as "CI/CD," "Console Admins," "Data Lake," "DevOps," and more. Each cluster is denoted by color and encircled by dashed lines, positioned against a grid background.
Figure 3. Global behavioral map with identified clusters labeled.

Methodology: The Clustering Pipeline

To build this behavioral map, we constructed a multi-stage data pipeline, as illustrated in Figure 4. The pipeline consists of the following stages:

  • Cloud audit log ingestion
  • Pre-processing and vectorization
  • Dimensionality reduction
  • Clustering
A flowchart depicting a process involving cloud audit logs. It starts with ingesting cloud audit logs, followed by pre-processing and vectorization to create high-dimensional vectors. These vectors are then processed through UMAP for dimensionality reduction. Projected vectors result in dense embeddings for HDBSCAN, assigning cluster IDs, and 2D visualizations for assigning 2D coordinates.
Figure 4. The complete pipeline with its multiple stages.

The process begins by converting raw cloud audit logs into identity vectors that capture each identity's behavior and allow us to measure the distance between them. In this format, each identity is represented as a vector containing information about the specific operations it invoked.

By treating the set of possible operations as a “vocabulary,” we can represent each identity as a boolean vector where positions are marked true if the operation was invoked within the given timeframe. Because this vocabulary spans at least 15,000 possible operations — most of which are rarely invoked — the resulting vectors are both large (high-dimensionality) and sparse (mostly filled with zeros), making them challenging to process. Figure 5 shows the data format after this vectorization process, using test identities and data.

A table showing various AWS IAM roles and users with their associated permissions and activity counts. Columns display counts for security configurations, records, tags, and configuration sets, mostly showing zeros, except for a few entries.
Figure 5. Sparse matrix representation of cloud identity behavior using boolean vectors.

We applied the Uniform Manifold Approximation and Projection (UMAP) algorithm to reduce high-dimensional data into a lower-dimensional space while preserving its essential structure. Considering our vector representation, we found that cosine similarity works well as the distance metric for UMAP, as it focuses on the angle between the vectors rather than their magnitude.

We ran this dimensionality reduction on the vectorized data, processing it in two parallel passes:

  • The first pass creates dense embeddings, which are lower-dimensional vectors for the clustering algorithm. This significantly reduces dimensions while preserving enough detail to maintain behavioral information.
  • The second pass compresses the original sparse vectors into a two-dimensional plot specifically for visualization, as shown in Figures 1, 2 and 5.

Figure 6 shows how the format and dimensionality of the data change after applying UMAP in the first pass. The initial large vectors consisting of over 10,000 boolean values are transformed into much smaller, dense vectors with 32 continuous values.

A diagram illustrating dimensionality reduction using UMAP. The top section shows a table with identity roles "Logger" and "DataResilience" and corresponding permissions, with dimensions over 10,000. An arrow labeled "Dimensionality Reduction (UMAP)" points to a lower section, showing the same identities with reduced dimensions labeled d0, d1, and d2, consisting of numerical values.
Figure 6. Illustration of the dimensionality reduction process.

At this stage, we feed the dense embeddings into the Hierarchical Density-Based Spatial Clustering of Applications with Noise (HDBSCAN) algorithm, which groups the identities by detecting dense regions in the dataset.

Once every identity is assigned to a cluster, or labeled as an outlier, we can begin investigating the groups to understand their shared behaviors. This analysis focuses on their common traits and how to distinguish them from identities in other clusters. The resulting groups align closely with standard functional roles in cloud environments, such as Administration, DevOps, Security and CI/CD.

Automated Detection Mechanics

After discovering the behavioral groups using the above pipeline, we can scale this detection capability to ingest new identities and automatically determine whether they belong to a known cluster.

Instead of running the full pipeline, we train a classifier to evaluate cluster membership for groups of interest. For example, a dedicated classifier can be built to detect DevOps users, while a different classifier can detect security tools.

We found that a simple logistic regression model trained directly on the original sparse boolean vectors can accurately identify our clusters of choice. Unlike more complex machine learning models that often require additional tools to interpret outputs and decisions, the trained logistic regression model is highly interpretable. This enables us to observe the cloud operations required to infer cluster membership, along with their respective mathematical weights.

In practice, the model's inference logic calculates a weighted sum of the present operations. This means that we can determine how each cloud operation increases or decreases the likelihood that an identity belongs to a target cluster, and which operations are most important for prediction.

Because the vocabulary of possible operations is vast, assigning weights to thousands of mostly irrelevant operations would be unnecessary. To address this challenge, we used L1 regularization, also known as Lasso. This is a penalty that forces the model to reduce the coefficients of irrelevant features to absolute zero, compressing the model to focus exclusively on a small subset of critical, defining operations.

These steps result in a local approximation of our more complex clustering model. By training the classifier on specific groups, the model is essentially distilled into an indicative set of a few dozen operations paired with corresponding coefficients. This concise logic can be used to quickly infer whether an identity belongs to a DevOps, administrative or security product cluster.

Beyond being transparent and explainable, this lightweight logic is simple and efficient enough to be implemented directly within standard SQL queries. By adopting this lightweight approach, organizations can perform accurate role inference at scale, without relying on resource-intensive pipelines.

Conclusion

While posture management establishes the essential baseline of what an identity is permitted to do, analyzing its behavior reveals what it actually executes in production. Knowing the true functional baseline of an identity allows security teams to quickly spot deviations, flag defense evasion attempts and accelerate incident response.

By utilizing unsupervised machine learning algorithms like UMAP and HDBSCAN, we demonstrated that cloud identities naturally form distinct behavioral clusters. Rather than relying on static assigned permissions, these clusters accurately reflect an identity's true functional role within an environment — such as administrative access, CI/CD pipelines or security scanning services.

After establishing these behavioral clusters, we can efficiently map identities to their functional roles using lightweight logic distilled from our model. This logic can be implemented directly in standard SQL queries, enabling highly scalable identity classification across enterprise environments. This methodology can also be applied to audit logs from other sources of operational data, including different cloud providers, Kubernetes and SaaS.

Enriching standard telemetry with behavioral metadata adds an important layer of context, exposing high-risk anomalies that static analysis could miss, such as a compromised backup service suddenly executing administrative actions.

As cloud environments continue to grow in complexity, a context-aware approach serves as a robust blueprint for future detection strategies, offering a clear path toward more precise, efficient and proactive security operations.

Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:

  • Cortex Cloud can help protect cloud posture and runtime operations against identity-driven threats by pairing static permission baselines with deep behavioral context. By embedding the functional identity baselines discussed in this research into our detection engine, Cortex Cloud adds a vital layer of operational context, enabling security teams to filter out noisy false positives and decisively catch threat actors attempting to masquerade, alter configurations, or execute anomalous operations in the environment.
  • Cortex XDR and XSIAM are designed to prevent the execution of known malicious malware and prevent the execution of unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module.
  • Idira Privilege Access Management (PAM) can help unify privileged access across human, machine, and agentic identities to secure cloud access across multi-cloud environments. Building on proven PAM, it delivers centralized secrets management alongside modern controls like Just-in-Time access and Zero Standing Privileges. This enforces consistent least-privilege security across on-premises, cloud, and SaaS targets.
  • Idira Identity Governance and Administration (IGA) can help automate user access reviews and access provisioning, using AI Profiles to continuously define job-appropriate access rather than relying on static, hard-to-maintain roles. By analyzing entitlements at a granular level, Idira surfaces excessive privilege with less effort, enforces least privilege at scale, and provides the integrated governance foundation for Zero Standing Privilege across all identities.

Unit 42 Cloud Security Assessment is an evaluation service that reviews cloud infrastructure to identify misconfigurations and security gaps.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
  • UK: +44.20.3743.3660
  • Europe and Middle East: +31.20.299.3130
  • Asia: +65.6983.8730
  • Japan: +81.50.1790.0200
  • Australia: +61.2.4062.7950
  • India: 000 800 050 45107
  • South Korea: +82.080.467.8774

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Additional Resources

Appendix: Cortex XDR/XSIAM Alerts Utilizing Behavioral Roles

Table 1 shows Cortex alerts that use roles assigned from behavioral analysis and the CDR module, mapped to MITRE ATT&CK® techniques.

Alert Name Alert Source MITRE ATT&CK Technique
AWS SSM send command attempt XDR Analytics BIOC, Cloud Detection & Response Module (CDR) Cloud Administration Command (T1651)
AWS Password Policy Discovery XDR Analytics BIOC, Cloud Detection & Response Module (CDR) Password Policy Discovery (T1201)
AWS resource discovery XDR Analytics BIOC, Cloud Detection & Response Module (CDR) Account Discovery: Cloud Account (T1087.004)
AWS web ACL deletion XDR Analytics BIOC, Cloud Detection & Response Module (CDR) Impair Defenses (T1562)
Compute activity in dormant cloud region XDR Analytics BIOC, Cloud Detection & Response Module (CDR) Unused/Unsupported Cloud Regions (T1535)
AWS Backup vault was deleted XDR Analytics BIOC, Cloud Detection & Response Module (CDR) Inhibit System Recovery (T1490)
Cloud instance creation attempt XDR Analytics BIOC, Cloud Detection & Response Module (CDR) Modify Cloud Compute Infrastructure: Create Cloud Instance (T1578.002)
AWS Lambda Cross-Account sensitive permissions configured XDR Analytics BIOC, Cloud Detection & Response Module (CDR) Account Manipulation: Additional Cloud Roles (T1098.003)
AWS IAM Role's Trusted Policy Modification Allows Cross-Account Access XDR Analytics BIOC, Cloud Detection & Response Module (CDR) Account Manipulation: Additional Cloud Roles (T1098.003)
AWS IAM Role Created with Cross-Account Access XDR Analytics BIOC, Cloud Detection & Response Module (CDR) Account Manipulation: Additional Cloud Roles (T1098.003)
AWS S3 bucket exposure via ACL / policy modification XDR Analytics BIOC, Cloud Detection & Response Module (CDR) Account Manipulation: Additional Cloud Roles (T1098.003)

The Machine With Many Faces: Post-Exploitation Identity Misuse in SPIFFE/SPIRE

Posted on by Sheida Azimi

Executive Summary

This research demonstrates post-exploitation techniques that could allow an attacker with root access on a compromised Kubernetes node to misuse an open standard and reference implementation for machine identity known as SPIFFE/SPIRE to impersonate co-located workloads and harvest SPIFFE Verifiable Identity Documents (SVIDs). We show how the trust assumption at the core of every machine-identity system — that the node is trusted — collapses once an attacker obtains root on that node. Unit 42 has not observed this technique exploited in the wild.

The Secure Production Identity Framework for Everyone (SPIFFE)/the SPIFFE Runtime Environment (SPIRE) is widely deployed in Kubernetes and cloud-native environments to replace long-lived secrets with short-lived, cryptographically verifiable workload identities.

Our research shows how an attacker with root can spoof the Linux control group (cgroup) information the SPIRE agent uses during workload attestation. This tricks the agent into issuing a co-located workload's SVID to an attacker-controlled process.

As part of this research, we developed Spooffe, an open-source tool that defenders can use to test whether an attacker with administrative access could manipulate cgroup metadata to retrieve co-located workload identities and assess the resulting identity area of impact.

When designing threat models for SPIFFE/SPIRE, organizations should assume that root-level access to a node grants access to all cryptographic identities scoped to it. We recommend performing the following activities to reduce exposure:

  • Harden nodes
  • Restrict root access
  • Prohibit privileged containers, host access
  • Minimize reliance on weak selectors

Palo Alto Networks customers are better protected from the threats described here through the following products and services:

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Related Unit 42 Topics Identity, Cloud, Kubernetes

Introduction

SPIFFE is an open standard for machine identity designed to solve the “Secret Zero” problem — the challenge of securely introducing the initial secret required to bootstrap trust — by replacing long-lived secrets with short-lived workload identities. When deployed correctly, SPIFFE enforces strong identity boundaries between workloads.

However, these guarantees rely on a core assumption shared by all identity systems that the underlying node is trusted. If an attacker gains root access to a node, they can interact with identity mechanisms to retrieve all identities authorized to that compromised node.

Our research explores how attackers can exploit root access to harvest workload identities from a compromised node. In this post, we lay the groundwork by explaining machine identity and how SPIFFE establishes and verifies trust in cloud-native environments. We then demonstrate workload impersonation through selector spoofing. Finally, we introduce Spooffe, a tool we built to automate the extraction of these workload identities (SVIDs).

Note to readers: If you’re already familiar with SPIFFE/SPIRE concepts and architecture, you can jump directly to Workload Attestation and How the Agent Attests the Workload sections.

SPIFFE Overview

Consider a scenario where two applications, a frontend and a backend, must communicate securely.

We could generate key pairs and exchange public keys to communicate through Mutual Transport Layer Security (mTLS), but this option raises a few key questions:

  • Who rotates those keys?
  • Who revokes them if the app is compromised?
  • Can we verify who/what is presenting the keys?

SPIFFE addresses these issues by standardizing how machines are named and how short-lived credentials are issued.

The term machines refers to two broad categories:

  • Workloads: Containers, processes and services running application logic
  • Devices: Endpoints such as desktops, mobile devices and internet of things (IoT) or operational technology (OT) systems
    • (Note: Device identity is not part of the core SPIFFE specification)

SPIFFE Identity Components

Each workload is assigned three identity components:

  1. SPIFFE ID: Who you are (your name)
  2. SPIFFE Verifiable Identity (SVID): Proof that you are who you are claiming to be (your credentials)
  3. Trust Bundle: How others verify that a trusted authority issued your credential

Let’s go into a little more detail about each of these.

SPIFFE ID is a canonical name for a workload identity that follows a URI-style format like spiffe://<trust-domain>/<path> (Figure 1).

A diagram illustrating a SPIFFE URI. The structure includes three parts: "URI scheme," "trust domain name," and "name or identity of the specific workload". Arrows point from each label to the corresponding parts of the URI.
Figure 1. SPIFFE ID.

The middle part (example[.]com) in Figure 1 is the trust domain, the issuer of identity that acts as a security boundary.

In this way, workloads can have an identity and know who to communicate with.

However, identity alone does not guarantee trust or security, so we add the SPIFFE Verifiable Identity Document (SVID). This is a short-lived credential that a workload presents to prove its identity. It is cryptographically signed by the certificate authority (CA) server and always includes the workload's SPIFFE ID.

SVIDs support two primary formats:

  • X.509 SVID: A certificate with an embedded public key, typically used for mTLS
  • JSON Web Token (JWT) SVID: A signed JWT token used as a bearer token for application-level authorization

Finally, we have the trust bundle, which is a set of trust anchors — root CA certificates or JSON Web Key Sets (JWKS). These are used to verify that a trusted authority issued an SVID within a trust domain.

To understand how these identity components are issued and verified in practice, we first need to look at the SPIRE architecture and its core runtime components.

SPIRE Architecture

SPIRE is a production-ready implementation of the SPIFFE specification. While several implementations exist, we chose SPIRE for this research because it is widely deployed in Kubernetes environments and fully implements the SPIFFE standard. Furthermore, because SPIRE is open source, we can inspect its internals to understand how the specification works in practice.

SPIRE is composed of a few simple pieces (as shown in Figure 2 below):

 

A diagram illustrating SPIFFE/SPIRE architecture. At the top, "CLI Tool" and "API Calls" lead to a "registration API" and "Trust bundle" within a server. Below the server, "Node API" connects to two agents, each with a "WL API." A highlighted entry shows components and related terms.
Figure 2. SPIFFE/SPIRE architecture.
  • Workload: A single piece of software deployed to do a specific job (e.g., a process, container, pod)
  • SPIRE Server (control plane): This is the CA that stores registration entries. It also issues and cryptographically signs SVIDs. Additionally, it publishes the trust bundle for the trust domain.
  • SPIRE Agent: This runs on every compute node (e.g., a Kubernetes node, VM or bare-metal host). It performs the following activities:
    • Accepts requests from workloads locally over the Workload API (UNIX socket)
    • Communicates with the server via the Node API
    • Performs attestation
    • Caches SVIDs
    • Handles rotation
  • Registration entries and selectors: These are server-side policy objects that define which workloads are allowed to receive which SPIFFE IDs. When a workload requests an identity, the SPIRE agent collects runtime attributes (selectors) about the workload and the server compares them against registration entries to determine which identity, if any, should be issued.

With the SPIRE architecture in mind, we can now walk through how workload-to-workload identity verification works end to end.

Workload-to-Workload Identity Verification Flow

When workload A needs to communicate with workload B over mTLS, it requests a short-lived credential from the local SPIRE agent. The agent attests the workload and forwards the attestation data to the SPIFFE server. Based on predefined registration policies, the server selects the appropriate SPIFFE ID for the workload and issues a short-lived X.509 SVID.

The server also publishes the corresponding public keys as part of the trust bundle.

When workload A initiates a connection, it presents its SVID during the mTLS handshake. Workload B verifies the SVID by validating the signature against the trust bundle, checking the certificate’s expiration, and confirming that the SPIFFE ID matches an expected identity.

If these checks succeed, workload B can cryptographically authenticate workload A and establish a secure connection. This enables workload-to-workload communication based on identity rather than long-lived secrets (Figure 3).

A diagram depicting a process flow between two workloads, A and B, using secure communication. Workload A signs data with a server's private key, creating an SVID (X.509) that includes a public key. This information is verified by Workload B using a trust bundle. The process includes verification and the exchange of digital certificates via an endpoint. The visual features robots and padlock icons to represent processes and security.
Figure 3. Workload communication.

The identity flow described above depends on attestation, the process by which SPIRE determines whether a workload is allowed to receive an identity. SPIRE performs attestation at two levels:

  1. Node attestation establishes trust in the agent running on a node
  2. Workload attestation determines the identity of individual workloads

In this post, we focus on workload attestation, as it is the mechanism directly involved in selector evaluation and the attacks discussed later.

Workload Attestation

Before the agent attests the workloads, the SPIRE server’s administrator must register the workload selectors in the SPIRE server so it can later compare them to the selectors in the agent.

In this Kubernetes example, the registration entry authorizes any pod running in the default namespace and using the default service account to receive the specified SPIFFE identity (spiffeID).

The resulting record is stored on the SPIRE server as follows:

The SPIRE agent periodically synchronizes and caches these registration entries from the server, using them locally during workload attestation to determine which identity applies. The agent generates key pairs for each registration entry, sends certificate signing requests (CSRs) to the server and caches the resulting SVIDs.

When a workload wants to authenticate, it requests an identity from the agent over the Workload API (Figure 4, step 1). The agent performs workload attestation (Figure 4, step 2) by gathering selectors from the workload process and matching them against cached registration entries.

Upon a successful match (Figure 4, step 3), the agent returns:

  • X.509 SVID
  • Private key
  • Trust bundle

Note: This example is based on an X.509 SVID request. For JWT SVID requests, the agent returns only a signed JWT token.

A diagram titled "Workload Attestation" illustrating the process flow. "Workload A" connects to "kubelet" and "Linux" components, then to "k8s" and "UNIX," leading to the "Agent." The "Agent" includes "Workload Attestor" and connects to the "Workload API." Cached entries and SVIDs are shown. The process is numbered 1 to 3, showing the flow of requests and responses.
Figure 4. Workload attestation.

With the high-level flow in mind, we can now examine how attestation works in practice.

How the Agent Attests the Workload

When a workload requests an SVID (via FetchJWTSVID or FetchX509SVID), it connects to the agent Workload API, typically via a Unix domain socket (such as /run/spire/sockets/agent.sock). The agent then extracts the PID for the calling process.

Once the agent receives the PID, it passes it to the configured workload attestor plugins, which collect selectors based on process and container metadata. SPIRE agents support several workload-attestor plugins. Common plugins include docker, k8s, systemd, Unix and Windows. In our cluster, the agent uses the k8s and Unix plugins.

Kubernetes Plugin (k8s)

The k8s plugin uses the workload PID to access /proc/<pid>/mountinfo or /proc/<pid>/cgroups. It calls GetPodUIDAndContainerID to extract the pod UID and the container ID. In our environment, this process looks like the following:

After extracting the container ID and pod UID, the k8s plugin queries the kubelet to retrieve pod metadata. To do this, it uses the SPIRE agent’s service account token, stored at /var/run/secrets/kubernetes.io/serviceaccount/token.

The agent's service account has the following permissions, which allow it to list pods and access node information:

Using this token, the plugin calls getPodList to retrieve all pods on the node. It then identifies the pod whose UID and container ID match the values extracted from the /proc directory. Once matched, it collects selectors from the pod's metadata:

Unix Plugin

The Unix plugin gathers information from /proc to produce selectors such as user identifier (UID) and group identifier (GID). These selectors are used during workload attestation to bind a workload’s identity to operating system level properties of the calling process, helping SPIRE distinguish between different workloads running on the same node.

Here is an example of the selectors it collects:

The agent combines these selectors from both the k8s and Unix plugins. It then matches this selector set against the locally cached registration entries. If an entry's selectors are a subset of the workload's selectors, the agent returns the corresponding cached SVID to the workload.

Workload Impersonation: Selector Spoofing via Cgroup

This attack requires root-level access to the node. Our analysis revealed that workload attestation relies heavily on the workload’s cgroup path. An attacker with root access on the node can manipulate this cgroup path, potentially tricking the agent into believing the attestation claims belong to a different workload and obtain that workload’s identity. This could allow the attacker to impersonate the victim workload and access any services or resources trusted under that identity.

As a first step, we created a registration entry for a pod named workload-a in the server and we verified that we could fetch its identity from the pod:

We verified that we could not retrieve this identity from the host by requesting a JWT SVID:

To spoof the workload-a cgroup, we first retrieve its PID:

We checked its cgroup path based on the above PID:

We copied this path to a mock cgroup path and wrote our shell’s current PID($$) into the mock cgroup’s cgroup.procs file:

Notably, writing the PID directly into the original cgroup path would have also worked. We used a separate cgroup only to avoid modifying the original workload’s runtime state.

Running the fetch command again successfully retrieved the identity associated with PID 9072:

We can also see the workload-a SPIFFE ID inside the JWT token:

The manual spoofing demonstration highlights that the security model relies entirely on a single, vulnerable assumption of node integrity. When we have root access, we can get the identity of any workload on the node.

This manual spoofing demonstration highlights a critical trust assumption in workload attestation. When an attacker has root-level access to a node, they can manipulate cgroup information to cause the SPIRE agent to misattribute workload identities. Under these conditions, the attacker can impersonate other workloads running on the same node and obtain their identities.

Spooffe

These findings motivated us to develop Spooffe, a tool that allows defenders to automate selector spoofing to retrieve all the workload identities from the node.

Spooffe scans the node for running workloads, discovers their cgroup paths, and replicates them as a mock cgroup for its own process. It then queries the local SPIRE agent for the resulting identities (SVIDs), allowing us to collect all workload identities present on the host (Figure 5).

A screenshot of a terminal displaying a command line output related to Kubernetes. The text includes creation and verification of a fake group, fetched JWTs, and viewing various certificates. It features commands like `spoofre` and directories related to Kubernetes pods.
Figure 5: Dumping all workloads' identities (SVIDs).

Besides selector spoofing, Spooffe includes additional capabilities. However, in this post we focus only on the features relevant to this research.

One such capability is agent impersonation, which examines whether an attacker can impersonate the SPIRE agent and communicate directly with the server to extract workload identities.

Conclusion

In this article, we demonstrated how an attacker with root access on a compromised node can misuse SPIFFE/SPIRE workload attestation to impersonate co-located workloads and retrieve their identities. By manipulating cgroup metadata, we showed how attackers could mislead the SPIRE agent into issuing valid SVIDs to an attacker-controlled process. We also introduced Spooffe, a tool that automates this technique to enumerate and extract workload identities from a node.

These findings highlight a fundamental assumption in workload identity systems: trust in the underlying node. While SPIFFE/SPIRE enforces strong cryptographic identity guarantees between workloads, those guarantees rely on the integrity of the environment where attestation occurs. Once that trust boundary is broken, identity isolation between workloads collapses, allowing attackers to move laterally using legitimate credentials rather than stolen secrets.

Organizations adopting workload identity should treat node-level compromise as equivalent to compromise of all identities scoped to that node. To reduce risk, restrict privileged containers, limit direct host access and minimize reliance on weak or easily spoofable selectors.

Palo Alto Networks has shared our findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Palo Alto Networks Product Protections

Palo Alto Networks customers are better protected from the threats discussed above through the following products:

  • Cortex XDR and XSIAM can help protect against post-exploitation activities using the multi-layer protection approach. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection, and Endpoint Protection Modules (EPM).
  • Cortex Cloud Identity Threat Detection can help deliver end-to-end visibility across cloud providers and IdPs by baselining real-time access patterns. By continuously monitoring these behaviors, ITDR detects identity abuse and compromised credentials targeting critical cloud resources and Kubernetes workloads, automatically triggering containment actions to keep attackers out.

If you think you might have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
  • UK: +44.20.3743.3660
  • Europe and Middle East: +31.20.299.3130
  • Asia: +65.6983.8730
  • Japan: +81.50.1790.0200
  • Australia: +61.2.4062.7950
  • India: 000 800 050 45107
  • South Korea: +82.080.467.8774

Additional Resources

Untracked Nightmares: The Threats Hiding Behind Commodity Infrastructure

Posted on by Sheida Azimi

Executive Summary

A recent Unit 42 investigation into seemingly low-priority enterprise infections demonstrates how the most effective camouflage in cybercrime is not necessarily in the use of sophisticated techniques, but in how unremarkable the threat appears. The activities that we investigated would typically not require escalation or further inquiry. But upon closer inspection, we discovered a massive cybercrime campaign largely targeting young gamers. Tracked as CL-CRI-1171, in accordance with Unit 42’s attribution framework, the group behind this cluster has operated under the radar for at least two years, distributing an indeterminate number of payloads.

The group behind CL-CRI-1171 provides an infection service for other threat actors who want to spread their malware indiscriminately. This pay-per-install (PPI) marketplace drove hundreds of infections through YouTube channels and a parallel search engine optimization (SEO)-poisoning funnel, all using the same custom loader.

We observed at least eleven YouTube channels that had hundreds of thousands of followers. We notified YouTube of these channels, which it promptly terminated.

These channels were actively interacting with viewers to promote gaming content laced with links to download malware. Content in the channels included advice on improving frame rates, fixing game crashes and adjusting settings on game platforms. Although the videos provided real content for gamers, they also served as the delivery vehicle for infection, prompting viewers to download malicious tools.

The SEO funnel targeted a more professional audience, promoting trojanized software that resulted in malware deployment on corporate endpoints, including critical infrastructure and even government entities. We identified three independent payloads delivered by the same loader between July 2025 and April 2026: two never publicly reported, Docro Hijacker and ARKTunnel, and a new variant of a previously unnamed backdoor, which we dubbed Insomnia remote access Trojan (RAT).

These infections represent only a small sample of a much larger deployment campaign. We have identified more than 10,000 distinct loader samples, each capable of delivering unique payload combinations.

We provide an overview of the cybercrime cluster and its loader infrastructure, and a technical analysis of three recently delivered malware strains.

Palo Alto Networks customers are better protected from the threats discussed in this article through the following:

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Related Unit 42 Topics SEO Poisoning, Browser Hijacking, RATs

Overview of CL-CRI-1171 Activity

Our discovery of two separate infections delivering three entirely distinct malware families revealed one common denominator: a shared loader. By tracing this infrastructure, we mapped the broader activity of CL-CRI-1171, ultimately tying the cluster to a PPI marketplace responsible for delivering countless payloads over the last two years.

This operation uses at least two funneling mechanisms to route traffic to the malware landing pages: a network of YouTube channels and SEO poisoning. The shared infrastructure between the YouTube and SEO funnels, consistent use of the same loader and a rotational domain pattern observed over an eight-month window all pointed to a single sustained operation, which we track as CL-CRI-1171.

The PPI Ecosystem: An Infection Marketplace

PPI networks operate as underground marketplaces. An operator compromises machines and auctions access to multiple buyers, each buyer deploying their own independent payloads through the same dropper. The result is a single infection that conceals multiple payloads from unrelated threat actors on the same endpoint, each with its own C2 infrastructure and objectives. Because the loader is designed to be disposable and generic, it rarely attracts the scrutiny needed to uncover its subsequent payloads.

Tracking CL-CRI-1171: The PPI Operation Behind the Payloads

The investigation began with two identical and seemingly routine infections at separate organizations. Both events involved trojanized software downloads — one a Bluetooth driver, the other WinDirStat — and both affected machines executed an identical post-exploitation chain. The loader was unnamed, untracked and generic enough to be dismissed as commodity adware.

But our discovery of a shared payload chain raised a question. How were two unrelated organizations infected by the same unnamed loader delivering the same set of payloads, just one week apart?

Pivoting on the loader's C2 infrastructure revealed a sprawling network of rotational domains — over 200 unique hostnames following a distinctive two-word compound naming pattern (including bubbleslip, churchpail, dinosaursjam), rotating across .xyz, .cfd, .space and .info top-level domains (TLDs).

Unpacking the Delivery Infrastructure

The payloads delivered through CL-CRI-1171's infrastructure are not fixed, enabling the simultaneous delivery of unrelated malware families. In April 2026, two incidents initiated this investigation. They shared a single loader that delivered three separate malware families: Insomnia RAT, ARKTunnel and Docro Hijacker. A subsequent infection, observed in June 2026, delivered two entirely different payloads: GCleaner and Socks5Systemz.

Figure 1 illustrates the structure of the operational architecture and the observed rotational malware bundles.

A diagram illustrating CL-CRI-1171 infrastructure with connections from YouTube and SEO funnels, listing several attack vectors.
Figure 1. Illustration of CL-CRI-1171 infrastructure.

Our in-depth analysis explores three operations that were spotted in two intrusion sets during April 2026. By examining the campaign’s trackers, we found that these operation payloads were in rotation from July 2025 to April 2026. This discovery provides a valuable snapshot of the group’s deployment capabilities and the variety of payloads they have been entrusted to deliver.

Although the observed rotation appears to be highly structured, the discovery of over 10,000 unique OfferLoader samples points to a much larger distribution pipeline. It is very likely that the loader has delivered numerous other malware families.

The SEO poisoning path was the first delivery channel we identified. Unsuspecting users searching for legitimate software landed on file-hosting lure pages that displayed a fake virus-scan animation before delivering the trojanized archive via a chain of redirectors into the PPI gate.

A reconstructed example download page from the SEO poisoning funnel is shown in Figure 2.

A screenshot of a webpage displaying a file download section. There’s a large green button labeled "Download File" and an option to "Check viruses." The footer includes links to hosting details and mentions of partner sites.
Figure 2. Reconstruction of the trojanized WinDirStat download page.

Analysis of the gate's tracker URLs revealed a critical detail. Each URL contained a click_id parameter: a Base64-encoded fingerprint containing the victim's operating system (OS), browser, the referring domain, the exact search keyword that led them to the lure and their public IP address, as Table 1 shows.

Operating System Browser Referring SEO Domain Search Keyword Victim IP
Windows_10 Chrome atthelake[.]info hwidspoofer 5.xxx.xx.xxx
Windows_10 Chrome atthelake[.]info combatwarriorsGit 2.xx.xxx.xx

Table 1. Example of a deobfuscated click_id.

The gate uses this fingerprint to decide who receives the payload: a valid, fresh click_id forwards the visitor to the malware/loader download. This is an evasion tactic used to ensure that only real targets are infected, and to protect the actor’s infrastructure: scanners, crawlers or analysts receive a decoy clone of the legitimate WinRAR download page or broken links. This is why the campaign has almost no public footprint despite being highly active: automated URL scanners rarely pass the gate.

Decoding hundreds of these fingerprints, with the assistance of AI, exposed the full names of YouTube video titles and their associated channels. Alongside search keywords for cracked software and game cheats, the q= field – which tracks which search query led to the infection – contained strings like "CS2 Potato Graphics Settings - Maximum FPS Boost for Low-End PC (2026 Guide) - Velvox."

The YouTube Funnel

Searching for titles derived from the fingerprints led us to uncover a chain of gaming optimization YouTube channels. Their content included tips on boosting frames per second (FPS), fixing game crashes and tweaking settings on popular game platforms. While the videos provided authentic, engaging content for young gamers, they ultimately served as an infection delivery vehicle, prompting viewers to download a malicious “tool” or “optimization pack” via links in the description, as Figure 3 shows.

A screenshot of a YouTube video titled by ADEX with 18.7K subscribers. The video has 168 views as of June 22, 2026. Hashtags include #CPUBottleneck and #LowGPUUsage. Two links are provided: one short link and a GearUp Booster product link.
Figure 3. A YouTube video from the ADEX channel directing viewers to a download link.

Those links pass through intermediary sites, such as Blogspot, which contain social-engineering instructions that lead the victim to the same PPI gate infrastructure serving the SEO path. An example blog page is shown in Figure 4.

A screenshot of a website page showing two featured articles. The first article discusses fixing high ping and packet loss for improved downloads. The second article is about optimizing SSD performance. Both articles include bold headlines and colorful images.
Figure 4. The download link leads to a Blogspot page.

We identified 11 channels connected to CL-CRI-1171, which collectively had hundreds of thousands of subscribers and millions of views.

Technical Analysis

Our investigation revealed three malware strains delivered by the group behind CL-CRI-1171 between June 2025 and April 2026. The following sections explain the technical aspects of the loader used by this cybercrime group and the deployed malware payloads:

  • OfferLoader – The delivery mechanism behind all recorded intrusions, an Inno Setup trojanized installer that sets up the other payloads.
  • Operation A: Insomnia RAT – A dual-payload, cross-platform backdoor that brings its own environment to ensure survival. Targeting both Windows and macOS using Node.js, paired with a twin Python agent.
  • Operation B: ARKTunnel – A previously unreported WebSocket tunneling RAT unpacks itself from a bitmap image using steganography. We found 50 samples spanning over a year of development, operating across four fictitious corporate-identity rotations.
  • Operation C: Docro Hijacker – A Chrome backdoor that revives a browser-hijacking technique first seen in 2015, re-engineered to bypass modern integrity protections. This campaign represents the first observation of this modern variant in the wild.

Initial Access Vector in Intrusions

We discovered two intrusion sets that began in the same way: a user searched for a legitimate utility, clicked a top search result that led to a malicious domain, and downloaded what appeared to be a legitimate application. Both infections delivered the same three payloads.

  • First intrusion set: Downloaded Bluetooth Driver for Windows 10.exe from a file-sharing archive. The installer was a trojanized Inno Setup package carrying the PPI loader with affiliate ID CID=2855.
  • Second intrusion set: Browsed to noiseship[.]cfd, a domain registered just 39 days earlier, and downloaded a trojanized windirstat.exe installer. This package carried the PPI loader with affiliate ID CID=3075.

The OfferLoader Execution Chain

The operator's code and C2 communication designate each payload slot as an "offer," tracking variables as offer_execution, offer_execution_fail and offer_exists. Based on the naming convention, we track this loader as OfferLoader. OfferLoader uses chained Inno Setup (a legitimate installation packager) packages to deliver multiple payloads. Figure 5 shows the infection chain.

A Cortex XSIAM infecton chain diagram illustrating the process of payload prevention by Advanced WildFire. It shows a main circle labeled "Installer" leading to another node. Three red X-marked paths branch indicate prevention. Advanced WildFire logo is present at the top.
Figure 5. Cortex XSIAM view of the infection chain. In this case, Advanced WildFire blocked the payloads.

OfferLoader is delivered in a ZIP file, with the source download site providing the social engineering instructions required to guide users through downloading and executing an extraction tool. Based on our analysis of the collected samples, we observed the loader being delivered alongside a legitimate version of WinRAR, renamed to .store. The installer contains no embedded application files; all malicious logic is contained in the compiled Pascal [Code] section, which triggers when the installation page is displayed.

In two separate intrusion sets we discovered that the ZIP file contained OfferLoader masquerading as a windirstat.exe installer that initiates the compromise by unpacking windirstat.tmp. This temporary file transmits an initial tracking beacon to voyagemist[.]space. This is another gating mechanism: depending on the structure of the beacon, one of two text files will be retrieved. They either contain “no” to signal that the loader should not unpack further stages, or “ok” to signal all offers will be deployed. Following this check-in, the process spawns three child processes: eld0.exe, eld1.exe and eld2.exe. Each child process corresponds to a different malware campaign. The loader passes specific affiliate-tracking parameters to each process via a command line.

Figure 6 illustrates the entire OfferLoader infection chain at the time of the intrusion.

A diagram showing an OffLoader attack chain process. The "Victim" is redirected to a domain, followed by the download of a file. This is unpacked into another file, which gates into a different domain. Three operations branch out: Operation A involves Insomnia RAT, Operation B involves ARKTunnel, and Operation C involves Docro Hijacker.
Figure 6. Example of an OfferLoader infection chain.

OfferLoader's role ends once the three offers are spawned. From this point forward, each child process operates as an independent malware campaign with its own infrastructure, C2 protocol and objectives. The following sections analyze what each offer delivers.

Operation A: Insomnia RAT – A Cross-Platform Backdoor

Insomnia RAT simultaneously distributes two payloads:

  • An upgraded variant of a Node.js backdoor (reported by Walmart Global Tech in 2025)
  • A complementary Python backdoor

We have dubbed these twin payloads Insomnia RAT, due to the user-agent string used for C2 communications: insomnia/2023.4.0 Windows.

Figure 7 shows the full infection chain that delivers Insomnia RAT’s twin payloads.

A flowchart illustrating the new Insomnia RAT variant infection chain. It starts with a file loading.The flow continues through a domain, then to a hidden PowerShell downloader. The diagram also includes components like Node.js and Python 3.12. Arrows show how these components connect, with persistence strategies and rotating command and control (C2) server domain.
Figure 7. The new Insomnia RAT variant infection chain.

Eld0.exe drops the a.dll payload and spawns a hidden PowerShell process to download and execute t.ps1. This double-stage installer script disables Windows Defender protections, adds the entire C:\ drive as an exclusion, suppresses security notifications and deploys the two Insomnia RAT backdoors. t.ps1 also downloads and sets up the environment needed to execute both backdoors by installing Python and Node.js on the victim’s machine. Node.js is hidden from the system's Add/Remove Programs list by setting SystemComponent=1 in the registry.

The first part of Insomnia RAT is a Node.js agent downloaded from stryper[.]info/aa.js. While the prior variant targeted Windows, Linux and FreeBSD with a single payload, this iteration targets Windows and macOS using platform-specific C2 server lists. It also deploys a companion Python agent as a redundant fallback, ensuring persistent access if one runtime environment is detected or removed.

The backdoor collects the victim's MachineGuid, universally unique identifier (UUID), hostname and operating system details. It then contacts its C2 servers via an HTTPS POST request to /d using a User-Agent string, insomnia/2023.4.0 Windows to disguise itself. The C2 server responds with a JSON array containing commands. These specify a payload type (node, cmd, ps1, sh, or ow for a self-update) and a download URL. Results are reported back to the /e endpoint.

To establish persistence, the installer registers a scheduled task named Maps Performance Task under \Microsoft\Windows\Maps\. This mimics a legitimate Windows task, executing the backdoor hourly and at system startup under the SYSTEM account.

The same t.ps1 script installs a second, redundant agent. This Python script is downloaded from aa.amazingshield[.]xyz. The installer downloads a legitimate Python distribution and registers a second scheduled task, OOBETaskScheduler, under \Microsoft\Windows\Servicing\.

The Python agent is simpler than its Node.js sibling, but follows the same C2 protocol pattern: POST requests to /d for tasks and POST requests to /e for error reporting. The agent collects the MachineGuid, OS product name, hostname and processor architecture.

The Python agent used crowdstri[.]com as its C2 domain. This appears to be a deliberate typosquat of crowdstrike[.]com, designed to blend into logs and evade quick security reviews.

Operation B: ARKTunnel – A WebSocket RAT Hidden in a Bitmap

The eld1.exe chain terminates in a previously undocumented tunnel payload. The chain uses least-significant-bit (LSB) steganography to deploy the final payload. Figure 8 shows the full infection chain of Operation B.

A flowchart illustrating the ARKTunnel infection chain, a sequence of events involving multiple software entities. The flowchart highlights processes such as persistence, host reconnaissance, and the use of an autorun.
Figure 8. The ARKTunnel infection chain.

Rather than dropping an executable directly to disk, eld1.exe extracts a ZIP archive from a BMP image resource using LSB steganography. The result is the payload archive, ProcorTrex.zip, which contains wscl.exe, a previously unreported WebSocket-based tunneling RAT. We named this RAT ARKTunnel, based on the attacker's fabricated company name rotation of EarthKark and TamarkLark.

ARKTunnel installs itself as a Windows service named wscl-13 or msvcsrvc with a delayed autostart configuration. The RAT supports TCP and UDP tunneling, as well as file execution.

The C2 server address, reg.pcsdkflyer[.]ca, is decoded from a 39-byte configuration blob using Base64-decoding followed by an XOR decryption routine. The portable executable (PE) metadata of wscl.exe contains a fabricated company name, TamarkLark Corporation, and a fictitious product name, TamarkLark Manager, which led us to suspect that other ARKTunnel samples might use additional fabricated company names.

The investigation revealed at least 50 samples deployed over the course of a year. The developer rotated through at least two fake company identities while maintaining an identical icon, binary structure and deployment pattern:

  • EarthLink in May 2025: EarthLink is the name of a legitimate internet provider, however the attackers used this name coincidentally in the file version information. The attackers did not use or impersonate EarthLink resources or identity.
  • EarthChain from May 2025–April 2026: EarthChain is also real company name that the attackers used coincidentally. Likewise, also they did not use or impersonate the company’s resources or identity.
  • EarthKark: A fake identity, used from February 2026–June 2026
  • TamarkLark: A fake identity, used from March 2026–June 2026

All of the samples share the same wscl.exe filename pattern and GUID-based temp directory extraction pattern, indicating that they are variants of the same family.

Despite 50 samples spanning a full year of development and four identity rotations, ARKTunnel has attracted no public reporting or dedicated tracking, with each sample individually flagged as a generic Trojan rather than recognized as a tunneling implant.

Operation C: Docro Hijacker – Reviving Old Techniques

The eld2.exe payload installs a Chrome browser hijacker that we have named Docro Hijacker. The hijacker revives a browser-hijacking technique that has resurfaced periodically since 2015, now re-engineered to bypass updates to Chrome's integrity protections. While this iteration closely mirrors a proof-of-concept detailed by Synacktiv in 2025, this campaign marks the updated technique’s first documented instance of in-the-wild deployment.

Figure 9 shows the Docro Hijacker installation chain.

A flowchart illustrating the Docro Hijacker infection chain. The flow includes tampering with Chrome secure preferences. The process installs "Docro Hijacker," which connects to four domain indicating various malicious activities like script injection and telemetry.
Figure 9. The Docro Hijacker infection chain.

eld2.exe is an Inno Setup package, and much like its loader, it extracts and runs eld2.tmp which contacts the affiliate’s extentrack[.]com install tracker.

eld2.tmp drops and loads Adblock.dll, which bypasses Chrome's Secure Preferences HMAC-SHA256 integrity check. The DLL extracts Chrome's HMAC key from resources.pak, computes valid HMAC signatures for the modified preference values and writes them directly to the Secure Preferences file. This file functions as an anti-tamper mechanism for browsers by storing a validated copy of the user's settings.

This manipulation allows the malware to execute two primary actions:

  • Search hijacking: Changes the default search provider to mqsearch[.]com, a domain that masquerades as a search engine
  • Extension installation: Installs the docro extension, a Chrome Manifest V3 extension located at C:\ProgramData\DocsHelper\docro\

The docro extension uses Chrome's declarativeNetRequest API to dynamically rewrite network requests. Upon installation, it contacts vendralo[.]info to retrieve a unique per-victim UUID and fetch a set of network rewriting rules that are refreshed hourly.

These rules are used to hijack and monetize search results in the victim's browser. When the victim performs an internet search, across any of more than 190 Google country-code domains, the extension loads a script from drelto[.]info/farlix into the search results page. Because the script runs within the search engine's own origin context, it has full access to the page content. This enables the operator to inject advertisements into organic search results, rewrite affiliate links to capture referral revenue and/or redirect clicks to attacker-controlled destinations. These actions are functionally transparent to the user and visually indistinguishable from the legitimate search page.

The extension also checks vendralo[.]info for updates via /extensionInstaller/updateChromeExtension, allowing the operator to silently rotate to a new extension version at any time. Install telemetry is reported to finersto[.]com and extentrack[.]com.

With more than 50 unique samples contacting mqsearch[.]com according to VirusTotal, Docro Hijacker appears to be a mature, independent monetization module.

Conclusion

The actors behind CL-CRI-1171 did not use sophisticated evasion techniques, but focused their efforts on building a loader that is exceptionally difficult to track due to its clever gating mechanisms.

Our investigation highlights how the authors of OfferLoader, by being intentional about its simplicity and by hiding all of its functions as bytecode within a package, designed the malware to evade scrutiny while quietly building a massive, mature infection funnel.

Although OfferLoader was easy for defenders and security products to miss, its gating mechanisms were not, and the sheer number of them was our first clue that more widespread activity was occurring.

While a loader that just drops a payload is seemingly routine, this mechanism allowed possibly thousands of rotational malware bundles, including entirely new and undocumented malware families, to remain hidden from standard security attention. Ultimately, this case serves as a critical reminder for defenders: Treating commodity loader infections as minor, routine events overlooks the dangerous payloads and campaigns that might be tied to them.

Palo Alto Networks Protection and Mitigation

Palo Alto Networks customers are better protected against the threats described in this report through the following products and services:

  • The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research. Through continuous cloud-based analysis, Advanced WildFire is designed to proactively identify and block OfferLoader samples as well as downstream payloads, including Insomnia RAT, ARKTunnel, and Docro Hijacker.
  • Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious.
  • Cortex XDR and XSIAM can help detect and prevent the OfferLoader chain and all three payload branches described in this article. Cortex customers benefit from multiple layers of protection against this threat, including:
    • YARA-based signatures targeting the OfferLoader family and its staged payloads
    • Behavioral detection rules that help prevent:
      • Malicious Chrome extension setup
      • Untrusted service installations used for persistence
      • Trojanized installer execution patterns

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
  • UK: +44.20.3743.3660
  • Europe and Middle East: +31.20.299.3130
  • Asia: +65.6983.8730
  • Japan: +81.50.1790.0200
  • Australia: +61.2.4062.7950
  • India: 000 800 050 45107
  • South Korea: +82.080.467.8774

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Indicators of Compromise

Initial Access and OfferLoader

SHA256 hash: 7f792c45de1e28fd42ac44c9444f157a2161742d130bac336c0e991aabbb112c
File name: windirstat.exe
File type: PE32 executable, Inno Setup 6.7.1
File description: OfferLoader trojanized WinDirStat installer delivered via SEO-poisoning

SHA256 hash: fc485882626512e7ff82a1d7cd8e8fb3e9751b026d97e682d6908aefff1f2d73
File name: windirstat.tmp
File type: PE32 executable, Inno Setup unpacked stage
File description: Unpacked WinDirStat stage

Operation A: Insomnia RAT

SHA256 hash: 3052bd320a34e12ee694811ed0578797477dfd480c664491e509ed15ce1a6961
File name: eld0.exe
File type: PE32 executable, Inno Setup 6.3.0 SetupLdr
File description: Insomnia RAT initial loader

SHA256 hash: 25558ea78c4aa0fdd0f45fafcaa546d3115dc5806809d144a5801a40e48fd4c5
File name: eld0.tmp
File type: PE32 executable, Inno Setup unpacked stage
File description: Unpacked loader stage

SHA256 hash: 9b0d9cbc0fd4a7bae8b78a15dfbe63052779414ad725845732c4a0083008da69
File name: a.dll
File type: PE32 DLL
File description: Executes the PowerShell downloader for the Node.js and Python second stages

SHA256 hash: ceb30a5eb9ad9d9c6712c80726df16f96f99d9fc0753be241b00b4d636eb576e
File name: t.ps1
File type: PowerShell
File description: Insomnia RAT PowerShell loader

SHA256 hash: cf184d04ca31fb2b6b7efd85399c29c1136b539153e137ceb3877b1b905791de
File name: <guid>.py
File type: Python script
File description: the Python-based component of the Insomnia RAT dual payload.

SHA256 hash: 62d49d0c78207ec2452cc8a30501db771c9edbae89889e41a7dd227551243e8e
File name: aa.js
File type: JavaScript
File description: the Node.js-based component of the Insomnia RAT dual payload.

URL: hxxps[:]//stryper[.]info/t.ps1
Description: Stage-2 PowerShell installer for the Node.js and Python agents

URL: hxxps[:]//stryper[.]info/aa.js
Description: Stage-3 Node.js agent

URL: hxxp[:]//aa.amazingshield[.]xyz/33244556546.py
Description: Stage-3 Python agent

Domain: stryper[.]info
Description: Second-stage PowerShell and Node.js agent host

Domain: aa.amazingshield[.]xyz
Description: Python agent host

Domain: crowdstri[.]com
Description: CrowdStrike-typosquat C2 for the Python agent

Operation B: ARKTunnel

SHA256 hash: aaebc8c07de485be6d1bfa956668c5e18aa1ff5588dfe84672e20ae90b4560f1
File name: eld1.exe
File type: PE32 executable
File description: LSB-steganography dropper. The attacker forged the PE version-info resource to mimic a popular test proctoring application.

SHA256 hash: e05bc22afbc5ddd50b49c85ee169dd13318000d38286de2b8bcff98217256a8d File size: 92,657 bytes
File name: procorTrex.zip
File location: C:\Users\Public\procorTrex.zip
File type: ZIP archive
File description: ZIP carved from the eld1.exe BMP steganography payload

SHA256 hash: b367762140ae7f5098230b8a5da738c9241f286281ec9439dd6ca581fc87989c File size: 245,248 bytes
File name: wscl.exe
File type: PE32 executable
File description: WebSocket tunneling RAT

ARKTunnel resource icons:
SHA256 hash: d8d783f8e050a6e394f3c0aa5e2bc73a38d822e55fbc39c0648cbff566de3cdf
File description: Resource Icon shared across ARKTunnel samples

SHA256 hash: 06e0afd01bbc6c9d5dc16c3165089b233dc071e1f251abd06235d1b9166cdac5
File description: Resource Icon shared across ARKTunnel samples

Domain: reg.pcsdkflyer[.]ca
Description: wscl.exe WebSocket RAT C2

Operation C: Docro Hijacker

SHA256 hash: 2c6e11027b011042c9a118fc20728f8f4ebb6be8795cc84cc9a45622c297d354
File name: eld2.exe
File type: PE32 executable, Inno Setup installer
File description: Branch C installer that drops Adblock.dll and the docro Chrome extension

SHA256 hash: 553ce594c9c6afdd4794fddc28c194e3bc3c1b052310e5099c58ac15bab72104
File name: eld2.tmp
File type: PE32 executable
File description: Inno Setup unpacked stage

SHA256 hash: fdcc95b7791c0d6590dcf1a412dc9fcc92ad2095818d1b78368b31efad012007
File size: 3,041,280 bytes
File name: Adblock.dll
File location: %TEMP%\Adblock.dll
File type: PE32 DLL
File description: Chrome Secure Preferences HMAC-SHA256 bypass DLL that sideloads the docro extension and hijacks the default search provider

Docro extension path:
File location: C:\ProgramData\DocsHelper\docro
File description: Manifest V3 Chrome extension sideloaded by Adblock.dll

Domain: vendralo[.]info
Description: Per-victim UUID and hourly rule delivery

Domain: finersto[.]com
Description: Extension install and start telemetry

Domain: drelto[.]info
Description: SERP-injection script host

Domain: mqsearch[.]com
Description: Hijacked the default search provider endpoint

Domain: extentrack[.]com
Description: Docs Helper install-success and install-failure callback

CL-CRI-1171 Rotational Infrastructure

Initial-Access Lure and SEO File-Locker Hosts

Domain Role
noiseship[.]cfd SEO-poison domain
atthelake[.]info Top referring SEO-poison domain
uy.basesfiles[.]com Fake file host
basesfile[.]com Sibling fake file host
igk.filexspace[.]com ikx.filexspace[.]com SEO file-locker lure hosts
filexstorage[.]site SEO file-locker lure host
filescloud[.]pro SEO file-locker lure host
zippyfiles[.]net SEO file-locker lure host
mifilesx[.]site SEO file-locker lure host
dw.xrsdownload[.]com SEO file-locker lure host
storage.ggclicker[.]com SEO file-locker / referrer host
watchadvance[.]com SEO-poisoning domain

Domains Used to Confirm OfferLoader Installations

Domain:

  • animalview[.]xyz
  • trickflag[.]info
  • suitstraw[.]info
  • connect.fuelleg[.]info
  • vesselsystem[.]xyz
  • minewave[.]info
  • collartitle[.]info
  • boardmagic[.]info
  • placespoon[.]xyz
  • needcherries[.]online

Payload-Handoff and Second-Stage Hosts

Install-Tracker Beacons (Operator Panel)

Domain Role
voyagemist[.]space PPI affiliate install tracker
statementtouch[.]xyz PPI affiliate install tracker
chawton[.]info PPI affiliate install tracker

YouTube Funnel – Burner Blogs and Custom-Domain Sites

Domain Name Persona Type
velfps.blogspot[.]com Velvox Blogspot burner
velvoxlab.blogspot[.]com Velvox Blogspot burner
venrx.blogspot[.]com Venrx Blogspot burner
venrxhub.blogspot[.]com Venrx Blogspot burner
venrx[.]xyz Venrx Custom-domain burner
ravexoffical.blogspot[.]com Ravex Blogspot burner
adex-blog.blogspot[.]com Adex Blogspot burner

Please note: While Velvox is a real company, the attackers used its name coincidentally. They did not use or impersonate the company’s resources or identity.

Additional Resources

Appendix A: CL-CRI-1171 Full Discovered Infrastructure Tables

Indicator Role
achievershelf[.]space Gate/landing
activitymeal[.]space Gate/landing
additionplot[.]cfd Gate/landing
adviceturn[.]xyz Gate/landing
afternoonscrew[.]space Gate/landing
agreementjuice[.]space Gate/landing
airplaneiron[.]xyz Gate/landing
airtwig[.]xyz Gate/landing
amountfuel[.]icu Gate/landing
animalrecord[.]xyz Gate/landing
apparatustruck[.]xyz Gate/landing
apparelplate[.]space Gate/landing
archairport[.]xyz Gate/landing
authoritykittens[.]info Gate/landing
babyvein[.]xyz Gate/landing
badgewing[.]xyz Gate/landing
bagcare[.]space Gate/landing
basinpleasure[.]xyz Gate/landing
basketballyear[.]xyz Gate/landing
baskethumor[.]xyz Gate/landing
bedroomdesire[.]xyz Gate/landing
beliefpicture[.]xyz Gate/landing
bellplayground[.]xyz Gate/landing
bikesdonkey[.]info Gate/landing
birthdaymagic[.]xyz Gate/landing
boatthought[.]xyz Gate/landing
boundarychickens[.]xyz Gate/landing
boytank[.]xyz Gate/landing
branchmorning[.]xyz Gate/landing
breathdoctor[.]xyz Gate/landing
bubbleslip[.]xyz Gate/landing
cabbagemeasure[.]xyz Gate/landing
cablecanvas[.]xyz Gate/landing
cardgrape[.]xyz Gate/landing
cattlegold[.]xyz Gate/landing
celeryerror[.]xyz Gate/landing
centscarf[.]xyz Gate/landing
chalkprose[.]xyz Gate/landing
cherriestruck[.]space Gate/landing
chesstail[.]xyz Gate/landing
chickensmine[.]space Gate/landing
churchpail[.]xyz Gate/landing
clothcrib[.]xyz Gate/landing
clothcurrent[.]xyz Gate/landing
coatberry[.]xyz Gate/landing
connect.activitykitty[.]xyz Install tracker
connect.apparatustaste[.]xyz Install tracker
connect.armcard[.]xyz Install tracker
connect.badgeterritory[.]xyz Install tracker
connect.baitmetal[.]xyz Install tracker
connect.beefteeth[.]xyz Install tracker
connect.believesisters[.]xyz Install tracker
connect.boundaryfly[.]xyz Install tracker
connect.bubbleappliance[.]xyz Install tracker
connect.cableland[.]xyz Install tracker
connect.chinexpert[.]xyz Install tracker
connect.conditiongrade[.]xyz Install tracker
connect.coppersummer[.]xyz Install tracker
connect.creatorcreator[.]xyz Install tracker
connect.dresstent[.]xyz Install tracker
connect.dropjeans[.]xyz Install tracker
connect.edgeplayground[.]xyz Install tracker
connect.exchangeclub[.]xyz Install tracker
connect.existencediscussion[.]info Install tracker
connect.expansionsalt[.]info Install tracker
connect.fangstitch[.]xyz Install tracker
connect.fogparcel[.]info Install tracker
connect.foodhook[.]info Install tracker
connect.forkcountry[.]xyz Install tracker
connect.geesepurpose[.]xyz Install tracker
connect.giantsdogs[.]info Install tracker
connect.giraffetoothpaste[.]xyz Install tracker
connect.guitarrobin[.]xyz Install tracker
connect.halllunch[.]info Install tracker
connect.harborclam[.]xyz Install tracker
connect.holecompany[.]info Install tracker
connect.knifesea[.]icu Install tracker
connect.monthsmoke[.]info Install tracker
connect.nosegovernor[.]xyz Install tracker
connect.pagesubstance[.]xyz Install tracker
connect.poisonblade[.]xyz Install tracker
connect.prosesalt[.]xyz Install tracker
connect.purposethings[.]info Install tracker
connect.quiltgirls[.]xyz Install tracker
connect.reactionbit[.]info Install tracker
connect.rewardrun[.]xyz Install tracker
connect.riceapparel[.]xyz Install tracker
connect.seashoreletters[.]info Install tracker
connect.selectiondogs[.]xyz Install tracker
connect.shapeboot[.]info Install tracker
connect.shoptax[.]xyz Install tracker
connect.stopfinger[.]info Install tracker
connect.structurekiss[.]xyz Install tracker
connect.tanksuggestion[.]xyz Install tracker
connect.thingbrass[.]xyz Install tracker
connect.thoughtslave[.]xyz Install tracker
connect.threadfuel[.]xyz Install tracker
connect.trailcontrol[.]xyz Install tracker
connect.trickbushes[.]info Install tracker
connect.vacationthought[.]xyz Install tracker
connect.viewschool[.]xyz Install tracker
connect.voyagelaugh[.]xyz Install tracker
connect.woolreward[.]xyz Install tracker
connect.yearicicle[.]xyz Install tracker
connect.zebratransport[.]xyz Install tracker
controlprice[.]xyz Gate/landing
coughcoal[.]icu Gate/landing
countrypipe[.]space Gate/landing
cowsfoot[.]xyz Gate/landing
crackfood[.]space Gate/landing
creamfurniture[.]space Gate/landing
creditchickens[.]xyz Gate/landing
crediteducation[.]cfd Gate/landing
crimestreet[.]xyz Gate/landing
crimesupport[.]cfd Gate/landing
curvebite[.]xyz Gate/landing
deathrock[.]xyz Gate/landing
deathshop[.]xyz Gate/landing
decisionreaction[.]xyz Gate/landing
dinosaursjam[.]cfd Gate/landing
distancebedroom[.]xyz Gate/landing
distributiontheory[.]cfd Gate/landing
dolldebt[.]xyz Gate/landing
doorsoap[.]cfd Gate/landing
dustprotest[.]icu Gate/landing
expansionsalt[.]info Gate/landing
fallbeginner[.]xyz Gate/landing
fangbear[.]xyz Gate/landing
filescenter[.]cloud Gate/landing
filesilo[.]cloud Gate/landing
fingerbasketball[.]xyz Gate/landing
flavorwood[.]xyz Gate/landing
fleshfrog[.]xyz Gate/landing
fleshplants[.]xyz Gate/landing
fleshproduce[.]xyz Gate/landing
foodrock[.]space Gate/landing
forkmice[.]xyz Gate/landing
friendjewel[.]cfd Gate/landing
geeseairport[.]xyz Gate/landing
girlsgrain[.]xyz Gate/landing
glassmove[.]xyz Gate/landing
goldsteel[.]cfd Gate/landing
governmentyard[.]cfd Gate/landing
grandfatherquiver[.]xyz Gate/landing
gripcollar[.]xyz Gate/landing
gripsleep[.]xyz Gate/landing
gunbear[.]xyz Gate/landing
hairreward[.]xyz Gate/landing
hatescale[.]info Gate/landing
healthiron[.]space Gate/landing
holemuscle[.]xyz Gate/landing
homecub[.]cfd Gate/landing
homefireman[.]xyz Gate/landing
honeyfear[.]xyz Gate/landing
ilesilo[.]cloud Gate/landing
instrumentvolcano[.]space Gate/landing
kittenschalk[.]xyz Gate/landing
kittensgrade[.]cfd Gate/landing
kittensrobin[.]info Gate/landing
landerror[.]xyz Gate/landing
lesilo[.]cloud Gate/landing
liptendency[.]info Gate/landing
liquidtoes[.]xyz Gate/landing
liquidwrench[.]cfd Gate/landing
lockettrail[.]xyz Gate/landing
lumberbaseball[.]xyz Gate/landing
memorycompany[.]xyz Gate/landing
micesisters[.]xyz Gate/landing
milkname[.]xyz Gate/landing
minuteblade[.]xyz Gate/landing
mountainsurprise[.]cfd Gate/landing
mouthfruit[.]cfd Gate/landing
noiseship[.]cfd Gate/landing
northbox[.]xyz Gate/landing
partpipe[.]xyz Gate/landing
partyfriends[.]cfd Gate/landing
passengerbrake[.]space Gate/landing
peacejewel[.]xyz Gate/landing
peacetongue[.]xyz Gate/landing
petminister[.]xyz Gate/landing
pictureporter[.]cfd Gate/landing
pieplant[.]space Gate/landing
pizzasthread[.]xyz Gate/landing
pleasurewaves[.]info Gate/landing
popcornregret[.]xyz Gate/landing
porterdebt[.]xyz Gate/landing
powerbushes[.]xyz Gate/landing
profitfact[.]xyz Gate/landing
prosetoothbrush[.]xyz Gate/landing
quincepage[.]xyz Gate/landing
raintexture[.]xyz Gate/landing
rakepurpose[.]xyz Gate/landing
raterake[.]cfd Gate/landing
readingscience[.]xyz Gate/landing
reasonachiever[.]xyz Gate/landing
recessgiraffe[.]xyz Gate/landing
recordhistory[.]xyz Gate/landing
regretsquirrel[.]xyz Gate/landing
restbucket[.]xyz Gate/landing
ricestar[.]xyz Gate/landing
rifledog[.]xyz Gate/landing
ringsparcel[.]xyz Gate/landing
roadyear[.]xyz Gate/landing
rockcredit[.]space Gate/landing
rollglass[.]xyz Gate/landing
roofbattle[.]xyz Gate/landing
roofreaction[.]xyz Gate/landing
rosegrip[.]xyz Gate/landing
routeletters[.]xyz Gate/landing
runhouses[.]xyz Gate/landing
scarecrowcare[.]xyz Gate/landing
scentrod[.]info Gate/landing
screwbirth[.]xyz Gate/landing
seatlace[.]space Gate/landing
seaword[.]xyz Gate/landing
servantadvice[.]xyz Gate/landing
shiptank[.]cfd Gate/landing
shirtexample[.]xyz Gate/landing
shoesearthquake[.]xyz Gate/landing
sinkwash[.]space Gate/landing
skirtloss[.]xyz Gate/landing
slipvegetable[.]xyz Gate/landing
smokecar[.]space Gate/landing
songtheory[.]xyz Gate/landing
spadeleg[.]xyz Gate/landing
sparkrice[.]space Gate/landing
sparkrub[.]xyz Gate/landing
spoonducks[.]cfd Gate/landing
springdogs[.]xyz Gate/landing
spybaseball[.]space Gate/landing
startmonkey[.]cfd Gate/landing
statementservant[.]xyz Gate/landing
statementtouch[.]xyz Gate/landing
steamhouses[.]cfd Gate/landing
stopzinc[.]xyz Gate/landing
structurelinen[.]xyz Gate/landing
suggestioncemetery[.]xyz Gate/landing
suitsoap[.]xyz Gate/landing
suitstraw[.]info Gate/landing
swimrest[.]xyz Gate/landing
tablechess[.]info Gate/landing
tailsilk[.]xyz Gate/landing
territorycaption[.]xyz Gate/landing
texturebadge[.]xyz Gate/landing
thrillducks[.]xyz Gate/landing
throneback[.]xyz Gate/landing
tinsofa[.]xyz Gate/landing
toespiders[.]xyz Gate/landing
toothpastesense[.]xyz Gate/landing
toothpastesun[.]xyz Gate/landing
townquiver[.]xyz Gate/landing
trampdonkey[.]icu Gate/landing
treesboard[.]xyz Gate/landing
truckpig[.]cfd Gate/landing
truckshat[.]xyz Gate/landing
turnclass[.]xyz Gate/landing
umbrellavessel[.]xyz Gate/landing
vacationengine[.]xyz Gate/landing
vesselsystem[.]xyz Gate/landing
vestthings[.]cfd Gate/landing
volcanopin[.]xyz Gate/landing
voyagemist[.]space Gate/landing
wastereading[.]xyz Gate/landing
wasteturkey[.]xyz Gate/landing
wastewine[.]xyz Gate/landing
wavepan[.]xyz Gate/landing
whistlebook[.]cfd Gate/landing
whistlesong[.]xyz Gate/landing
wormspark[.]xyz Gate/landing
woundsecretary[.]xyz Gate/landing
wrenobservation[.]xyz Gate/landing
yamsmell[.]xyz Gate/landing
yardvalue[.]cfd Gate/landing
zephyrhall[.]cfd Gate/landing

Appendix B: YouTube Channels Linked to CL-CRI-1171 Activity

(Channels were taken down after we notified Google.)

Persona Channel
Velvox @VelvoxYT
Venrx @Venrx
Ravex @RAVEX-wu1pg
Adex @adex915
Ripex @ripex
HASNZ TWEAKS @hasnzyt
Ontrendytt @OnTrendd
Trend Rise @trendrise
Reknotic Lab @Reknotic
NowFixTutorials @NowFixTutorials
f4fix @f4fix

Attackers Expose Ongoing AI Tool Use Targeting Organizations in Latin America

Posted on by Sheida Azimi

Executive Summary

We have analyzed two ongoing, multi-stage network intrusion and data-exfiltration campaigns targeting organizations in Latin America. Corroborating recent findings from the broader threat intelligence community, we observed attackers leveraging artificial intelligence (AI) to enhance their capabilities.

Our investigation categorizes this activity as follows:

  • Mexican transportation campaign: This campaign impacted a transportation organization, alongside federal government ministries and municipal water utilities in Mexico and Ecuador. Operators relied on living-off-the-land (LotL) techniques. They executed iterative batch scripts to manipulate and exfiltrate sensitive data, and self-hosted NextChat instances on operational infrastructure. We track the activity in this cluster as CL-CRI-1131.
  • Brazilian financial campaign: Attackers targeted the Brazilian financial sector. We observed an expansion of previously reported targeting of vulnerable web servers in a job-themed phishing campaign. The attackers employed custom remote access Trojans (RATs) and tunneling tools, including a Go-based SOCKS5 proxy with iterative filenames that suggest AI-enablement. We track the activity in this cluster as CL-CRI-1163.

We track them as two separate activity clusters with distinct geographic focuses. However, the technical and behavioral overlaps between CL-CRI-1131 and CL-CRI-1163 highlight shifting trends in Latin American targeting and threat actor tooling.

Both clusters have overlapping SOCKS5 relay infrastructure and they both rely on AI to orchestrate operations via commercial large language models (LLMs). This signals a broader evolution in the regional threat landscape. Rather than isolated incidents, these clusters demonstrate how diverse threat groups in Latin America are independently adopting advanced proxy networks and AI integration to streamline their execution.

Palo Alto Networks customers are better protected from the threats discussed here through the following products and services:

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Related Unit 42 Topics AI, LLM, Phishing, RATs

CL-CRI-1131: Mexican Transportation Campaign

During an April 2026 compromise, the attacker’s host-based operations reflected the trial and error of LLM usage. Infrastructure associated with the campaign persisted into June 2026 and exposed targeting profiles of the attacker.

Initial Host-Based Footprint: Execution Challenges

During an intrusion as part of CL-CRI-1131 activity in April 2026, we observed the attacker struggling to gather sensitive data. After repeated attempts to dump the Security Account Manager (SAM) registry hive and the domain controller NTDS.dit file, the attacker created shadow copies across multiple drives before copying files, as shown in Figure 1.

A screenshot of a command-line interface showing commands for creating shadow copies on Windows drives C: and F: using "vssadmin create shadow" and executing a script located in the Windows Temp folder.
Figure 1. Volume shadow copy manipulation.

This occurred while the attacker used a series of numbered batch scripts to collect sensitive data from the compromised host, as shown in Figure 2.

A screenshot of a Windows command prompt window displaying a series of command lines. The commands include executing PowerShell scripts and handling text files.
Figure 2. Commands used for a series of batch scripts to collect sensitive data.

The attackers inserted a permissions check to ensure successful file writing to the collection directory. These trial-and-error actions and successive script fixes are consistent with LLM usage.

After struggling to collect these files, we observed attackers troubleshooting connectivity with infrastructure at 62.171.185[.]97.

Infrastructure Analysis: Tracing Exfiltration Commands to Exposed Certificates

Pivoting on 62.171.185[.]97, the IP address used in CL-CRI-1131 activity for data exfiltration, we discovered an active Let's Encrypt TLS certificate using the domain m-doxa-apodo.duckdns[.]org and following a unique dynamic DNS naming standard.

Shared Infrastructure: What the SSL Certificates Revealed

Searching for the m-doxa prefix revealed that attackers established the infrastructure for the campaign in February 2026 using a single, consolidated multi-Subject Alternative Name (SAN) certificate. This single certificate reveals five active subdomains. These subdomain names indicate their operational functions and intended Mexican federal government targets, as Table 1 shows.

Subdomain Interpretation
m-doxa-apodo.duckdns[.]org apodo = alias/nickname (Spanish)
m-doxa-geo.duckdns[.]org geo for geolocation
m-doxa-intel.duckdns[.]org intel for intelligence
m-doxa-vacunas.duckdns[.]org vacunas = vaccines (Spanish)

Table 1. Subdomains and their likely operational capabilities and targets.

In February 2026, following the initial window of activity reported by CloudSEK, attackers deployed a single-SAN certificate during this campaign. The certificate was configured to secure only one specific domain: m-doxa-apodo. However, as the operation evolved, so did the infrastructure.

By April 2026, and again in June 2026, attackers rotated their infrastructure and generated new multi-SAN certificates.

Table 2 shows, by date, the certificates and hosts used for CL-CRI-1131 activity, demonstrating a timeline for the associated infrastructure.

Date Certificate SHA-256 Hash SANs Host
Feb. 27, 2026 7d766942ef34542cee39c852286599958c4c2e23187010c4d38dbf88fcb40bf8 1 165.22.184[.]26
April 20, 2026 4e218e70afdbb116209ec0ebe8fc556e296e69648aa4e0425b83c0e863a8fee5 5 178.128.87[.]160
June 19, 2026 46ac289ce0c13666de616446f5d5a68da8bd150f4f065c3bec02f63776d3899c 5 178.128.87[.]160

Table 2. Certificate procurement timeline.

AI Integration: Discovering the Backend Troubleshooting Interface

In a previous report by Gambit, The AI-Assisted Breach of Mexico’s Government Infrastructure [PDF], the February 2026 activity was notable for using multiple LLMs. The report by CloudSEK linked above detailing activity from June 2026 tracks the activity we call CL-CRI-1131 as Operation Escaneo.

These reports describe attackers using multiple LLMs, including Claude and GPT-4.1 to troubleshoot issues faced by the attackers across their campaigns. We discuss the attackers using NextChat as part of their broader LLM process.

The IP address 178.128.87[.]160 was used in CL-CRI-1131 activity during the associated April and June 2026 compromises. This address hosted an instance of the open-source tool NextChat on TCP port 3000. Figure 3 shows an example of the associated NextChat user interface, as it would look from a web browser window.

A screenshot of a NextChat interface with a light blue sidebar that displays "New Conversation" and the date and time. The main area shows a white text box with the message "Hello! How can I assist you today?" A row of icons for sending and formatting messages is below the text box.
Figure 3. Example of a locally hosted NextChat window.

NextChat is an open-source web interface where users can load and interact with multiple models. NextChat allows operators to compare across models and ensure prompts are hosted on attacker-controlled infrastructure.

Beyond revealing new targets, tracking this infrastructure provided a critical window into the activity cluster's backend operations. Given the initial failures to extract data from the host combined with the NextChat interface on this backend, we assess that the attackers relied on LLMs to generate the required workaround scripts.

Integrating AI into the operational infrastructure is not unique to this incident. We observe an identical technical setup when pivoting to a secondary campaign targeting the Brazilian financial sector.

CL-CRI-1163: Brazilian Financial Service Campaign

Unlike the Mexican transportation campaign, the Brazilian financial campaign we track as CL-CRI-1163 involved homebrewed malware. We observed that the attackers behind CL-CRI-1163 likely gained initial access through a job-themed phishing compromise.

Despite trading built-in Windows utilities for custom-built implants, the underlying operational shift remains consistent in both campaigns. Exposed staging infrastructure revealed operational scripts with filenames that suggest an LLM dynamically generated them rather than a human developer.

The apparent presence of this AI setup, deployed alongside advanced proxy networks, reinforces the conclusion of a broader regional trend. Even for attackers capable of deploying custom malware, an AI-driven backend serves as a force multiplier to populate directories with exploit scripts, streamline execution and lower the barrier to entry for managing complex post-exploitation workflows.

Initial Access and Execution: Phishing and Automated Actions on Objectives

In February 2026, we observed that attackers associated with CL-CRI-1163 achieved initial access through a resume-themed phishing email attachment.

After attackers dropped multiple RATs, we observed a similar iterative naming structure, likely due to the attackers' failure to install their tool set. We observed attempts to install versions 1–8 of a Go-based reverse SOCKS5 tunneling tool named SockTz from a compromised WordPress site.

Figure 4 shows the attempt to execute version 8, named socktz_v8.exe.

A screenshot of a command prompt text shows a command to use 'certutil' to download and execute a file from a URL, followed by running it from the user's directory and displaying "DONE".
Figure 4. Attempt to retrieve SockTz version 8 from a compromised WordPress site.

Likely due to failure to install the SockTz malware and open a successful proxy connection, attackers behind CL-CRI-1163 pivoted to attacker-controlled infrastructure to retrieve version 9, named socktz_v9, as Figure 5 shows.

A screenshot of a command line interface displays a command executing `cartutil` with parameters to split a file and download SockTz version from a specific IP address to a user's directory.
Figure 5. Pivot to attacker-controlled infrastructure to retrieve SockTz version.

Infrastructure Inspection: Analyzing AI-Generated Naming Conventions in the Open Directory

Researchers previously identified this SockTz proxy tool and 167.148.195[.]53 tied to persistent targeting of vulnerable JBoss servers. Where previous reports identified different versions of this tool across campaigns, we observed installation attempts of versions 1–9 in a two-hour window.

SockTz installers were hosted along with hundreds of campaign scripts on an open directory at 167.148.195[.]53. Similar to the SockTz version numbers and the CL-CRI-1131 operations, the open directory associated with this CL-CRI-1163 activity exposed iterative scripts with appended identifier _output, indicating the attackers employed LLMs throughout the campaign. A partial list of the files is shown in Figure 6.

A screenshot of a list of file names displayed in blue text, each preceded by a bullet point. The files include scripts with ".sh" extensions such. There are also text files with ".txt" extensions, named sequentially.
Figure 6. Partial list of the campaign scripts hosted on an open directory at 167.148.195[.]53.
In addition to exposing scripts across multiple phases of the attack chain, attackers appended exploit filenames with descriptive adjectives. This suggests that the attackers employed iterative, language model-driven development: exploit_creative.py, exploit_careful.py and rce_focused.py.

The threat actors behind the CL-CRI-1131 and CL-CRI-1163 campaigns have enhanced their technical capabilities by incorporating commercial LLMs into their workflows. This integration enables them to author advanced proxy configurations and dynamically address complex execution failures. However, the infrastructure they deployed to leverage this AI became their Achilles' heel.

Exposing an open NextChat directory to the public internet reveals a fundamental lack of operational maturity. The AI provided the necessary tactical workaround to extract the Active Directory database, but the human operators failed to secure the staging server. This left their entire playbook, prompt history and staging scripts visible to threat researchers.

This highlights a critical vulnerability for defenders to exploit. As less skilled and experienced actors adopt AI to accelerate their attacks, their foundational operational security (OpSec) failures remain the most reliable way to track and dismantle their operations.

Conclusion

The CL-CRI-1131 and CL-CRI-1163 operations orchestrated in the Mexican transportation and Brazilian financial sector campaigns highlight a notable evolution in the regional threat landscape. Through these campaigns, we observe attackers leveraging AI to enhance their capabilities.

Whether manipulating built-in Windows utilities or deploying custom-built proxy networks, these operators rely on commercial LLMs to overcome tactical hurdles and streamline their execution. However, this rapid technical acceleration is offset by fundamental operational security failures. Exposed staging directories, unsecured NextChat interfaces and structured multi-SAN certificates provide defenders with a clear roadmap of the attacker's infrastructure.

By pivoting on these OpSec oversights, defenders can proactively track the activity and disrupt the attackers' campaigns.

Palo Alto Networks customers are better protected from the threats discussed above through the following products:

  • The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research
  • Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious.
  • Cortex XDR and XSIAM are designed to help prevent the threats described in this article, by employing the Malware Prevention Engine. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection and the Local Analysis module, intended to prevent both known and unknown malware from causing harm to endpoints.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
  • UK: +44.20.3743.3660
  • Europe and Middle East: +31.20.299.3130
  • Asia: +65.6983.8730
  • Japan: +81.50.1790.0200
  • Australia: +61.2.4062.7950
  • India: 000 800 050 45107
  • South Korea: +82.080.467.8774

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Indicators of Compromise

Mexican Transportation Campaign

Domains:

  • m-doxa-apodo.duckdns[.]org
  • m-doxa-geo.duckdns[.]org
  • m-doxa-intel.duckdns[.]org
  • m-doxa-repuve.duckdns[.]org
  • m-doxa-sre.duckdns[.]org
  • m-doxa-vacunas.duckdns[.]org

Certificate SHA-256 Hashes for Fingerprints and Corresponding Hosts:

  • 46ac289ce0c13666de616446f5d5a68da8bd150f4f065c3bec02f63776d3899c
    • 178.128.87[.]160
  • 4e218e70afdbb116209ec0ebe8fc556e296e69648aa4e0425b83c0e863a8fee5
    • 178.128.87[.]160
  • 7d766942ef34542cee39c852286599958c4c2e23187010c4d38dbf88fcb40bf8
    • 165.22.184[.]26

Brazilian Financial Campaign

SHA-256 hashes:

  • a38b2cf8beff32a276eed8783723ecf8cc53d7dc88669e1b998dddc4db6fe996
  • 87bf8bc8b4a2cf34f0af1afe161f123a3d200e77f6c6f41b81bf6ae66ee172ec

URL:

  • hxxp[:]//167.148.195[.]53:8888/socktz_v9.exe

Additional Resources

An AI-Assisted Cyber Attack: Inside a Unit 42 Investigation

Posted on by Ria Bhatia

Unit 42 responded to an incident where a human attacker used frontier AI to breach an enterprise network autonomously as part of a ransom attack. The agents breached the company's security layers in a methodical manner, each targeting a different layer of defense to achieve a shared goal. The impact was at the scale of a coordinated effort from multiple red teams, which would normally take human operators around two weeks.

The threat actor told us in negotiations that they leveraged frontier AI models and attack-specific agentic AI frameworks. By shifting execution to an automated loop, the attacker compressed weeks of methodical intrusion tradecraft (using more than 50 MITRE ATT&CK techniques) into less than 10 hours.

After they gained initial access, the attacker used agents to map the internal architecture, raid source repositories and seize root credentials. The agents also triggered unauthorized continuous integration/continuous delivery (CI/CD) builds and claimed master keys to the victim's cloud AI infrastructure.

What made the attack stand out was AI-assisted operational efficiency, without the need for a novel zero-day or super elite tradecraft. The attacker left tactical execution to AI agents that monitored, evaluated, acted and re-planned in real time, increasing speed throughout the attack chain.

The attacker also directed the agent to leave behind a “report” on the organization’s security posture: an 80-page, technical audit detailing dozens of exploited findings.

Inside the Machine-Speed Attack Chain

The adversary ran their operation using current AI-enabled software development processes. We observed multiple indicators consistent with AI usage:

  • LLM calls to multiple frontier AI agents in parallel
  • Structured Markdown files passing information between agents and sessions
  • Custom scripts (assessed with high confidence to be AI-generated due to UI elements) managing dynamic operations

The 10-hour operational timeline included the following:

  • Infiltration and mapping: The actor breached a publicly accessible web service to tunnel into the network, deploying an automated recon agent to map internal microservices.
  • Secrets harvesting: Sub-agents combed enterprise code repositories, extracting hard-coded tokens and service passwords.
  • Privilege takeover: Using exposed tokens, the actor infiltrated the secrets management system, harvesting master administrative credentials to seize control of root system access.
  • Pipeline exploitation: The actor hijacked an enterprise code application via custom workflows to exfiltrate cloud access keys. They attempted to plant backdoors in Terraform configurations, but hard branch-protection controls stopped this.
  • AI infrastructure hijacking: Using stolen cloud keys, the actor turned the victim’s AI endpoints into post-compromise infrastructure — using the company’s compute power to perpetrate future moves.

Figure 1 maps the AI-orchestrated workflow.

Figure 1. AI-orchestrated intrusion workflow. The actor sets objectives and makes consequential decisions. Specialized agents execute, share results and adapt in real time.

Unified Threat Framework Mapping

For illustration, Table 1 below maps some of the techniques used against the MITRE ATT&CK and ATLAS frameworks:

Intrusion Stage Threat Actor Action MITRE ATT&CK® Mapping MITRE ATLAS™ (AI-Specific) Mapping
Initial Access and Recon Publicly accessible web service breach; automated service mapping via service discovery tool T1190: Exploit Public-Facing Application

T1046: Network Service Discovery

 AML.T0000: Initial Access

AML.T0002: AI-Automated Reconnaissance
Credential Access Code scraping for secrets across code repos T1552.001: Credentials In Files AML.T0014: Credentials Harvesting
Privilege Escalation Infiltrating secrets manager to harvest admin system secrets T1555: Credentials from Password Stores AML.T0016: Privilege Escalation via Automated Pivot
Pipeline Abuse Executing CI/CD actions; attempting cloud provisioning tool edits T1578: Modify Cloud Compute Infrastructure AML.T0010: ML/DevOps Pipeline Interception
AI Infrastructure Abuse Invoking cloud AI models via stolen keys T1078: Valid Accounts AML.T0043: LLM Invocations via Stolen API Keys

Table 1. Major MITRE ATT&CK and MITRE ATLAS techniques used by the attacker.

Key Lessons: Addressing Agentic Attacks

This incident exposes how an attacker who understands how to deploy frontier AI agents effectively can dramatically speed up the pace of their attack. We assess that attackers will increasingly add AI agents to their tool sets. Organizations should take note of the following to address agentic attacks:

  • AI agents reduce the time between steps in the attack flow: AI agents in this attack were designed to parse raw tool output and quickly take next steps, speeding up the overall attack flow.
  • AI agents leave recognizable indicators: Defenders can identify agentic attacks by watching for indicators such as the use of structured Markdown, Python caches and paired asset folders.
  • Attackers can use AI to establish redundant persistence across the environment: In this incident, the attacker used AI agents to efficiently establish overlapping persistence across SSH keys, serverless functions, container restart policies, cloud identities and CI/CD pipelines. Using AI agents can make it easier for an attacker to maintain and test this entire portfolio in parallel.
  • Attackers can use an organization’s AI tools as post-compromise infrastructure: Attackers can hijack enterprise AI services to assist in their attacks. This allows threat actors to hide orchestration traffic among expected traffic, and offload the financial cost onto the victim.

Defending Against Machine-Speed Attacks

Defending against automated agent loops requires matching the speed and adaptability of AI-driven attacks:

  • Execute synchronized containment: Deploy automated playbooks that simultaneously revoke credentials, terminate OAuth sessions, freeze CI/CD pipelines and isolate cloud accounts across all operational planes.
  • Govern AI as core infrastructure: Inventory every model endpoint, API key, Model Context Protocol (MCP) gateway and AI tool integration. Apply strict rate limits, least-privilege policies and diagnostic logging.
  • Detect behavioral loops: Hunt for operational loops including bursty API requests, rapid 401/200 HTTP state shifts, parallel authentications and sudden model usage from unexpected identities.
  • Lock down DevOps pipelines: Enforce mandatory, multi-party code reviews and immutable branch protection on all infrastructure-as-code repos to block automated backdoor injection.

Learn more about how Unit 42 can help defend against AI-driven threats through Unit 42 Frontier AI Defense.

Updated Sept. 3, 2026, at 5:25 a.m. PT to clarify that the attack was an intrusion, and not a ransomware attack. 

Updated Sept. 4, 2026, at 6:42 a.m. PT for minor clarifying copyedits. 

Spring Ring: An Inside Look at Voice Phishing Campaigns in Microsoft Teams

Posted on by Sheida Azimi

Executive Summary

Between January and April 2026, we uncovered a coordinated social engineering operation that leveraged external Microsoft Teams accounts to masquerade as IT help desk personnel. Our telemetry reveals that this operation targeted more than 150 employees across at least 10 companies in various industries. We call this activity Spring Ring.

What seems like a benign chat is in fact a voice phishing (vishing) call, during which adversaries try to coerce victims into executing remote monitoring and management (RMM) tools or custom malware. In a more advanced variant, attackers transitioned from a vishing call to a full-blown Microsoft NT LAN Manager (NTLM) relay attack aimed at an organization's domain controller (DC).

We provide a technical breakdown of this operation’s attack lifecycle across two observed campaigns, both illustrating vishing manipulation that resulted in the attempted payload delivery via two distinct attack vectors.

These two campaigns demonstrate the weaponization of communication platforms as identity becomes a primary attack vector.

Palo Alto Networks customers are better protected from the threats described here through the following products and services:

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Related Unit 42 Topics Phishing, Identity, Social Engineering

Overview: The Trust Gap

Spring Ring’s activity mirrors a broader trend in the threat landscape toward social engineering campaigns. According to our recently published Insights blog, threat actors have increasingly moved away from traditional phishing techniques toward trusted collaboration tools.

In the first four months of 2026, phishing alerts from collaboration tools represented 42% of all phishing alerts in Cortex, up from 30% of all phishing alerts in the preceding four months. In addition, according to KnowBe4’s Phishing Threat Trends Report, Teams-based attacks rose by 41% [PDF] between October 2025 and March 2026. They note that this surge is driven by attackers exploiting the platform's default “Chat with Anyone” feature to initiate direct chats with users outside their organization.

Previous Teams-based attacks, such as those by Cloaked Ursa (aka APT29), focused on credential harvesting and group chat-based social engineering. They often relied on malicious links or fake Entra ID tenants to appear legitimate.

Spring Ring’s approach relies on active human voice interaction. In this way, attackers can evade detection without a software exploit. Instead, they rely on exploiting the trust that employees place in software as a service (SaaS) collaboration platforms.

SaaS Applications: The New High-Value Target

SaaS applications are essential for business operations, storing an organization’s most critical and sensitive data. Unlike email, where users are trained to look for external sender banners or suspicious links, communications platforms provide a closed loop that attackers exploit by:

  • Leveraging platform trust: People are more likely to engage with a message from a help desk identity than a random email from an external domain
  • Exploiting human interaction: A professional voice on an audio call creates a level of trust that is difficult to manufacture in text, making the victim more susceptible to manipulation
  • Bypassing the monitoring gap: Voice calls are often less monitored, recorded or documented than employees’ digital file operations or email histories, providing attackers with a secluded environment to execute their lures

The Evolution of Collaboration Attacks

The Spring Ring operation represents an evolution from previous campaigns by merging vishing into the Teams workflow. This shift moves the attack from a passive click-and-harvest model to a real-time engagement.

Attackers can then pivot based on the victim's responses. Once the trust gap is crossed, the path to domain-level privileges via open-source tools like PetitPotam is short.

Figure 1 shows an example of the warning that Teams users get when an external identity creates a chat with them.

A screenshot of Microsoft Team's notification about being added to a group chat. A warning message indicates the person is from outside the organization, advising caution against sharing account information. Options to "Delete" or "Accept" are available.
Figure 1. External chat created, Delete/Accept screen.

Anatomy of Spring Ring: How Attackers Masquerade as Internal Support

The Spring Ring campaigns are a coordinated operation that relies on impersonating corporate IT structures. Attackers can drop their lures into a victim's primary communication channel using external Microsoft Teams accounts.

The Discovery: Spotting the Pattern

Our investigation into this activity began after the release of a new detection suite for Microsoft Teams. By monitoring these alerts, we identified a suspicious pattern of chat creation across multiple tenants. Further investigation into these alerts led to the initial discovery of 26 distinct identities approaching targets across different organizations.

The Initial Hook: Crafted Personas and Domains

The attack begins with creating a Microsoft Teams chat using identities designed to mirror legitimate internal support units. The attackers opt for professional, urgency-focused display names such as help desk, IT assistance or support staff.

To strengthen the impression of legitimacy, the attackers operate from external .onmicrosoft[.]com tenants. These are meant to resemble legitimate corporate infrastructure. They are used by attackers to provision Microsoft 365 tenants. The subdomains are controlled by the adversaries.

Threat actors frequently abuse or subvert legitimate products for malicious purposes. This does not indicate that the product itself is flawed or compromised. Unit 42 has no evidence of any compromise or vulnerability within Microsoft's product related to this campaign.

Here are examples of these subdomains:

  • ithelp@InternalSystemsDaily[.]onmicrosoft[.]com
  • HelpDesk@ITProtectionDepartment[.]onmicrosoft[.]com
  • itadmin@MandatoryNetworkMonitoring[.]onmicrosoft[.]com
  • Internal@InternalUSAHelpDeskIT[.]onmicrosoft[.]com
  • ithelpdesk@CertifiedUpdateNetwork[.]onmicrosoft[.]com

In some instances, the actors went beyond generic role names and used specific names to increase the perceived authenticity of the technician on the other end of the line:

  • patrick[..]@infrastructureopsdesk.onmicrosoft[.]com
  • robert[..]@systemdeploymentcenter.onmicrosoft[.]com
  • clara[..]@systemsupportoperations.onmicrosoft[.]com

Names have been partially redacted because the attackers used specific names of legitimate industry personnel. The use of these names does not indicate a compromise of their accounts.

After the chat is created, the attacker initiates a voice call (the vishing element) to coerce the victim. After establishing a connection with what the victim believes is their own IT department, the attacker guides targeted employees through the steps to grant them remote control or execute malicious payloads.

The Scale of Spring Ring

Our telemetry reveals that these attackers often make several attempts — including leaving voicemails — before establishing a connection. We observed the attackers engaging victims in calls that varied in duration:

  • Many calls last only a few seconds or they are missed by the victim as the attacker cycles through targets
  • Successful calls often last between 10 and 15 minutes

Figure 2 shows several vishing attempts made by the same attacker identity on six different targets, with different conversation durations.

A screenshot of a table showing attacker call logs. Columns include Attacker Identity, Display Name, IP, and Call Duration. All Attacker Identities and Display Names are the same, with an IP address from Mullvad. Call Duration includes completed calls, missed calls, and voicemail, with times listed in hours, minutes, and seconds.
Figure 2. Examples of an attacker initiating calls with different targets, and different time durations.

The reach of these campaigns is significant:

  • More than 10 tenants were attacked: We observed the campaigns targeting many organizations across different industries
  • More than 150 targets were approached: The attackers contacted more than 150 individual employees
  • Persistent activity: We tracked the campaigns since January 2026 over a period of several weeks. According to our telemetry, these campaigns were active up until April 2026.

Technical Deep Dive: The RMM and Custom Dropper Combination

Once the attacker establishes trust through the initial vishing call, the Spring Ring campaigns transitioned into a technical execution phase designed to gain a permanent foothold. We provide a detailed analysis of two campaigns (Campaign A and Campaign B) that both began with a Microsoft Teams lure. They then diverged in their payload delivery, tool complexity and post-compromise activities.

Figure 3 shows the full attack flow of the two campaigns' attack methods.

a diagram illustrating Spring Ring attack flow, starting with creating a chat lure in Microsoft Teams. Two campaigns are shown: Campaign A leads to convincing the target to download RMM tools, then downloading obfuscated PowerShell-based malware. Campaign B involves convincing the target to download malware from a cloud endpoint, leading to persistence and environment enumeration, followed by attempted lateral movement using PetitPotam.
Figure 3. Full attack flow of the two Spring Ring campaigns.

Campaign A: From Support Tools to Obfuscated Payloads

In Campaign A, the attacker used a bring-your-own-tool approach, luring the victim to execute legitimate RMM software. The attacker posing as a technician walked the employee through launching built-in Windows tools like Quick Assist or downloading third-party RMM software. Once the RMM tool ran, the attacker could request remote control of the victim’s machine.

After gaining remote control, the attacker performed a series of basic enumeration commands to gain information on the host and domain. We observed them executing:

After confirming the environment's value, the attacker pivots to payload delivery. The attacker used a PowerShell command line to download an obfuscated PowerShell-based remote access Trojan (RAT) from the attacker-controlled domain, san-sid[.]com. This malware used variable manipulations and arithmetic obfuscation designed to evade automated security analysis and sandbox detection.

By leveraging advanced AI and pattern-matching algorithms, we were able to de-obfuscate the RAT. We started by stripping away anti-analysis bloat from the code that was used to cause a time-out for deobfuscation tools.

The actual payload is a tiny, nine-line command and control (C2) stager. The script disables Antimalware Scan Interface (AMSI) via the amsiInitFailed flag and executes a test scan to verify the bypass. Upon verification, the script encrypts host data and beacons out to san-sid[.]com to download and execute further payloads.

Figure 4 shows a snippet of the obfuscated PowerShell-based RAT.

A screenshot of the obfuscated PowerShell-based RAT code snippet with various programming elements such as loops, conditional statements, and arithmetic operations. The code includes variable names, mathematical calculations, and logical operators.
Figure 4. A snippet from the obfuscated PowerShell-based RAT.

This campaign was blocked by automated Cortex XDR Agent protections during the malware's execution phase.

Campaign B: The Tailored Cloud Execution Chain

The second campaign used a more customized delivery method. During the vishing call, the attacker directed the victim to a cloud endpoint. The attackers tailored the cloud infrastructure and filenames to match the targeted organization and the specific user, for example:

<company_name>-org-filters-update-<victim_name>.s3.us-west-2.amazonaws[.]com

When the victim clicked a link containing their own company's name and downloaded <company_name>-org-filters-update-<victim_name>[.]exe, it triggered an execution chain:

  1. Staging and persistence: The executable moved itself to the \Temp\ directory and spawned copies (e.g., vhlp-*.exe and scnr-*.exe) as a persistence mechanism
  2. Browser hijacking: The malware launched a hidden, headless instance of Microsoft Edge, and the attackers wrote to the disk and sideloaded an Edge extension
  3. Lateral movement and authentication coercion: The attackers used Python (C:\ProgramData\IntegrityData\python.exe) to initiate a lateral movement sequence:
    1. SMB scanning: Initiated port 445 traffic targeting internal servers
    2. NTLM authentication: Generated NTLM traffic targeting the organization's DC
    3. PetitPotam exploitation: The attacker attempted a PetitPotam attack to coerce the DC into authenticating back to an attacker-controlled machine. This NTLM relay attack was designed to grant the attacker domain-level privileges

After attempting to coerce the DC, the attacker's domain-takeover attempt was blocked by Unit 42 Managed Detection and Response.

Summary of Tactical Divergence

By comparing the two campaign paths, we can better understand the diversity of threats targeting collaboration platforms. Table 1 compares the campaigns' specific methods of attack.

Feature Campaign A Campaign B
Initial Lure Microsoft Teams vishing Microsoft Teams vishing
Primary Delivery RMM tools Tailored hosting infrastructure executables
Stealth Mechanism Obfuscated PowerShell Headless Microsoft Edge and sideloaded extension
Lateral Movement Basic enumeration only PetitPotam NTLM relay

Table 1. Comparing the two campaigns’ methods.

This comparison highlights an important point for defenders. A simple vishing hook can lead to either a standard malware infection, or to a serious domain-level breach if the attacker pivots to payload delivery.

Identifying Teams Impersonation and Identity-Based Anomalies

Recognizing campaigns like Spring Ring requires a strategy of profiling external and internal entity behaviors. The attackers behind these campaigns operate within a legitimate ecosystem, so detection hinges on identifying small anomalies in how external identities interact with your organization.

Profiling the Identity

The first line of defense is recognizing the markers of the external actor. Our research into these campaigns highlights several consistent patterns:

  • Spoofed domain naming: Attackers mostly use external .onmicrosoft[.]com tenants that include keywords like internal, certified, network or infrastructure to project authority
  • Persona mimicry: They use professional display names, like IT help desk or admin, to increase the perceived authenticity of the technician during vishing calls
  • Infrastructure red flag: The source IP addresses for these connections often originate from commercial VPN services to mask the attacker's true location

Behavioral Metrics of the Interaction

Our researchers were able to identify key markers of Spring Ring activity by analyzing the metadata of these interactions, despite the deceptive nature of the attacker’s initial lures:

  • The chat-to-call ratio: A primary indicator is the rapid transition from a 1:1 chat request to an unsolicited audio call
  • Call curation profiling: Attackers cycle through targets quickly. We observed call patterns ranging from 30-second initial attempts to 15-minute sessions.
  • Multiple approaches: These actors demonstrate high operational volume, often approaching 5-6 identities within a matter of minutes using one of their spoofed identities

Recognizing Post-Compromise Behavior

Upon a successful compromise, we observed endpoint activity characterized by:

  • Atypical execution of RMM tools by users who do not require remote support
  • Access to unknown links, including cloud storage URLs or other file hosting servers that victims might be lured to access

Organizations can identify the Spring Ring lifecycle before the attacker transitions from a chat to a domain-level attack, by profiling these signals, the origin of the tenant and the subsequent attack flow.

Figure 5 shows one example of a Cortex alert on a new suspicious conversation created in Microsoft Teams. This alert is based on behavioral and metadata analysis of a newly created chat.

A screenshot of a Cortex alert in an application interface. The alert is titled "An external user started a conversation in Microsoft Teams with a suspicious user or chat name." It shows details like the description of the incident, occurrence count, and affected assets. The description mentions a user creating a Microsoft Teams chat with two users in the organization. Status and assignee fields are visible, but not filled. Other tabs include Overview, Resolution, War Room, and XDR Analytics.
Figure 5. Example of a Cortex alert on the creation of a suspicious chat in Microsoft Teams.

Conclusion

The Spring Ring campaigns demonstrate a strategic pivot in social engineering, where attackers move beyond email phishing to enterprise collaboration tools. Attackers turn an important productivity tool into a conduit for domain-level exploitation, masquerading as internal help desk personnel through vishing calls.

This activity highlights an important shift in the security landscape. Identity is now a primary perimeter, and the platforms we rely on for daily communication are being weaponized.

Looking forward, attackers might further refine their ability to operate within SaaS ecosystems. These platforms are not just an initial access vector, they contain sensitive documentation, workflows and communication logs that could allow an adversary to advance their attack chain.

Our analysis of the Spring Ring operation reinforces several key lessons:

  • Trusted SaaS applications are not inherently safe: Attackers exploit the confidence that employees place in communications platforms
  • Attack vectors are simple and scalable: By using seemingly legitimate external tenants and professional vishing lures, attackers can target hundreds of employees across many industries with minimal friction
  • Adaptability is key: Attackers are evolving their methods, shifting from basic credential harvesting to human-led lateral movement

As these threats evolve, organizations must prioritize user education regarding unsolicited external communication across collaboration platforms. Robust behavioral monitoring can help identify identity-based anomalies before they escalate to lateral movement.

Palo Alto Networks Protection and Mitigation

Palo Alto Networks customers are better protected from the threats discussed above through the following products:

  • Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious.
  • Cortex XDR and XSIAM can help prevent the execution of both known and unknown malware through Behavioral Threat Protection and machine learning powered by the Local Analysis module. Beyond stopping initial execution via malicious droppers, Cortex XDR actively halts post-exploitation activities, such as PetitPotam NTLM relay attacks, before adversaries can achieve lateral movement.
  • Cortex Cloud Identity Threat Detection  can help deliver real-time protection against identity-based threats across cloud providers, IdPs, and SaaS applications. Using advanced behavioral analytics on real-time telemetry, ITDR baselines access patterns to detect anomalies, track complex attack chains—such as the Spring Ring lifecycle and trigger automated responses to contain compromised credentials.
  • The Cortex Advanced Email Security module can help extend the power of the Cortex platform into cloud-hosted email environments, providing a scalable, AI-driven layer for detection, investigation, and response. By automatically stopping email threats and malicious communications across enterprise environments, it provides seamless protection across one of your most vulnerable attack vectors.
  • Idira Threat Detection and Response can help enable security teams to counter identity-based attacks targeting Idira Next Generation Identity (NGI) Platform and the identities it secures. Using near real-time detection, powered by CORA AI, and leveraging Idira’s visibility across multiple contexts (like PAM, authentication, SSO, cloud, endpoints, browsers, and more), Idira ITP can apply automated, tailored non-disruptive in-session response to contain and minimize potential identity-based threats.
  • Idira Endpoint Privilege Manager can help enable enterprises to reduce risk, satisfy compliance, and streamline operations. It helps implement least privilege via policy-driven elevation and removal of standing admin rights, and blocks risky actions, such as execution of unvetted applications and access to memory of other processes, while providing audit-ready evidence and unified identity governance. Automation and consolidation improve efficiency and support Zero Trust strategies, strengthening security without slowing the business.
  • Idira Privileged Access Management can help unify privileged access across human, machine, and agentic identities to secure cloud access across multi-cloud environments. Building on proven PAM, it delivers centralized secrets management alongside modern controls like Just-in-Time access and Zero Standing Privileges. This enforces consistent least-privilege security across on-premises, cloud, and SaaS targets.
  • Idira Secure Infrastructure Access can help enforce Zero Standing Privileges (ZSP) through Just-in-Time (JIT) provisioning which grants temporary, tightly scoped access only as needed. Backed by continuous session recording and real-time command monitoring, SIA can detect high risk actions before an attacker compromises critical systems.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
  • UK: +44.20.3743.3660
  • Europe and Middle East: +31.20.299.3130
  • Asia: +65.6983.8730
  • Japan: +81.50.1790.0200
  • Australia: +61.2.4062.7950
  • India: 000 800 050 45107
  • South Korea: +82.080.467.8774

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Indicators of Compromise

Attacker Identities Used in Vishing Attempts – Generic

  • helpcenter@ithelpcenter365[.]onmicrosoft[.]com
  • helpdesk@itprotectiondepartment[.]onmicrosoft[.]com
  • helpdesk@newsystemmaintenance[.]onmicrosoft[.]com
  • helpdesk@officedesk365[.]onmicrosoft[.]com
  • helpdesk@officesecures[.]onmicrosoft[.]com
  • helpdesk@tbcsschid[.]onmicrosoft[.]com
  • internal@internalusahelpdeskIT[.]onmicrosoft[.]com
  • it_assistance@teams0137[.]onmicrosoft[.]com
  • it@infrastructurefirewall[.]onmicrosoft[.]com
  • itadmin@mandatorynetworkmonitoring[.]onmicrosoft[.]com
  • itassistant@bilelonellc[.]onmicrosoft[.]com
  • ithelp@certifiednetworksec[.]onmicrosoft[.]com
  • ithelp@internalsystemsdaily[.]onmicrosoft[.]com
  • ithelp@itprotectiondepartment[.]onmicrosoft[.]com
  • ithelp@mandatorynetworkmonitoring.onmicrosoft[.]com
  • ithelpdesk@certifiedupdatenetwork[.]onmicrosoft[.]com
  • support@bilelonellc[.]onmicrosoft[.]com

Attacker Identities Used in Vishing Attempts – Usernames

Names have been partially redacted to protect the users associated with accounts that were impersonated by the attackers.

  • andreas[..]@idigitalserviceoperation.onmicrosoft[.]com
  • andrew[..]@hapsinfrastructureops.onmicrosoft[.]com
  • brandon[..]@devsitoperationhub.onmicrosoft[.]com
  • brian[..]@appssupportsys.onmicrosoft[.]com
  • christopher[..]@adevpsitplatformops.onmicrosoft[.]com
  • christopher[..]@itplatformops.onmicrosoft[.]com
  • christopher[..]@helpaphelpitinfraops.onmicrosoft[.]com
  • clara[..]@systemsupportoperations.onmicrosoft[.]com
  • daniel[..]@opsnetsupportit.onmicrosoft[.]com
  • daniel[..]@apsitsupporthub.onmicrosoft[.]com
  • emily[..]@apsitechsupportdesk.onmicrosoft[.]com
  • eric[..]@appopshelp.onmicrosoft[.]com
  • henrik[..]@enterpriseoperationsflo.onmicrosoft[.]com
  • james[..]@helpitsupportcore.onmicrosoft[.]com
  • james[..]@itcoretechhelp.onmicrosoft[.]com
  • jonathan[..]@itservicedesk.onmicrosoft[.]com
  • justin[..]@techopshelpsupp.onmicrosoft[.]com
  • kevin[..]@itopsupportdesk.onmicrosoft[.]com
  • kevin[..]@netopsdeskhelp.onmicrosoft[.]com
  • leon[..]@netcorevdapp.onmicrosoft[.]com
  • lucas[..]@applicationoperationsunit.onmicrosoft[.]com
  • martin[..]@syslanevdapp.onmicrosoft[.]com
  • matthew[..]@supportopsupp.onmicrosoft[.]com
  • michael[..]@appdeploymentservices.onmicrosoft[.]com
  • michael[..]@infratechopsdesk.onmicrosoft[.]com
  • michael[..]@itopsdeskhelp.onmicrosoft[.]com
  • patrick[..]@infrastructureopsdesk.onmicrosoft[.]com
  • rachel[..]@ioseccloudsupport.onmicrosoft[.]com
  • rebecca[..]@infrastructureopsservice.onmicrosoft[.]com
  • robert[..]@systemdeploymentcenter.onmicrosoft[.]com
  • ryan[..]@apstechopsdeskdev.onmicrosoft[.]com
  • ryan[..]@helpssupportcloudops.onmicrosoft[.]com
  • ryan[..]@seqhelpitsuppnetops.onmicrosoft[.]com
  • sarah[..]@secinfrahelpdesk.onmicrosoft[.]com
  • sarah[..]@apsscloudopsdesk.onmicrosoft[.]com
  • sarah[..]@helpitdevsupportops.onmicrosoft[.]com
  • sarah[..]@itdevsupportops.onmicrosoft[.]com
  • scott[..]@cloudinfrastr.onmicrosoft[.]com
  • steven[..]@ittechnologyopsitdesk.onmicrosoft[.]com
  • thomas[..]@networkoperationsec.onmicrosoft[.]com
  • thomas[..]@seqapsitsupportops.onmicrosoft[.]com

Infrastructure Used in Vishing Attempts (VPNs and Proxies)

  • 193.32.248[.]251
  • 193.138.7[.]142
  • 185.65.134[.]209
  • 178.130.47[.]46
  • 5.181.3[.]106
  • 2.56.172[.]214
  • 185.234.67[.]53
  • 45.8.157[.]185
  • 80.66.72[.]215
  • 136.0.20[.]6
  • 185.213.155[.]226
  • 185.155.99[.]161
  • 92.118.232[.]131
  • 45.182.189[.]80
  • 185.65.133[.]51
  • 45.33.22[.]47

Malicious Files From Post-Compromise Activity (Campaign A)

  • SHA256 hash: 24ab9fe5d5be62d3bf055a0ca4508e8bca2996b6d78649dce8145d8a27bc1c5b (obfuscated PowerShell payload)

File description: Obfuscated PowerShell RAT dropper downloaded via Invoke-WebRequest

  • URL: hxxps[:]//san-sid[.]com/owners

Description: URL hosting obfuscated PowerShell payload used as RAT dropper

Cortex XDR Alerts and MITRE ATT&CK® Techniques

Table 2 lists the Cortex XDR alerts and the associated MITRE ATT&CK techniques these alerts detect.

Alert Name Alert Source MITRE ATT&CK Technique
External user started a Microsoft Teams conversation XDR Analytics, Identity Threats Phishing (T1566)
External user created a Microsoft Teams conversation with suspicious operations XDR Analytics, Identity Threats Phishing (T1566)
External user added a link to a Microsoft Teams chat XDR Analytics, Identity Threats Phishing (T1566)
External user call via Microsoft Teams XDR Analytics, Identity Threats Phishing: Spearphishing Voice (T1566.004)
Rare process execution by user XDR Analytics, UEBA User Execution (T1204)
Rare process execution in organization XDR Analytics, UEBA User Execution (T1204)
Multiple rare process executions in organization XDR Analytics, UEBA User Execution (T1204)
A process connected to an atypical rare cloud resource XDR Analytics Exfiltration Over Web Service: Exfiltration to Cloud Storage (T1567.002)
Uncommon local scheduled task created XDR Analytics Scheduled Task/Job (T1053)
A browser was forced to load an extension using a special command-line argument XDR Analytics Software Extensions: Browser Extensions (T1176.001)
Uncommon browser extension loaded XDR Analytics Software Extensions: Browser Extensions (T1176.001)
SMB traffic from non-standard process XDR Analytics Network Service Discovery (T1046)
Rare NTLM access by user to host XDR Analytics, UEBA Use Alternate Authentication Material (T1550)
Unusual Encrypting File System Remote Protocol call (EFSRPC) to domain controller XDR Analytics, UEBA Forced Authentication (T1187)

Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay (T1557.001)
Possible authentication coercion to a sensitive server XDR Analytics, UEBA Forced Authentication (T1187)

Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay (T1557.001)
Possible Distributed File System Namespace Management (DFSNM) abuse XDR Analytics Forced Authentication (T1187)

Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay (T1557.001)
Possible authentication coercion XDR Analytics, UEBA Forced Authentication (T1187)

Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay (T1557.001)

Table 2. Cortex XDR alerts and MITRE techniques.

Additional Resources

Perturbation Probing: A New Diagnostic for the Fragility of LLM Safety

Posted on by Yuhao Wu

Introducing a New Angle on LLM Safety

Our previous research on logit-gap steering demonstrated that the safety guardrails of an aligned LLM can be bypassed by closing a measurable gap in the model's output scores. That work answered the question of how an attacker bypasses alignment. A natural follow-up question is where inside the model the alignment lives in the first place — and how concentrated or how diffuse that defense actually is. The answer matters because it tells defenders whether safety is a thick perimeter or a thin layer of paint.

Modern LLMs are aligned through reinforcement learning from human feedback (RLHF), a training stage that pushes the model toward refusing harmful prompts and complying with safe ones. Until now, no method has been able to point to the specific pieces of the network that carry that learned behavior cheaply enough to run on every model an enterprise deploys. Our new academic research presents a method that does exactly that, and it produces a result that should change how the industry talks about LLM safety.

Our Research: Perturbation Probing Findings and Technical Impact

Our research introduces a method called perturbation probing. With only two forward passes per prompt and a significantly lower computational cost, it identifies the small set of feed-forward neurons inside an aligned LLM that are causally responsible for a targeted behavior, such as refusing harmful requests.

The headline finding is striking. On open-source LLM Qwen3-4B, just 50 neurons out of 350,208 — about 0.014% of the model's feed-forward neurons — control the safety refusal template. Removing those 50 neurons changes the response format on 80% of 520 standard harmful-prompt benchmarks. The result was replicated on 200 prompts of a second standard benchmark. On a smaller model, Qwen3.5-2B, just 20 neurons were enough to stop the LLM from falsely agreeing with users in multi-turn conversations, dropping that behavior from 36.7% to 0% across 30 questions.

This concentration matters because it demonstrates that an aligned LLM's refusal behavior does not live in a robust, distributed defense. It lives in a thin template layer — a tiny fraction of the network that an attacker who can manipulate internals could disable, and that even a normal optimization run could shift. Relying on this thin layer alone is the LLM analog of relying on a single perimeter firewall: structurally insufficient. True AI safety demands a defense-in-depth strategy, with external content filters and runtime guardrails layered on top of whatever the base model was trained to do.

Beyond identifying the neurons, the same computation produces a diagnostic we call the FFN/Skip ratio: a single number, computable in seconds per model, that predicts whether a model's safety circuit can be easily steered with minimal modifications. Across the 13 models tested, this ratio explained 81% of the variance in how vulnerable each model's safety behavior was to a small targeted change. That makes it a candidate for a quantitative safety fragility score, a metric that allows security teams to compare models on alignment robustness without running adversarial red-team campaigns first.

Figure 1 displays these tests below. The horizontal axis measures how much a model routes decisions through a narrow internal pathway, and the vertical axis measures how much the model’s safety behavior changed when we disabled just 50 neurons. Models track the diagonal closely, which is why one number can predict the other.

Figure 1. Graph displaying the 13 tested models.

Building a Stronger Future for AI Safety

We hope that perturbation probing will serve two roles for the AI security community. First, as a pre-deployment diagnostic. Security teams can measure how much of a model's safety rests on a thin, easily removed layer before they put that model in production. In our experiments, amplifying just 10 identified neurons on a small model improved factual self-correction from 52% to 88% on 200 TruthfulQA prompts without any retraining. The same toolkit that exposes fragility can also be used to repair it.

We are sharing this research to empower the broader AI and security community to build LLMs whose safety properties can be measured, audited and reinforced, not merely asserted. We urge researchers to read the full paper on arXiv, “Perturbation Probing: A Two-Pass-per-Prompt Diagnostic for FFN Behavioral Circuits in Aligned LLMs.” We also recommend integrating fragility diagnostics into your own evaluation pipelines.

For organizations deploying LLMs today, Prisma AIRS Runtime Security provides the external content filters and inline guardrails that a thin template layer alone cannot. Unit 42's AI Security Assessment helps identify where AI adoption introduces governance and exposure risk. Together, they deliver the defense-in-depth posture that this research shows is necessary.

Additional Resources

Disclaimer

We used publicly available open-weight models under their respective licenses for local mechanistic and safety evaluation. The study reports aggregate rates, model-internal measurements, and non-operational summaries only. We do not release harmful generations, executable attack artifacts, jailbreak prompts or instructions that facilitate misuse. For models governed by acceptable-use or prohibited-use policies, experiments are framed as defensive safety evaluation and robustness measurement.

The State of AI-Enabled Malware August 2026: From Brand Abuse to Agentic Execution

Posted on by Sheida Azimi

Executive Summary

To assess the impact of AI-enabled malware, we collected and analyzed over 400 malware samples that integrate AI in some capacity, from brand impersonation and large language model (LLM)-generated code to agentic execution loops. Our central finding was that the AI malware space is currently overwhelmingly composed of proof-of-concept code, security validation testing and researcher submissions that have never reached a production environment.

Of the 405 samples in our dataset, only 12 appeared in our telemetry on Cortex XDR-protected endpoints, and a small subset was forwarded through Next-Generation Firewalls to WildFire for analysis. Palo Alto Networks products detected and blocked every sample that attempted to reach a customer environment.

These numbers tell a story that sits between two poles in the current discourse. AI-enabled malware is real. However, the volume of genuine operational activity remains a fraction of what public sample repositories suggest. Approximately 97% of the samples we examined exist only in sandboxes and on VirusTotal.

For defenders, the practical takeaway is straightforward. Existing behavioral detection, cloud-based sandboxing and endpoint analytics catch these threats using the same mechanisms that stop conventional malware. The AI component does not evade detection. It changes how the code is authored, not how it executes.

Palo Alto Networks customers are better protected against the threats discussed in this article through the following products and services, which detected these AI-enabled malware threats out of the box:

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Related Unit 42 Topics LLM, Agentic AI, Malware

The Dataset

Our starting dataset consisted of 405 unique SHA-256 hashes collected from WildFire analysis reports, VirusTotal Intelligence and published open-source intelligence (OSINT) research.

The collection criteria were broad. We included any sample where AI integration was either a functional component of the malware, a feature of its delivery mechanism or part of its branding. This intentionally inclusive approach captured everything from LLM-powered ransomware agents to cryptocurrency miners that simply used “ChatGPT” in their filename.

We queried this dataset across multiple telemetry sources to measure real-world prevalence:

  • Endpoint presence: Cortex XDR agent telemetry from non-test tenants (December 2024–June 2025)
  • Network visibility: WildFire session data from samples forwarded by Next-Generation Firewalls and Cortex XDR agents (June 2024–June 2025)
  • Alert generation: Cortex XDR alert records for samples that triggered detection logic on endpoints
  • Sandbox verdicts: WildFire analysis results with malware classification

Table 1 summarizes the results of this dataset.

Telemetry Source Samples Queried Samples Discovered Prevalence in Production
Cortex XDR endpoints 405 12 3.0%
WildFire sessions 405 ~15–20 unique hashes ~4%
Cortex XDR alerts generated 12 12 100%

Table 1. Telemetry coverage across the AI malware dataset.

The disparity between the 405-sample dataset and the 12 samples observed in production environments is the most important number in this analysis. Approximately 97% of AI-enabled malware samples exist only in research repositories, sandbox environments and security validation platforms. We found no evidence that they reached a customer endpoint or traversed a customer firewall.

The following sections examine the characteristics of the dataset.

What the Other 97% Looks Like

The samples that never appeared in production telemetry fall into three categories:

  • Proof-of-concept and research code
  • Security validation and testing
  • AI-themed brand abuse

Proof-of-Concept and Research Code

The largest category consists of proof-of-concept implementations published to demonstrate a technique. These include:

  • LLM-powered ransomware frameworks with hard-coded test parameters (such as ransom addresses pointing to the Bitcoin Genesis Block, which cannot receive recoverable payments)
  • AI-assisted reconnaissance scripts designed for conference demonstrations
  • Modular attack frameworks built to test specific AI integration patterns rather than to compromise real targets

Many of these samples share common characteristics:

  • They target localhost or private IP address ranges in their configuration
  • They contain verbose debug logging that no operational threat actor would leave enabled
  • Their submission histories show a single upload from a security research organization or academic institution

Additionally, we found many of these samples in file paths that indicated malware analysis or research. They contained terms such as research, mal or analysis in their directory paths.

Security Validation and Testing

A second category comprises samples submitted by breach-and-attack simulation (BAS) platforms and internal security teams. These appear in WildFire and on VirusTotal because organizations deliberately test their detection capabilities against publicly reported AI malware samples.

The submission patterns are distinctive. They include multiple uploads of the same hash from the same organization within a short time window, often during business hours in a single time zone. They frequently come from IP addresses associated with known security testing infrastructure.

AI-Themed Brand Abuse

A third category uses AI branding without meaningful AI integration. Filenames reference popular AI companies or other AI products, but the payload is conventional malware wrapped in an installer that mimics an AI application.

The AI branding is a social engineering tactic, not a technical capability. These samples are real threats to the people who download them, but they do not represent a new category of AI-enabled attack.

The 3% Found on Endpoints

Twelve samples from the dataset appeared on Cortex XDR-protected endpoints across organizations in three countries. They span five distinct malware families, each representing a different pattern of AI integration or AI-themed delivery. These five families are:

  • FunkSec ransomware
  • A trojanized AI application
  • The Oyster backdoor
  • The Rhadamanthys stealer
  • A COM hijacking DLL

FunkSec Ransomware

The most represented family in our endpoint data is FunkSec, a ransomware strain that multiple researchers have assessed as partially generated with LLM assistance. Seven distinct variants appeared across production endpoints, compiled between Jan. 1–6, 2025. The variants share a common Rust codebase and use similar evasion techniques:

  • Disabling Windows Defender through PowerShell and registry modifications
  • Deleting volume shadow copies
  • Changing the desktop wallpaper to display a ransom note

The PDB paths embedded in the binaries reveal an active development cycle. Variants use project names including:

  • Dev.pdb
  • Funksec.pdb
  • Darkzone.pdb
  • Darkfunk.pdb

This is consistent with a developer iterating on the same codebase under multiple working names. Seven distinct builds in six days is a pace that suggests LLM-assisted development, where generating a new variant is closer to a prompt generation rather than a software development task.

WildFire classified all seven variants as malware. Cortex XDR generated alerts for every variant that executed on an endpoint.

Trojanized AI Application

The most widely encountered sample in the dataset is an NSIS installer that masquerades as a recipe-finding application called Recipe Lister. The binary is signed with a code-signing certificate issued to Global Tech Allies Ltd. — a certificate that has since been revoked. When executed, it extracts and runs a JavaScript backdoor from a temporary directory.

This sample generated the highest volume of telemetry in our dataset. It appeared across more than 50 organizations and generated over 6,500 endpoint profile records and 9,600 XDR alerts during the observation window. The alert data confirms that Cortex XDR blocked the binary across these environments through a combination of local analysis, behavioral protection and WildFire cloud verdicts. No execution succeeded on a protected endpoint.

The detection dynamics around this sample illustrate how layered defense handles AI-themed threats:

  • The code signature initially suppresses static detection, as the file appears legitimately signed
  • Behavioral analytics identify the threat through two secondary signals:
    • The signer is uncommon across the organization's fleet
    • The file entropy is near-maximum (0.999970), indicating packed or encrypted content
  • The WildFire cloud verdict, which arrives after the file is forwarded for sandbox analysis, provides the definitive classification and triggers the block action

Oyster Backdoor

One sample masquerades as a Dropbox installer and carries an Authenticode signature whose subject identity reads Dropbox, Inc. To the victim, this appears to be verified, publisher-signed software. In reality, the installer drops an AutoIt loader that side-loads the Oyster (aka CleanBoost) backdoor. The signed file is not Dropbox software, and the signature lends it false legitimacy.

Attackers are using AI tools to quickly generate the malicious code required for the initial access and delivery phases of the attack, lowering the barrier to entry and speeding up the deployment of loaders like this NSIS installer.

Rhadamanthys Stealer

A .NET executable named redist.exe delivers the Rhadamanthys information stealer with active command-and-control communication. According to previous reporting, this sample was part of an AI-enabled infection chain that ultimately delivered this sample of Rhadamanthys stealer.

COM Hijacking DLL

A DLL masquerading as a component of 360 Total Security named 360Util.dll implements persistence through COM object hijacking. The PDB path references 360Util.pdb, and the file metadata impersonates the Chinese-language product name. We included this sample in the dataset because it was delivered alongside AI-branded lures in campaigns we observed.

Conclusion

The gap between the volume of AI malware samples in public repositories and the volume observed in production environments reflects the current state of AI-enabled threats. AI lowers the barrier to creating malware, and the number of samples in our dataset confirms that many people are experimenting with the technique. But creating a sample and successfully deploying it against a defended environment are different problems, and malware authors have not to date succeeded at using AI to solve the second one.

The samples that did reach production environments were detected by the same mechanisms that catch conventional malware:

  • Sandbox detonation
  • Behavioral analytics
  • Code-signing anomaly detection
  • Entropy analysis

None of the AI-enabled samples in our dataset required a novel detection approach. The AI component influenced how the malware was written, but the resulting binary still exhibits the same behavioral indicators that existing detection logic targets.

This does not mean we can dismiss AI-enabled threats:

  • The development velocity visible in FunkSec's PDB paths suggests that LLM-assisted coding accelerates the iteration cycle for ransomware development
  • The trojanized AI application campaign demonstrates that AI brand recognition is an effective social engineering vector, with the sample reaching more than 50 organizations
  • The presence of legitimate code signatures on multiple samples shows that the delivery sophistication of AI-themed malware matches that of conventional threats

Telemetry data does not reveal statistically significant targeting patterns across the samples. The encounters span three countries and industries with no concentration in any single sector or geography. This is consistent with opportunistic operations rather than targeted campaigns directed at specific organizations or verticals.

The absence of targeting patterns is itself informative. AI-enabled malware, at this stage of adoption, follows the same distribution model as most offensive cyber activity. Threat actors are integrating AI capabilities into tools that they’ve deployed broadly rather than reserving them for operations against specific high-value targets.

When evaluating AI in the current malware landscape, it should not be categorized as mere hype or altogether dismissed. AI-enabled malware is a real and growing category, but our current defensive frameworks detect and block AI-enabled malware regardless of the role that use of AI played in its development. Organizations that maintain strong defense in depth are well positioned to detect these threats as they evolve.

Palo Alto Networks customers are better protected from the threats discussed above through the following products, which detected these AI-enabled malware threats out of the box:

  • The Advanced WildFire machine-learning models and analysis techniques identify indicators shared in this research.
  • Cortex XDR and XSIAM are designed to prevent the execution of known malicious malware and prevent the execution of unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
  • UK: +44.20.3743.3660
  • Europe and Middle East: +31.20.299.3130
  • Asia: +65.6983.8730
  • Japan: +81.50.1790.0200
  • Australia: +61.2.4062.7950
  • India: 000 800 050 45107
  • South Korea: +82.080.467.8774

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Indicators of Compromise

Samples

Table 2 lists the samples assessed as genuine threat actor activity.

SHA256 hash Family
1619bcad3785be31ac2fdee0ab91392d08d9392032246e42673c3cb8964d4cb7 Trojanized application (RecipeLister)
5226ea8e0f516565ba825a1bbed10020982c16414750237068b602c5b4ac6abd FunkSec ransomware
dcf536edd67a98868759f4e72bcbd1f4404c70048a2a3257e77d8af06cb036ac FunkSec ransomware
66dbf939c00b09d8d22c692864b68c4a602e7a59c4b925b2e2bef57b1ad047bd FunkSec ransomware
c233aec7917cf34294c19dd60ff79a6e0fac5ed6f0cb57af98013c08201a7a1c FunkSec ransomware
e622f3b743c7fc0a011b07a2e656aa2b5e50a4876721bcf1f405d582ca4cda22 FunkSec ransomware
b1ef7b267d887e34bf0242a94b38e7dc9fd5e6f8b2c5c440ce4ec98cc74642fb FunkSec ransomware
20ed21bfdb7aa970b12e7368eba8e26a711752f1cc5416b6fd6629d0e2a44e5d FunkSec ransomware
dd15ce869aa79884753e3baad19b0437075202be86268b84f3ec2303e1ecd966 FunkSec ransomware
c398b3e06ef860670b9597daed85632834fa961aea87164b8ba8bb2f094a14ef COM hijacking DLL
bb932056cae8940742e50b4f2b994a802e703f7bc235e7dd647d085ae2b2baf7 Oyster backdoor/CleanBoost
4fb58687a364c3f6d6f7e0ca03654f9dec0f8832a499d61d40b0d424db1b1b14 Rhadamanthys stealer

Table 2. Samples observed on production endpoints.

Additional Resources

Analyzing the Current State of AI Use in Malware — Palo Alto Networks, Unit 42

Connecting the Dots: Securing the Overlooked Corners of the Software Development Lifecycle (SDLC) Supply Chain

Posted on by Ria Bhatia

While supply chain threats have been quietly compounding over the past decade, the last 12–18 months have triggered a drastic shift in the scale and velocity of these attacks. Rather than just hunting for bugs in finished software, attackers are targeting the everyday tools and code developers rely on.

Unit 42 research shows this happening at every step of the building process. We've observed attackers spending years pretending to be helpful contributors just to hide backdoors in core software, as seen in the XZ Utils vulnerability (CVE-2024-3094). We've seen attackers hijack accounts to drop malware into popular libraries, like in the Axios supply chain attack. And we've seen them misuse setup scripts to automatically steal credentials using the Shai-Hulud npm worm.

Simply put, attackers are more focused on poisoning the digital factory that builds an application as opposed to the application itself. By targeting continuous integration/continuous delivery (CI/CD) pipelines and developer environments, they hijack software at the source before it ever hits production.

Threat Analysis: ChainDrop npm Worm

Consider the recent ChainDrop npm worm, which infected over 400 packages including massively popular libraries like keyv and cacheable-request using a highly evasive three-step chain:

  • The hook: Attackers modified package manifests with a malicious preinstall script that downloaded the legitimate Bun runtime to silently launch a 727 KB obfuscated payload in the background.
  • The theft: Rather than just scraping disk files, a hidden Python script directly read live process memory from GitHub Actions runners to steal temporary OpenID Connect (OIDC) tokens and secrets, alongside a massive sweep for local developer credentials.
  • The payload: The worm used those stolen npm and GitHub tokens to self-propagate, silently infecting and republishing additional packages while leaving their legitimate functionality perfectly intact so that developers don't notice.

ChainDrop secured long-term persistence by establishing cross-linked hooks directly inside developer tools like VS Code and Claude Code, while managing its entire command-and-control (C2) infrastructure dynamically through Ethereum blockchain transactions.

The malware triggers silently the second someone runs npm install by misusing npm's setup scripts (preinstall hooks). From there, it hits three distinct targets:

  1. Cloud secret harvesting: It searches build server memory to scrape unencrypted credentials and platform access tokens
  2. Local endpoint backdooring: It modifies local developer tool configs (like VS Code's tasks.json) so the attacker retains access even after the build finishes
  3. Automated propagation: It uses stolen tokens to automatically create rogue code repositories, turning compromised accounts into new launchpads to spread the worm

Package Visibility Across the SDLC

The main takeaway is that open-source and third-party packages touch every single phase of the software development lifecycle (SDLC). Modern applications aren't built from scratch, they are assembled. Because open-source code makes up 80-90% of modern codebases, the attack surface expands to developer laptops, CI/CD pipelines and cloud infrastructure.

Ten years ago, a project might have relied on a few dozen external libraries. Today, even a simple application pulls in thousands of indirect dependencies. Generating a software bill of materials (SBOM) at the end of a build is great for compliance, but an SBOM alone simply doesn't cut it anymore. An inventory list created at the finish line won't catch malware that was executed during the build process. To truly secure an environment, every single place a third-party package touches needs to be mapped.

The Endpoint Attack Surface

Developers today navigate an endless matrix of language-specific package managers. They routinely execute installations across a massive array of ecosystems — npm install, pip install, cargo build, go get, mvn install and many more — while simultaneously juggling 10–30 integrated development environment (IDE) extensions. Why are these attacks so effective? Because developer tools lack basic guardrails.

Think about your web browser. When you visit a website, the browser locks it in a safe container (a sandbox) so it can’t touch your computer. But setup scripts and code editor extensions don't have those walls. The second they run, they get the same permissions you have, giving malware total freedom to read your files, steal keys and run commands on your machine.

This massive, un-isolated weakness is exactly why registries and marketplaces have become prime targets, as seen in the recent GlassWorm campaign. Whether it’s a malicious script running silently during a routine dependency pull or a compromised IDE extension updating automatically in the background, an attacker instantly gains unrestricted execution rights on a developer's machine and access to valuable cloud knowledge.

CI/CD Pipelines

Build pipelines rely on numerous outside tools, plugins and helper scripts to assemble code. Attackers often target these build environments because they are packed with temporary passwords and cloud access keys. The compromise of Trivy highlights the potential attack surface of pipeline security tools. This means that only scanning app code is insufficient. A pipeline bill of materials (PBOM) is also needed, which is an inventory list of every single tool running inside your build system.

The Cloud Runtime

Finally, we can't forget the cloud. A standard application SBOM typically only lists the code libraries developers explicitly add to their software. However, cloud environments rely on containers, which require a broader approach. A container SBOM provides the full picture by tracking both the application code and the hidden operating system tools built into the container image such as basic security utilities and system libraries like OpenSSL. Standard application scans completely overlook these deeper system layers.

The danger of this weakness was starkly illustrated by the wave of OpenSSL zero-day vulnerabilities disclosed in early 2026. Because these critical flaws sit deep within the foundational cryptographic infrastructure of the container's operating system, the application-layer code will look perfectly clean and pass every repository scan, while the underlying cloud workload remains completely exposed to a remote takeover.

Given this extensive attack surface, relying on static, point-in-time gateway scans is an insufficient strategy. True supply chain resilience requires continuous visibility between local developer endpoints, automated pipelines and cloud runtime workloads. Correlating telemetry across all three domains is the only way to intercept malicious behaviors and halt a compromise before it propagates downstream.

Tips for Hardening Pipelines

Defending against automated supply chain attacks requires shifting from reactive code scanning to strict execution control across the entire build path. Because tools, IDE extensions and package managers run with high privileges, organizations must lock down the developer environment by disabling lifecycle install scripts (--ignore-scripts), enforcing package cooldown periods, restricting CI/CD egress traffic, using ephemeral CI/CD servers and pinning dependencies down to exact commit SHAs.

Beyond environment hardening, neutralizing autonomous malware like Shai-Hulud means eliminating the long-lived credentials that fuel them. By transitioning to brief OIDC authentication and enforcing end-to-end cryptographic provenance, teams can establish an unbroken chain of trust. This trust extends from signed commits at the developer endpoint to signed artifacts and SBOMs in production, helping stop self-propagating worms in their tracks.

Identity Abuse Through Trusted Communication Channels

Posted on by Sheida Azimi

Executive Summary

Identity has become a primary security boundary for most organizations, reducing the ability to solely trust other boundaries once associated with corporate networks. Users authenticate to cloud services using enterprise identities that provide access to collaboration platforms, business applications and sensitive data. With the adoption of software-as-a-service (SaaS) on the rise, people are shifting to platforms for communication and collaboration.

Threat actors have adapted to this shift. In addition to typical email-based phishing, attackers increasingly misuse trusted collaboration platforms to conduct identity phishing, impersonation, credential theft, malware delivery and social engineering. Over the last 12 months, our endpoint alerts of malicious activity associated with collaboration tools have more than quadrupled, as Figure 1 shows. This activity could involve compromised accounts, external federated organizations, guest accounts or trusted third-party relationships. In each case, the attackers seek to exploit the trust that people place in enterprise communication platforms.

 

A bar chart displaying the number of collaboration tool alerts from July 2025 to June 2026. The bars show a gradual increase over the months, starting at 1490 in July 2025 and peaking at 6799 in June 2026.
Figure 1. Collaboration tool alerts of severity low or higher per month.

This changes the role that collaboration platforms play within enterprise security. They are not just productivity applications, they have become part of the enterprise attack surface. Unit 42 researchers found that 99% of the alerts generated related to chat or voice phishing operations, indicating that attackers often gain access to these environments through targeted phishing operations. After a successful compromise, attackers can then communicate using the identity and privileges of the compromised user. This allows malicious activity to appear as normal collaboration activity.

Security controls typically remain focused on email and authentication events, often providing limited visibility into activity occurring within authenticated collaboration sessions.

We examine how threat actors leverage trusted communication channels and review identity abuse techniques. We also provide practical recommendations for detecting and defending against identity-focused attacks targeting enterprise collaboration platforms.

Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Related Unit 42 Topics Phishing, Identity, Credential Theft 

Understanding Trusted Communication Channels

Enterprise collaboration platforms have become integral to business operations. Employees use these platforms to exchange messages, share files, coordinate projects and communicate with colleagues, customers and business partners. Organizations typically connect collaboration platform access to their identity provider, and people rely on these platforms for trusted, authenticated communication.

Unlike email, collaboration platforms enable real-time conversations and support features such as external federation, guest access, shared workspaces and third-party integrations. These capabilities improve productivity but also create opportunities for misuse. Attackers can exploit compromised accounts, trusted business relationships or authorized external access to interact with victims through legitimate communication channels. Figure 2 shows common pathways for attackers to compromise identities in enterprise and cloud environments.

A flowchart illustrating a cyberattack sequence with five stages: "Threat Actor Access Method," "Trusted Communication Channel" (examples include Slack, Teams), "Identity-Focused Interaction," "Requested User Action," and "Identity Outcome." Each stage describes actions and examples, connected by red arrows denoting progression.
Figure 2. How attackers leverage collaboration platforms to compromise identities.

When a collaboration account is compromised, attackers inherit the identity context of that user, including their permissions, relationships and ongoing conversations. Requests that might appear suspicious in an email can appear routine when delivered through an authenticated collaboration platform. This reduces a target’s suspicion and increases the effectiveness of identity phishing, impersonation, credential theft and social engineering.

As organizations adopt more SaaS collaboration platforms, they should treat these environments as part of the identity attack surface. Protecting them requires both strong authentication, and visibility into how trusted identities and communication channels are used after authentication.

Real-World Misuse of Collaboration Platforms

Recent campaigns demonstrate that attackers use collaboration platforms in multiple stages of identity-focused attacks, from initial access to post-compromise operations. Table 1 summarizes these intrusion stages.

Intrusion Technique Campaign Misuse Pattern
Initial access: Phishing (T1566) Identity phishing through external collaboration channels
Stealth: Impersonation (T1684.001) Impersonation through legitimate platform notifications, hosted content and direct messages
Persistence: Modify Authentication Process (T1556) MFA removal and privileged credential exfiltration through a native Slack webhook integration

Table 1. Collaboration platform misuse by MITRE ATT&CK intrusion technique.

Initial Access

One of the most common techniques is identity phishing through enterprise collaboration platforms. In our Insights article, "When 'Hi, This Is IT' Comes Through Microsoft Teams", we discussed how APT29 used compromised Teams accounts to send links to credential-harvesting pages. We reported that attackers misuse external federation in Teams to initiate conversations with victims while impersonating IT support or other trusted personnel. These campaigns often begin with a request to chat, followed by instructions to visit a phishing site, approve a multifactor authentication (MFA) request, install remote access software or provide credentials.

Okta Threat Intelligence has also documented the technique of identity phishing through attacker-controlled Slack workspaces. The threat actor behind this activity impersonated administrators and employees from targeted organizations and sent phishing links through direct messages, channel mentions and legitimate notifications. The links redirected victims to adversary-in-the-middle phishing proxies designed to capture corporate credentials and MFA tokens.

Security teams might not detect the initial collaboration message directly. They could instead see the actions that follow. An example of this is shown in a process tree from a malicious chat scenario in Figure 3.

A process tree diagram showing a communication application launching a system process, which uses an archive utility to extract a DLL from a downloaded archive file.
Figure 3. Example of an initial access process tree.

In this case, the threat actor sent a RAR file via a link to a victim in a Teams chat. The victim downloaded the file to their Downloads folder. Note that attackers may avoid sending files through Teams because doing so creates an additional detection point through Safe Links/Safe Attachments, instead directing victims to websites or scripts during calls.

The victim then opened an Explorer window and double-clicked [REDACTED].rar, launching WinRAR.exe to open the archive. WinRAR extracted the malicious lpk.dll, which the victim’s endpoint security agent detected. The extracted lpk.dll is a known, older malicious DLL that masquerades as a legitimate Windows language pack DLL. Attackers use the file for DLL sideloading attacks. This recent event demonstrates that attackers continue to use older malware families in attacks delivered through collaboration platforms.

Unlike commonly-seen email phishing, some collaboration platforms support interactive communication. This enables attackers to respond to targets and adjust their social engineering tactics in real time. If successful, the attacker obtains a valid enterprise identity. The attacker can then access enterprise and cloud services with the privileges and identity context of the compromised user.

Impersonation and Identity Compromise

Attackers use impersonation to exploit trust in collaboration platforms and gain access to enterprise identities, posing as known individuals, trusted organizations or support personnel.

  • In January 2026, Fireblocks disclosed a recruitment-themed social engineering campaign in which attackers impersonated Fireblocks executives, recruiters and hiring managers to target technology workers. The attackers initially contacted targets through social media, provided professionally prepared recruiting materials and then scheduled interviews through Google Meet. During the video interviews, an individual presented as a Fireblocks HR manager discussed the candidate’s experience, compensation and other expected hiring topics before assigning a code review task for a fictitious Fireblocks project. Candidates were instructed to clone a GitHub repository and run standard setup commands, including npm install, which executed malicious code and downloaded malware onto their systems. The campaign used legitimate Google Meet communications and a convincing interview process to reinforce the Fireblocks impersonation and persuade victims to execute malicious code. Fireblocks assessed the activity as closely aligned with the North Korea-linked Contagious Interview campaign pattern.
  • In March 2026, a threat actor used a staged Slack workspace as part of a targeted social engineering campaign against the lead maintainer of the Axios npm package. The threat actor impersonated a legitimate company and created a convincing, simulated Slack environment with company branding, channels, users and message history. The interaction later moved to a meeting that was designed to look like Teams. During this meeting, the maintainer was convinced to install software that delivered a remote access Trojan. The threat actor then gained access to the maintainer’s npm account and published two poisoned Axios versions, causing projects that installed the affected releases to retrieve and execute a malicious dependency.
  • In April 2026, OpenSSF reported a campaign targeting members of the Linux Foundation TODO Group Slack workspace and related communities. The threat actor impersonated a known Linux Foundation community leader and contacted targets through Slack direct messages. The messages contained a Google Sites link that led to a fraudulent Google Workspace authentication process. The site requested the target’s email address and verification code. It then instructed the target to install a malicious root certificate. On macOS, the process also downloaded and executed a binary that could provide system access. The campaign used the identity of a recognized community member and an established Slack workspace to support credential collection and malware delivery.

Each of these campaigns used impersonation through trusted collaboration workflows. The attackers relied on recognized identities, legitimate services and familiar business processes to obtain credentials or persuade victims to take actions that enabled identity compromise.

Persistence

In a more novel approach, attackers have misused trusted collaboration services to maintain their access after identity compromise. In a December 2025 intrusion investigated by CERT Polska, a threat actor modified compromised firewall-VPN appliances at a manufacturing company in Poland. The threat actor used the appliances’ built-in scripting mechanism to create weekly scheduled tasks. One script retrieved the password of a privileged identity, and another script modified security settings and disabled two-factor authentication for a privileged account. A third script used the appliances’ native Slack notification capability to send the results to a Slack channel under the threat actor’s control. This activity combined identity persistence and credential exfiltration with a legitimate SaaS integration. It also avoided the need for a separate exfiltration tool. The case demonstrates how attackers can misuse built-in appliance features and trusted collaboration services during post-compromise operations.

The firewall event in Figure 4 shows an example of a Slack webhook request, a similar communication method to the one described in the CERT Polska report. The request used HTTP POST to hooks.slack[.]com with a curl user agent. The example event below is not malicious.

A screenshot of a desktop screen displaying two overlapping windows. The top window is a terminal displaying a cURL command to send a JSON payload with the text "Hello, World!" to a Slack webhook. The bottom window is Wireshark's "Follow HTTP Stream" feature, displaying HTTP request details for the Slack API.
Figure 4. Webhook firewall event.

Perimeter firewalls provide valuable visibility into webhook-related traffic exiting the organization. Many network and security appliances, including VPN appliances, operate behind a separate perimeter firewall and send outbound webhook requests through the enterprise egress path when configured for external alerting or automation. Security teams should review unexpected Slack webhook traffic, uncommon user agents and webhook activity from systems without an approved Slack integration. This type of activity should also be flagged in Microsoft Teams, which supports similar incoming webhook workflows for posting messages from external services.

These examples of initial access, impersonation and persistence demonstrate how attackers leverage trusted communication channels to support identity-focused attacks. Although the techniques differ, each example leverages legitimate platforms, authenticated identities or authorized communication paths to increase the likelihood of success. The common objective is to misuse the trust, access and identity context associated with enterprise collaboration platforms.

Defensive Measures for Securing Collaboration Platforms

Organizations should protect collaboration platforms with the same level of scrutiny applied to email and identity infrastructure. Because these platforms are integrated with enterprise identities, security controls should focus on both preventing identity compromise and detecting misuse after authentication.

Reduce Exposure

The first priority is reducing unnecessary exposure. Collaboration platform administrators should review external federation, guest access and third-party integrations to ensure they support legitimate business requirements. Where possible, limit external communications to trusted organizations, and implement a process to review guest accounts regularly and remove unnecessary access.

Comprehensive Identity Controls

Identity protections should also extend beyond authentication. MFA, conditional access and session risk evaluation help reduce the likelihood of account compromise, but they do not prevent an attacker from misusing a valid session. Security teams should monitor for behavior that could indicate identity compromise, including unusual messaging activity, unexpected file sharing or communications with unfamiliar external tenants.

Identity Verification Procedures

Identity and security teams should define and communicate verification procedures for security-sensitive requests received through collaboration platforms. Users should not approve MFA prompts, install remote access tools, share credentials, transfer files or modify access based only on a message. Instruct people to verify high-risk requests through an approved secondary channel, such as a known phone number, ticketing system or documented internal process.

User Awareness

User awareness remains an important part of effective verification procedures. People should treat collaboration messages, platform notifications and links to hosted content with the same caution as email. This is especially important when a request involves credentials, MFA approval, software installation, remote access tools or sensitive data.

Security training should make clear that content associated with an enterprise collaboration platform is not automatically trustworthy. An attacker can send a direct message, trigger a legitimate platform notification or use content hosted on an approved service to direct victims to a phishing site.

Security awareness teams should include these scenarios in phishing simulations and security awareness exercises. Many people recognize email phishing indicators but might not apply the same scrutiny to collaboration platforms and related notification workflows.

Active Monitoring

Security teams should incorporate collaboration platform telemetry into routine monitoring and incident response. Authentication logs, messaging activity, file sharing events and external tenant interactions provide valuable context for detecting identity abuse.

Network and security appliances should also be included in monitoring coverage. Firewalls, VPN appliances, load balancers and managed switches increasingly support automation, notification integrations and scheduled tasks. Attackers can potentially use these capabilities for malicious purposes following a compromise. To protect against such activity, security teams should monitor:

  • Administrative activity
  • Configuration changes
  • Outbound webhook usage
  • Unusual connections to collaboration or SaaS services

This telemetry should be ingested into a security information and event management (SIEM) system and correlated with identity, endpoint and collaboration platform data. This can improve visibility into malicious activity that might otherwise appear to originate from legitimate users or approved infrastructure.

Collaboration-based reporting must also be easy for users. Security teams should provide a clear process for reporting suspicious communications, notifications, hosted content and links associated with collaboration platforms. Each report should be triaged using identity telemetry, sign-in activity, endpoint alerts, file-sharing events and external tenant information. This helps to determine whether the activity reflects user error, external misuse or identity compromise.

Conclusion

Enterprise collaboration platforms are integrated with enterprise identity and access workflows. As organizations rely on these platforms for communication, attackers are exploiting the trust associated with authenticated users and sanctioned communication channels to conduct identity phishing, impersonation, credential theft and post-compromise operations.

Common security strategies have focused on protecting email and authentication systems. While these controls remain essential, they should be complemented by security measures that address collaboration platforms as part of the enterprise identity attack surface. Authentication alone is no longer sufficient to establish trust. Organizations must also understand how authenticated identities are communicating and recognize when trusted communication channels are being misused.

By extending identity security to include collaboration platforms, defenders can better detect identity abuse, reduce opportunities for compromise and strengthen their ability to respond to identity-focused attacks. As collaboration technologies evolve, organizations should monitor and protect them with the same controls they apply to other critical identity infrastructure.

Palo Alto Networks Protection and Mitigation

Palo Alto Networks customers are better protected from the threats discussed above through the following products:

  • Cortex XDR and XSIAM help to prevent the threats described in this article, by employing the Malware Prevention Engine. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection and the Local Analysis module, to prevent both known and unknown malware from causing harm to endpoints.
  • Idira Endpoint Privilege Manager (EPM) can enable enterprises to reduce risk, satisfy compliance, and streamline operations. It can help implement least privilege via policy-driven elevation and removal of standing admin rights, and block risky actions, such as execution of unvetted applications and access to memory of other processes, while providing audit-ready evidence.
  • Idira Secrets Manager centralizes the API keys, service account passwords, and webhook tokens that appliances, scheduled tasks, and pipelines depend on, so automation retrieves credentials at runtime instead of reading them from local scripts or device configuration. Automated rotation shortens the window in which a stolen credential stays valid, and universal workload identity replaces static credentials with short-lived SPIFFE-based workload identities where the environment supports it.
  • Idira Privileged Access Management (PAM) helps unify privileged access across human, machine, and agentic identities to secure cloud access across multi-cloud environments. Building on proven PAM, it delivers centralized secrets management alongside modern controls like Just-in-Time access and Zero Standing Privileges. This enforces consistent least-privilege security across on-premises, cloud, and SaaS targets.
  • Idira Secure Infrastructure Access (SIA) can help enforce Zero Standing Privileges (ZSP) through Just-in-Time (JIT) provisioning which grants temporary, tightly scoped access only as needed. Backed by continuous session recording and real-time command monitoring, SIA can detect high risk actions before an attacker compromises critical systems.
  • Idira Secure Cloud Access (SCA) can help enforce Zero Standing Privileges (ZSP) across multicloud environments by applying Just-in-Time (JIT) access controls to cloud consoles, command-line interfaces (CLIs), and the modern cloud infrastructure where workloads reside, including Managed Kubernetes clusters and elastic cloud workloads.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
  • UK: +44.20.3743.3660
  • Europe and Middle East: +31.20.299.3130
  • Asia: +65.6983.8730
  • Japan: +81.50.1790.0200
  • Australia: +61.2.4062.7950
  • India: 000 800 050 45107
  • South Korea: +82.080.467.8774

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Additional Resources

Threat Hunting Query

The query below is designed to help Palo Alto Networks customers hunt for, investigate and identify potentially suspicious activity using Cortex XDR. Results returned by this query should not be considered inherently malicious and require further analysis to determine their significance.

Query to Identify Collaboration Tool Spawning a Shell

This XQL query can help to identify where legitimate collaboration platforms — specifically Slack or Teams in this example — are used to execute system shells. The query inspects both the direct process hierarchy and the broader causality chain. It identifies instances where a collaboration tool is either the immediate parent process or an ancestor process that initiated the execution of a shell. Analysts can use this logic to identify:

  • Post-exploitation activity
  • Unauthorized command execution
  • Living-off-the-land techniques that originate from compromised user accounts or application integrations

The query can be modified to search for additional collaboration platforms or system shells.

Threat Brief: Mitigating Large-Scale Credential Attacks (Updated August 18)

Posted on by Unit 42

Executive Summary

Identity has effectively become the new perimeter, where cybercriminals are increasingly choosing to log in rather than break in. To accomplish this, attackers frequently gather previously leaked username and password pairs. Gathering these credentials can then allow them to pivot to password spraying against services exposed to the internet, gaining credentials for other products and services.

As this sort of attack occurs frequently, this article will be a resource repository of the following information about these attacks:

  • Details of noteworthy large scale credential attacks 
  • Actionable guidance for mitigating these attacks

TheHatman Attack

  • The Hatman attack: In August 2026, the actor TheHatman claimed to have stolen large volume of credentials from organizations' Microsoft Entra tenants

FortiBleed Attack

  • Fortibleed Credential Campaign: In June 2026, there was a large-scale password spraying campaign targeting Fortinet devices

Unit 42 recommends auditing remote access logs for suspicious activity with a focus on successful logins shortly after large volume password failure events. We also recommend reviewing and implementing the hardening guidance in this article for edge devices. 

Palo Alto Networks customers are better protected from this activity through our products and services, such as:

The Unit 42 Incident Response team can also be engaged to help with a compromise or to provide a proactive assessment to lower your risk.

Related Unit 42 Topics Fortibleed, Credential Theft

Activity From TheHatman

From Aug. 1–Aug. 17, 2026, an actor using the handle "TheHatman" made posts across multiple forums offering to sell employee information for multiple enterprises. TheHatman allegedly exfiltrated from organizations' Microsoft Entra tenants. While TheHatman has claimed this data was stolen using compromised credentials, we have been unable to verify a specific intrusion vector.

This activity was publicly reported as early as Aug. 16, 2026, and we have offered initial guidance through social media.

TheHatman claims to have sensitive or confidential information from several high-profile organizations, and this actor has claimed that they used compromised credentials through MFA fatigue and password spraying attacks to gain unauthorized access to these organizations. Unit 42 has not verified these claims.

FortiBleed Campaign

A large-scale password spraying and credential theft campaign (“FortiBleed”) against Fortinet devices was initially disclosed in June 2026. We observed attempts targeting MSSQL devices as well, and have seen reports of Sophos devices also being targeted. While this activity is not targeting Palo Alto Networks devices, we have blocked suspicious login attempts in customer telemetry.

The attackers have used a curated password list to attempt password spraying against services exposed to the internet. We assess that the initial password list for this activity was likely developed through a mix of previous breaches, including the successful exploitation of vulnerabilities. Once the attackers obtain credentials, they add them to their password list for future attempts against additional targets, as well as for logging into accounts they successfully compromised.

The attackers have leveraged a multi-stage process to gain persistent, high-privilege access:

  • Password spraying for initial access: Massive internet-wide scanning and password spraying attempts against Fortinet, Sophos and MSSQL services
  • Configuration extraction: Depending on the permissions of their initial access, the actor could exploit a privilege escalation vulnerability prior to pulling device configuration files, including stored credentials
  • Offline Cracking: Offline password cracking of the stolen credentials adds to the password list used in step one to target new devices, as well as to log into compromised devices to establish persistence as an administrator

We observed an initial access broker (IAB) on the Russian-language cybercrime forum Exploit[.]in claiming responsibility for this campaign, referencing a CVE (no further information), and offering the harvested credentials for sale on June 16, 2026. We have not validated their claims at this time.

Unit 42 observed an initial access broker (IAB) on the Russian-language cybercrime forum Exploit[.]in claiming responsibility for this campaign of large-scale credential attacks, referencing a CVE (no further information), and offering the harvested credentials for sale on June 16, 2026. Unit 42 has not validated their claims at this time.
Figure 1. Darkweb post of IAB selling credentials.
SOCRadar provided the initial reporting on the targeting of FortiGate devices. We observed attempts targeting MSSQL devices as well, and have seen reports of Sophos devices also being targeted.

Interim Guidance

Unit 42 recommends auditing remote access logs for suspicious activity with a focus on successful logins shortly after large volume password failure events. We also recommend reviewing and implementing the hardening guidance below for edge devices.

Palo Alto Networks customers receive assistance protecting against and mitigating credential attacks in the following ways:

Palo Alto Networks also recommends the following hardening guidelines:

  • Require MFA: Require strong phishing-resistant multi-factor authentication for all remote services. NGFW customers can integrate several MFA platforms   (including Palo Alto Networks Idira MFA) and customize their Password Profiles and complexity to enhance their security posture.
  • Adopt zero trust architecture: Leverage “jump boxes” and Zero Trust Network Access (ZTNA) policies to ensure management interfaces are never exposed directly to the public internet, further narrowing the attack surface for configuration extraction.
  • Change default credentials: Change the credentials for default accounts, ensuring long, complex passwords are used to mitigate the risk of password guessing attempts. Ideally onboard accounts to Privileged Access Management system and rotate passwords automatically on-time and on-use.
  • Implement ITDR: Timely detect malicious access attempts and accelerate response with automated identity-centric actions.
  • Disable unused accounts: Run continuous discovery of privileged accounts. Onboard and disable unused accounts to limit the attack surface.
  • Update and patch: Ensure you have the latest software versions and patches installed to mitigate known vulnerabilities, including local privilege escalation vulnerabilities.

The Unit 42 Incident Response team can also be engaged to help with a compromise or to provide a proactive assessment to lower your risk.

Conclusion

We continue to monitor our threat landscape for this and other identity-based attacks. We encourage customers to implement the hunting and hardening recommendations to identify, mitigate, and prevent credential attacks against their networks.

Palo Alto Networks has shared our findings with our fellow Cyber Threat Alliance (CTA) members, including Fortinet. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Palo Alto Networks customers are better protected by our products, as listed below. We will update this threat brief as more relevant information becomes available.

Palo Alto Networks Product Protections For Large-Scale Credential Attacks

Palo Alto Networks customers can leverage a variety of product protections and consulting services to identify and defend against this threat.

If you think you might have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
  • UK: +44.20.3743.3660
  • Europe and Middle East: +31.20.299.3130
  • Asia: +65.6983.8730
  • Japan: +81.50.1790.0200
  • Australia: +61.2.4062.7950
  • India: 000 800 050 45107
  • South Korea: +82.080.467.8774

Deep and Darkweb Monitoring

Unit 42's Deep and Dark Web (DDW) monitoring is a service that assists clients in identifying sensitive information and leaked credentials that surface on the dark web, providing critical insights to reduce risk exposure and reduce the time between detection and response.

Cortex Cloud

Cortex Cloud Identity Security encompasses Cloud Infrastructure Entitlement Management (CIEM), Identity Security Posture Management (ISPM), Data Access Governance (DAG) as well as Identity Threat Detection and Response (ITDR) and provides clients with the necessary capabilities to improve their identity related security requirements. By providing visibility into cloud based identities, and their permissions, Cortex Cloud can detect misconfigurations, unwanted access to sensitive data and real-time analysis surrounding usage and access patterns. Additionally, Cortex Cloud provides protections against credentials that were compromised, lost or exposed being leveraged against cloud resources, such as those discussed within this article.

Idira Identity Threat Protection

Idira Identity Threat Protection enables security teams to counter identity-based attacks targeting Idira Next Generation Identity (NGI) Platform and the identities it secures. Using near real-time detection, powered by CORA AI, and leveraging Idira’s visibility across multiple contexts (like PAM, authentication, SSO, cloud, endpoints, browsers, and more), Idira ITP can apply automated, tailored non-disruptive in-session response to contain and minimize potential identity-based threats.

Idira Multi-Factor Authentication

Idira Multi-Factor Authentication helps protect organizations against password spraying, credential theft, and other identity-based attacks by verifying that the person signing in is the legitimate user, not just someone with a valid password. Using phishing-resistant MFA, including passkeys, biometrics, and FIDO2 security keys, along with adaptive, risk-based authentication, Idira evaluates signals such as device trust, location, and login behavior. When risk is detected, it requires additional verification before granting access, helping prevent account compromise while keeping access simple for trusted users.

Idira Privileged Access Management

Idira Privileged Access Management is a SaaS-delivered Privileged Access Management (PAM) solution that mitigates credential compromise and password spraying by prioritizing automated discovery, onboarding, and rotation. The platform continuously scans hybrid environments and infrastructure to detect unmanaged local, domain, service accounts and cloud roles. Discovered credentials are automatically onboarded into a hardened digital vault for centralized management. Privilege Cloud then enforces programmatic transactional credential rotation using complex, randomized strings. This eliminates the static, predictable passwords exploited during spraying attacks, removing standing privileges and blocking lateral movement across the network infrastructure and devices.

References

Updated June 26, 2026 at 1:00 p.m. PT to add product protection for Idira Security and Cortex Cloud, and more information to the hardening guidelines section.

Updated August 18, 2026 at 1:30 p.m. PT to add information about TheHatman attack. 

Kimwolf v7: An Evolution of the Kimwolf Botnet

Posted on by Asher Davila

Content Warning

We are providing a content warning because the following article contains usage of a racial slur by a threat actor, which Unit 42 does not condone in any instance. We have partially redacted the racial slur, but preserved some references to it in order to provide researchers with the ability to identify it and check IoCs as needed.

Executive Summary

We identified a new version (v7) of the Kimwolf Android/internet-of-things (IoT) botnet. This version upgrades its distributed denial-of-service (DDoS) attack capabilities and the resilience of its command-and-control (C2) infrastructure. Kimwolf primarily affects Android TV boxes and set-top boxes.

Kimwolf v7 adds an HTTP/2-based DDoS flood that constructs complete browser fingerprints. This makes attack traffic more difficult to distinguish from legitimate browsing.

The threat’s binary includes five hard-coded public Ethereum-based endpoints for resolving Ethereum Name Service (ENS) domains. ENS is a blockchain-based naming system used to obtain C2 addresses.

Kimwolf also carries a hard-coded Tor .onion hidden service as a backup and a local proxy architecture for flexible routing between clearnet and Tor. The malware developers added this function to directly respond to C2 server takedown efforts in December 2025.

We discovered this variant on Feb. 3, 2026, through threat hunting that followed public disclosures by XLab, Synthient, Infoblox, Cloudflare and others.

Palo Alto Networks customers are better protected through the following products and services:

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Related Unit 42 Topics Malware, Botnet, DDoS

Background

The Kimwolf botnet (also tracked as AISURU) has been active since August 2024. It initially targeted Linux IoT devices under the AISURU name. The botnet transitioned to Android TV boxes around August 2025.

This reflects two separate codebases under the same operators. AISURU covers the Linux IoT variants, and Kimwolf covers variants targeting Android.

Kimwolf spreads by misusing residential proxy services to reach unauthenticated Android Debug Bridge (ADB) instances on local networks. Some Android TV boxes ship with ADB enabled on port 5555. Once attackers tunnel through a proxy endpoint into the local network, they can install the malware without any authentication.

Kimwolf Sample Overview

The Kimwolf sample we analyzed as a baseline is a statically linked ARM Executable and Linkable Format (ELF) binary. The file was compiled with the Android Native Development Kit (NDK) using Clang and uses Bionic libc. It statically links BoringSSL for Transport Layer Security (TLS) operations and nghttp2 for HTTP/2 functionality.

The binary is stripped but retains some symbol information. It is not uncommon for malware authors to use racial slurs in their code. The Kimwolf malware family has historically included racial slurs. In our discussion of the v7 variant, we have partially redacted these slurs, but have left enough information present that defenders could identify the variant and check for IoCs.

Previous Kimwolf builds used the internal version strings such as n[redacted]boxv4 and n[redacted]boxv5, establishing the naming pattern for the family. The version string n[redacted]boxv7, shown in Figure 1, identifies this sample as version 7. The binary creates a Unix domain socket @n[redacted]boxv7 to ensure only one instance runs at a time. 

A screenshot of a hexadecimal code in columns, with highlighted values in orange and yellow on the left. The visible ASCII values on the right are lowercase letters "b", "o", "x", and the digit "7".
Figure 1. The n[redacted]boxv7 version string.
On execution, the malware masks its process name as netd_service to blend in with legitimate Android system processes.

We identified six ELF samples that we clustered together based on multiple indicators:

  • They share an identical ELF section layout produced by a common Android NDK build environment, and the same hard-coded set of Ethereum remote procedure call (RPC) endpoints
  • Overlapping C2 infrastructure within the same hosting provider
  • Consistent process-name masquerading behavior

HTTP/2 Flood with Browser Fingerprint Spoofing

One of the most notable new capabilities in Kimwolf v7 is an HTTP/2 flood powered by the nghttp2 library. The function that performs the attack_case17_http2_flood constructs complete browser fingerprints. ​​This makes the flood traffic difficult to distinguish from legitimate browser requests.

Figure 2 shows the header construction logic in the decompiled binary.

A screenshot of code in a development environment. The code is written in a dark-themed editor and contains various programming elements, such as functions, variables, and libraries. Mentions of "Google Chrome" and "Safari" are visible in the code.
Figure 2. Fingerprint header construction in build_http2_attack_headers.

Three-Tier C2 Infrastructure

Kimwolf v7 uses a layered C2 resolution system designed to survive the domain takedowns that disrupted the botnet twice in December 2025.

This isn't the last time operation of this malware faced disruption. On March 19, 2026, the U.S. Justice Department and international partners announced a court-authorized operation that seized C2 infrastructure used by the Aisuru, KimWolf, JackSkid and Mossad botnets.

Ethereum Name Service Resolution

The binary contains five hard-coded public Ethereum RPC endpoints stored in plaintext, shown in Figure 3:

  1. hxxps[:]//0xrpc[.]io/eth
  2. hxxps[:]//eth.llamarpc[.]com
  3. hxxps[:]//ethereum-rpc.publicnode[.]com
  4. hxxps[:]//eth-protect.rpc.blxrbdn[.]com
  5. hxxps[:]//eth.merkle[.]io
A screenshot of a code snippet showing allocation of strings to different variables. Each variable is assigned a URL from various platforms.
Figure 3. Hard-coded public Ethereum RPC endpoints.

These endpoints are legitimate public Ethereum RPC services. The malware misuses them to query ENS domain records and resolve C2 addresses. Organizations should monitor for unusual Ethereum RPC traffic from IoT and Android devices rather than blocking these endpoints outright.

The malware shuffles these endpoints using a pseudo-random number generator (PRNG) before each resolution attempt. The five-way redundancy makes blocking ENS-based C2 resolution harder.

Operator RPC Facade

While the five public RPC endpoints in the baseline binary are third-party services, our infrastructure investigation identified a sixth endpoint that we assess with moderate confidence to be under the operator's control: eth[.]rpcuniverse[.]com.

Several properties distinguish it from the legitimate providers:

  • The legitimate endpoints are established services with significant traffic and resolve to multiple anycast IP addresses across major cloud delivery network (CDN) and cloud providers
  • They have apex domains registered between 2005 and 2022
  • The rpcuniverse[.]com domain has no global traffic ranking
    • It resolves to a single IP address on a low-cost virtual private server (VPS) that was registered on Dec. 12, 2023
    • Its TLS certificate first appeared on the hosting IP address days later
    • Reverse passive DNS shows the IP address hosts only rpcuniverse[.]com subdomains with no other tenants
  • Two Kimwolf samples hardcode eth[.]rpcuniverse[.]com as an additional RPC endpoint alongside the five legitimate providers
    • Both ELF and Android APK variants contact the hosting IP address directly
    • We did not observe this direct-to-IP address contact pattern with any of the legitimate RPC endpoints

We cannot confirm domain ownership. However, the dedicated single-tenant hosting, the timing of its registration relative to Kimwolf activity and its exclusive presence in Kimwolf binaries suggest it is an operator-controlled facade rather than a public service.

Tor Hidden Service Backup

When ENS resolution fails, the v7 binary falls back to a hard-coded v3 Tor .onion address (edctgwib2n5l34t525zkxqzk5bqb6e5il2yiq5r6zu7gtlxa4uosn3qd[.]onion). Figure 4 shows the hard-coded address in the binary.

A screenshot of a code snippet displayed in a text editor, showcasing a function related to building and sending SOCKS CONNECT requests to hidden services. The code includes C++ elements such as variables, hex codes, and the construction of a domain name with ".onion" at the end. The text is color-coded to differentiate elements like functions, operators, and comments.
Figure 4. Hard-coded .onion address.

A function (tor_proxy_state_machine) manages the protocol states. To do this, it performs the following activities:

  • Sending the greeting (0x05 0x01 0x00)
  • Building a CONNECT request with domain type 0x03 and the 62-byte .onion address
  • Waiting for the response and performing a TLS handshake over the tunnel

Figure 5 shows the greeting and TLS handshake states.

A screenshot of computer code in a programming environment. The code includes socket programming and comments related to network communication. The code is shown in multiple colors, likely indicating syntax highlighting, with sections in black for code, orange for comments, and some red highlighting.
Figure 5. Greetings.

Additionally, it uses a local proxy architecture. All C2 traffic routes through a local proxy at 127.0.0[.]1:23075 shown in Figure 6, regardless of whether it is destined for clearnet or Tor. This modular design allows the proxy component to be updated independently from the main bot binary. ​​

A screenshot of a code snippet showing a function definition related to a SOCKS5 proxy with specific values and addresses. The code includes comments and standard programming syntax elements like variables, operators, and function calls.
Figure 6. Local proxy connection.

C2 Infrastructure Clustering

Analysis of Kimwolf v7 samples revealed C2 connections to several IP addresses, including:

  • 212.193.31[.]119 and 212.193.31[.]122 on TCP port 13
  • 212.193.31[.]92 and 212.193.31[.]158 on TCP port 443

None of these IP addresses had prior indicators of malicious activity or associations with public threat intelligence.

During infrastructure analysis, we observed that these hosts presented the same SSH host key. Pivoting on that shared key revealed 22 total IP addresses within the same range, presenting the identical key between Dec. 18, 2025, and Feb. 3, 2026. No hosts outside this range shared the key.

IP address 212.193.31[.]102 was the first host observed with this key on Dec. 18, 2025, and it was the seed from which the configuration propagated. The remaining 21 hosts appeared over the following six weeks, with the last addition on Jan. 31, 2026. All 22 hosts reside in AS202799, geolocated to Saint Petersburg, Russia.

High-Performance UDP Flood

Kimwolf implements a dedicated high-performance UDP flood function that uses a Xorshift256 PRNG seeded from /dev/urandom. It (prng_seed_from_urandom) reads 32 bytes (four 64-bit state words) to initialize the full 256-bit state. A SplitMix64 fallback initializer activates if /dev/urandom is unavailable.

The flood function accelerates IP/UDP checksum computation with ARM NEON single instruction, multiple data (SIMD) instructions. The vectorized checksum loop processes four 16-bit halfwords simultaneously using VLD1.16, VADDW.U16 and VADD.I32 instructions.

This optimization is tailored for the ARM processors found in Android TV boxes. It reduces per-packet checksum overhead to maximize throughput.

Figure 7 shows the NEON SIMD instructions in the disassembled binary.

A screenshot of assembly code from a disassembler tool. The code includes instructions such as ADD, LDR, BIC, and VADD, along with memory addresses and registers. It contains comments referencing "NEON SIMD checksum computation" with labeled sections.
Figure 7. NEON SIMD instructions.

Complete Attack Method Inventory

The dispatch table supports 15 DDoS methods across Layers 3–7 of the Open Systems Interconnection (OSI) model. Cases 8, 11 and 13 are absent from the switch statement, suggesting they are either reserved for future use or were removed during consolidation from the 43 text-named methods in prior versions.

Table 1 lists all 15 attack methods.

Case number Function Description
0 attack_case0_tcp_socket_flood TCP socket-based flood
1 attack_case1_udp_flood_v1 UDP flood variant 1
2 attack_case2_game_server_udp Game server UDP flood (port 27015)
3 attack_case3_dns_flood DNS query flood
4 attack_case4_udp_flood_v2 UDP flood variant 2
5 attack_case5_tcp_syn_flood TCP SYN flood
6 attack_case6_tcp_ack_flood TCP ACK flood
7 a​​ttack_case7_tcp_synack_flood TCP SYN-ACK flood
9 attack_case9_udp_async_flood Asynchronous UDP flood
10 attack_case10_tcp_rst_flood TCP RST flood
12 udp_flood_attack High-performance UDP flood (NEON SIMD)
14 attack_case14_icmp_flood ICMP flood
15 attack_case15_tcp_connection_flood epoll-based TCP connection flood
16 attack_case16_tls_https_flood TLS/HTTPS flood (BoringSSL)
17 attack_case17_http2_flood HTTP/2 flood with Chrome fingerprints (nghttp2)

Table 1. Kimwolf v7 DDoS attack methods.

What Changed From Prior Versions

In Kimwolf v7, malware authors consolidated the attack count to 15 numbered methods. They removed all scanning, exploitation and brute-force functionality. The new additions target:

  • DDoS stealth through HTTP/2 with browser fingerprinting
  • C2 resilience through ENS, Tor and the local proxy

The removal of the scanner and exploit modules suggests the operators have separated the propagation pipeline from the DDoS bot. External loaders now handle initial access while the Kimwolf binary handles attacks and proxy relay.

The earliest dropped sample, targeting the x86 architecture with a Dirty COW exploit, suggests the family evolved from traditional Linux exploitation toward the current ADB-based Android propagation model. The transition from libn[redacted]kernel.so to the less conspicuous libdevice.so filename in November 2025, followed by a revert in December, indicates active operational security adjustments.

Android APK Variants

Alongside the standalone ELF payloads, the Kimwolf operators distribute Android APK packages that bundle an ELF kernel payload inside a Java wrapper. We identified eight APK samples spanning October through December 2025, all sharing the component class systemservice0644.N[redacted]Kernel.

These APKs masquerade as a system service called SystemService. On execution, they probe for root access and execute the embedded ELF kernel with commands shown below in Figure 8.

A screenshot of a computer terminal displaying two command lines related to a system service.
Figure 8. Commands used to execute the embedded ELF kernel.

The earliest build (October 2025) used the com. Android prefix and bundled three kernel variants in a single APK. By late October, the package name shifted to com.n2.systemservice0644, and the kernel was consolidated to a single binary. In November, the kernel filename changed from libn[redacted]kernel.so to libdevice.so, then reverted in the December builds.

Three signing certificates appear across the cluster:

  • The original Kimwolf APK certificate (C=CN, CN=a) used by the com.android.logcatd variants
  • An Android Debug certificate used during development
  • A self-signed certificate with subject C=XK, ST=lol, L=lol, O=lol, OU=lol, CN=lol (country code XK for Kosovo, all other fields set to lol) used by five of the eight N[redacted]Kernel APK files

Dropped ELF Kernel Payloads

The APK wrapper drops one of three ELF kernel payloads, depending on the build. These are listed in Table 2.

SHA256 Hash Filename Architecture
9470c68f9b6fe5f90d61891b95623afd7b4298815b0f95e25610e1c09008dc24 libn[redacted]kernel.so ARM
8242443dfcec66e3fe04cbfa2fbd211ad34065ee07aa93813d792a437caab212 libdevice.so ARM
421111a57b0a4224c052fa4108d90429d579974b5b5111ed2e58516ba09422ca libn[redacted]kernel.so (v1) x86

Table 2. Dropped ELF kernel payloads.

The earliest sample (first seen Sept. 2, 2025) is notable for two reasons:

  • It targets x86 architecture rather than ARM
    • This indicates that the botnet originally targeted x86 Linux systems before pivoting to ARM-based IoT and Android devices
  • It drops a file named libcow.so, and renames its process to inetd to blend in with Unix network services
    • The name libcow.so is likely a reference to the Dirty COW privilege escalation vulnerability (CVE-2016-5195)

The libdevice.so sample renames its process to TVHelper, which explicitly targets Android TV set-top boxes by mimicking a legitimate TV helper service.

Neither the libn[redacted]kernel.so nor libdevice.so kernels embed the Ethereum RPC endpoints found in the standalone ELF builds. The C2 resolution layer resides in the outer APK wrapper or the standalone ELF binary, while the kernel handles lower-level bot operations.

Conclusion

Kimwolf v7 is a focused evolution of an already large-scale botnet. The HTTP/2 flood with Chrome browser fingerprinting complicates application-layer DDoS mitigation, as attack traffic now mirrors legitimate browser behavior at the protocol and header level.

The three-tier C2 system (Ethereum ENS, Tor .onion, local proxy) indicates that the operators are investing in infrastructure built to withstand takedown operations. Organizations should monitor for the following behavioral indicators of Kimwolf compromise on IoT and Android devices:

  • Outbound HTTPS connections to public Ethereum RPC endpoints (e.g., 0xrpc[.]io) from devices that typically do not interact with blockchain services
  • Tor circuit establishment or SOCKS5 proxy traffic from Android TV boxes or IoT devices
  • Connections to port 23075 on localhost
  • A process named netd_service running on consumer Android devices

Organizations should treat Android TV boxes as untrusted and segment them from enterprise networks. Disabling ADB or restricting it to USB-only access removes the primary propagation vector for this botnet.

Palo Alto Networks customers are better protected through the following products and services:

  • The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research,
  • Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious.
  • Device Security is designed to proactively protect the entire device attack surface, from IT to IoT and OT, with a unified platform that helps deliver comprehensive visibility, actionable risk insights and adaptive security enforcement.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
  • UK: +44.20.3743.3660
  • Europe and Middle East: +31.20.299.3130
  • Asia: +65.6983.8730
  • Japan: +81.50.1790.0200
  • Australia: +61.2.4062.7950
  • India: 000 800 050 45107
  • South Korea: +82.080.467.8774

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Indicators of Compromise

SHA256 hash: 406647de09a0ffa279756b4ccb344b1b76a333320c5b50fd367901fa006cf0ff
MD5 hash: d759364844d78a728505fb0485c3adbc
File size: 1,720,108 bytes
File type: ELF 32-bit LSB executable, ARM, statically linked, stripped
File description: Kimwolf v7 bot payload (baseline analyzed sample); version string n[recacted]boxv7

SHA256 hash: 345222bca004595977f971d76900b0c65fd9bf9d91c50cd0c5bf5a93f1ad9e49
MD5 hash: 036bcb62be72c4663b9564955f93b05f
File size: 1,712,624 bytes
File type: ELF 32-bit LSB executable, ARM, statically linked, stripped
File description: Kimwolf v7 bot payload

SHA256 hash: 2ec2e85b0358e0c681cb5067489a9086ec97dbbf7e3c952dd9cd496b319d5af5
MD5 hash: 33faca1e0090f6b12eff703daf4606e4
File size: 1,720,108 bytes
File type: ELF 32-bit LSB executable, ARM, statically linked, stripped
File description: Kimwolf v7 bot payload; hard codes eth.rpcuniverse[.]com in the binary

SHA256 hash: 951c94809aa6c7ab587125f9d4df30fa6a49ee0cbba76a4b7ceedaaa0e5dcd36
File type: Android APK
Package name: com.android.logcatd
File type: ELF 32-bit LSB executable, ARM, statically linked, stripped
File description: Kimwolf Android variant; masquerades as system logcat daemon; includes TorService and BootReceiver persistence; contacts 23.94.221[.]104

SHA256 hash: f07821e313c16cbbd82def45094a22c8d474164051bdbc7648d6869e012014b4
File type: Android APK
Package name: com.android.logcatd
File type: ELF 32-bit LSB executable, ARM, statically linked, stripped
File description: Kimwolf Android variant; sibling of the above, same signing certificate and package; contacts 23.94.221[.]104

VHash: 76554ad09897ac723a850eaf8c525efa
Description: Structural hash shared by the three Kimwolf v7 ELF samples (5 total matches across VirusTotal)

APK signing certificate (SHA-1 thumbprint): 2a1d96f1b066877812587ac94f45f82dfff5f5f9
Subject: C=CN, CN=a
Description: Self-signed certificate used to sign both Kimwolf Android samples

TLS certificate (SHA256 hash): f3e8a55a2a3ea7c7b6676e90f4f49a2c55b13065b68ee50c51cc35fe2b5c3237
Issuer: Let's Encrypt
Description: Certificate issued for eth.rpcuniverse[.]com, observed on 23.94.221[.]104 between Dec. 13, 2023, and March 12, 2024

Domain: rpcuniverse[.]com
Description: Multi-chain RPC service; apex registered Dec. 9, 2023 (Namecheap); resolves to 23.94.221[.]104; hard-coded subdomain present in Kimwolf sample

Domain: eth.rpcuniverse[.]com
Description: RPC subdomain hard-coded in Kimwolf sample 2ec2e85b...

Domain: avax.rpcuniverse[.]com
Description: RPC subdomain resolving to 23.94.221[.]104

IP address: 23.94.221[.]104
Description: Operator host (AS36352 RackNerd, Dallas); hosts rpcuniverse[.]com; contacted by Kimwolf ELF and APK samplesng

IP address:port: 212.193.31[.]158:443
Description: HTTPS C2 traffic (AS202799 SYSECT, Russia); offline after Jan. 31, 2026

IP address:port: 212.193.31[.]119:13
Description: C2 traffic

IP address:port: 212.193.31[.]122:13
Description: C2 traffic

IP address: 212.193.31[.]102
Description: C2 host (linked via shared SSH host key with .158

IP address:port: 212.193.31[.]92:443
Description: HTTPS C2 traffic (AS202799 SYSECT, Russia)

Tor hidden service: edctgwib2n5l34t525zkxqzk5bqb6e5il2yiq5r6zu7gtlxa4uosn3qd[.]onion
Description: v7 hidden-service C2 fallback

Additional Resources

Updated August 13 2026 at 2:00 p.m. PT to add information on the U.S. Justice Department and international partner operation seizing C2 domains used by KimWolf and related botnets.

Get the latest news, invites to events, and threat alerts

Default Heading

Read the article Right Arrow