Mac users have historically trusted their operating system to keep them safe. That peace of mind mostly comes from Apple’s strict control over its ecosystem, and the fact that macOS has historically faced fewer mass attacks than Windows. However, that doesn’t mean Macs are invulnerable: threats do exist, and new ones emerge all the time. Over just the past few weeks, security researchers have published reports on at least two new campaigns that target Apple devices.
The malware used in one of the campaigns has been dubbed CrashStealer, while the other is known as ClickLock. Both rely on different tricks to force users into entering their Mac password, which attackers then use to steal account credentials, crypto assets, documents, and much more. In today’s post, we take a close look at how CrashStealer operates — and how to avoid falling victim to it.
A videoconferencing app with CrashStealer inside
It was back in May 2026 that researchers spotted the first signs this malware was being developed, and by early July, they caught it operating in the wild. The malware earned its name because of its core mechanism: it disguises itself as the macOS built-in crash reporting tool (CrashReporter) while functioning as an infostealer designed to hijack sensitive data.
Researchers managed to trace one of the websites users visited to download the malware. The site poses as a legitimate platform for distributing the video conferencing tool Werkbit.
According to researchers, this is the site victims used to download Werkbit, which secretly contained the CrashStealer malware loader. Source
However, you can’t just visit the site and download the software. Before downloading, visitors are asked to enter a special meeting PIN. This setup likely allows the attackers to limit the distribution scope by targeting only specific, pre-selected victims. Exactly how the cybercriminals choose their targets and deliver the PIN remains unknown.
The “lucky” users with a code end up installing the initial malicious payload — named Werkbit Setup. Interestingly, it carries a valid Apple developer certificate and has successfully passed Apple’s notarization process — meaning it cleared the automated prescan for malicious code. As a result, the attackers manage to bypass the operating system’s built-in Gatekeeper defense. This allows the payload to launch without triggering the usual untrusted software warnings.
The Werkbit Setup installer is signed with a valid Apple developer certificate and has passed notarization. Source
Once launched, Werkbit Setup first reaches out to GitHub. Researchers believe using this popular platform helps attackers blend in by making these initial network requests look far less suspicious to security tools. After retrieving instructions from a GitHub repository, the program connects directly to the attackers’ server to fetch CrashStealer itself.
The loader then saves the malware to a temporary macOS folder, launches it, and wipes most of the intermediate setup files. As a result, a fully functional infostealer is up and running within seconds of Werkbit Setup starting. By the way, the user never gets any videoconferencing app.
How CrashStealer works
Unlike the Werkbit Setup loader, the CrashStealer malware itself isn’t signed with an Apple developer certificate. To keep users from suspecting anything, the malware disguises itself as the built-in macOS crash reporting tool, CrashReporter, by using the exact same name, app identifier, and a similar icon.
Once launched, CrashStealer completes a sequence of steps to gain access to sensitive data, establish persistence in the system, and cover its tracks:
Remove metadata — including the attribute that flags the app as an internet download.
Display a fake system prompt asking for the user’s macOS password.
Use the previously captured credentials to gain access to Keychain, the built-in macOS password manager.
Check the computer for installed security tools and malware analysis software.
Collect saved browser passwords, cookies, Keychain contents, and data from other password managers and crypto wallets.
Encrypt the data it stole and prepare it for forwarding to the attackers’ server.
Create a copy of itself and establish persistence to launch automatically every time macOS boots.
Delete temporary files and other installation traces to make detection much harder.
Step two deserves a closer look. The password prompt that the user sees looks extremely convincing. What’s more, the malware immediately verifies whether the credentials are correct: if you make a typo and enter an invalid password, CrashStealer will pop the window right back up to ask you again.
Once launched, CrashStealer displays a pop-up that mimics the standard macOS password request. Source
What data is CrashStealer after?
CrashStealer’s hit list is massive. First and foremost, its operators target Keychain: the built-in macOS password manager where the system stores account credentials, cryptographic keys, certificates, tokens, and more.
Users of third-party password managers aren’t safe either: the malware steals data from 14 of these services, including 1Password, Bitwarden, LastPass, Dashlane, Keeper, KeePassXC, NordPass, Enpass, and RoboForm.
In addition, the malware collects all credentials and cookies stored in Chromium-based browsers — Chrome, Brave, Edge, Opera, Opera GX, Vivaldi, Chromium, and NAVER Whale — as well as Firefox. The attackers clearly have a strong interest in crypto assets: CrashStealer specifically targets data from 80 different crypto wallet extensions, including MetaMask, Phantom, Coinbase Wallet, Trust Wallet, Rabby, Exodus, Keplr, and Solflare.
Finally, the malware scans the Documents and Downloads folders to pick files that might be of interest to the cybercriminals. CrashStealer encrypts all the stolen data with the AES-256-GCM algorithm, ZIP’s it up, and sends it to the attackers’ server.
How to protect your device
The spike in attacks on macOS is a clear wake-up call: Apple users need to get proactive about their security. We recommend:
Researching apps online before installing them
Sticking to utilities from official app stores whenever possible
Using a reliable security solution that blocks malicious websites and stops malware activity on your device
Kaspersky security solutions detect the malware described in this post and assigns to it the verdicts HEUR:Trojan-Downloader.OSX.Agent.gen and HEUR:Trojan-PSW.OSX.Agent.gen.
Since early May 2026, Microsoft Threat Intelligence has observed Storm-2945, a sub-cluster of Midnight Blizzard, conducting widespread but targeted traffic manipulation attacks involving hospitality sector networks served by captive portals worldwide. Despite some tactic, technique, and procedure (TTP) similarities to the Forest Blizzard DNS hijacking operation that we publicly disclosed in April 2026, we attribute this campaign, which we call CaptiveCrunch, to Storm-2945. As reported by ReliaQuest on July 23, a portion of this activity leverages doppelganger domains mimicking Microsoft online services to conduct follow-on adversary-in-the-middle (AitM) phishing operations that abuse the device code authentication flow in Microsoft Entra ID. Microsoft Threat Intelligence has also identified active traffic manipulation attacks leading to the delivery of malware on impacted systems. Microsoft has observed Storm-2945 leveraging AI to support a significant portion of these operations.
Today, we are sharing our findings on these ongoing intrusions to raise awareness of this threat and enable customers to protect their devices, especially while traveling. We provide our assessment of Storm-2945’s relationship to Midnight Blizzard and analysis of the CaptiveCrunch campaign, detailing the malware and tradecraft used in these operations. We also provide mitigation, detection, and hunting guidance to help organizations identify and defend against Storm-2945 and related activity.
Microsoft Threat Intelligence would like to thank our partners at Anthropic and OpenAI for their collaboration and support during this investigation.
The CaptiveCrunch campaign
Since February 2026, Storm-2945 has conducted AI-augmented operations including targeted device code and OAuth code phishing campaigns leading to Entra device registration and subsequent data collection from Microsoft 365. Since early May 2026, Microsoft Threat Intelligence has observed Storm-2945 manipulating DNS and HTTP traffic from networks served by captive portals to redirect user traffic through actor-controlled infrastructure. Although our investigation into the initial compromise vector for the captive portal networks is ongoing, we have observed notable commonalities in the equipment and management systems used across multiple affected networks. These similarities suggest that the activity might not be limited to isolated compromises of individual venues and could reflect access to shared services within portions of the captive portal ecosystem.
Figure 1. Overview of the CaptiveCrunch attack flow
As part of the CaptiveCrunch campaign, Storm-2945 has leveraged their AitM position to redirect users through actor-controlled phishing infrastructure and has also delivered malware purporting to be browser or operating system updates in response to automated connectivity checks issued by users’ browsers. Multiple variants have been delivered, including fully-featured Windows remote access trojans (RAT) in compiled Golang, with functionality to conduct system enumeration, collect files and keystrokes, steal credentials and session tokens, conduct audio and video surveillance, monitor for removable media, and provide the threat actor a remote shell on infected systems.
The threat actor infrastructure leverages a variety of ClickFix techniques to elicit the user into downloading and executing the malware:
Figure 2. ClickFix prompt with manual user instructionsFigure 3. ClickFix prompt with additional user instructions after verification failure
In addition to variants of malware targeting Windows systems, Microsoft Threat Intelligence is also aware of indications that the threat actor might be targeting Android devices with similar techniques as the ClickFix landings also include instructions for Android devices to download and install an APK file.
To date, Microsoft has identified widespread compromise of Wi-Fi networks at hospitality-related organizations and other networks serviced by captive portal equipment in several countries. ReliaQuest has identified this activity not only at hotels, but also conference centers and other shared venues, and assesses that the goal of this activity is to access the accounts of corporate travelers.
Storm-2945 and Midnight Blizzard
Microsoft Threat Intelligence assesses that Storm-2945 is an operational sub-cluster of Midnight Blizzard based on distinctive technical and operational overlaps. These include technical similarities to Storm-2372, a Midnight Blizzard initial access operations sub-cluster, also notable for their device code and OAuth code phishing operations tracked throughout 2025, Microsoft Graph-based email exfiltration, social engineering delivered via commercial messaging apps, and significant similarities in victimology.
Midnight Blizzard is a Russia-based threat actor attributed by the US and UK governments to the Foreign Intelligence Service of the Russian Federation, also known as the SVR. This threat actor is known to primarily target governments, diplomatic entities, non-governmental organizations (NGOs), and information technology (IT) service providers, primarily in the US and Europe. Midnight Blizzard is consistent and persistent in their operational targeting, and their objectives rarely change. Their focus is to collect intelligence through longstanding and dedicated espionage in support of Russian foreign policy interests.
Midnight Blizzard operations often involve compromise of valid accounts and, in some highly targeted cases, advanced techniques to compromise authentication mechanisms within an organization to expand access and evade detection. They utilize diverse initial access methods, and Midnight Blizzard is also adept at identifying and abusing OAuth applications to move laterally across cloud environments and for post-compromise activity, such as email collection.
CaptiveCrunch tradecraft and tooling
CornFlake: Remote access and infostealer implant
CornFlake is a full-featured Windows RAT written in Go that serves as Storm-2945’s primary persistent implant. Microsoft has observed the threat actor rapidly iterating on this malware layer, which features customizable capabilities from the social engineering user interface and data collection capabilities to anti-detection and evasion techniques.
On initial execution, CornFlake operates in dropper mode: it displays a convincing fake progress window designed to occupy the victim’s attention while the binary copies itself to %APPDATA%\svchost32\svchost32.exe and establishes persistence.
Fake window options configurable by the threat actor at build time:
winupdate — A Windows Update screen displaying “Working on updates… Don’t turn off your computer”
defender — A Windows Security virus scan
directx — A DirectX End-User Runtime Web Installer
vcredist — A Microsoft Visual C++ 2015-2022 Redistributable installer
sysopt — A disk optimization utility
netfix — A Windows Network Diagnostics tool
browser — A browser update prompt
pdfview — A document viewer installer
Figure 4. False update window
CornFlake registers as a Windows service named svchost32 with the display name “Cloud Sync Service” and description “Synchronizes files with the cloud storage provider”, deliberately mimicking the legitimate svchost.exe process. It establishes redundant persistence mechanisms: Windows service registrations, Registry Run keys, named scheduled tasks, and a persistence watchdog routine that runs continuously to restore any persistence mechanism that is removed by defenders or endpoint protection.
For command and control (C2), CornFlake performs an Elliptic Curve Diffie-Hellman (ECDH) P-256 ephemeral key exchange with the C2 server, derives a session key via SHA-256, and communicates over a custom JSON protocol framed within the encrypted channel. This provides an encrypted channel to the C2 server, with each C2 session using a unique ephemeral key, making decryption of captured traffic impossible without the session-specific private key. The runtime configuration file sync.dat supports hot reconfiguration of C2 servers, watched directories, file targeting patterns, and Transport Layer Security (TLS) settings without requiring redeployment.
Once established on a victim system, CornFlake provides the operator with a comprehensive collection toolkit, gated by configuration flags that allow selective activation post-deployment:
Capability
Description
Keylogging
Raw input API-based keylogger capturing all keystrokes, including password fields
Clipboard monitoring
Captures clipboard changes with SHA-256 deduplication and records the active window title at time of capture
Screenshot capture
Idle-triggered and on-demand screenshots with configurable idle threshold
Audio surveillance
Windows Audio Session API (WASAPI)-based microphone capture, encoded as WAV files
Video surveillance
Media Foundation-based webcam capture, encoded as JPEG
Browser credential theft
ChromeKatz-derived module supporting live cookie extraction from process memory (Chromium browsers) and stored password extraction from on-disk databases, including Chrome App-Bound Encryption (ABE) bypass and Firefox NSS/SDR decryption
File exfiltration
Targets files based on file extensions with real-time file system monitoring and an upload throttle (1,000 files or 500 MB per cycle). File extensions are categorized as Documents, Archives, Images, Code, Data, Emails, and Keys
USB drive monitoring
Detects and scans removable media when inserted
Security posture sweep
Collects 18 categories of host intelligence including installed software, antivirus (AV)/endpoint detection and response (EDR) products, Defender exclusions, User Account Control (UAC) level, Remote Desktop Protocol (RDP) history, Office most recently used (MRU) files, and credential hints
Remote shell
Arbitrary command execution via cmd.exe or PowerShell (with -NoP flag to suppress profile-based detection)
CornFlake also exposes a localhost HTTP API server (/upload, /reload, /status) that transforms the RAT into a modular platform: companion or next-stage payloads such as ChocoShell could task file exfiltration, trigger configuration hot reloads or check C2 connectivity using the pre-established secure C2 channel for communication.
ChocoShell: PowerShell infostealer
ChocoShell is the campaign’s Powershell-based infostealer, delivered and executed entirely in-memory. Its primary objective is the high-volume theft of browser session cookies, saved passwords, Microsoft 365 Single Sign-On (SSO) tokens, and Wi-Fi credentials from compromised systems. Where CornFlake provides the operator with a persistent, long-running foothold on the device, ChocoShell is designed to extract the most operationally valuable credentials, giving the operator access to victim cloud environments.
The ChocoShell script was authored with full developer comments that reveal the operator’s intent behind each code decision, including explicit references to Microsoft detection signatures and the reasoning behind specific evasion choices. The consistent coding standard and descriptive commentary suggest the author might have leveraged AI-assisted code generation.
Defense evasion. Upon execution, ChocoShell beacons to a hardcoded C2 server at 213.145.86[.]112 and implements several evasion techniques in sequence. It disables the Antimalware Scan Interface (AMSI) via .NET reflection to prevent ScriptBlock scanning and evades Microsoft behavioral detection that triggers on suspicious PowerShell web request cmdlets. A timing-based sandbox detection check is also employed as a virtual machine (VM) detection mechanism, silently exiting without performing any collection if detected.
C2 communication. ChocoShell communicates with its C2 server using HTTPS with URI paths designed to blend in with legitimate web traffic. Beacons use /t/pixel.gif?m=<status>, mimicking an image tracking pixel. Additional tooling is fetched from /cdn/chunks/polyfill-7e2b.min.js, disguised as a JavaScript polyfill file. This downloaded module is Base64-decoded and executed in memory via [ScriptBlock]::Create(), providing browser encryption key extraction capabilities, SYSTEM token impersonation, and Defender signature locking. Exfiltrated data is sent by POST to /t/event as GZip-compressed, Base64-wrapped JSON.
Privilege escalation. ChocoShell requires administrative privileges for its most impactful capabilities: SYSTEM token impersonation for Chrome ABE decryption, Volume Shadow Copy Service (VSS) shadow copy creation, Defender signature locking. It implements three silent UAC bypass techniques with ordered fallback:
SilentCleanup task hijack: Writes a malicious command to HKCU\Environment\windir, then triggers the built-in SilentCleanup scheduled task, which resolves %windir% from the user’s environment, executing the threat actor’s command at elevated privilege. The registry value is cleaned up after two seconds to avoid cloud detection.
wsreset.exe COM hijack: Creates a COM handler key in HKCU\Software\Classes and launches the auto-elevating Windows Store reset tool.
sdclt.exe folder hijack: Hijacks HKCU\Software\Classes\Folder\shell\open\command and launches the Windows Backup utility with the /KickOffElev flag.
If none of the silent bypasses succeed (for example, the user is not a local administrator), ChocoShell falls back to a visible UAC prompt via Start-Process -Verb RunAs. Notably, the script also contains a variant designed to execute within the WinGet Desired State Configuration (DSC) host process (ConfigurationRemotingServer), suggesting an attack vector through malicious WinGet DSC configuration used in Windows machine provisioning.
Credential and session theft. Once running with elevated permissions, ChocoShell locks Defender signature updates and systematically harvests data from multiple sources. For Chromium-based browsers (Chrome, Edge, Brave, Opera, Opera GX, Vivaldi), it extracts the master encryption key from the browser’s Local State file, handling both the modern ABE scheme (Chrome v127+) and the legacy data protection API (DPAPI)-only scheme. ABE decryption requires SYSTEM-level DPAPI access, which the malware obtains by impersonating a SYSTEM process token borrowed from winlogon.exe, wininit.exe, or services.exe. Locked browser SQLite databases are accessed through three strategies: shared file access, Volume Shadow Service snapshots, and direct copy as a fallback.
As a parallel collection path, ChocoShell launches Chrome, Edge, and Brave with the –remote-debugging-port flag and issues Network.getAllCookies through the Chrome DevTools Protocol (CDP). This completely bypasses ABE, enabling the browser to perform its own internal decryption and returns plaintext cookie values. To handle privilege issues (SYSTEM-launched browsers inherit the wrong token), the malware creates transient scheduled tasks with TASK_LOGON_INTERACTIVE_TOKEN to launch the browser under the signed-in user’s session. After extraction, the browser is stopped and relaunched with –restore-last-session to avoid alerting the user.
For Firefox family browsers (Firefox, Waterfox, LibreWolf, Floorp, Zen), the malware copies unencrypted cookies.sqlite databases from each profile. Additionally, ChocoShell collects Microsoft 365 and Azure Active Directory (AD) access tokens, refresh tokens, and Web Account Manager (WAM) tokens from .tbres files in the Token Broker cache. Collection of these tokens represents a significant threat to enterprise environments, as threat actors could replay SSO sessions without browser cookies. Additionally, Wi-Fi credentials are harvested via netsh wlan show profile with key=clear.
Exfiltration and cleanup. All collected data is aggregated into a JSON structure, GZip-compressed, Base64-encoded, and sent by POST to the C2’s /t/event endpoint. After exfiltration, all collected data variables are nulled, garbage collection is forced, VSS shadow copies are deleted via Windows Management Instrumentation (WMI), temporary elevation scripts are removed, and all UAC bypass registry keys (already cleaned during escalation) are verified removed.
FruitStone: Operator C2 panel
FruitStone is the web-based C2 panel that Storm-2945 operators use to manage the entire CaptiveCrunch campaign infrastructure. Implemented as a single-page application (HTML and JavaScript) serving as the front-end of the C2 server with all functionality exposed without authentication, FruitStone provides a centralized dashboard for managing compromised endpoints, building and deploying new campaign payloads, and reviewing all collected data (such as screenshots, keystrokes, browser credentials).
Operational cover. The panel is branded as “CloudSync Console” with a footer reading “Acuity Systems, Inc. — Cloud Infrastructure Portal v3.2.1,” designed to appear as legitimate enterprise cloud management software if the panel URL is discovered by defenders or hosting providers. This masquerading extends to the CornFlake agent’s service name (Cloud Sync Service) and description (“Synchronizes files with the cloud storage provider”), creating a consistent cover story across the toolchain.
Figure 5. CloudSync Console panel masquerade
Session management and multi-operator support. FruitStone uses JSON Web Token (JWT)-based authentication, session revocation, and rate limiting with IP blocking to prevent brute force attacks against the panel sign in. Multiple operators could be provisioned with individual accounts, and all active sessions are visible with IP address, user-agent, and creation time to enable operational security awareness across the operators.
Agent management. The panel displays all registered CornFlake agents in a dashboard with real-time status updates via Server-Sent Events (SSE). Each agent card shows comprehensive system information including hostname, username, OS version, CPU, RAM, disk usage, screen resolution, timezone, domain membership, and camera/microphone presence, all collected during the CornFlake posture sweep. Agents are grouped by country and subnet, with geographic distribution visualized on a map.
Operators could interact with individual agents through:
Remote shell — Interactive cmd.exe or PowerShell command execution with command history
File system browser — Live directory traversal and arbitrary file download from compromised hosts
Collection tasking — On-demand screenshot, process list, keylog buffer flush, clipboard dump, security posture survey, ChromeKatz cookie/password extraction, camera capture, and audio recording
Configuration push — Live runtime reconfiguration of C2 servers, watch paths, and C2 beacon timing
Agent update — In-place implant update by pushing a new CornFlake build to a running agent
Agent kill — Remote termination of the CornFlake implant
Campaign builder. A step-by-step wizard enables operators to configure and build new CornFlake payloads directly from the panel:
Identity — Campaign ID, C2 host and port, HTTP base URL, executable file name (svchost32.exe by default), and dropper type (C dropper at ~19 KB, Go stub at ~8 MB, or standalone self-installer)
File Paths — Configure targeted directories and file extensions by category (documents, archives, images, code, data, emails, encryption keys)
Figure 8. File paths tab
Evasion — Enable garble symbol randomization (for GoLang payloads), XOR string encoding, GZip upload compression, and debug mode
Figure 9. Evasion tab
Infrastructure management. FruitStone provides management interfaces for three layers of supporting infrastructure:
Proxy relays — Multi-proxy C2 relay architecture with TLS certificate tracking (fingerprint, expiry), health checks, connection counts, bytes forwarded, and rotation capabilities that push updated server lists to all online agents
Beacon profiles — Configurable timing profiles controlling agent sleep intervals, reconnection delays, TLS Server Name Indication (SNI) spoofing (like teams.microsoft.com), and DNS fallback domains
Staging servers — External payload hosting infrastructure with push-to-deploy, file listing, and health monitoring
Figure 10. View of the CloudSync staging servers interface
Device code abuse for cloud access
Since July 16, Microsoft has observed a portion of CaptiveCrunch landing pages redirecting users to device code authentication flow experiences. In these cases, users served these landings might be instructed to enter a device code into a legitimate Microsoft sign-in page, a technique commonly referred to as device code phishing.
Device code authentication is a legitimate OAuth workflow designed for devices that cannot support a traditional sign-in experience. However, threat actors could abuse this flow by initiating an authentication request on behalf of a user then convincing the user to enter an actor-controlled device code into a legitimate Microsoft authentication page. When successful, the victim authenticates the threat actor’s session rather than their own.
This activity is consistent with previously reported device code phishing operations conducted by Midnight Blizzard since August 2024. The observed technique does not appear fundamentally novel; however, integrating device code phishing into captive portal and traffic manipulation operations might increase the likelihood that users perceive the authentication request as legitimate. For additional details on Midnight Blizzard-related device code phishing techniques, see: Storm-2372 conducts device code phishing campaign. To understand other threat actors’ use of device code phishing and associated mitigations, see Inside an AI‑enabled device code phishing campaign.
How to protect against CaptiveCrunch activity
Minimize trust in hospitality and guest networks
When traveling, users should treat hotel, conference, airport, and other guest wireless networks as untrustworthy.
Prefer private connectivity (including mobile hotspots, satellite, and eSIM-based cellular data connections) over public Wi‑Fi whenever practical.
Consider using enterprise-managed travel routers or hotspot devices that establish encrypted tunnels back to trusted corporate infrastructure before accessing sensitive resources.
Avoid downloading software updates, certificates, browser updates, network troubleshooting tools, or security utilities presented through captive portals or other unexpected web prompts.
Verify update requests through trusted operating system mechanisms rather than pop-up messages or website prompts.
Strengthen identity and access controls
Organizations should assume that public and hospitality network infrastructure might not be trustworthy and should adopt controls that limit exposure to traffic manipulation, credential theft, and device code phishing.
Educate users to recognize ClickFix-style prompts, fake verification checks, and paste-and-run instructions as malicious, especially when they invoke command interpreters or script hosts such as cmd.exe, PowerShell, rundll32.exe, or mshta.exe.
Use passwordless solutions like passkeys and implement multifactor authentication (MFA).
Only allow device code flow where necessary. Microsoft recommends blocking device code flow wherever possible. Where necessary, configure Microsoft Entra ID’s device code flow in your Conditional Access policies.
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 is not 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 MFA.
When a user is a high risk and Conditional access evaluation is enabled, the user’s access is revoked, and they are forced to re-authenticate.
For regular activity monitoring, use Risky sign-in reports, which surface attempted and successful user access activities where the legitimate owner might not have performed the sign-in.
Use a Security Service Edge (SSE) solution like Global Secure Access to secure access to any app or resource using network, identity, and endpoint access controls.
Reduce exposure during captive portal registration
Organizations should review what information employees provide to hospitality providers when connecting to guest networks.
Do not reuse corporate credentials on hotel, conference, or guest-network registration pages.
Where possible, organizations should evaluate whether venue-provided wireless is required for corporate events and conferences.
Organizations should minimize unnecessary disclosure of employee identities, organizational affiliations, and travel details when booking accommodations or registering for guest network access, consistent with corporate policy and applicable local requirements.
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 for Endpoint detects Storm-2945 activity under the detection Suspicious activity linked to a Russian state-sponsored threat actor has been detected. However, these alerts might be triggered by unrelated threat actor activity. The following chart lists Microsoft Defender detections specific to the TTPs utilized by Storm-2945 in this attack.
CornFlake registers a Windows service, a Registry Run key, a scheduled task
Microsoft Defender for Endpoint – Suspicious Scheduled Task Process Launched – Suspicious scheduled task – Suspicious file added to run key – Suspicious service registration
Microsoft Defender XDR – User account compromise via OAuth device code phishing – Malicious sign in from an IP address associated with recognized attacker infrastructure – Suspicious Azure authentication through possible device code phishing
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.
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 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:
Detect file creation after Wi-Fi connectivity test on devices
The following query checks for a file creation on a device within two minutes of the device performing built‑in Network Connectivity Status Indicator (NCSI) test, which occurs when network connectivity is established to a Wi-Fi network with a captive portal. This activity might indicate an attacker’s initial access file presence on a device.
Please note that not all files discovered through this query might be malicious or related to this threat activity.
let ncsi_endpoints = dynamic(["msftconnecttest.com","edge-http.microsoft.com","msftncsi.com","captive.apple.com","clients1.google.com",
"clients3.google.com","clients4.google.com","clients6.google.com","connectivitycheck.gstatic.com","connectivitycheck.android.com",
"android.clients.google.com","www.gstatic.com","detectportal.firefox.com","detectportal.brave-http-only.com","cloudflareportal.com",
"cloudflarecp.com","cloudflareok.com","connectivity-check.warp-svc","connectivity.cloudflareclient.com","spectrum.s3.amazonaws.com",
"nmcheck.gnome.org"]);
let NCSIEvents = DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteUrl has_any (ncsi_endpoints)
| project NCSI_Timestamp = Timestamp, DeviceId, DeviceName, RemoteUrl, NCSI_ReportId = ReportId, NCSI_InitiatingProcessFileName = InitiatingProcessFileName, NCSI_InitiatingProcessCommandLine = InitiatingProcessCommandLine, NCSI_AccountName = InitiatingProcessAccountName;
let FileDownloadEvents = DeviceFileEvents
| where Timestamp > ago(7d)
| where ActionType == "FileCreated"
| where FileName has_any (".exe",".msi",".zip",".rar",".7z")
| project Download_Timestamp = Timestamp, DeviceId, FileName, FolderPath, Download_ReportId = ReportId, Download_InitiatingProcessFileName = InitiatingProcessFileName, Download_InitiatingProcessCommandLine = InitiatingProcessCommandLine, Download_AccountName = InitiatingProcessAccountName;
NCSIEvents
| join kind=inner (
FileDownloadEvents
) on DeviceId
| where Download_Timestamp >= NCSI_Timestamp and Download_Timestamp
Detect connectivity to Storm-2945 infrastructure
The following query checks for connectivity to Storm-2945 infrastructure observed in this attack activity.
let target_domains = dynamic(["ms365-device.com", "ms365-live.com", "m365-owa.com", "owa-ms365.com"]);
let target_ips = dynamic(["31.57.243.154", "38.146.28.75", "38.146.28.132", "104.194.159.150", "107.189.26.194", "213.145.86.112"]);
DeviceNetworkEvents
| where RemoteUrl has_any(target_domains) or RemoteIP in (target_ips)
| project
Timestamp,
DeviceName,
DeviceId,
RemoteUrl,
RemoteIP,
LocalIP,
InitiatingProcessFileName,
InitiatingProcessCommandLine,
AccountName = InitiatingProcessAccountName,
ReportId
Detect CornFlake RAT presence on affected systems
The following query checks for the presence of the CornFlake RAT binary.
The following query checks for the CornFlake RAT Windows service registration.
DeviceRegistryEvents
| where RegistryKey has @"\SYSTEM\CurrentControlSet\Services\svchost32"
| where ActionType == "RegistryValueSet"
| where (RegistryValueName == "DisplayName" and RegistryValueData == "Cloud Sync Service")
or (RegistryValueName == "Description" and RegistryValueData == "Synchronizes files with the cloud storage provider")
| project
Timestamp,
DeviceName,
DeviceId,
RegistryKey,
RegistryValueName,
RegistryValueData,
ActionType,
InitiatingProcessFileName,
InitiatingProcessCommandLine,
InitiatingProcessAccountName,
ReportId
Microsoft Sentinel
Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace.
Detect network IP and domain indicators of compromise using ASIM
The following query checks IP addresses and domain IOCs across data sources supported by ASIM network session parser:
//IP list and domain list- _Im_NetworkSession
let lookback = 30d;
let ioc_ip_addr = dynamic(["213.145.86.112"]);
let ioc_domains = dynamic(["213.145.86.112/t/pixel.gif", "213.145.86.112/cdn/chunks/polyfill-7e2b.min.js", "213.145.86.112/t/event"]);
_Im_NetworkSession(starttime=todatetime(ago(lookback)), endtime=now())
| where DstIpAddr in (ioc_ip_addr) or DstDomain has_any (ioc_domains)
| summarize imNWS_mintime=min(TimeGenerated), imNWS_maxtime=max(TimeGenerated),
EventCount=count() by SrcIpAddr, DstIpAddr, DstDomain, Dvc, EventProduct, EventVendor
Detect web sessions IP and file hash indicators of compromise using ASIM
The following query checks IP addresses, domains, and file hash IOCs across data sources supported by ASIM web session parser:
//IP list - _Im_WebSession
let lookback = 30d;
let ioc_ip_addr = dynamic(["213.145.86.112"]);
let ioc_sha_hashes =dynamic([“918fa52ae45ed60ba7cc8bdc99c3cbe9ab92e0375ec31fc05d0d4513be11c593”, “be99857449d2856dd5a84e21c8a3d5e0e01456adb44062ddec5a6b4970d8d42c”]);
_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 domain and URL indicators of compromise using ASIM
The following query checks domain and URL IOCs across data sources supported by ASIM web session parser:
// file hash list - imFileEvent
// Domain list - _Im_WebSession
let ioc_domains = dynamic(["https://213.145.86.112/t/pixel.gif", "https://213.145.86.112/cdn/chunks/polyfill-7e2b.min.js", "https://213.145.86.112/t/event"]);
_Im_WebSession (url_has_any = ioc_domains)
ChocoShell C2 communications
The following query detects ChocoShell communications with its C2 server using HTTPS with URI paths designed to blend in with legitimate web traffic. Beacons use /t/pixel.gif?m=<status>, mimicking an image tracking pixel.
let lookback = 30d;
let ioc_url_artifacts = dynamic(["/t/pixel.gif?m="]);
_Im_WebSession(starttime=todatetime(ago(lookback)), endtime=now())
| where DstDomain in (ioc_url_artifacts)
| summarize imWS_mintime=min(TimeGenerated), imWS_maxtime=max(TimeGenerated),
EventCount=count() by SrcIpAddr, DstIpAddr, Url, Dvc, EventProduct, EventVendor
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
Your phone rings, you pick up and say hello. On the other end: total silence. No one answers, and the call abruptly disconnects. If you don’t already use spam call blockers, you’ve almost certainly run into this situation before.
In most cases, these are scam calls. Today, we explain why these calls happen, what the callers want from you, and how to protect yourself. Most importantly, we’ll look at whether you even need to bother protecting yourself against them in the first place.
Who’s calling?
It’s not just scammers on the line — robots, legitimate call center operators, and ordinary folks make these calls too. Let’s break down each type of caller — ordered from best-case to worst-case scenario for your security.
Actual person
The most harmless scenario is that an actual person called you, but their microphone is acting up. Maybe they accidentally muted themselves with their ear, or their smartphone connected to a Bluetooth headset, speaker, or car system that isn’t capturing their voice. Carrier glitches can also mute one side of a call. The caller might have no idea there’s a problem — as far as they know, they are speaking, but no one can hear them. In cases like this, you usually recognize the incoming phone number.
If the call comes from an unknown number, there’s still no need to panic — though the list of those who might be calling gets much longer.
One legitimate possibility is a call center agent who simply didn’t pick up or connect their headset in time. Call center systems are designed to dial numbers faster than agents can wrap up their calls. The system tried to route the call to a human, but no reps were available. That’s why you sometimes have to wait a few seconds before hearing a single word, or why you might hear ringing tones as if you were the one making the call.
Robot or AI
Silence on the line is a common sign of robocalls. Robots test whether a phone number is active and, if it is, pass it along to a human — meaning a real sales rep (or scammer) will call you back in the next few days. It’s worth noting that scammers aren’t the only ones making these pinging calls. Legitimate call centers use the exact same tools to reduce the workload on their live agents.
An AI agent could also be behind the silent call. To the person answering, there’s no practical difference: the call looks identical to one made by a standard bot. However, AI can do more than just auto-dial numbers — it can analyze your response and use that data to decide whether your number is active and ready to be handed off to a live person for follow-up.
Unwanted caller
Now we get to the real threat. Perhaps one of the most dangerous and unpleasant sources of silent phone calls is a scammer. A quick, silent call like this can actually be the groundwork for a long, elaborate attack with cover stories about loans, government agencies, other fraudsters, even law enforcement.
Debt collectors might also be calling and staying quiet. Your number could end up on their radar if you, your family, or close contacts have outstanding debts. In these cases, a silent call is often used as a tactic for psychological pressure.
A similar technique is used in stalking. While silent calls cause no direct harm on their own, they can be leveraged to induce anxiety, create a feeling of being constantly watched, and cause ongoing emotional distress.
Why do they call and stay silent?
When you pick up, you likely respond out of habit with a quick “Hello?” or “Hi there.” That’s all it takes for the other party to gather a wealth of data. While this information used to be difficult to process, the rise of artificial intelligence has made the task significantly easier. Let’s look at what someone can learn about you from just one spoken word:
Region, accent, and location. Scammers are sophisticated and cunning. Their tactics are often tailored by region — targeting residents of specific countries or even regions within them. This is especially relevant in places like India or South Africa, which have 22 and 11 official languages, respectively.
Approximate age and gender. While a human listener might easily confuse a teenager’s voice with a young woman’s or misjudge someone’s age entirely, AI is far better at picking up on subtle vocal nuances. Knowing your age and gender helps scammers refine their playbook for future social engineering attacks.
Times you’re available. If you answer the phone in the morning, afternoon, or late at night, attackers can schedule their follow-up call during the exact time window when you’re most likely to pick up.
Likelihood of a successful attack. AI can automatically assess the potential value of a target. For instance, if someone answers quickly, speaks calmly, and doesn’t immediately hang up on unknown numbers, they’ll likely be assigned a higher priority for follow-up calls by live scam operators.
Back to the “why do they call and stay silent”, the main reason is to harvest biometric data. Just a few seconds of recorded audio can help cybercriminals create a voice deepfake. While one or two words might not yield a convincing clone on their own, attackers can stitch together recordings from multiple silent calls to build a believable replica.
This technology is already being used in real-world scams. Impersonating a relative, colleague, or boss, fraudsters can urgently ask you to send them money, to share a two-factor authentication code for government services, or to complete some other seemingly innocuous request. The more realistic the deepfake sounds, the harder it is to spot the scam — especially when backed by a convincing backstory.
What to do if you get a silent call?
If you answer a call, say a few words, and hang up, there’s no need to panic. However, that brief interaction can confirm to attackers that your number is active and that you’ll answer calls from unknown numbers. As a result, your phone number could end up on target lists for future spam or scam campaigns. That said, it’s important to remember that a single silent call poses no immediate security threat.
Here are a few tips to help you stay calm and avoid falling for scam tactics if those silent calls are becoming a problem:
Don’t answer calls from unknown or hidden numbers. Here’s a helpful tip: if someone genuinely needs to reach you, they’ll find another way to do so, or keep calling from the exact same number at various times. Scammers almost always dial from different numbers, while automated bots operate on a rigid schedule — like calling every day at precisely 8:05 AM.
Don’t rush to call back. Scammers often count on proactive victims who are curious enough to return calls from unfamiliar numbers. On top of that, calling back could end up costing you money if it’s a premium-rate number.
Don’t speak first. Wait for the caller to greet you before starting a conversation. If you hear muffled noise or complete silence on the line, hang up and save yourself the hassle — it’s likely a scam.
Block unknown numbers — even after the call. If you picked up and realized the call could be risky, it’s best to block the number right away. You can use the built-in features on most modern smartphones to do this.
Don’t share your number everywhere. Phishing sites, fly-by-night web pages, and sketchy giveaways often exist solely to collect your personal data. When filling out forms online, it doesn’t hurt to use a burner or secondary number.
Get a second phone number. Separate your daily life between two numbers. Use your main line strictly for family, friends, and work contacts, and reserve the secondary line for deliveries, online marketplaces, and general web sign-ups.
AI is getting better and better at solving CAPTCHAs. This makes website creators — who still need to verify that they’re dealing with humans rather than bots — come up with increasingly sophisticated proof-of-humanity checks. It seems an average user would no longer be surprised if asked to recite a poem — or, say, dance Gangnam Style — just to access certain websites. The latter could double as an age check, but I digress.
Attackers have learned to exploit this variety of sometimes bizarre checks to their advantage. In our blog, we’ve talked more than once about the ClickFix attack technique, which is all about slipping a malicious instruction to the victim under the guise of yet another CAPTCHA. Historically, this technique has been used to attack users of Windows-powered devices. However, researchers recently discovered a campaign that targets macOS users. In this post, we talk in more detail about the ClickFix attack technique, the new campaign aimed at Mac users, and the criminals’ goals.
What is the ClickFix attack technique?
Many common attacks and scams rely on social engineering, or more simply put — manipulation. Instead of looking for software vulnerabilities, attackers try to trick the user into doing the dirty work themselves: opening a malicious file, clicking a link to a fake website, sharing sensitive data, or running a harmful command.
The ClickFix attack also relies on social engineering, except the scammers aren’t betting on the victim’s fear of an authority figure, but rather on their trust in technology and their habit of following instructions — even when they don’t quite make sense.
In a classic ClickFix scenario, a user visits a compromised or fake website and, instead of the expected page, sees a notification that there’s an issue. The site might claim that to continue, you need to complete an extra verification check, update your browser, or fix an error.
ClickFix: how to infect your own computer with malware in three easy steps. One of the classic variations of the attack targeting Windows users Source
Next, the victim is prompted to follow a few simple steps that look harmless enough at first glance. Usually, this involves copying some text from the attackers’ website, opening the Run window, pasting the text there, and hitting Enter.
In reality, the text is a malicious command that downloads and runs malware on the device. Since the user carries out all the steps themselves, the operating system’s security mechanisms and built-in warnings are often dismissed as just another part of the instructions. In our blog, we’ve covered the typical pretexts used to trick victims into taking dangerous actions; you can read more about them here.
The ClickFix attack scheme quickly began spawning various spin-offs, such as FileFix and ConsentFix. Until recently, the victims of ClickFix and its variants were mostly Windows users, while Mac fans encountered it much more rarely. But lately, the number of ClickFix attacks targeting Apple device owners has been on the rise.
How does the ClickFix attack on macOS work?
The ClickFix attack on Macs, as documented by cybersecurity researchers, begins with the classic fake CAPTCHA scenario. To pass the proof-of-humanity check, attackers prompt the user to copy a command, open Terminal, and paste the text into it.
The contents of the command that the user is prompted to run via Terminal. Source
The more interesting part is what happens after the malicious command is run. First, it downloads a malicious DMG — the standard format for disk images containing installation files in macOS — from a remote server, and saves it to the /tmp temporary folder under a random name. Then the script mounts the disk image without showing it in Finder or creating a desktop icon — keeping it hidden from the user. After that, the script searches the disk image for an app or installation package, and automatically launches it once found.
One case documented in the researchers’ findings involved the widespread AMOS (Atomic macOS Stealer) infostealer being distributed this way. To gain extra privileges on the system, the stealer Trojan displays a fake macOS system authentication window tricking the user into willingly typing in their password.
What are the attackers’ goals?
After the malware is installed, the attackers steal literally everything they can get their hands on from the victim’s device. Atomic macOS Stealer extracts sensitive information stored in Chromium-based browsers (Google Chrome, Microsoft Edge, Brave, Opera, Arc, Vivaldi, CocCoc, and Yandex), as well as Firefox-based ones (LibreWolf, SeaMonkey, Tor Browser, Waterfox, and Zen Browser), such as the following:
Cookies
Saved logins and passwords
Auto-fill data
Saved credit and debit cards
Browser profile data
On top of all that, the attackers also steal PDF, TXT, and RTF files from the victim’s device. The criminals are especially interested in crypto apps; specifically: desktop crypto wallets like Exodus, Electrum, Atomic Wallet, Wasabi Wallet, Bitcoin Core, Litecoin Core, DashCore, Guarda, Binance Wallet, Dogecoin Wallet, and Tonkeeper. The malware also gathers data from more than 200 cryptocurrency-related browser extensions.
But that’s still not everything…
It also targets the Telegram and Discord desktop apps. The malware doesn’t spare Apple’s ecosystem either — stealing Safari cookies, notes from Apple Notes, and passwords stored in the built-in Apple Keychain.
Once a device is infected, Atomic macOS Stealer whisks away everything valuable. Source
All of the collected information is added to a ZIP archive and uploaded to the attackers’ server. In addition, the malware replaces legitimate versions of hardware crypto wallet apps — specifically Ledger Wallet and Trezor Suite — with malicious fakes.
Together, this trove of data gives attackers broad opportunities to further compromise accounts, steal digital assets, and launch new attacks on behalf of the victim.
How do I avoid becoming a victim of ClickFix?
As social engineering attacks continue to grow, users need to be more vigilant than ever. That goes for everything from chatting with strangers on the phone or in messaging apps to everyday online activity.
Never paste commands into your Terminal just because a website asks you to — whether it’s to pass a verification check, confirm your identity, or view hidden content. No legitimate website will ever ask you to enable its features by manually running commands Terminal.
Never enter your macOS administrator password unless you completely understand what app is asking for it.
Regularly install macOS security updates, or better yet, set them to install automatically by going to System Settings → General → Software Update and clicking the i icon next to Automatic Updates. While recent versions of macOS may warn you when you try to paste suspicious or malicious commands into Terminal, this isn’t a reliable feature. For example, the malicious code shown in the screenshot above didn’t trigger any warnings at all on macOS Tahoe 26.5.2.
Trust the warnings from your operating system and security software rather than the instructions — or even the demands — of websites and apps.
Twenty years ago, a British mathematician named Clive Humby popularized a phrase that came to describe data’s relationship with the entire global economy: “Data is the new oil.”
Pithy as the phrase sounds, it is undeniably true.
Data steers decisions at businesses of every size. Data created entirely new industries built around its capture. And, for a select number of companies, data has produced billions—if not trillions—of dollars in value.
So how is it that, on the dark web, your stolen identity can be purchased for just 95 cents?
That’s what a Malwarebytes researcher found last month after spending 48 hours inside the dark web to investigate cybercrime. Across a variety of forums and directories, he found subscription plans for malware that steals information once implanted on a device. He found guides for deploying social engineering scams. He found people selling their services to build fake websites that trick people into handing over their usernames and passwords. And he found one of the dark web’s most traded commodities—personal data, packaged together about individual people, to help a cybercriminal commit identity fraud.
These packages are called “fullz.” For victims in the United States, a fullz contains a full name, Social Security Number, date of birth, address, and other personal details. That is enough, on its own, for a cybercriminal to potentially open a bogus line of credit, file a fake tax return, access financial accounts, or obtain medical services under someone else’s name.
As we wrote on Malwarebytes Labs:
“For less than the cost of a cup of coffee, a cybercriminal can buy enough information to devastate someone’s financial life.”
It’s the kind of risk that could scare anyone, especially considering the scale behind it. In just the first six months of 2026, Malwarebytes found more than 7,500 compromised data sets on the dark web containing more than 8.4 billion records.
And yet, even today, cybersecurity professionals still get asked why anyone should bother protecting their data.
The public, understandably, are exhausted. With data breaches happening every week—if not every day—cybersecurity can start to feel pointless. With young people unable to build financial security, they start believing that they have nothing worth stealing. And with Big Tech already collecting our every movement, behavior, click, and concern, people understandably feel powerless to fight any kind of data abuse, be it corporate or criminal.
So today’s episode approaches the question from a different direction. This isn’t about why you should protect yourself—plenty of company websites will tell you that, and most of them rely on fear. This is about why hackers want your data in the first place.
Today, on the Lock and Code podcast, host David Ruiz explains how cybercriminals turn a single repeated password into account takeover, how a screenshot of your house from Google Maps became a tool in extortion emails, and why the most benign information about you—an address, an age, one public photo—is often the most useful data a stranger can buy.
Twenty years ago, a British mathematician named Clive Humby popularized a phrase that came to describe data’s relationship with the entire global economy: “Data is the new oil.”
Pithy as the phrase sounds, it is undeniably true.
Data steers decisions at businesses of every size. Data created entirely new industries built around its capture. And, for a select number of companies, data has produced billions—if not trillions—of dollars in value.
So how is it that, on the dark web, your stolen identity can be purchased for just 95 cents?
That’s what a Malwarebytes researcher found last month after spending 48 hours inside the dark web to investigate cybercrime. Across a variety of forums and directories, he found subscription plans for malware that steals information once implanted on a device. He found guides for deploying social engineering scams. He found people selling their services to build fake websites that trick people into handing over their usernames and passwords. And he found one of the dark web’s most traded commodities—personal data, packaged together about individual people, to help a cybercriminal commit identity fraud.
These packages are called “fullz.” For victims in the United States, a fullz contains a full name, Social Security Number, date of birth, address, and other personal details. That is enough, on its own, for a cybercriminal to potentially open a bogus line of credit, file a fake tax return, access financial accounts, or obtain medical services under someone else’s name.
As we wrote on Malwarebytes Labs:
“For less than the cost of a cup of coffee, a cybercriminal can buy enough information to devastate someone’s financial life.”
It’s the kind of risk that could scare anyone, especially considering the scale behind it. In just the first six months of 2026, Malwarebytes found more than 7,500 compromised data sets on the dark web containing more than 8.4 billion records.
And yet, even today, cybersecurity professionals still get asked why anyone should bother protecting their data.
The public, understandably, are exhausted. With data breaches happening every week—if not every day—cybersecurity can start to feel pointless. With young people unable to build financial security, they start believing that they have nothing worth stealing. And with Big Tech already collecting our every movement, behavior, click, and concern, people understandably feel powerless to fight any kind of data abuse, be it corporate or criminal.
So today’s episode approaches the question from a different direction. This isn’t about why you should protect yourself—plenty of company websites will tell you that, and most of them rely on fear. This is about why hackers want your data in the first place.
Today, on the Lock and Code podcast, host David Ruiz explains how cybercriminals turn a single repeated password into account takeover, how a screenshot of your house from Google Maps became a tool in extortion emails, and why the most benign information about you—an address, an age, one public photo—is often the most useful data a stranger can buy.
When an administrator introduces a rule change in AWS Network Firewall and network connectivity is disrupted, pinpointing the cause requires inspecting multiple points in the traffic path. The firewall gives you stateless and stateful rule engines, domain rules, and routing to the firewall endpoint inside your Amazon Virtual Private Cloud (Amazon VPC). A network drop looks the same from the workload no matter where it started. Isolating the cause means correlating the alert and flow logs with the firewall configuration, route tables, and recent API calls in AWS CloudTrail that might have changed them. That manual correlation is exactly where AWS DevOps Agent helps, accelerating root cause analysis so you can restore connectivity in minutes instead of hours.
AWS DevOps Agent does that correlation for you. As your always-available operations teammate, it resolves and proactively prevents operational issues across AWS, multicloud, and on-premises environments. When an Amazon CloudWatch alarm triggers, it reaches the agent through a webhook. The agent then reads the firewall configuration and logs through AWS APIs, ties the drop to recent API activity, and returns a root cause with a mitigation plan you review before you apply it.
This post connects CloudWatch monitoring to DevOps Agent. It walks through three Network Firewall failures from end to end. The first is a domain deny list blocking a legitimate endpoint. The second is a stateless rule priority misconfiguration. The third is an asymmetric cross Availability Zone (AZ) routing drop. Each maps to a different layer, so each leads down a different investigation path. An AWS Cloud Development Kit (AWS CDK) app deploys the whole environment in your own account so you can reproduce each failure and follow along.
The sample workload
As part of this blog post, we provide a CDK stack that deploys both the AWS DevOps Agent Space and a sample workload used to walk through three separate troubleshooting scenarios. A single t3.micro instance in a protected subnet checks its connectivity to a test endpoint on a continuous loop and publishes results to CloudWatch. Traffic takes the internet egress path through Network Firewall, the NAT gateway, and the internet gateway, so the firewall can intercept or drop it. After completing the walkthrough, you can apply the same troubleshooting techniques with DevOps Agent against your own Network Firewall deployments.
The test endpoint runs in a separate VPC deployed by the same CDK app. It serves HTTPS on port 443 and TCP on port 9142, giving each scenario a different protocol layer to exercise: Scenario 1 targets a TLS connection on 443 (matched by Server Name Indication), Scenario 2 targets a TCP connection on 9142, and Scenario 3 exercises the whole egress path.
A live status page shows one card per scenario plus the network topology. The whole stack deploys from a single CDK app across two Availability Zones, each with a firewall endpoint and NAT gateway, which is what makes Scenario 3 possible.
As shown in the following figure, the egress data path runs from the workload through Network Firewall and the NAT and internet gateways to the test endpoint. The alarm pipeline runs from CloudWatch through Amazon Simple Notification Service (Amazon SNS) and the webhook AWS Lambda function to DevOps Agent.
Figure 1: The sample workload
To use this with your own workload, you need a CloudWatch alarm that detects the connectivity problem and the webhook pipeline (SNS topic and Lambda function) that delivers it to DevOps Agent. The agent reads your firewall configuration, logs, and CloudTrail through AWS APIs, so no additional instrumentation is needed on the firewall side.
AWS CDK 2.x is required. You can use it through the project’s npx dependency, or install it globally:
npm install -g aws-cdk
Deploy the sample workload
Clone the project and deploy it into us-east-1 with one command (set awsRegion to use another AWS Region).
git clone https://github.com/aws-samples/sample-accelerating-aws-network-firewall-troubleshooting-with-aws-devops-agent.git
cd sample-accelerating-aws-network-firewall-troubleshooting-with-aws-devops-agent
bash scripts/deploy.sh
The script checks prerequisites, installs dependencies, compiles and tests, and bootstraps the CDK if needed. It then deploys all the stacks from a clean baseline and prints the outputs, including the status-page URL and sign-in details.
Open the status-page link (an https://<random-id>.cloudfront.net address).
Sign in using the username and password provided from the CDK output and confirm all three cards show the green Healthy status.
Keep the page open while you run the scenarios.
Connect AWS DevOps Agent
To connect AWS DevOps Agent to the alarm pipeline
In the AWS DevOps Agent console, open the nf-devops-agent-space Agent Space created by the CDK deployment.
On the status page, choose Configure webhook, paste the URL and signing secret, and save. The page writes them to the nf-devops-agent-webhook-credentialsAWS Secrets Manager secret, so there is no AWS CLI or console step. Until you set it, the bridge Lambda function sees a placeholder and skips delivery.
Verify the path before you run a scenario. In the Lambda console, open nf-devops-agent-webhook and use the Test tab with this event.
{
"Records": [
{
"Sns": {
"Message": "{\"AlarmName\":\"TEST-webhook-verification\",\"AlarmDescription\":\"[TEST] Webhook integration test - not a real alarm.\",\"NewStateValue\":\"ALARM\",\"NewStateReason\":\"[TEST] Manual webhook connectivity test. Safe to ignore.\",\"Region\":\"us-east-1\"}"
}
}
]
}
A 200 response confirms the path, and a test investigation appears in the DevOps Agent Operator Web App view.
How the alarm pipeline works
Every scenario reaches DevOps Agent the same way. A CloudWatch alarm moves to ALARM and notifies the SNS topic. Amazon SNS invokes a Lambda function. The function reads the webhook URL and signing secret from Secrets Manager, signs an alarm payload, and POSTs it to the DevOps Agent webhook (as shown in Figure 1). Amazon SNS also provides delivery retries, fan-out to other subscribers, and cross-account publishing.
Prebuilt Network Firewall metric (Scenario 1) – Alarm-1 watches the DroppedPackets metric, summed across the stateful streams, and triggers when drops rise above a baseline threshold. This requires no workload or custom metric and works on an already-deployed firewall. However, it only tells you that the firewall is dropping packets, not which rule is responsible.
Application health metric (Scenarios 2 and 3) – Alarm-2 and Alarm-3 watch a custom metric from a connectivity check. Use this for an alarm tied to user-facing impact or to tell one traffic path from another, which requires running a component that emits the metric.
Alarm
Source
Triggers when
Alarm-1
Native AWS/NetworkFirewall DroppedPackets
The firewall’s dropped-packet count rises above the baseline
Alarm-2
Custom application health metric
The port 9142 (TCP) connectivity check to the test endpoint is being dropped
Alarm-3
Custom application health metric
The cross Availability Zone connectivity check is being dropped
Run the scenarios
Work through each of the scenarios one at a time, following the same cycle. Interrupt network connectivity, watch the alarm trigger, let DevOps Agent investigate, apply the recommended fix, and confirm recovery before moving on.
The status-page cards follow the live CloudWatch alarm state. A card shows a green dot and the word Healthy when its alarm is clear, and a red dot and the word DROPPED when its alarm triggers. In the DROPPED state the card also adds a Condition: line describing what’s being dropped, which isn’t shown when the card is healthy. Network Firewall applies changes to new flows, so a change shows within a minute or two. Recovery comes from the mitigation DevOps Agent recommends, which you review and apply.
Scenario 1. Domain deny list blocking a legitimate endpoint
At baseline, the rg-domain Suricata domain rule group denies only an unused placeholder, so the test endpoint stays reachable. The rule group inspects the TLS Server Name Indication (SNI) on each outbound connection and drops any that matches a denied domain. The exact rule syntax and console steps follow.
In the navigation pane, under Network Firewall, choose Network Firewall rule groups.
Choose the rg-domain rule group to open its details page.
In the Rules section, choose Edit.
The rules box already contains two baseline placeholder rules (they match blocked.placeholder.invalid, so nothing real is denied). Leave those in place. Find the <app-endpoint-dns> value for Scenario 1 in the deployment script output (a Nework Load Balancer (NLB) DNS name such as NfTest-AppNl-a1b2C3dEf4G5-1234abcd5678efgh.elb.us-east-1.amazonaws.com). On a new line below the existing rules, add a drop rule that matches that DNS name on the TLS SNI, then choose Save.
drop tls $HOME_NET any -> $EXTERNAL_NET any (ssl_state:client_hello; tls.sni; content:"<app-endpoint-dns>"; startswith; nocase; endswith; msg:"S1 domain denylist"; flow:to_server, established; sid:2000002; rev:1;)
After saving, the rules box holds all three lines. The two placeholders remain, plus the new drop rule for the endpoint DNS name (note the distinct sid 2000002).
What happens. The workload’s HTTPS check to the test endpoint times out, the “AWS/NetworkFirewall DroppedPackets metric climbs above baseline, and Alarm-1 moves to ALARM. The Scenario 1 card reads DROPPED (with the condition Firewall dropping the monitored domain on its allow/deny rules), while the Scenario 2 and Scenario 3 cards stay Healthy (Figure 3). On the topology, the alarm pipeline from CloudWatch through Amazon SNS and Lambda to DevOps Agent and the workload-to-firewall inspect lines both turn amber, which the legend defines as collateral / alarm active, because the packets are now dropped at the firewall. To demonstrate the resulting failure, the HTTPS · SNI line from the internet gateway to the test endpoint is shown in red, which the legend defines as dropped (root cause).
Figure 3: Scenario 1 active – Traffic blocked at the firewall
Let DevOps Agent investigate. The agent runs several lines of investigation in parallel and correlates them:
Reads the DroppedPackets metric and correlates the spike with a simultaneous drop in passed packets, confirming the firewall is actively blocking traffic.
Reads the ALERT log and finds the workload’s TLS connections to the test endpoint blocked by the S1 domain denylist rule.
Compares the current state against a baseline window, where the same endpoint was reachable with no alerts, which shows the block is new.
Searches CloudTrail and surfaces the UpdateRuleGroup call that added the deny rule, identifying the user, role, and timestamp approximately one minute before the drops began.
Reports the root cause as that manual rule-group change. Recommends removing the deny entry or adding an allow exception and enabling FirewallPolicyChangeProtection to prevent unauthorized changes.
Presents this as a plan you review and apply, not an automatic change.
In the DevOps Agent Operator Web App view, the agent first restates the Alarm-1 trigger and confirms the firewall is dropping packets above the threshold (Figure 4).
Figure 4: Scenario 1 – The symptom
Next, the agent identifies the root cause: a manual update to the rg-domain rule group that added a domain deny rule (SID 2000002) shortly before the alarm fired, blocking TLS connections to the ELB endpoint (Figure 5).
Figure 5: Scenario 1 – The root cause
Finally, the agent presents a mitigation plan, recommending you remove the problematic deny rule (SID 2000002) to restore connectivity (Figure 6).
Figure 6: Scenario 1 – The mitigation plan
Note: In a real-world environment, this type of rule typically exists for a reason. Before removing it, verify whether it was intentional but scoped too broadly. If so, refine the rule to block only unauthorized endpoints rather than removing it entirely.
Confirm recovery. Apply the change the agent recommends. After the deny entry is gone, DroppedPackets falls back to baseline, Alarm-1 clears, and the card returns to green. Move on to Scenario 2.
At baseline, the rg-stateless-priority stateless rule group keeps the allow rule at priority 100 and the drop rule at 200 for the test class, TCP destination port 9142. The workload opens a TCP connection to the test endpoint on this port. Lower priority numbers evaluate first, so the allow rule wins. This scenario uses port 9142 instead of 443 to demonstrate a stateless rule, which matches on the packet’s 5-tuple (protocol, ports, addresses) rather than application content.
Introduce the change. Invert the two rule priorities so the drop rule evaluates before the allow rule. This is the kind of change a rushed rule edit can introduce.
In the navigation pane, under Network Firewall, choose Network Firewall rule groups.
Choose the rg-stateless-priority rule group to open its details page.
In the Rules section, choose Edit.
Raise the (Action: Pass) rule’s priority number so it sits after the (Action: Drop) rule, then choose Save. For example, change the (Action: Pass) rule from 100 to 300 (any number higher than the drop rule’s 200 works). You only need to move one rule, and using 300 avoids a clash with the drop rule that already sits at 200. Network Firewall evaluates the lowest priority number first, so the (Action: Drop) rule at 200 now wins for this traffic class, ahead of the (Action: Pass) rule at 300.
Figure 7: Scenario 2 – Rule priority change blocking the traffic class
What happens. The drop rule now wins, the TCP connection to the test endpoint on port 9142 times out, the StatelessRuleFailures metric climbs above baseline, and Alarm-2 moves to ALARM. The Scenario 2 card reads DROPPED (with the condition Stateless rules dropping the monitored traffic class), while the Scenario 1 and Scenario 3 cards stay Healthy (Figure 8). On the topology, the alarm pipeline from CloudWatch through Amazon SNS and Lambda to DevOps Agent and the workload-to-firewall inspect lines both turn amber, which the legend defines as collateral / alarm active, because the packets are now dropped at the firewall. To demonstrate the resulting failure, the TLS :9142 line from the internet gateway to the test endpoint is shown in red, which the legend defines as dropped (root cause).
Figure 8: Scenario 2 active
Let DevOps Agent investigate. A stateless drop happens before traffic reaches the stateful inspection engine, so it produces no ALERT log entries. The agent turns to configuration and flow logs instead:
Reads the stateless rule group state and finds the drop rule at the lower priority number, ahead of the pass rule, so the drop evaluates first.
Reads the flow logs and sees passed packets drop to zero within a minute of the change.
Searches CloudTrail and surfaces the UpdateRuleGroup call that inverted the priorities, identifying the user, role, and timestamp about a minute before the alarm.
Reports the root cause as that priority inversion. Recommends removing the redundant drop rule and managing the rule group through infrastructure-as-code (IaC) to prevent manual misconfigurations.
Presents this as a plan you review and apply, not an automatic change.
In the DevOps Agent Operator Web App view, the agent first restates the Alarm-2 trigger and confirms that a workload connectivity health check is failing because the firewall’s stateless rules are dropping egress (Figure 9).
Figure 9: Scenario 2 – The symptom
Next, the agent identifies the root cause, using the rule-group state and CloudTrail to pinpoint the conflicting DROP/PASS rules, where the new DROP rule’s lower priority number makes it match first (Figure 10).
Figure 10: Scenario 2 – The root cause
Finally, the agent presents a mitigation plan, recommending you remove the conflicting DROP rule at priority 200 to restore traffic flow (Figure 11).
Figure 11: Scenario 2 – The mitigation plan
Confirm recovery. Apply the change the agent recommends. After the allow rule is ahead of the drop rule again, Alarm-2 clears and the card returns to green. Move on to Scenario 3.
Scenario 3. Asymmetric cross Availability Zone routing drop
At baseline, the protected subnet in each Availability Zone routes its egress through the firewall endpoint in that same Availability Zone , and the matching return route uses that same endpoint. One endpoint sees both directions of the flow, so the stateful engine completes the handshake. The workload runs in the protected subnet in us-east-1a (CIDR 10.0.4.0/24), so at baseline its egress and its return both use the us-east-1a firewall endpoint.
Introduce the change. Make the flow asymmetric by sending egress out one Availability Zone endpoint while the return comes back through the other. This takes two route edits, and both are required. With only the first edit the flow can still complete, so the alarm will not trigger until both are saved. It makes no firewall-policy change, mirroring a real multi-Availability-Zone routing mistake.
To create asymmetric cross Availability Zone routing
Go to the Amazon VPC console and choose Route tables in the navigation pane.
Flip the egress. Select the NfNetworkStack/SampleVpc/protectedSubnet1 route table (the us-east-1a protected subnet, where the workload runs). On the Routes tab, choose Edit routes. Its 0.0.0.0/0 route currently targets the us-east-1a firewall endpoint. For the target, choose Gateway Load Balancer Endpoint and select the us-east-1b firewall endpoint, then choose Save changes.
Move the return. Select the NfNetworkStack/SampleVpc/publicSubnet2 route table (the us-east-1b public subnet, where egress now exits). Choose Edit routes, then Add route. For the destination enter the workload CIDR 10.0.4.0/24. For the target, choose Gateway Load Balancer Endpoint and select the us-east-1a firewall endpoint. Choose Save changes.
After both edits, a flow’s egress leaves through the us-east-1b endpoint while its return is directed to the us-east-1a endpoint. Neither endpoint sees the whole flow.
Figure 12: Scenario 3 routing change breaking the flow’s symmetry
What happens. A new connection leaves through one endpoint. Its return arrives at the other endpoint, which never saw the connection open, so the handshake fails. Unlike Scenarios 1 and 2, this affects the whole subnet, so all egress stops and Alarm-2 and Alarm-3 both move to ALARM. The AWS/NetworkFirewall DroppedPackets alarm (Alarm-1) stays quiet because no endpoint is making a drop decision. The flow is lost to asymmetric routing rather than counted as a firewall drop. This is why monitoring application connectivity matters. A routing fault is invisible to the firewall’s own drop counter. On the status page, the Scenario 2 card reads DROPPED (with the condition “Stateless rules dropping the monitored traffic class”) and the Scenario 3 card reads DROPPED (with the condition Return traffic dropped by asymmetric cross-Availability-Zone routing), while the Scenario 1 card stays Healthy (Figure 13). On the topology, the alarm pipeline from CloudWatch through Amazon SNS and Lambda to DevOps Agent and the workload-to-firewall inspect lines both turn amber, which the legend defines as collateral / alarm active, while the egress path from the firewall through the NAT gateway and the TLS :9142 and HTTPS · routing lines to the test endpoint turn red, which the legend defines as dropped (root cause).
Figure 13: Scenario 3 – The status page during a path-wide outage
Let DevOps Agent investigate. Both Alarm-2 and Alarm-3 fire in the same datapoint. DevOps Agent recognizes them as linked and merges them into a single investigation:
Reads the flow logs and sees bidirectional TLS connections stop abruptly, with only one-way traffic remaining and no flows reaching the established state.
Reads the firewall metrics and sees received and passed packets shift from one Availability Zone to the other at the moment of the change.
Calls DescribeRouteTables and finds the egress route pointing at one Availability Zone firewall endpoint while the return route points at the other.
Searches CloudTrail and surfaces the ReplaceRoute and CreateRoute calls by the same user, about a minute before both alarms fired.
Reports the root cause as that asymmetric routing change. Recommends restoring symmetric same-Availability-Zone routing so egress and return traverse the same endpoint.
Presents this as a plan you review and apply, not an automatic change.
A mitigation plan is a recommendation you review, not an automatic change, and the right fix depends on the intended design. Restoring symmetric routing can mean sending the workload subnet’s egress back through its own-Availability-Zone firewall endpoint (this sample’s architecture) or, in a design that doesn’t inspect this path, back through a NAT gateway. The agent infers a plausible target from what it can observe, so review the specific route it proposes against your intended topology before you apply it. (Connecting your pipeline or infrastructure-as-code, covered in the next section, lets the agent recommend the target that matches your design.)
In the DevOps Agent Operator Web App view, the agent restates the Alarm-3 (AsymmetricFlowFailures) trigger and confirms the workload’s egress to a monitored endpoint is being blocked by the Network Firewall (Figure 14).
Figure 14: Scenario 3 – The symptom
Next, the agent identifies the root cause: manual route table changes that created cross-AZ asymmetric routing through the network firewall, breaking its symmetric routing requirement (Figure 15)
Figure 15: Scenario 3 – The root cause
Finally, the agent presents a mitigation plan, recommending you restore symmetric routing by pointing protectedSubnet1‘s default route back to the same Availability Zone firewall endpoint, so one endpoint sees both directions of the flow again (Figure 16).
Figure 16: Scenario 3 – The mitigation plan
Confirm recovery. Apply the change the agent recommends, after checking the route target matches your intended design. After the workload subnet’s egress and return use the same Availability Zone firewall endpoint again, the control probe recovers, the alarms clear, and every card returns to green.
Further considerations
In production a single change can trigger several alarms at the same time, as Scenario 3 shows. DevOps Agent links related investigations and works them as one, so you review a single root cause. You can validate the linked findings or unlink an alarm to investigate it independently. If you would rather collapse alarms before they reach the agent, you can add correlation logic in the bridge Lambda function, buffering and grouping by firewall. You can also add email, Amazon Simple Queue Service (Amazon SQS), or HTTP subscribers to the SNS topic, or add the webhook Lambda function to a topic you already run. DevOps Agent produces a mitigation plan but does not change your environment on its own.
You can also give the agent more to work with. DevOps Agent connects to source repositories and CI/CD pipelines, integrating with GitHub (including GitHub Enterprise Server and GitLab Self-Managed through a private connection). It can associate AWS resources with deployments of AWS CloudFormation, AWS CDK, Amazon Elastic Container Registry (Amazon ECR) images, and Terraform. With deployed configuration and recent deployment events in view, the agent correlates the disruption against the change that introduced it and recommends a fix matching your intended design. For this sample, that means recommending the workload subnet’s own Availability Zone firewall endpoint rather than a generic symmetric path.
DevOps Agent also supports proactive incident prevention. It analyzes patterns across past investigations and delivers recommendations to prevent similar issues from recurring, including governance recommendations that strengthen deployment processes and pipeline controls. For Network Firewall rule changes, this means the agent can recommend guardrails for your CI/CD pipeline based on the classes of misconfigurations it has already resolved. You can access these recommendations through the Improvements page in the DevOps Agent Operator Web App.
Clean up
Clean up the environment with one command.
bash scripts/destroy.sh
It reverts any active scenario, runs cdk destroy for all stacks, and sweeps for stragglers by the Project = nf-devops-agent tag. The main cost drivers are the two Network Firewall endpoints, the NAT gateways (one in the main VPC for each Availability Zone, one in the test-endpoint VPC), and the test endpoint’s load balancers. Each of these bills at an hourly rate for as long as it’s provisioned, whether or not traffic is flowing, so a stack left running continues to accrue charges around the clock even while idle. Running the scenarios and tearing the stack down the same day limits the cost to a few active hours rather than days of idle hourly charges.
Conclusion
In this post, we showed you how AWS DevOps Agent accelerates troubleshooting for three common network firewall connectivity issues. The first was a domain deny list. The second was a stateless priority inversion. The third was an asymmetric cross-AZ routing drop. For each one, DevOps Agent investigated the drop and returned a root cause with a mitigation plan you approve before applying. The first scenario triggered on a prebuilt Network Firewall metric, and the other two on application health metrics. That shows both ways to alarm on a firewall problem through one pipeline.
The second quarter of 2026 (April–June) was largely defined by the continuing downstream effects following Microsoft’s Digital Crimes Unit-led disruption efforts against the Tycoon2FA phishing-as-a-service (PhaaS) platform in March. Phishing volume linked to the platform fell 92% from pre-disruption averages, including QR code phishing and CAPTCHA-gated phishing both declining from their March highs. Despite ongoing efforts to rebuild operations, Tycoon2FA did not recover its previous scale or influence during Q2, and no single service emerged to replace the platform at comparable scale.
These trends reflect both the measurable impact that disruption operations can have on phishing ecosystems and the adaptability of threat actors as they diversify delivery channels. At the same time, Microsoft Threat Intelligence observed continued growth in Teams-based social engineering, particularly voice phishing (vishing), with weekly malicious call attempts reaching nearly ten times the mid-2025 baseline by the end of the quarter. This activity illustrates how threat actors continue to expand beyond email into trusted workplace communication platforms where communications may appear more trustworthy to users.
Microsoft detected approximately 7.6 billion email-based phishing threats throughout the quarter, with monthly volumes declining modestly from 2.7 billion in April to 2.4 billion in June. Credential phishing remained the dominant objective behind malicious payloads, while business email compromise (BEC) activity largely returned to historical norms after a brief, anomalous surge in April. Notable campaigns observed during the quarter also demonstrated how threat actors combine automation, trusted services, and multi-stage delivery chains to scale operations. These campaigns ranged from an automated BEC campaign that reached more than 67,000 users across 42,000 organizations in under three hours, to a multi-stage phishing campaign that used nested EML files, calendar invitations, and a Microsoft authentication redirect to deliver malware.
This blog provides a view of email threat activity across the second 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 and CAPTCHA-gated phishing activity, malicious payload trends, BEC activity, the growth of Teams-based threats, and notable campaigns observed during the quarter. We also provide recommendations and Microsoft Defender detections to help organizations identify and mitigate evolving threats while prioritizing defensive measures.
Tycoon2FA Q2 disruption impact
The disruption operation that Microsoft’s Digital Crimes Unit launched against Tycoon2FA infrastructure in early March continued to produce measurable results throughout Q2 2026. After falling 15% in March and another 22% in April, Tycoon2FA-linked phishing volume dropped 74% in May to just 1.5 million messages, then fell another 20% in June to 1.2 million, by far the lowest monthly volumes observed in at least a year. For reference, the average monthly volume of phishing messages linked to Tycoon2FA during the second half of 2025 was 15.1 million. By the end of Q2, volumes were running at roughly 8% of that baseline, representing a 92% total decline since the disruption operation began.
Tycoon2FA’s influence across two primary phishing tactics, QR code lures and CAPTCHA-gated landing pages, also continued to decline throughout the quarter:
CAPTCHA-gated phishing: Tycoon2FA’s share of CAPTCHA-gated phishing sites fell from 41% in March to 16% in April and 12% by June, down from a peak of 76% in December 2025.
QR code phishing: The share of QR code campaigns redirecting to Tycoon2FA domains decreased from 20% in March to 17% in April and 14% by June, down from a peak of 33% in November 2025.
These declines indicate that the platform’s customer base has not migrated to replacement infrastructure at anything close to the scale they previously operated.
After being forced off Cloudflare, which had provided anti-analysis protection that made Tycoon2FA pages harder to scan and take down, the service continued to rely on infrastructure hosted on the .RU top-level domain (TLD), a shift that began in late March. More than 40% of newly observed Tycoon2FA domains used .RU registrations throughout Q2. While this reflects an ongoing effort to find replacement hosting, Tycoon2FA’s role in the phishing ecosystem has nonetheless been significantly diminished and the pace of recovery has been slow.
QR code phishing attacks
After peaking at 18.7 million attacks in March, the highest monthly volume in at least a year, QR code phishing declined for three consecutive months in Q2. Volume fell 7% in April to 17.4 million, then dropped more sharply in May (-38%) and June (-22%), closing the quarter at 8.3 million attacks. By June, QR code phishing had returned to levels last seen in mid-2025.
Figure 2.Trend of QR code phishing attacks by weekly volume (January 2026–June 2026)
The delivery methods used in QR code attacks shifted notably during Q2. PDF attachments remained the dominant vehicle throughout, but their dominance weakened after April:
PDF attachments peaked at 79% of QR code attacks in April before falling to 59% in May and 58% in June. By raw volume, malicious PDFs containing QR codes dropped more than 60% between April and June.
DOC/DOCX attachments moved in the opposite direction, increasing 30% in May to account for 38% of QR code payloads, the highest share since December 2025. By June, DOC/DOCX payloads reached 40% of QR code attacks. This swap between PDF and DOC/DOCX dominance is a pattern that has recurred throughout the past year, as operators appear to rotate between delivery formats.
Email-embedded QR codes, which had surged 336% in March and accounted for 5% of QR code attacks, effectively disappeared in Q2. This delivery method dropped to near-zero across all three months, leaving QR code phishing almost entirely an attachment-based tactic.
Figure 3. QR code phishing delivery method share by month (January-June 2026)
CAPTCHA-gated phishing tactics
After accumulating to nearly 12 million attacks in March, the highest monthly volume observed over the past year, CAPTCHA-gated phishing declined sharply throughout Q2. Volume fell 32% in April to 8.2 million, then dropped another 65% in May and 24% in June, closing the quarter at just 2.2 million attacks. Since the March peak, CAPTCHA-gated phishing has fallen more than 81%, reaching its lowest monthly volume in more than a year.
The rapid rotation of delivery methods that characterized Q1 continued into Q2, with no single payload type maintaining the top position for more than one or two months:
PDF attachments surged to 63% of CAPTCHA-gated attacks in April, the highest single-payload share observed in the past year, after more than quadrupling in March. This dominance was short-lived, however. PDF volumes dropped 69% in May and another 70% in June, falling to just 22% of attacks by the end of the quarter.
HTML attachments, which had been a major delivery vector through January (37% of attacks), declined sharply during Q2. After declining to 8% in April, HTML payloads fell to just 3% in May before recovering slightly to 5% in June, their lowest sustained share in at least a year.
SVG files reached their lowest observed volume in April (5% of attacks) before rebounding to 12% in May and 26% in June. While still well below the levels seen when Tycoon2FA actively used SVG files, this gradual recovery bears monitoring.
Email-embedded URLs reclaimed the top position in June for the first time since December 2025, accounting for 30% of CAPTCHA-gated attacks. This was more a function of every other delivery method declining in raw volume than a resurgence in URL-based delivery. The actual volume of URL-delivered CAPTCHA-gated phish in June was still far lower than most months over the past year.
DOC/DOCX files declined from their March spike, falling steadily from 15% to 10% of attacks over the quarter.
Figure 5. CAPTCHA-gated phishing distribution method share by month (January-June 2026)
Tycoon2FA’s continued decline was a significant factor in the overall volume reduction. The platform’s share of CAPTCHA-gated phishing fell from 41% in March to 16% in April, 18% in May, and 12% by June, down from a peak of 76% in December 2025. No single service has emerged to fill the gap at comparable scale, contributing to the sustained decline in CAPTCHA-gated phishing activity overall.
Malicious payloads
Credential phishing continued to dominate the malicious payload landscape throughout Q2, accounting for 94–96% of all payload-based attacks each month. 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 represented just 4–6% of payloads, consistent with its long-term decline.
HTML and PDF attachments remained the two most common malicious payload types across the quarter, together accounting for roughly 60–70% of all payload-based attacks each month:
HTML attachments held the top position across all three months at 35–41% of attacks. After peaking in April, HTML payload volume declined 33% in May and another 17% in June.
PDF attachments consistently ranked second at 24–31% of attacks. PDF volume was relatively stable in April before declining 41% in May and 4% in June.
SVG files continued the decline that has tracked closely with Tycoon2FA’s diminishing activity. After peaking at 23% of malicious payloads in July 2025, SVG’s share fell to around 7% by Q2, consistent with SVG’s historical role as a preferred Tycoon2FA payload format.
DOC/DOCX and ZIP/GZIP files oscillated without a clear directional trend. DOC/DOCX increased 26% in May before falling 17% in June, while ZIP/GZIP attachments declined 48% in April, rebounded 27% in May, then dropped 40% in June.
ICS files (calendar invitations), while still a small share of overall payload volume (roughly 4%), nearly quadrupled in June (+277%). These attacks take advantage of the fact that calendar invitations are processed differently than standard email attachments and can inject malicious links into a user’s calendar without requiring an explicit open-and-click interaction.
EXE files continued to decline, falling to their lowest monthly volume in June, reflecting the broader shift away from traditional malware delivery via email attachments.
Figure 6. Malicious payload file type (Q2 2026)
Business email compromise
April 2026 produced the most anomalous BEC data point in more than a year: nearly 9 million attacks, a 121% increase from March and more than double any previous month. The spike was short-lived as volume fell 62% in May to 3.4 million and settled at 3.9 million in June, both figures consistent with the monthly baseline that had held throughout the prior year. The April surge appeared to be driven by a small number of high-volume campaigns rather than a fundamental escalation in BEC activity.
The composition of BEC attacks remained consistent throughout Q2. Generic outreach messages (like “Are you at your desk?”) accounted for 87–92% of initial contact emails each month, while explicit requests for specific financial transactions or documents represented just 3–8%. This pattern underscores that BEC operators overwhelmingly favor establishing conversational rapport with targets before making fraudulent requests, rather than leading with direct financial asks.
Figure 8. Initial BEC email content by type (Q2 2026)
Within the smaller subset of explicit financial requests, the most notable trend was the near-disappearance of fake invoice payment requests:
Invoice payment requests fell 67% in May and another 77% in June, reaching their lowest volume in more than a year. By June, invoice-themed BEC accounted for less than 0.4% of all attacks, down from around 3.6% in March.
Payroll update requests declined moderately across the quarter, from roughly 4% of attacks in March to 2.3% by June.
Gift card requests remained at roughly 1–4% of attacks, with no clear directional trend.
Microsoft Teams threats
While email remains the dominant initial access vector, threat actors increasingly abused Microsoft Teams during Q2 to deliver social engineering, phishing, and malware payloads. Unlike email, Teams traffic typically bypasses secure email gateways and benefits from the perceived legitimacy of a colleague-initiated chat, which can make lures particularly effective in this environment.
Teams-based phishing volume climbed steadily throughout Q2, with the average number of detected attacks rising 19% from March to April, holding roughly flat into May (+1%), then increasing another 10% into June. Financial and executive impersonation has remained largely absent from Teams-based attacks over the past several months.
Figure 9. Weekly observed malicious Microsoft Teams calls (January-June 2026)
The dominant lure theme remained technical support impersonation, with attackers posing as an employee’s information technology (IT) help desk, typically warning of an impending account lockout. However, the way attackers presented themselves continued to evolve:
Display names shifted away from IT- or help desk-branded identities. For the second consecutive month, more than half (52%) of Teams-based phishing attacks in June used generic display names rather than obvious IT support impersonation.
Attacker email addresses associated with these chats moved away from support-themed domains toward software-as-a-service (SaaS) terminology, scan/update language, and infrastructure keywords. This shift may align with the broader rise of ClickFix-style attacks adopting update-fix and similar themes.
Figure 10. Malicious Teams call impersonation percentage (Q2 2026)
Vishing through Teams showed the steepest growth of any threat category tracked in this report during Q2. Average weekly malicious call attempts rose 31% from April to May and another 27% into June, with the final two weeks of June recording the two highest weekly volumes on record. Since the beginning of 2026, weekly vishing attempts have increased roughly 80% and now run at nearly ten times the mid-2025 baseline. Attackers time these calls deliberately when targets are most likely to be online and active, with the heaviest activity falling between 14:00 and 20:00 UTC, Monday through Friday, with near-zero weekend activity. Notably, a growing share of these calls go unanswered, end quickly, or are rejected outright, partly reflecting Microsoft’s ongoing efforts to harden the Teams attack surface and improve protections against social engineering abuse.
Automated BEC campaign scales aging report and payroll diversion lures
On June 1, 2026, Microsoft Defender Research observed a high-volume BEC campaign that used automation to operate at scale. Over a send window of under three hours (14:08–16:52 UTC), the actor reached more than 67,000 users across more than 42,000 organizations, almost exclusively in the United States. Targeting spanned a broad range of industries rather than a single vertical, most notably retail and consumer goods (17%), technology and software (15%), and financial services (14%). The campaign ran two lures in succession from shared infrastructure: arequest impersonating sales executives to obtain aging report data and customer contact details, and a payroll diversion pretext impersonating the CEO or President to redirect salary payments to attacker-controlled bank accounts.
Figure 11. Timeline of campaign messages sent by minute, separated by lure theme
Delivery was fully scripted. The messages were generated programmatically using Python’s email.mime library, identifiable from its default MIME boundary format (===============[integer]==), and dispatched through the Amazon Simple Email Service (SES) API rather than a manual webmail interface, as indicated by the SES Feedback-ID and Message-ID formats. This allowed the actor to iterate through a recipient list and inject per-message variables (like spoofed executive display names, recipient addresses, and unique tracking identifiers) at volume. Messages were sent from a DomainKeys Identified Mail (DKIM)-configured Slovak domain (ecajovna[.]sk) through SES, so they passed Sender Policy Framework (SPF) and achieved DKIM alignment. Neither lure contained a malicious link or attachment; both relied on eliciting a reply to attacker-controlled mailboxes that mimicked legitimate providers (ilyff[.]com, j-gmails[.]com, x2mails[.]com).
Automation also extended to targeting and follow-up. The actor addressed generic role-based mailboxes (like “ar”, “accountsreceivable”, “hr”, “payroll”) rather than named individuals, reducing per-target effort. Each message embedded a 1×1 open-tracking pixel served from an Amazon SES engagement subdomain, with per-message identifiers that let the actor confirm which recipients opened the email and prioritize follow-up against those targets. The combination of scripted message generation, API-based bulk delivery, role-based targeting, and automated engagement tracking allowed a single actor to run a personalized, financially motivated BEC operation at a scale not practical to execute manually.
Figure 12. Rendered example of aging report email used in this campaignFigure 13. Rendered example of payroll diversion email used in this campaign
Staff update campaign with nested EML file and calendar invitation leads to BAT file dropper
Between June 14–15, 2026, Microsoft Defender Research observed a phishing campaign targeting more than 107,000 users across nearly 19,000 organizations, almost exclusively in the United States. The campaign targeted a broad range of industries rather than a single vertical, most notably financial services (17%), technology and software (14%), and retail and consumer goods (14%). Emails impersonated an internal “Internal Affairs – Financials & Staff Updates” function at the recipient’s own organization, with the display name and subject line both opening with the recipient’s organization name and closing with constant trailing text. The messages were sent from a Postfix host on 9i6pokerdepot[.]com routed through Barracuda’s outbound mail service, and DKIM passed cleanly for the sending domain.
Figure 14. Rendered sample of initial campaign email
The visible email body contained minimal content. One line told the reader to download the attached file for the meeting summary, followed by a confidentiality notice. Each message carried two attachments: a nested EML posing as a Teams archive recording, and an ICS calendar invite addressed to placeholder administrative accounts at the recipient’s domain. The nested EML’s file name retained an unfilled template token ( {{DATE2}} ), indicating a per-recipient templating tool.
When opened, the EML displayed a voicemail notification with a single action button. That button pointed to Microsoft’s OAuth sign-in endpoint at login.microsoftonline[.]com, with parameters that asked for a silent sign-in attempt against an Entra application that the attacker had registered as multi-tenant.
Figure 15. Rendered sample of voicemail notification from the nested EML
Because no active sign-in session could satisfy the silent request, Microsoft’s authentication service redirected the recipient to the destination the attacker had pre-registered on the application. That destination was a path on clickup-attachments[.]com, ClickUp’s public attachment host, and served a Windows batch file named Financial_report.bat. Because the link routed through Microsoft authentication infrastructure, both recipients and URL scanners saw a login.microsoftonline[.]com link.
The batch file ran a hidden PowerShell command that pulled installer.exe from pixeldrain[.]com, saved it under the user’s Temp directory, ran it with a silent flag, and deleted the dropper on exit. Rather than stealing credentials, the campaign ultimately resulted in silent malware execution on the user’s Windows device.
Figure 16. Source code of Financial_report.bat
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.
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.
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.
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 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 (IOCs)
Indicator
Type
Description
First seen
Last seen
9i6pokerdepot[.]com
Domain
Sending domain; DKIM-signed by the operator
2026-06-15
2026-06-15
Customer.Service[@]9i6pokerdepot[.]com
Email address
Campaign sender address
2026-06-15
2026-06-15
t90141296286.p.clickup-attachments[.]com
Domain
ClickUp attachment subdomain hosting the stage 2 BAT dropper
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
Cybercriminals are increasingly moving away from complex malware, relying instead on social engineering that exploits a common user habit: mindlessly clicking through endless digital rituals like CAPTCHAs, cookie consents, and authentication prompts. This habit is often targeted by various kinds of the ClickFix technique, which threat actors have been actively using lately. Researchers recently discovered a new variant of this technique, which they dubbed ConsentFix. It allows attackers to gain unauthorized access to Microsoft 365 accounts via OAuth — a highly popular vector right now — thereby completely bypassing the need to steal passwords. For organizations, these attacks present a severe risk of compromised corporate email, exposed documents, and breached cloud resources.
How ConsentFix works
Social engineering lies at the core of all ClickFix variations. Attackers prompt the user to follow a seemingly harmless set of instructions, which actually lead to the compromise of their device or account. In the case of ConsentFix, these instructions are designed to trick the user into granting the attacker access to their Microsoft 365 account.
The attack begins by making the user believe they must authenticate with their Microsoft account to access a specific page or document. To do this, cybercriminals usually send an email containing a link to a website typically imitating a popular file-sharing service. Attempting to access a specific document on this site prompts the user for verification, which can be obtained by following this sequence of actions:
Clicking Verify with Microsoft.
Signing in to the work account, at which point the attackers warn that multi-factor authentication (MFA) may be required.
After being redirected to a new page, waiting until “localauth” appears in the address bar.
Dragging the information icon ⓘ from the browser’s address bar into a drop zone on the page.
In practice, following these instructions causes the user to drag an URL containing a session OAuth token directly onto the attacker’s page. This token is exactly what grants the attackers access to the victim’s email and other Microsoft 365 services.
The potential fallout of a Microsoft 365 session compromise
At first glance, it might seem like attackers only gain access to a mailbox. In reality, the consequences can be significantly more severe. The attacker’s specific capabilities depend on the organization’s Microsoft 365 license, the services deployed, and the privilege level of the compromised account.
Even compromised corporate email alone is a major breach. The attacker not only gains access to email archives that may contain confidential business intelligence, but also can send phishing messages or launch internal BEC attacks on behalf of the user.
Beyond email, attackers are highly likely to gain access to the victim’s Microsoft Teams account, providing them with even deeper insights and broader leverage for various scams. Access to OneDrive and SharePoint is equally dangerous: it allows attackers to exfiltrate corporate documents, upload malware into cloud storage, tamper with existing files, and more. Ultimately, this creates a launchpad for moving laterally within the corporate infrastructure.
Publicly available attack blueprints
According to a Bleeping Computer article, the mechanics of ConsentFix are no secret. Attackers share detailed implementation guides on cybercrime forums, offering not only ready-to-use code but also video tutorials demonstrating how to deploy the attack. They also actively trade tips on how they harvest intelligence on organizations and their employees via LinkedIn and other OSINT channels to craft highly convincing phishing messages.
Collectively, this significantly lowers the barrier to entry for novice cybercriminals. As these guides and turnkey tools continue to proliferate, ConsentFix attacks will likely become increasingly common. Consequently, organizations should immediately factor this technique into both their defense strategies and employee awareness training programs.
How to secure your corporate infrastructure
The emergence of this new ClickFix variation demonstrates that simply blocking a specific keyboard shortcut or an isolated risky action on employee devices is not enough. Clearly, attackers quickly adapt to these measures. Therefore, to protect an organization from these types of attacks, we recommend the following:
Be sure to deploy a robust security solution at the mail gateway level — this minimizes the likelihood of attackers successfully luring your employees to a page hosting the ConsentFix mechanism.
Conduct regular cybersecurity awareness training for employees to keep them ahead of the latest social engineering tactics. Our training platform, Kaspersky Automated Security Awareness Platform, can assist with this initiative.
From late April 2026 to mid-June 2026, Microsoft Defender Experts observed increased ACR Stealer activity across customer environments. These campaigns are successfully using ClickFix lures to steal browser credentials, authentication tokens, and sensitive documents from enterprise environments. Successful compromise can expose browser credentials, session tokens, authentication artifacts, and sensitive enterprise data, potentially enabling account compromise, unauthorized access to cloud resources, and follow-on intrusion activity. Security teams should prioritize monitoring for ClickFix lures, suspicious WebDAV activity, obfuscated PowerShell execution, and attempts to access browser credential stores.
ACR Stealer is an information-stealing malware family reportedly offered through a malware-as-a-service (MaaS) model and associated with the rebranding of Amatera Stealer. During this period, two campaigns stand out, together appearing frequently in reviewed recent intrusions. Both begin the same way, with a ClickFix social engineering technique that tricks targets into running the threat actor’s command, but the intrusion chains that follow diverge in how they deliver payloads, establish execution, and evade detection.
The first campaign relies on WebDAV-delivered payloads, staged PowerShell, Python-based loaders and persistence, and, in some intrusions, blockchain-backed dead-drop command-and-control (C2) resolution. The second campaign takes a more fileless route, using MSHTA, obfuscated PowerShell, and steganography-assisted in-memory execution. Despite these differences, both campaigns ultimately pursue the same goal: stealing browser-stored credentials and other sensitive data for exfiltration.
These two campaigns represent some of the most prevalent ACR Stealer delivery campaigns observed by Defender Experts; however, they do not represent the full range of delivery methods used by this malware family. Attribution to ACR Stealer is based on the observed behavior and post-exploitation tradecraft, corroborated by open-source intelligence on the infrastructure associated with this malware family. Additional campaigns, infrastructure patterns, and execution chains are likely active, and organizations should treat the indicators and techniques described here as representative.
Microsoft Defender for Endpoint can help surface both campaigns through behavioral coverage for living-off-the-land execution, suspicious WebDAV and MSHTA activity, obfuscated PowerShell, scheduled-task persistence, in-memory payload execution, and browser credential theft. In this blog, we analyze both campaigns in detail, including their delivery mechanisms, post-exploitation tradecraft, indicators of compromise, hunting opportunities, and guidance to help defenders detect and disrupt related activity in their environments.
Campaign 1: WebDAV-based ClickFix with Python loaders and blockchain C2
Initial access
In this campaign, a ClickFix prompt, likely delivered through malvertising or SEO-manipulated search results, instructs the target user to run a command that launches cmd.exe. The command subsequently invokes rundll32.exe to load a DLL from a remote WebDAV share accessed over HTTPS. The WebDAV path commonly uses a GUID-based directory structure and filenames designed to resemble legitimate resources (for example, google.ct), enabling the activity to blend with expected network traffic and evade casual inspection.
We observed three variants of the initial execution command:
Variant 1: Direct rundll32 invocation
Variant 2: pushd-Mounted WebDAV Share
Variant 3: Headless and obfuscated pushd execution
Variants 2 and 3 are notable for their use of pushd, which transparently maps the remote WebDAV share to a temporary local drive prior to execution. This technique allows threat actors to execute remotely hosted content through what appears to be a local path, simplifying payload execution while reducing user awareness. In the more advanced variant, threat actors further enhance stealth by launching commands through conhost.exe –headless, suppressing visible console windows, and employing environment variable obfuscation with delayed variable expansion to conceal critical execution components such as pushd, rundll32, and the remote host name. Combined with minimized or headless execution, these techniques reduce user visibility, complicate static analysis and detection, and enable the infection chain to execute with minimal indication to the victim.
Execution, persistence, and evasion through process masquerading
Once rundll32.exe loads the DLL retrieved from the remote server, the malware establishes communication with threat actor-controlled infrastructure and executes a heavily obfuscated PowerShell script. The script employs excessive arithmetic no-ops, dead loops, fake control flow, and randomized variable names to hinder static analysis and evade signature-based detection.
The PowerShell script subsequently deploys another stage that functions as both a malware installer and a persistence mechanism. It:
Downloads a ZIP-packaged payload from a remote server and extracts it into a deceptive directory under %LocalAppData%\Temp (for example, LogiOptionsPlus).
Launches a Python script using a bundled pythonw.exe instance to avoid displaying a console window.
Removes previous deployments and terminates running instances before installation, effectively operating as an updater.
Establishes persistence through a hidden scheduled task disguised as a legitimate software update, ensuring execution at user sign-in.
Copies timestamps from a trusted Windows binary (notepad.exe) to the deployed files and clears PowerShell command history to reduce forensic visibility.
PowerShell loader downloads and executes a payload through a masqueraded scheduled task.
Python loader launching the stealer
The Python component serves as a heavily obfuscated loader designed to conceal its true functionality until runtime. It employs multiple layers of defense against static analysis, including dynamic API resolution, encoded string reconstruction, junk-data removal, character shifting, string reversal, Base64 decoding, and zlib decompression. These techniques ensure that the embedded payload remains unreadable in its static form and is reconstructed only during execution, significantly hindering signature-based detection and automated analysis.
Once decoded, the final-stage payload functions as an in-memory shellcode loader. It extracts an archive file masquerading as a legitimate application installer, reads a file from the archive, and injects the payload into a system process. The loader allocates executable memory using VirtualAlloc, copies the payload into the allocated memory region, and transfers execution through the Windows Fiber API (ConvertThreadToFiber, CreateFiber, and SwitchToFiber). This technique facilitates stealthy in-memory execution while minimizing artifacts written to disk.
Decoded Python shellcode loader using VirtualAlloc and Fiber-based execution.
Credential theft and data staging for exfiltration
The malware (injected code) aggressively harvests information from browser credential stores. It invokes Windows Data Protection API (DPAPI) routines to decrypt locally stored browser passwords, cookies, and authentication tokens. It also enumerates files across the system, targeting PDFs, Microsoft 365 documents, and data stored in enterprise-synchronized directories such as OneDrive and SharePoint. The collected data is subsequently archived, indicating preparation for exfiltration.
Blockchain dead-drop C2 resolution
A notable variation in this campaign is the use of blockchain services for C2 resolution, utilizing a technique known as EtherHiding. While most intrusions rely on more conventional C2 mechanisms, a subset deploys an additional secondary Python loader that leverages blockchain services as dead-drop resolvers. When this loader executes, it has been observed communicating with public blockchain RPC endpoints and third-party Web3 node infrastructure, likely querying data stored on a decentralized public ledger to retrieve follow-up payloads or a C2 address.
By externalizing C2 information to the blockchain, operators could dynamically update infrastructure without modifying or redeploying the malware, significantly complicating detection and takedown efforts. This behavior was observed across both variants of the campaign.
Campaign 2: MSHTA-initiated PowerShell chain with steganographic payload delivery
The second campaign takes a distinctly different approach to both delivery and execution. Where Campaign 1 relies on disk-based artifacts (Python runtime, scheduled tasks, and masquerading binaries), this campaign achieves its objectives almost entirely through fileless, in-memory execution, making it harder to detect through file-based scanning and forensic analysis.
Initial access through MSHTA and ClickFix
The execution chain begins when the victim, directed through malvertising or SEO-manipulated search results, encounters a ClickFix prompt that triggers a command spawning MSHTA to fetch and execute remote HTA content from an threat actor-controlled domain. The embedded VBScript loader abuses COM objects to decode and execute encoded PowerShell content.
VBScript loader using COM objects to decode and launch a PowerShell payload.
PowerShell downloader and obfuscation
The decoded PowerShell stage employs obfuscation techniques similar to those seen in Campaign 1: randomized variable names, arithmetic no-op operations, dead loops, misleading control flow, and custom encryption routines. Prior to contacting its next-stage infrastructure, the malware generates a victim-specific identifier and disables certificate validation. The retrieved content is executed directly in memory.
Steganography-based payload delivery
A notable technique in this campaign is the use of steganography to conceal malicious content inside a publicly hosted image. Instead of downloading a secondary script (as in Campaign 1), the malware retrieves a JPEG image from an image-hosting service.
Steganographic payload extraction from a downloaded image prior to decryption and execution.
Analysis of the script revealed custom routines that extract an embedded payload from image pixels, decrypt and decompress it, and execute it entirely in memory. The payload dynamically resolves APIs such as LoadLibrary, GetProcAddress, VirtualAlloc, CreateThread, and WaitForSingleObject at runtime to perform reflective shellcode execution. By combining steganography with in-memory execution, the malware minimizes on-disk artifacts and complicates both detection and analysis.
Credential theft, data collection, and exfiltration
Following execution, the malware accesses credential stores belonging to Chromium-based browsers, including Google Chrome and Microsoft Edge, specifically the Login Data and Web Data databases, alongside Windows DPAPI decryption activity. This behavior indicates attempts to recover stored browser credentials, session cookies, authentication tokens, and other sensitive user information.
The malware also enumerates and accesses multiple high-value PDF documents across Desktop and Downloads locations, suggesting targeted collection of potentially sensitive files. The combination of browser credential harvesting and systematic document access points to an information-stealing objective focused on staging credentials and valuable user data for exfiltration.
Mitigation and protection guidance
Microsoft recommends the following mitigations to reduce the impact of ClickFix lures, script-based payload delivery, credential theft, and post-compromise activity.
Educate users to recognize ClickFix-style prompts, fake verification checks, and paste-and-run instructions as malicious, especially when they invoke command interpreters or script hosts such as cmd.exe, PowerShell, rundll32.exe, or mshta.exe.
Reduce exposure to malvertising, SEO poisoning, and other web-based delivery chains by enforcing web filtering, blocking low-reputation or newly observed domains, and limiting access to remote content sources that are not required for business operations.
Use application control and attack surface reduction rules to restrict PowerShell, Python, mshta.exe, rundll32.exe, and similar tools from launching untrusted or internet-delivered content, particularly from user-writable directories such as Downloads, Temp, and %LocalAppData%.
Monitor for suspicious persistence and defense-evasion behavior, including scheduled tasks masquerading as software updates, timestomping, PowerShell history clearing, and execution chains that progress from remote content retrieval into PowerShell, Python, or shellcode-loading behavior.
Investigate abnormal access to Chromium-based browser databases, DPAPI-related decryption activity, staged collection of Microsoft 365 documents or PDFs, and compression activity that may indicate credential theft or data staging for exfiltration.
If compromise is suspected, isolate affected devices, rotate exposed credentials, revoke potentially compromised tokens, review persistence mechanisms, and investigate outbound connections to remote shares, image-hosting services, or other infrastructure used to resolve or retrieve follow-on payloads.
Harden endpoints against credential theft by reducing reliance on browser-stored credentials, enforcing multifactor authentication and conditional access, and reviewing how privileged accounts access sensitive applications and synchronized enterprise data.
Turn on cloud-delivered protection and behavior-based detections to help identify rapidly evolving threats, suspicious script execution, in-memory payload delivery, abuse of browser credential stores, and unusual child-process activity.
Harden PowerShell by enforcing appropriate execution policies, turning on script block logging, module logging, and transcription, and monitoring this telemetry for signs of malicious script activity.
Turn on tamper protection and prevent local administrators from weakening antivirus protection through local policy or exclusion changes.
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.
Tactic
Observed Activity
Microsoft Defender Coverage
Execution
– Suspicious MSHTA launch through ClickFix execution – Rundll32 loads remote WebDAV DLL – COM objects launch in-memory PowerShell
Microsoft Defender for Endpoint – Use of living-off-the-land binary to run malicious code – Obfuscated command line was launched – Suspicious process executed PowerShell command – Suspicious process launch by Rundll32.exe
Microsoft Defender for Antivirus Behavior:Win32/Interhta.Int
Persistence
PowerShell creates Scheduled task, masquerading as a software update
Microsoft Defender for Endpoint – Suspicious Scheduled Task Process Launched – Suspicious scheduled task
Stealth/Defense Evasion
– Fiber-API in-memory shellcode execution – Reflective shellcode via CreateThread
Microsoft Defender for Endpoint Possible process hollowing
Credential Access
Collects browser credentials, cookies, and tokens while enumerating files for exfiltration
Microsoft Defender for Endpoint – Information stealing malware activity – Suspicious DPAPI activity – Possible theft of passwords and other sensitive web browser information
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.
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 current information available in the Defender portal about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to help prevent, mitigate, or respond to associated threats found in customer environments:
Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.
Advanced hunting queries
Microsoft Defender XDR customers can run the following advance hunting queries to find related activity in their networks:
Run the query below to identify suspicious commands executed through ClickFix-based activity observed while delivering this stealer
DeviceRegistryEvents
| where RegistryKey has "RunMRU"
| where (RegistryValueData has_all ("rundll32", "@ssl", " /c ", " start ") and (RegistryValueData matches regex @"\\\\[^\\]+@ssl\\[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}\\\w+\.\w+,#1" or
RegistryValueData matches regex @"(?i)pushd \\\\[^\\]+@ssl\\[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12} "))
or RegistryValueData has_all ("@ssl", " /c ", "conhost --headless ") and RegistryValueData contains "rundll32"
Run the query below to identify scheduled task creation used for persistence by a malicious PowerShell script
DeviceProcessEvents
| where InitiatingProcessFileName =~ "powershell.exe"
| where InitiatingProcessCommandLine has_all ("-Command", "powershell")
| where ProcessCommandLine has_all ("schtasks", " /run /tn ", " Autoupdate ") and ProcessCommandLine matches regex "[0-9]{8}"
Run the query below to identify suspicious MSHTA launch through PowerShell
DeviceProcessEvents
| where InitiatingProcessParentFileName has "explorer.exe"
| where InitiatingProcessFileName =~ "powershell.exe" and InitiatingProcessCommandLine in~ ('"PowerShell.exe" ', '"PowerShell.exe"')
| where ProcessCommandLine has_all ('"mshta.exe" https://') and ProcessCommandLine matches regex "/[0-9]{7}"
MITRE ATT&CK techniques observed
The following mapping summarizes the primary tactics and techniques observed across the two ACR Stealer intrusion chains. The mapping is intended to help defenders align observed behaviors with existing detection coverage, response playbooks, and hunting priorities.
Tactic
Technique
Observed behavior
Initial Access
Drive-by Compromise; User Execution
ClickFix lure prompts command execution.
Execution
Command and Scripting Interpreter: Windows Command Shell; PowerShell; Python
cmd.exe, PowerShell, and pythonw.exe launch staged payloads.
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.
Login
