Malicious extensions and ClickFix attacks are two hugely popular topics on our blog, and for a good reason: they’re both very common. In this post, we bring them together. Here’s the thing: in our posts about malicious ClickFix instructions, we don’t always explain exactly how users end up on the attackers’ pages in the first place. A recent study gives us a chance to fill that gap and talk about one of those methods: malicious extensions.
Readers who are not deep into cybersecurity may already have a bunch of questions at this point: how can extensions be malicious? where do they come from? and what exactly is ClickFix, anyway? Fret not: this post answers all these questions.
The danger of browser extensions
Let’s start with the basics. Browser extensions or add-ons are lightweight tools installed in your browser to give it extra capabilities or change how it works with web pages. For example, extensions can block ads, translate pages, download audio and video, save passwords, or take screenshots.
Most browser developers offer users an official extension store. For instance, for the most popular browser, Chrome, that store is the Chrome Web Store. There are also alternative platforms for distributing extensions, though browser developers have recently made it much harder to install and use extensions that don’t come from an official source.
Just like any other software, extensions can be useful, but they can also be malicious. In fact, cybercriminals often spread malicious extensions through those very same official stores, and we’ve covered plenty of such cases on our blog before.
It’s no accident that criminals love spreading malicious plug-ins. To work properly, most extensions need permission to read and modify the content of every web page the user visits. Without that permission, add-ons would be basically useless. For instance, a translation extension needs to read all the text on a page before it can swap the original for the translation.
Cybercriminals take advantage of these capabilities for their own purposes: for example, they intercept logins, passwords and other data entered on websites, swap out payment details, or show victims fake forms and messages. And all of this happens on legitimate sites that users have come to trust without a second thought.
Almost twenty malicious extensions for Chrome and Edge
In late August, cybersecurity researchers reported finding 18 malicious extensions for Chrome and one for Edge. They said all 19 add-ons were probably linked to the same campaign. They base this on the similarity of the malicious code and the methods the attackers used. You’ll find the full list of malicious extensions at the end of this post.
Most of the extensions discovered, 14 in total, were built by the attackers themselves. Their first versions weren’t malicious at all and did exactly what users downloaded them for. But after a while, once users had come to trust the add-on, the attackers pushed an update that slipped in malicious functionality.
As for the remaining five extensions, their creators had nothing to do with the cybercriminals at all. They simply sold their creations to them. This way of getting hold of extensions is also popular among cybercrooks. There are plenty of reasons for that: ready-made add-ons can be bought for relatively little money, and criminals don’t have to build or promote them from scratch. And most importantly, along with the extension, they also inherit its existing user base. Upon buying the add-on, all the attackers need to do is add malicious functions and push an update that installs automatically for users. Users are never told that the extension’s real owner has changed.
In this case, the add-on cybercriminals bought most often was Enable Right Click & Copy — Smart Unlock + OCR. It had 70 000 users in Chrome and 10 000 in Edge. This purchase is exactly why there’s a single Edge extension among all its Chrome relatives. The add-on itself originally served a perfectly benign purpose: it let users select and copy text on sites where that’s normally blocked, and it could also pull text out of images with optical character recognition (OCR).
At the time of the research, the Edge version of the extension had more than 10 000 users. Source
The malicious functionality introduced into the extension makes it reach out to the attackers’ command-and-control (C2) server to download additional modules of nefarious code. These modules can change over time. Since Chrome automatically updates all installed extensions by default, the malicious version lands on the device without users having to do anything at all.
For the downloaded code to run on the websites the user visits, the extension disables one of their defenses — Content Security Policy (CSP). This mechanism allows website owners to declare which scripts and other resources are allowed to load and run on a page. Once this protection is turned off, the extension can inject code it gets from the C2 server right into the pages open in the browser. The website itself isn’t hacked, and it looks the same to everyone else, but for that one infected user, the legitimate page quietly turns malicious.
What these 19 extensions can do
Now let’s take a closer look at what the malicious modules loaded by the extension are actually capable of. Researchers found 16 such modules, built for all sorts of tasks: from stealing data and hijacking cryptocurrency to the ClickFix attacks we’re focusing on here.
Some of the modules simply collect user data. They intercept logins, passwords, email addresses, and other valuable information the user enters into web forms, including payment details. On top of that, the add-ons steal data from Facebook and LinkedIn accounts and collect browsing history. Criminals can use this information to take over accounts, steal money, and launch further attacks against the victim.
A few other modules focus specifically on stealing cryptocurrency and related data directly. One of them is a crypto drainer, a tool that empties crypto wallets. It works with Ethereum and compatible blockchains as well as Solana and Tron. It replaces the real Connect Wallet and Swap buttons on websites with its own fake ones. When a user clicks one of these buttons, the drainer takes over all further interaction with the wallet and walks the victim through confirming the actions needed to steal their cryptocurrency.
Other modules target users of Ledger and Trezor hardware wallets. Right on the official websites of these services, the malicious extension displays a fake wallet update-and-restore page that asks for a seed phrase of 12, 18, or 24 words. The seed phrase the user enters is forwarded straight to the attackers, giving them full control over the wallet.
The fake form asks the user to enter a seed phrase of 12, 18, or 24 words, which then ends up in the attackers’ hands. Source
Finally, some modules gather information from crypto service pages open in the browser, such as OKX, MEXC, Kraken, KuCoin, Coinbase, Binance, Bybit, and MetaMask, including balance details and active session data that can be used to hijack accounts.
And now we’ve finally reached the module that matters most for this post: the one used for ClickFix attacks. We’ll talk about it in the next part.
How malicious extensions are used in ClickFix attacks
The ClickFix attack technique has become extremely popular among cybercriminals lately. It relies on social engineering: the victim is shown fake instructions supposedly needed to complete some action, such as passing a CAPTCHA check, fixing an error, or updating a program. Following these instructions, the user copies the command suggested by the attackers, pastes it into a system tool built for running these commands, and runs it, all by themselves.
We’ve written about attacks like this and their consequences more than once on our blog. But we rarely dig into exactly how a victim ends up on a page with fake instructions in the first place. A campaign that spread malicious extensions through the Chrome Web Store shows us one way this can happen.
Add-ons turn out to be a very handy tool for ClickFix attacks. As we mentioned earlier, when a user visits a page, extensions are allowed reading and changing its content in order to work. That gives attackers the chance to swap in a fake ClickFix instruction at just the right moment, replacing the content of the page the person actually wanted to open.
What’s more, the ClickFix technique itself lets attackers break out of the browser and gain a foothold directly in the system. That means removing the malicious extension won’t necessarily undo the damage: after the user has run the ClickFix command, malware may already be installed outside the browser.
In the specific attack example the researchers describe, the user sees a fake notification saying their browser needs to be updated, along with instructions on how to do it. The instructions change depending on the operating system, and the extension picks up that information automatically too.
In the macOS version of this attack, the user is told to open Terminal, copy a command, paste it there and run it, then restart Chrome to supposedly finish the update. Source
How to avoid falling victim to infected extensions
First off, we recommend checking whether any of the following malicious extensions are already installed in your browser:
Enable Right Click & Copy — Smart Unlock + OCR
RapidLens – Google Lens for Screen Search & Images
Meta & Facebook Ad Library Spy — Save Ads, Finder, Downloader | FeedX-Ray
If you find any of these extensions on your device, we recommend removing it as soon as you can and running a full system scan with a reliable antivirus. As we mentioned above, simply deleting the add-on might not be enough. You can use a free trial version to detect and remove the infection.
How to avoid falling victim to malicious extensions and ClickFix attacks in the future?
Don’t install too many extensions and regularly check the list of those you have.
Remove extensions you don’t use.
Trust the warnings from your operating system and security software, rather than the instructions — or even the demands — of websites and apps.
Threat actors are increasingly improving their tactics to make suspicious emails look like legitimate email notifications to potential victims, deploying techniques that impersonate internally sent emails from executive team members. While this technique is not new, the adoption of AI has enabled threat actors to improve their campaign templates and construct emails tailored to their recipients. Additionally, threat actors are incorporating multiple techniques within the same email to improve the overall narrative further.
In this blog, we will discuss a recent campaign observed using third-party email delivery infrastructure to send out over a million financial fraud scam emails that displayed multiple indicators consistent with the use of generative AI during email template creation. The threat actor impersonated CEOs of multiple target companies, attempting to convince accounts payable departments of the same companies to process an Automated Clearing House (ACH) payment of nearly $50,000. To add legitimacy, the actor included a forwarded email thread (and a fabricated invoice) between the impersonated CEO and ServiceNow (which was also being impersonated).
Attack chain overview
The campaign follows steps before and during the execution of the campaign: threat actors register impersonation domains, send executive-themed payment requests through trusted infrastructure, embed fabricated invoices and supporting conversations, and attempt to convince finance personnel to initiate ACH transfers.
Figure 1: Attack chain showing domain registration, executive impersonation, invoice fraud delivery, ACH payment execution, and financial theft.
Email Delivery
Between August 3 and 5, Microsoft detected a campaign consisting of more than a million emails targeting enterprise users. The attacker used multiple third-party email service accounts to send out the emails. A huge majority of these emails were sent to users in the United States (87.7% of the total campaign).
Figure 2. Campaign timeline.Figure 3. Industry distribution of targeted enterprises of this campaign with ‘IT services & business advisory’ along with ‘Consumer goods’ and others.
Unlike traditional invoice scams that rely on a single social engineering lure, this campaign layered executive impersonation, vendor branding, fabricated invoices, and supporting email conversations into a unified narrative intended to reduce recipient skepticism.
The threat actor impersonated executive team members (such as a CEO, CFO, President) of multiple targeted companies, attempting to convince accounts payable departments of the same companies to process an ACH payment of nearly $50,000. More specifically, the CEOs were impersonated in multiple places in the email such as in the sender display name, reply-to display name, and in the email signature. Email bodies contained a simple and direct “approval” of the “invoice below” as well as urged users to request a PDF version if they need it. Additionally, as mentioned earlier, the email signature contained certain details about the spoofed CEO such as name and email address.
Figure 4. Spoofed message from executive team member.
Important note: Throughout this campaign, threat actors impersonated legitimate organizations using attacker-controlled infrastructure, fabricated communications, and lookalike domains. Microsoft found no evidence that the legitimate organizations referenced in the lures, including ServiceNow, were compromised or involved in the activity. Rather, the campaign relied on fraudulent domains and content designed to mimic trusted brands and individuals.
The threat actor did not stop there. To add further legitimacy, directly below the CEO signature, the actor included “forwarded” content , specifically a professional looking but fabricated “ServiceNow Platform — Annual Subscription” invoice. The extremely detailed invoice contains various ServiceNow branding and logos. It has basic invoice details such as invoice number, issue and due dates, currency, amount due, payment method, and itemized line items. The payment method instructed is a bank transfer to accounts controlled by the threat actor. Microsoft observed the use of multiple financial institutions across samples, indicating that payment destinations may vary between targets. Certain parts of the invoice are personalized to the recipient. Specifically, the “BILLED TO” section has the recipient company name and executive name.
The invoice shown below is a threat actor-created impersonation and was not issued by ServiceNow.
Figure 5. Spoofed ServiceNow invoice.
Finally, directly below the fake invoice, two more “forwarded” emails are included which are essentially a short conversation between the two spoofed executives (the targeted company executive, and ServiceNow President). The two executives are seen discussing the ServiceNow purchase, implementation and handling of the invoice.
Figure 6. “Forwarded” replies thread within the email lacking usual headers.
From a defender point of view there are several indicators within the email indicating that the email and the “forwarded” thread are not genuine.
“From” headers from the spoofed thread lack any data headers like actual forwarded emails.
Suspicious language used in the spoofed thread such as “no need to copy me”.
Suspicious language in headers i.e display name not matching sender address, subjects using financial lure keywords like ‘due bill’, ‘ACH Parment’ etc.
Despite the sophistication of the generated content, several inconsistencies remained visible to defenders
In real email threads, the previous threads are normally tabbed or otherwise visually grouped, while the previous threads in this example were left aligned.
An additional inconsistency was observed where the targeted company’s CEO requested the recipient to send the invoice directly to victims and not CC the sender. However, in the most recent thread, the CEO stated that the invoice is approved and the invoice is sent from his address.
Domain registration
Before initiating the campaign, the threat actor registered several domains. A ‘ServiceNow’ lookalike domain service-nowinc[.]com was registered on July 31, shortly before the campaign activity was observed. This domain was used for the spoofed email address of ServiceNow President. It was also used in several places in the fabricated invoice such as in the contact email in case of any questions. The actor also registered another domain on the same day. The domain domainlify[.]net was used in the Reply-To email.
Figure 7. Account information linked with email of impersonated domain.
Generative AI usage
Microsoft observed several indicators consistent with AI-assisted template development. These included extensive HTML comments, structured section labeling, and highly uniform template construction. While these indicators suggest generative AI involvement, they do not independently establish the extent to which AI generated campaign content.
Examples:
Figure 8. Code snippet showing a verbose HTML comment describing a section (a characteristic commonly observed in AI-generated code).Figure 9. Another code snippet showing extensive comments on HTML style elements and sections.
Additionally, the use of ‘em dash’ (“—”) and banner ‘===========’ have also become other indicators associated with AI usage.
Figure 10. Another code example indicating AI usage. This example shows a verbose capitalized section header and yet more style elements excessively commented.
One possible indication of template-based generation is that invoice identifiers and narrative structure remained largely consistent across samples while organization-specific details changed between targets.
Mitigation and protection guidance
Microsoft provides layered protection against this type of executive-impersonation and invoice-fraud campaign. Properly configured email authentication, spoof protection, mail-flow connectors, and Microsoft Defender for Office 365 help identify and block suspicious messages before delivery; messages later determined to be malicious can be quarantined or removed through post-delivery remediation, including Zero-hour Auto Purge. Security teams can then use Microsoft Defender XDR and Security Copilot to investigate related alerts, affected users, and campaign indicators, coordinate response, and take remediation actions.
Together, these capabilities help reduce the likelihood that fraudulent payment requests reach finance personnel and support faster containment if a message is delivered.
To defend against social engineering campaigns involving executive impersonation, invoice fraud, and potentially AI-assisted content development, Microsoft recommends the following mitigations:
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.
Enable Zero-hour auto purge (ZAP) in Office 365 to quarantine sent mail in response to newly acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.
Invest in advanced anti-phishing solutions that monitor and scan incoming emails and visited websites. For example, organizations can leverage web browsers like Microsoft Edge that automatically identify and block malicious websites, including those used in this phishing campaign, and solutions that detect and block malicious emails, links, and files.
These links provide information on how to properly configure mail flow with connectors:
Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.
Tactic
Observed activity
Microsoft Defender coverage
Financial Theft
Scam emails
Microsoft Defender for Office 365 – Invoice scams delivered detected as Spam and malicious categories. – Email messages marked malicious removed after delivery and spam moved to quarantine – Email messages removed after delivery – Messages retroactively removed through Zero-hour Auto Purge (ZAP).
Microsoft Security Copilot
Security Copilot customers can use the standalone experience to create their own prompts or run the following prebuilt promptbooks to automate incident response or investigation tasks related to this threat:
Incident investigation
Microsoft User analysis
Threat actor profile
Threat Intelligence 360 report based on MDTI article
Vulnerability impact assessment
Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.
Threat intelligence reports
Microsoft Defender XDR customers can use 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 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.
MITRE ATT&CK Techniques observed
This threat has exhibited use of the following attack techniques. For standard industry documentation about these techniques, refer to the MITRE ATT&CK framework.
Reconnaissance
T1591 – Gather Victim Organization Information Threat actors collect publicly available information about target organizations, executives, finance personnel, vendors, and business relationships to build convincing invoice-fraud narratives.
T1598 – Phishing for Information Information gathered from victims and public sources is used to craft highly targeted business email compromise (BEC) lures.
T1036 – Masquerading Attackers disguise emails, domains, invoices, and business correspondence as legitimate communications.
T1656 – Impersonation Executives, vendors, and trusted business entities are impersonated to establish credibility and influence payment decisions.
Impact
T1657 – Financial Theft Victims are deceived into transferring funds to attacker-controlled financial accounts through fraudulent invoice payment requests.
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.
Every wave of technology excitement creates a new opportunity for cyberattackers, and AI is no exception. Microsoft Threat Intelligence has published research showing a growing set of campaigns that impersonate popular AI platforms and tools, including ChatGPT, Microsoft Copilot, DeepSeek, and Claude.1 The goal is to make phishing, search-driven malware campaigns, and malvertising—which is malicious advertising that uses online ads to lure users to harmful sites, downloads, or redirect chains—more convincing. A ChatGPT-themed phishing campaign sent up to 100,000 emails in a single day, tricking users into updating their ChatGPT Plus payment information and stealing personal and credit card data. These campaigns do not represent a compromise of the AI services being referenced. They represent something more familiar—cyberattackers doing what they have always done: borrowing trust. Right now, AI brands can carry significant trust and curiosity, making them attractive themes for cyberattackers to exploit.
Understanding why this trend matters and what it means for security teams is critical to shaping a modern protection strategy. The tactics are the same ones cyberattackers have always refined: urgency, curiosity, and impersonation of something familiar to lower a user’s guard. What has changed is the wrapper. A message about a new model release, a policy update from a familiar AI assistant, or a plugin that promises to make the workday easier is today’s version of the fake invoice or the shipping notification. AI-themed lures deserve attention not because they are a passing trend tied to one product cycle, but because AI remains a genuine source of excitement and urgency for employees and consumers alike, and cyberattackers are exploiting the human instinct to explore what is new, useful, or urgent.
The attack pattern is evolving
Microsoft’s research team recently observed several AI brand campaigns including:
A ChatGPT-themed phishing kit built to harvest credit card data.
A Claude-themed campaign that harvested credentials and access tokens through adversary-in-the-middle (AiTM) techniques.
Malvertising for a fake AI Windows plugin that delivered the Vidar stealer.
Fraudulent DeepSeek installers distributed through GitHub.
In one case, an initial access broker tracked as Storm-3075 used AI-themed malvertising to distribute payloads for multiple downstream actors, a sign of how quickly this tactic is being commoditized across the criminal ecosystem.
Figure 1. Snippet of the top portion of the email impersonating ChatGPT and enticing users to click on the link.
What ties these campaigns together is not sophistication in the traditional sense. It is patience and precision in exploiting a moment. Threat actors are capitalizing on anticipated launches and emerging trends, layering multi-stage redirection chains and disposable infrastructure to slip past both users and defenses. That has real implications for security leaders: it means these incidents cannot be evaluated one surface at a time. A single AI-themed lure can begin as an email, become a malicious link, trigger a suspicious download, and end as an identity or endpoint compromise. Organizations that assess each of those as an isolated event are always a step behind. Organizations that connect them see the full shape of the cyberattack, often early enough to stop it.
Turning AI lures into dead ends with Microsoft Defender
In practice, protection starts before the user ever engages with the lure. Microsoft Defender’s anti-phishing policies can help detect spoofing and impersonation attempts, including user and domain impersonation, first-contact messages, mailbox intelligence signals, and other suspicious sender characteristics. For an AI-themed lure, that might look like a fake “Copilot policy update,” a spoofed support notice, or a lookalike domain designed to make a credential collection page feel legitimate.
If the campaign relies on links, Defender’s Safe Links provides URL scanning and detonation during mail flow, plus time-of-click verification when a user selects a link in email, Microsoft Teams, or supported Microsoft 365 apps. That is important when cyberattackers use redirect chains, delayed activation, or links that appear benign at delivery but later resolve to phishing infrastructure, fake sign-in pages, or malicious downloads.
For campaigns that use fake installers, malicious downloads, or weaponized attachments, Safe Attachments adds another layer by detonating attachments in a virtual environment before delivery when policies are configured. For example, if a message promotes a “new AI plugin” but includes a harmful attachment, Safe Attachments can analyze the file for malware, ransomware, or phishing behavior before it reaches the user. If a cyberthreat is identified after delivery, Defender’s post-delivery filtering capabilities help remove malicious content from mailboxes and reduce the window of exposure.
Figure 2. Simplified Defender email detection stack with pre-delivery and post-delivery protections.
Protect against multi-stage attacks with attack disruption
But AI-powered attacks don’t stop at email. Their objective is to gain the highest level of access possible, using compromised accounts as a foothold to move across identities, devices, and data. When a cyberattack moves beyond the inbox, Defender helps connect the evidence. Signals from email and collaboration tools, endpoints, identities, and software as a service (SaaS) apps are correlated into an attack story so analysts can see whether the same lure led to a clicked link, a downloaded payload, risky sign-in behavior, or endpoint activity.
As cyberattackers expand beyond email to gain broader access across the environment, Defender moves from detection to disruption. For multi-stage, multi-domain attacks like business email compromise or AiTM, Defender’s powerful, built-in response capability, attack disruption, will contain the compromised asset during the attack to prevent further lateral movement while security teams investigate and remediate. Attack disruption contains more than 81,000 compromised user accounts monthly and is now disrupting more than 45,000 AiTM attacks each month.
Figure 3. Recent attack disruption statistics. (Source: Internal Microsoft Research, September 2026)
In a recent case study, Defender disrupted a business email compromise attack within four minutes of the initial activity (Figure 4). While response times may vary by scenario, this case shows the impact of attack disruption on a real cyberthreat. The cyberattacker used a convincing document-sharing lure to trick a user to start a legitimate Microsoft device code sign-in flow, which avoided traditional credential theft techniques. Defender recognized the resulting device code authentication and follow-on activity as suspicious, correlated signals across identity and email telemetry, and disrupted the attack within four minutes before the attacker could establish persistence, create inbox rules, or execute payroll fraud.
Figure 4. Business email compromise attack through OAuth device code phishing.
The takeaway
AI brands are the new bait, but the underlying lesson is bigger than any single campaign. As cyberattackers continue to exploit the momentum around AI, organizations should expect social engineering to become more targeted, more believable, and more difficult to evaluate in isolation.
The answer is not to treat every new lure as a brand-new category of risk. It is to build a protection model that makes trust harder to exploit across the full attack chain. Microsoft Defender helps organizations do that by connecting prevention, detection, investigation, and response across the attack path, so AI-themed lures are harder to deliver, harder to trust, and harder to turn into broader compromise.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.
Microsoft Security Research is tracking active cloud-based intrusions spanning multiple accounts in which unusual sign-ins were followed by threat actor-added authentication methods, high-volume Microsoft Graph activity, SharePoint and OneDrive downloads, and email collection through REST APIs. Microsoft Security Research assesses that this sequence is consistent with automated collection from compromised cloud identities using proxy-associated infrastructure, the activity has been observed since May 2026.
The activity begins with identity-focused social engineering and impersonation infrastructure, proceeds through authentication persistence and cloud reconnaissance, and is followed by targeted data access and activity consistent with data collection and potential exfiltration. Domains, IP addresses, and hosting providers can change quickly, but the recurring sequence of identity compromise, persistence, reconnaissance, content discovery, and exfiltration provides a more durable basis for investigation. Defenders should investigate this sequence across identity, Microsoft Graph, SharePoint, OneDrive, and Exchange signals, then revoke sessions and remove unauthorized authentication methods for confirmed compromises.
Attack chain overview
Figure 1. Observed attack sequence showing identity compromise through social engineering, MFA persistence, Microsoft Graph reconnaissance, and cloud data collection/exfiltration.
Step 1-2 : Initial access: Passkey and SSO lures
The attack often begins with a seemingly routine call or message on a user’s personal phone number from someone claiming to be from the organization’s IT helpdesk. The caller creates a sense of urgency, explaining that a passkey, multifactor authentication (MFA), or single sign-on (SSO) configuration must be updated immediately to avoid disruption. Employees are directed to a website that closely resembles a legitimate Microsoft sign-in experience and may receive the link through SMS messages sent directly to their personal mobile phones.
Despite the frequent use of passkey-themed lures, passkey enrollment is often not the actor’s true objective. Instead, the passkey narrative serves as a convincing pretext to guide victims through adversary-in-the-middle (AiTM) phishing or device-code authentication flows. In AiTM scenarios, the actor captures credentials and session tokens; in device code attacks, the victim unknowingly authorizes access on the actor’s behalf. This initial interaction may leave very little forensic evidence. If the victim opens the phishing link on a personal mobile device that is not onboarded to Microsoft Defender for Endpoint, the related activity may be absent from endpoint telemetry.
In many investigations, the employee’s recollection of a phone call or text message becomes the earliest and sometimes the only evidence explaining how the compromise began. As a result, investigators must often reconstruct the attack by connecting these reports with subsequent sign-ins, device code authentication events, token activity, and authentication method changes.
Reconnaissance on targeted organization
The actor appears to invest heavily in pre-attack research, likely gathering information about employees and organizational structure from public sources such as social networking and professional profiling platforms.
Reusable domains, personalized targeting
In a smaller number of cases, actors take advantage of already compromised accounts to expand their reach. Using a trusted employee identity, they send similar passkey-themed messages through Microsoft Teams, making the request appear legitimate and significantly increasing the likelihood of engagement. To support these operations, the actors rapidly deploy convincing phishing infrastructure built around themes such as passkeys, SSO enrollment, account activation, and identity verification.
A commonly observed technique involves registering generic domains and embedding the target organization’s name as a subdomain, creating URLs that appear familiar at first glance. Multiple domains may be created for the same organization, allowing the actor to rotate infrastructure as needed. These domains are often registered with Nicenic registrar (observed in previous extortion campaigns) and operational within hours, giving defenders little opportunity to identify and block the infrastructure before employees encounter it. Registration alone should not be interpreted as evidence of registrar involvement in the activity. For example, company-name.integratedsso[.]com and company-name.secure-passkey[.]com illustrate how the same company name can appear under different actor-controlled domains.
Together, the phone-based social engineering, personalized targeting, trusted internal messaging, and rapidly changing phishing infrastructure form the opening chapter of a highly coordinated intrusion designed to blend technical deception with human trust.
The actor creates domains following the pattern companyname[.]maliciousdomain[.]com to impersonate organization-specific authentication portals. Including the victim organization’s name in the URL helps establish credibility and can persuade users to proceed with authentication. Example: contoso[.]add-passkey[.]com.
In one investigated attack sequence, the activity began with an anomalous sign-in to Microsoft OfficeHome application from an unmanaged device, possibly attacker-owned. Once MFA was completed, the actor began accessing identity portals such as My Sign-Ins and enterprise application stores such as My Apps. Sign-in artifacts, including user-agent patterns, indicated possible AiTM phishing.
Using the same session, the actor further accessed several management applications, including Microsoft Approval Management, which is used for identity and approval-related services. SharePoint Online and OneDrive were used to enumerate sensitive files, primarily through the Graph API. The investigation revealed that the actor’s sessions persisted for approximately one hour while enumerating sensitive files and internal applications.
Passkey lure leads to device code phishing
In another investigated attack sequence, the actor was observed using the device code flow to compromise the session token after the passkey lure. In device code phishing, the user is persuaded to enter a code on the legitimate Microsoft authentication page. This approval issues a token to an attacker-controlled client, which can then access permitted resources without stealing a browser cookie. Following the device code flow, the actor successfully replayed the compromised token, effectively bypassing MFA and conducting enumeration and further attack progression.
Reusing the same credentials after an earlier compromise
The third attack pattern involved the actor signing in with compromised credentials, with MFA approved using a previously registered PhoneAppOTP method. This suggests that the attacker had registered the authenticator app days before launching the campaign. Once the sign in was successful, the actor followed the same reconnaissance pattern observed in other attack sequences. This activity was primarily carried out using an automated system developed with Node.js and Microsoft Graph.
To illustrate how the activity unfolded over time, the following timeline summarizes the key events identified during the investigation.
Time, UTC
Application or resource
What happened and why it matters
T+0min
OfficeHome
Sign-in from an unmanaged context received error 50074, requiring secondary authentication / Multifactor authentication (MFA).
T+1min
OfficeHome
MFA completed (AiTM with non-phishing resistant MFA) followed by error 50140 for the keep-me-signed-in interruption.
T+1min
OfficeHome
Authentication succeeded, establishing the session used for subsequent access.
T+2min
My Apps
The session enumerated applications assigned to the compromised identity.
T+2min
My Profile
Organizational profile information was accessed.
T+3min
Microsoft Approval Management
Identity and approval-related services were accessed. This could expose approval workflows available to the identity.
T+3min
Microsoft Account Controls V2
Account and authentication management interfaces were accessed.
T+4min
My SignIns
Sign-in and security information was accessed through Microsoft Graph using the same source context, session, Chrome user agent, and browser ID as the OfficeHome authentication.
T+10min
OCaaS
The organizational application catalogue was loaded through My Apps. In this sequence, OCaaS supports application discovery rather than appearing as an isolated background event.
T+11 – T+50min
SharePoint Online
The session requested access to organizational sites and document resources. The sign-in events do not prove that a document was opened or downloaded.
T+11 – T+50min
Outlook Web
Mailbox-related services were accessed, creating an opportunity for mailbox and business-context reconnaissance.
T+12min
Windows App – Web
The session entered the Azure Virtual Desktop authentication flow. A desktop or remote workspace launch was not confirmed.
T+14min
Internal virtual application and desktop portal
Authentication succeeded to the internal virtual application and desktop portal. This could expose published applications and virtual desktops assigned to the identity, although no internal virtual application and desktop portal resource launch was confirmed.
T+15min
OwaDownloadAttachments
Outlook successfully requested the attachment download resource. This is more consequential than generic mailbox access, but the sign-in telemetry does not prove that an attachment was downloaded.
T+16min
M365ChatClient
Microsoft 365 collaboration, Teams, and search services were accessed.
T+16min
Internal business workflow application
Authentication succeeded to another internal business workflow application.
Step 5 : New MFA device for persistence
Following initial access, the actor’s first objective was to transform a temporary compromise into a persistent foothold. Rather than relying solely on stolen credentials, the actor enrolled an MFA method under their control, typically by registering a new phone number, authenticator application, or software-based one-time password (OTP) token. This effectively inserted an actor-controlled factor into the victim’s identity, allowing future authentication challenges to be satisfied without the user’s involvement.
By registering an actor-controlled MFA method, the threat actor ensured that future authentication challenges could be satisfied using a factor they controlled. While MFA enrollment alone does not survive a complete credential and session reset, it provides a durable persistence mechanism when combined with stolen tokens, unrevoked sessions, or subsequent access to valid credentials. As a result, actors frequently establish MFA persistence early in the intrusion to increase the likelihood of maintaining long-term access to the compromised identity.
Phone or authenticator device addition
Detects a newly registered MFA device with a populated device token. The query compares the previous and updated authentication method values and returns newly added device records.
CloudAppEvents
| where ActionType == "Update user."
| where tostring(RawEventData.ResultStatus) == "Success"
| where RawEventData has_any ("StrongAuthenticationPhoneAppDetail", "StrongAuthenticationUserDetails")
| extend AccountObjectId = extract(@"User_([a-f0-9\-]+)", 1, tostring(RawEventData.Target))
| where isnotempty(AccountObjectId)
| mvexpand ModifiedProp = RawEventData.ModifiedProperties
| where tostring(ModifiedProp.Name) in ("StrongAuthenticationPhoneAppDetail", "StrongAuthenticationUserDetails")
| extend OldValue = tostring(ModifiedProp.OldValue),
NewValue = tostring(ModifiedProp.NewValue)
| extend OldDeviceCount = countof(OldValue, @"""Id"""),
NewDeviceCount = countof(NewValue, @"""Id""")
| where NewDeviceCount > OldDeviceCount
Software token addition
Below is a real-world example of attacker controlled Software token added to the user’s identity with Update user operation. This is added as a second NewValue entry containing the device name NO_DEVICE, device token NO_DEVICE_TOKEN, and the SoftwareTokenActivated device tag.
Once MFA persistence was established, the actor initiated an extensive internal reconnaissance phase using Microsoft Graph to inventory users, groups, permissions, resources, and accessible content across the tenant with the compromised identity. The actor deliberately rotated infrastructure throughout the attack lifecycle, with separate IP addresses often used for authentication, reconnaissance, and exfiltration activities. As a result, piecing together the full intrusion required correlating activity across multiple stages rather than relying on individual network indicators.
The attack underscores a critical detection challenge: Microsoft Graph abuse rarely appears suspicious when viewed through a single API call. Requests to endpoints such as /users, /groups, or /sites are commonplace in enterprise environments. However, when the same identity, application, or access token systematically traverses multiple tenant resources, evaluates privilege and authentication settings, and subsequently accesses mail, files, attachments, or document content, those actions collectively form a clear reconnaissance-to-exfiltration chain. This attack serves as a strong example of why Graph activity must be assessed holistically, with emphasis on behavioral progression and cross-event correlation rather than individual API requests in isolation.
Graph reconnaissance pattern matrix initiated by the actor
Recon pattern
Graph URI examples
What it reveals
Why it matters
Tenant profile
/organization, /subscribedSkus, /licenseDetails
Identifies the tenant, verified domains, licenses, and enabled services.
Useful setup activity; stronger when followed by user, role, or repository discovery.
Directory enumeration
/users, /groups, /members, /transitiveMembers
Builds a map of identities, groups, and effective membership.
Can identify targets, privileged users, and sensitive collaboration groups.
Locates sites, document libraries, folders, and files.
Often converts broad tenant reconnaissance into a collection-ready file map.
Mailbox discovery
/messages, /mailFolders, /attachments
Enumerates messages, folders, and attachment metadata.
Supports intelligence collection, business email compromise (BEC), and targeted attachment retrieval.
Automation and pagination
$top, $skip, $skiptoken, $count, /delta, /search
Walks large result sets or repeatedly searches repositories.
Raises confidence when combined with broad discovery or sensitive endpoints.
Content collection
/content, message or attachment retrieval, large ResponseSize
Retrieves the underlying data after discovery.
Strongest indicator that reconnaissance has progressed into collection.
Hunt for broad Graph reconnaissance in one session
Find identities or applications touching several reconnaissance categories from the same IP within 30 minutes.
let Lookback = 24h; [MI25.1][IM25.2]
GraphAPIAuditEvents
| where Timestamp > ago(Lookback)
| where toint(ResponseStatusCode) between (200 .. 299)
| extend Uri = tolower(RequestUri),
ActorId = coalesce(AccountObjectId,
ServicePrincipalId, ApplicationId),
Path = tostring(split(tolower(RequestUri), "?")[0])
| extend ReconType = case(
Uri has "/organization" or Uri has "/subscribedskus", "Tenant",
Uri has "/users" or Uri has "/groups", "Directory",
Uri has "/directoryroles" or Uri has "/rolemanagement", "Privilege",
Uri has "/applications" or Uri has "/serviceprincipals"
or Uri has "/oauth2permissiongrants", "Application",
Uri has "/sites" or Uri has "/drive", "Repository",
Uri has "/messages" or Uri has "/mailfolders", "Mailbox",
"Other")
| where ReconType != "Other" and isnotempty(ActorId)
| summarize Requests=count(), Categories=dcount(ReconType),
DistinctPaths=dcount(Path),
ReconTypes=make_set(ReconType, 10),
SampleUris=make_set(RequestUri, 10)
by ActorId, IpAddress, ApplicationId, bin(Timestamp, 30m)
| where Requests >= 10 and Categories >= 3 and DistinctPaths >= 6
| order by Categories desc, Requests desc
Hunt for privilege, MFA, application, and consent discovery
Highlight sensitive control-plane reconnaissance that can expose persistence or escalation opportunities.
GraphAPIAuditEvents
| where Timestamp > ago(24h)
| where toint(ResponseStatusCode) between (200 .. 299)
| extend Uri = tolower(RequestUri),
ActorId = coalesce(AccountObjectId,
ServicePrincipalId, ApplicationId)
| where Uri has_any ("/directoryroles", "/rolemanagement",
"/authentication/methods", "/applications",
"/serviceprincipals", "/oauth2permissiongrants",
"/approleassign")
| summarize Requests=count(), DistinctPaths=dcount(tostring(split(Uri, "?")[0])),
ScopesSeen=make_set(Scopes, 10),
SampleUris=make_set(RequestUri, 12)
by ActorId, IpAddress, ApplicationId, bin(Timestamp, 30m)
| where Requests >= 4 and DistinctPaths >= 2
| order by Requests desc
Hunt for SharePoint and OneDrive repository discovery
Detect search, child traversal, delta queries, and paging used to map file repositories.
GraphAPIAuditEvents
| where Timestamp > ago(24h)
| where toint(ResponseStatusCode) between (200 .. 299)
| extend Uri = tolower(RequestUri),
ActorId = coalesce(AccountObjectId,
ServicePrincipalId, ApplicationId),
Path = tostring(split(tolower(RequestUri), "?")[0])
| where Uri has_any ("/sites", "/drives", "/drive/")
| where Uri has_any ("/search", "/children", "/delta",
"$skiptoken", "%24skiptoken", "$top", "%24top")
| summarize Requests=count(), DistinctPaths=dcount(Path),
SampleUris=make_set(RequestUri, 12)
by ActorId, IpAddress, ApplicationId, bin(Timestamp, 20m)
| where Requests >= 8 and DistinctPaths >= 4
| order by Requests desc
Hunt for mailbox and attachment reconnaissance
Find concentrated enumeration of messages, mail folders, and attachments.
GraphAPIAuditEvents
| where Timestamp > ago(24h)
| where toint(ResponseStatusCode) between (200 .. 299)
| extend Uri = tolower(RequestUri),
ActorId = coalesce(AccountObjectId,
ServicePrincipalId, ApplicationId),
Path = tostring(split(tolower(RequestUri), "?")[0])
| where Uri has_any ("/messages", "/mailfolders", "/attachments")
| summarize Requests=count(),
DistinctPaths=dcount(Path),
MessageRequests=countif(Uri has "/messages"),
AttachmentRequests=countif(Uri has "/attachments"),
TotalResponseBytes=sum(coalesce(ResponseSize, 0)),
SampleUris=make_set(RequestUri, 12)
by ActorId, IpAddress, ApplicationId, bin(Timestamp, 30m)
| where (Requests >= 8 and DistinctPaths >= 4) or AttachmentRequests >= 3
| order by AttachmentRequests desc, Requests desc
Step 7-8 : High-volume cloud data collection and suspected exfiltration
Following reconnaissance, the actor transitioned into large-scale data collection across Microsoft 365 workloads using the compromised identities. Microsoft observed high-volume access and download activity targeting Microsoft SharePoint Online and Microsoft OneDrive for Business, with some intrusions extending into Microsoft Exchange Online through REST API-based access to email content. Across SharePoint and OneDrive, the activity generated significant volumes of FileAccessed and FileDownloaded events, indicating systematic retrieval of cloud-hosted documents and organizational data.
The activity frequently exhibited characteristics of automation rather than interactive user behavior. In several cases, Microsoft observed the python-httpx user agent associated with high-volume SharePoint and OneDrive access patterns. However, the user agent alone should not be treated as malicious. Instead, such activity should be evaluated in the broader context of data volume, affected identities, source infrastructure, prior reconnaissance activity, and evidence of identity compromise.
Unlike rapid smash-and-grab operations, data exfiltration was typically measured and sustained, often spanning several hours to multiple days depending on the volume of files and email content available to the compromised user. The actors generally maintained a controlled pace of collection, with fewer than 1,000 files or emails accessed within any one-hour period, likely helping the activity blend with normal enterprise usage while enabling the gradual extraction of large amounts of sensitive data over time.
Hunt for exfiltration through Exchange Online
Exfiltration of data through REST API using Microsoft Office or One Outlook Web
CloudAppEvents
| where isempty(AccountObjectId)
| where ApplicationId == '20893'
| where AccountDisplayName in ("One Outlook Web", "9199bf20-a13f-4107-85dc-02114787ef48", "d3590ed6-52b3-4102-aeff-aad2292ab01c")
| where isnotempty(IPAddress)
| extend AccountObjectId = tostring(RawEventData.TokenObjectId)
| summarize ExchangeRestEventCount=count() by IPAddress, AccountObjectId, bin(Timestamp,1h)
| where ExchangeRestEventCount >= 500
Hunt for exfiltration through Microsoft SharePoint Online, OneDrive for Business
Exfiltration of data through python-httpx user agent
CloudAppEvents
| where ApplicationId == "20892" or ApplicationId == "15600"
| where ActionType in ("FileDownloaded", "FileAccessed", "SyncDownloadedFull")
| where isnotempty(AccountObjectId)
| where isnotempty(IPAddress)
| where isnotempty(UserAgent)
| where UncommonForUser has_any("ISP","UserAgent")
| where UserAgent has 'python-httpx'
| project Timestamp, AccountObjectId, IPAddress, ISP, UserAgent
| summarize FilesAccessedLastWindow = count() by AccountObjectId, IPAddress, ISP, UserAgent, bin(Timestamp,2h)
| where FilesAccessedLastWindow >=100
Hunt for anomalous high-volume exfiltration
Exfiltration of data through anonymous proxy
CloudAppEvents
| where ApplicationId in (20892, 20893, 15600)
| where ActionType in~ ("FileDownloaded", "FileAccessed", "FilePreviewed")
| where IsAnonymousProxy == true
| where UserAgent !has "ODMTADemand"
| extend FileSizeBytes = coalesce(tolong(RawEventData.FileSizeBytes), 0)
| summarize
FileSizeBytes = sum(FileSizeBytes),
FirstSeen = min(Timestamp),
LastSeen = max(Timestamp),
EventCount = count(),
ActionTypes = make_set(ActionType),
Applications = make_set(Application)
by AccountObjectId, IPAddress,
TimeBucket = bin(Timestamp, 2h), UserAgent, ISP
| extend FileSizeGB =
round(FileSizeBytes / 1024.0 / 1024.0 / 1024.0, 2)
| where FileSizeGB >= 5 or EventCount >= 1000
| order by EventCount desc
Attribution
Microsoft Threat Intelligence assesses that the initial access activity observed in this campaign is used by a range of threat actors, including Storm-3121, Storm-3032, and others. Storm-3121 conducts initial access activity leading to ShinyHunters and Falcon extortion. Storm-3032 represents a set of actors that splintered from the BlackFile group and now operate under the Helix extortion banner. That being said, Microsoft Defender has detection coverage for the known tactics, techniques and procedures from Storm-3121, Storm-3032 and other operators in the same ecosystem.
Mitigation and protection guidance
Microsoft recommends that organizations investigate identity and cloud-workload signals as a connected sequence, with priority given to unusual sign-ins followed bys authentication method enrollment, Microsoft Graph reconnaissance, token issuance, and abnormal SaaS download or mailbox activity.
Investigate
Review newly registered authentication methods and devices for users with risky or unusual sign-ins and remove unauthorized methods after validating the user.
Investigate high-volume or programmatic Microsoft Graph activity involving directory enumeration, role discovery, service principal discovery, SharePoint, OneDrive, or sensitivity-label discovery.
Correlate SharePoint and OneDrive download anomalies, Exchange REST activity, and mailbox or attachment searches with identity and authentication events.
Contain and remediate
Revoke active sessions and refresh tokens for confirmed compromised identities, reset credentials, remove attacker-registered authentication methods, remove attacker created mailbox rules, and require secure re-registration of authentication methods.
Reduce future risk
Do not treat an IP or domain match as conclusive on its own. Validate workload behavior, affected identities, persistence events, and data access volume.
Enforce phishing-resistant MFA (FIDO2/passkeys, Windows Hello for Business) via Conditional Access
Enforce Conditional Access that requires a managed, compliant device for Exchange, SharePoint, and Graph-privileged apps
Enforce strict conditional access controls for security info registration, including setting required sign-in frequency to always (require a new interactive auth), requiring managed devices and/or named locations, and requiring phish-resistant MFA as a required authentication strength, and in a separate policy blocking security info registration with a high sign-in risk condition
Enforce risk-based access policies for risky sign-ins and risky users – remediate elevated risk with phishing-resistant MFA or secure password change, and block access at the highest risk levels.
Train users against voice and email phishing that targets MFA and passkey enrollment. Provide a verified channel to report unsolicited authentication requests.
Block the device code and authentication transfer flows via Conditional Access, except where an explicit business need exists.
Restrict user consent for applications, require admin approval, and regularly review service principals holding high-privilege Graph permissions such as Mail.Read, Files.Read.All, and Directory.Read.All.
Limit access from unmanaged devices to web-only sessions without download or sync, and disable anonymous sharing links in SharePoint and OneDrive.
Enable Microsoft Graph activity logs and mailbox auditing, and alert on anomalous enumeration, authentication-method registration, and high-volume file or mail access.
Educational training: Verify user identity through a rigorous process before performing any helpdesk-initiated credential or MFA reset, and alert on every such reset.
Microsoft Defender XDR detections
Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.
Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.
Tactic
Observed activity
Microsoft XDR Defender coverage
Credential Access
Unusual cloud activity from a tracked potentially malicious IP
Microsoft Defender for Cloud – A storage account was accessed from a suspicious IP address.
Microsoft Defender for Identity – Malicious registration of a device with strong MFA. – Malicious registration of an attacker controlled MFA device. – Suspicious registration of a new Authenticator MFA method. – Malicious registration of a new Authenticator MFA method. – Suspicious registration of a new Phone MFA method. – Malicious registration of a new Phone MFA method – Malicious registration of a new Email MFA method.
Microsoft Defender XDR – Malicious sign in from an IP address associated with recognized attacker infrastructure.
Discovery
Graph API reconnaissance activity
Microsoft Defender for Identity – Suspicious Entra Graph API query observed.
Exfiltration
Data exfiltration activity
Microsoft Defender for Cloud – Unusual number of blobs extracted from a storage blob container. – Unusual amount of data extracted from a storage file share. – Unusual number of files extracted from a storage file share. – Unusual amount of data extracted from a sensitive blob container. – Unusual number of blobs extracted from a sensitive blob container. – Unusual amount of data extracted from a sensitive storage file share. – Unusual number of files extracted from a sensitive storage file share. – Sensitive data was exfiltrated from a publicly exposed blob container.
Microsoft Defender XDR – Automated mass SharePoint/OneDrive file access via python-httpx.
Microsoft Security Copilot
Security Copilot customers can use the standalone experience to create their own prompts or run the following prebuilt promptbooks to investigate activity associated with this intrusion pattern:
Incident investigation – Generates investigation summaries and helps analysts understand incidents involving compromised identities, suspicious sign-ins, persistence activity, and cloud-based data access.
Microsoft User analysis– Analyses user accounts, sign-in activity, authentication events, risk indicators, and related identity signals that may help identify compromised accounts.
Customers can also use Microsoft Security Copilot together with Microsoft Threat Intelligence to investigate indicators, threat activity, and related intelligence associated with suspicious sign-ins, Microsoft Graph reconnaissance, and cloud data exfiltration activity.
Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.
Threat intelligence reports
Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.
T1087.004 Account Discovery: Cloud Account | The threat actor uses Microsoft Graph to enumerate tenant users and identities, including information useful for identifying high-value identities and privileged accounts.
T1069.003 Permission Groups Discovery: Cloud Groups | Microsoft Graph reconnaissance enumerates group memberships and directory roles, allowing the threat actor to understand privilege relationships and identify potentially valuable identities.
Collection
T1530 Data from Cloud Storage | The actor searches and accesses SharePoint and OneDrive content and performs high-volume file access/download activity to collect targeted cloud-hosted information.
T1114 Email Collection | Mailboxes, messages, and attachments are searched for material of interest and email is collected through REST APIs.
T1213 Data from Information Repositories | The actor searches enterprise cloud repositories, including SharePoint content and other organizational cloud data, to identify information of value for collection.
Exfiltration
T1567 Exfiltration Over Web Service | The campaign performs high-volume cloud data access and uses automated Python-based activity for rapid collection and exfiltration.
Advanced hunting queries
Additional advanced hunting query for Graph reconnaissance:
Hunt for automated pagination, delta, and search behavior
Identify actors walking large Graph result sets or repeatedly querying for data.
GraphAPIAuditEvents
| where Timestamp > ago(24h)
| where toint(ResponseStatusCode) between (200 .. 299)
| extend Uri = tolower(RequestUri),
ActorId = coalesce(AccountObjectId,
ServicePrincipalId, ApplicationId),
Path = tostring(split(tolower(RequestUri), "?")[0])
| where Uri has_any ("$top", "%24top", "$skip", "%24skip",
"$skiptoken", "%24skiptoken", "$count",
"%24count", "/delta", "/search")
| summarize AutomatedRequests=count(), DistinctPaths=dcount(Path),
SampleUris=make_set(RequestUri, 12)
by ActorId, IpAddress, ApplicationId, bin(Timestamp, 15m)
| where AutomatedRequests >= 8 and DistinctPaths >= 4
| order by AutomatedRequests desc
Hunt for reconnaissance progressing to content collection
Prioritize sessions where broad discovery and content retrieval occur together.
GraphAPIAuditEvents
| where Timestamp > ago(24h)
| where toint(ResponseStatusCode) between (200 .. 299)
| extend Uri = tolower(RequestUri),
ActorId = coalesce(AccountObjectId,
ServicePrincipalId, ApplicationId)
| extend ActivityType = case(
Uri has "/content" or Uri has "/attachments", "ContentCollection",
Uri has "/users" or Uri has "/groups", "DirectoryRecon",
Uri has "/directoryroles" or Uri has "/rolemanagement"
or Uri has "/authentication/methods", "PrivilegeRecon",
Uri has "/applications" or Uri has "/serviceprincipals", "ApplicationRecon",
Uri has "/sites" or Uri has "/drives" or Uri has "/drive/", "RepositoryRecon",
Uri has "/messages" or Uri has "/mailfolders", "MailboxRecon",
"Other")
| where ActivityType != "Other"
| summarize DiscoveryFirst=minif(Timestamp, ActivityType != "ContentCollection"),
CollectionFirst=minif(Timestamp, ActivityType == "ContentCollection"),
DiscoveryCategories=dcountif(ActivityType, ActivityType != "ContentCollection"),
ContentRequests=countif(ActivityType == "ContentCollection"),
TotalResponseBytes=sum(coalesce(ResponseSize, 0)),
SampleUris=make_set(RequestUri, 15)
by ActorId, IpAddress, ApplicationId, bin(Timestamp, 1h)
| where isnotnull(DiscoveryFirst) and isnotnull(CollectionFirst)
| where CollectionFirst >= DiscoveryFirst
and DiscoveryCategories >= 2 and ContentRequests >= 1
| order by CollectionFirst desc
Hunt for exfiltration through Microsoft Graph
Prioritize sessions where broad discovery and content retrieval occur together.
GraphAPIAuditEvents
| where Timestamp > ago(24h)
| where toint(ResponseStatusCode) between (200 .. 299)
| extend Uri = tolower(RequestUri),
ActorId = coalesce(AccountObjectId,
ServicePrincipalId, ApplicationId)
| extend ActivityType = case(
Uri has "/content" or Uri has "/attachments", "ContentCollection",
Uri has "/users" or Uri has "/groups", "DirectoryRecon",
Uri has "/directoryroles" or Uri has "/rolemanagement"
or Uri has "/authentication/methods", "PrivilegeRecon",
Uri has "/applications" or Uri has "/serviceprincipals", "ApplicationRecon",
Uri has "/sites" or Uri has "/drives" or Uri has "/drive/", "RepositoryRecon",
Uri has "/messages" or Uri has "/mailfolders", "MailboxRecon",
"Other")
| where ActivityType != "Other"
| summarize DiscoveryFirst=minif(Timestamp, ActivityType != "ContentCollection"),
CollectionFirst=minif(Timestamp, ActivityType == "ContentCollection"),
DiscoveryCategories=dcountif(ActivityType, ActivityType != "ContentCollection"),
ContentRequests=countif(ActivityType == "ContentCollection"),
TotalResponseBytes=sum(coalesce(ResponseSize, 0)),
SampleUris=make_set(RequestUri, 15)
by ActorId, IpAddress, ApplicationId, bin(Timestamp, 1h)
| where isnotnull(DiscoveryFirst) and isnotnull(CollectionFirst)
| where CollectionFirst >= DiscoveryFirst
and DiscoveryCategories >= 2 and ContentRequests >= 1
| order by CollectionFirst desc
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.
Microsoft researchers observed a high-volume phishing campaign using invisible Unicode tag characters, a technique popularized in AI prompt injection research as ASCII Smuggling. Instead of using these characters to hide instructions from people while exposing them to AI models, the attacker used them to split financial lure words such as ‘funding’ to prevent email filters from parsing them.
The finding emerged from Microsoft Defender for Office 365 prompt injection protection research, showing how AI-era evasion techniques can surface in traditional phishing campaigns. In Microsoft telemetry, hits on a hunting signature designed to detect ASCII-smuggling increased sharply beginning February 9, 2026, and remained elevated on weekdays for approximately three months. Microsoft Defender for Office 365 telemetry showed that the majority of messages were flagged by layered protections rather than by reliance on a single Unicode-specific signal.
What is ASCII smuggling?
“ASCII smuggling” refers to the use of invisible or non-rendering Unicode characters to hide content inside text that looks normal. The most abused range is the Unicode Tags block, U+E0000 to U+E007F. This block contains a shadow copy of the printable ASCII characters (for example, U+E0041 mirrors ‘A’, U+E0061 mirrors ‘a’). The block was originally intended for language tagging and is now largely deprecated.
The important property for an attacker is this: most of these code points are not rendered by typical fonts and user interfaces. A string can therefore carry a message that is not readable to a human but will be processed by any language model or other software that receives a copy of the email content.
Why the AI-security world made it famous
Over the past year, ASCII smuggling became a recurring technique in the prompt injection and cross-prompt injection (XPIA) literature. The attack pattern is straightforward:
An attacker hides instructions inside invisible tag characters embedded in a web page, document, email, or other content.
A human (and many user interfaces) sees nothing unusual.
An AI assistant that ingests the raw text does “see” the hidden characters, decodes them as text, and may be induced to follow threat actor-controlled instructions, potentially including data exposure or unauthorized actions depending on the assistant’s permissions and safeguards.
Because this technique cleanly demonstrates the gap between what the human sees and what the model reads, it appeared frequently in AI red-teaming write-ups, conference talks, and tooling throughout 2025. That attention put a spotlight on the U+E0000-U+E007F range.
Because tag characters are invisible to humans but exist at the text-processing level, the same property that makes them useful for smuggling instructions into a model also makes them useful for obfuscating keywords before a detector evaluates them. The intent is inverted, but the mechanism is similar and a user’s suspicions are not raised.
Writing a practical ASCII-smuggling signature
As part of work on Microsoft Defender for Office 365 prompt injection protection, we built hunting logic for email-borne XPIA and prompt obfuscation patterns: content that looks harmless to users but may carry hidden instructions for an AI system that ingests the raw message. The same hunt designed to identify prompt injection risk in email became the starting point for this phishing-evasion discovery.
One practical way to hunt for ASCII smuggling is to look for messages carrying characters from the Unicode tags block (U+E0000-U+E007F), the hallmark of attempts to hide instructions from, or for, an AI model. That broad signature is a useful starting point, but it needs enough Unicode context to avoid mistaking legitimate tag-character sequences for abuse.
The first version simply flagged any code point in that range, which proved too blunt. It kept firing on a small subset of perfectly legitimate messages – which, on inspection, all contained one of three subdivision flag emojis: the flags of England, Scotland, and Wales – because those emojis are encoded using tag characters.
After those exclusions, remaining hits were mostly benign artifacts from email-security gateways, mailbox providers, and security or AI researchers forwarding or testing messages that contained tag characters. This provided a good baseline where any spikes would indicate abuse of this technique by attackers.
Figure 1. The three subdivision flag emojis – England, Scotland, and Wales – that tripped the naive signature. Each is encoded as a sequence of invisible Unicode tag characters (U+E0000-U+E007F).
Figure 2. The Wales flag emoji pasted into the ASCII Smuggler tool from Embrace The Red. What renders as a single flag is actually a base flag code point (U+1F3F4) followed by an invisible tag-character sequence spelling gbwls (U+E0067 U+E0062 U+E0077 U+E006C U+E0073) and a terminating tag (U+E007F) – the same U+E0000-U+E007F range the signature watches for.
What we observed: ASCII smuggling repurposed for phishing
New activity emerges in telemetry
The tuned ASCII-smuggling signature began as an AI-security hunt for hidden prompt injection content in email. Instead, it surfaced finance-themed phishing messages using the same Unicode range for filter evasion.
On February 9, 2026, signature hits increased sharply. The following chart reflects Microsoft Defender for Office 365 telemetry for the hunting signature over the measured period:
Figure 3. Daily hits on the ASCII smuggling signature, a week before and after onset. Volume holds at a low-thousands baseline through February 8, jumps roughly two orders of magnitude on February 9, peaks at over 2.3 million messages on February 11, and dips sharply on Sunday February 15 before rebounding.
The day before onset (February 8) the signature fired on roughly 21,000 messages; the next day it fired on more than 1.3 million. Most of the emails can be formed into a cluster of roughly 150 finance-themed sender domains.
Observed over three months with a weekly rhythm
Continuing to track the clustered sender domains forward in time, we measured messages matching the activity described every day. The high-volume phase persisted for roughly three months after February 9 and dropped sharply after May 15, 2026. These dates bound the observed use of the specific technique in our telemetry, not the broader campaign, which started earlier without it and continued without it.
Figure 4. Daily Unicode-tag signature hits on finance-themed sender domains, log scale, measured every day from February 9 through June 18, 2026. The deep recurring drops are weekend pauses in the observed signature matches; the decline after May 15 marks the end of the high-volume phase matching this exact activity, followed by a low residual.
Two characteristics stand out:
A strict weekly cadence. The campaign ran hard on weekdays and went almost completely silent every weekend. Sundays’ volume collapsed to a near-zero and then back to full volume the next day. This on/off pattern is typical of scheduled bulk-sending infrastructure.
A long, gradual decline. After an intense first phase, with weekday volumes of 1 to 2.37 million messages, peaking on February 26, the numbers stepped down slowly to roughly 80% less per weekday by late March. The high-volume usage of the technique dropped sharply after May 15, with lower residual activity through mid-June and occasional smaller spikes.
After identifying the activity through this technique-specific signal, we connected it to a broader ActiveCampaign-delivered SBA-themed phishing campaign that Fortra had documented earlier. That earlier reporting indicates the campaign predated the adoption of Unicode tag characters; our analysis focuses on the period and messages in which this method was present, not the full lifetime of the broader campaign.
Not instruction smuggling, but filter evasion
Observed obfuscation pattern
When we looked at a sampling of the flagged messages, the surprise was there were no smuggled instructions to an AI assistant. Instead, the invisible tag characters were inserted inside common financial keywords, splitting them apart so that a literal signature or keyword match would fail.
Figure 5. Example of a finance-themed phishing email promoting business funding and credit-line offers.Figure 6. A second example of a finance-themed phishing email advertising business funding and line-of-credit offers. Similar messages in the campaign inserted invisible Unicode tag characters into financial lure terms to help evade detection.
For example, a finance lure term that appeared normal to the recipient could be transmitted with an invisible tag character in the middle:
funding
became:
fun⟨U+E0020⟩ding
Figure 7. Example of the HTML source of a phishing email from the observed campaign. The yellow rectangles highlight invisible Unicode tag characters.
Here, ⟨U+E0020⟩ represents the invisible Unicode TAG SPACE inserted between letters. In the messages we examined, the campaign did not encode a hidden ASCII message in the tag block; it used a single invisible tag character as a separator sprinkled inside high-signal words. Strictly speaking, this is invisible-character insertion using a code point from the ASCII-smuggling tag block, rather than full message smuggling.
Why it can affect detection
To a recipient, and to parsing pipelines that drop or normalize these characters, the word still reads as funding. To a detector matching the literal string funding, or a regex that does not account for interleaved invisible code points, the byte sequence no longer contains the contiguous keyword. Whether real-world detectors behave that way depends on their normalization step, which is examined below.
The bigger prize for the attacker, though, is not preventing the literal string matches; it is the ML- and NLP-based models that increasingly drive modern spam and phishing classification. Unless a filtering system takes a picture of a message and does OCR extraction over the visual image, it may miss this type of attack. A standard email classifier may not reason over whole words exactly as a human sees them; for efficiency, they can first split text into tokens or sub-word pieces. A clean lure term such as funding may be represented as a familiar token or a familiar sequence of sub-tokens. Insert an invisible U+E0020 into the middle, however, and the tokenizer may no longer see that same familiar unit. It might split the text into fun, an unexpected tag character, and ding; it might emit rare or unknown sub-tokens; or, if normalization runs first, it simply removes the U+E0020 character, leaving funding.
Why it can help defenders
There is also a defensive opportunity. Since this kind of manipulation appears so seldom in normal traffic, its presence becomes a high-confidence signal. A technique meant to make messages look more benign to ML models can instead give defenders a low-false-positive indicator to detect on.
What is known and what is new
Inserting invisible or look-alike characters to break keyword and signature matching is a long-standing evasion technique used in spam and phishing: defenders have for years seen zero-width spaces (U+200B), zero-width non-joiners, the no-break space (U+00A0), soft hyphens, and homoglyph substitutions used to fracture words so naive string matchers fail.
What is new is the specific characters and scale of the campaign:
The character choice. Instead of the usual zero-width space or NBSP, this campaign reached for the Unicode Tags block. That block went from forgotten to famous over the past year because of AI security research into ASCII smuggling and prompt injections.
The scale and discipline. At its peak in Microsoft telemetry, the campaign generated multi-million message daily volume.
A possible detection blind spot. Because the Unicode Tags block is less commonly abused than zero-width spaces or NBSP, defenders should verify that normalization and tokenization pipelines handle tag characters consistently.
Financially themed sending domains
The campaign ran on hundreds of disposable, finance-themed sender domains with lures that resembled business loan, line-of-credit, and advance-funding phishing patterns often associated with fraud or credential-harvesting funnels. This pattern accounted for roughly 96% of the volume flagged by the hunting signature. The signature also fired on other domains, but those were unrelated senders – chiefly email-security gateways and personal mailbox providers – not part of the campaign.
A partial sample of sender domains counts from February 9, 2026 alone illustrates both the naming pattern and the per-domain volume:
Sender domain
Hits (Feb 9, 2026)
guardiangrowthfunding[.]com
30,442
digitalcapitalboost[.]com
27,021
thebusinessloanexpress[.]com
25,048
yourlocfunding[.]com
24,482
advancefundingboost[.]com
24,053
guardiancapitalway[.]com
23,921
harboradvancefunding[.]com
23,595
unitedfundingwave[.]com
23,269
directcapitalboost[.]com
22,875
onlinedirectfinance[.]com
21,195
catalystcapitalharbor[.]com
21,130
rocketboostfunding[.]com
20,908
digitalrushcapital[.]com
20,796
guardianloccapital[.]com
20,781
guardianlocchoice[.]com
20,553
ourbusinessloans[.]com
20,444
directcapitalpulse[.]com
19,767
catalystboostfunding[.]com
19,519
elevatecapitalrush[.]com
19,395
fundingexpresscapital[.]com
18,695
Table 1. Top 20 (by signature hits) of the 148 finance-themed campaign sender domains seen on February 9, 2026, illustrating the naming convention and per-domain volume.
Every domain is just a recombination of the same small vocabulary. The 20 domains above are built from only 28 word-tokens:
advance · boost · business · capital · catalyst · choice · digital · direct · elevate · express · finance · funding · growth · guardian · harbor · loan · loans · loc · online · our · pulse · rocket · rush · the · united · wave · way · your
Sent through a legitimate email-marketing platform
The finance-themed domains in Table 1 are the brand (header / P2) domains the recipient sees, but the actual mail was relayed through infrastructure associated with the legitimate email-marketing platform ActiveCampaign. The platform, which is used widely for marketing, rewrites every outbound link in the message body to route through its own click-tracking domains (acemlnd[.]com and activehosted[.]com), so the URLs the recipient clicks do not point at the brand domain at all – they look like:
Most of the flagged messages carried links associated with the platform’s tracking domains rather than direct links that point directly to the sender-branded domains. The envelope (P1) senders were platform subdomains of the form em-<id>.<brand-domain>.
ActiveCampaign response
Before we published this information, we shared our findings with ActiveCampaign to help them with this abuse, and they wanted us to share the following statement on their work to detect it:
“We appreciate Microsoft’s research and welcome collaboration with the security community to combat this activity. We take abuse, fraud, and security extremely seriously. We tested the specific technique described in this research against our content-moderation systems: messages containing invisible Unicode characters receive the same moderation verdicts as their unobfuscated equivalents, and heavy use of the technique is itself treated as a suspicious signal. We continually invest in improving our detection and prevention capabilities, including expanding our use of AI and machine learning to identify abusive sending behavior earlier in the account lifecycle.”— ActiveCampaign spokesperson
As with any shared sending service, attacker abuse of customer accounts or workflows can complicate reputation-based filtering. By originating from a reputable marketing platform with established IP reputation and authentication, the activity may appear more similar to legitimate marketing traffic and can complicate reputation-based filtering.
Most observed volume also originated from cloud-hosting ranges consistent with the platform’s outbound infrastructure, with the vast majority coming froma single network block, 173.236.20[.]0/24. This indicator helped us cluster the campaign more precisely but note that this is a legitimate segment that belongs to the abused service, and not an IOC on its own.
Identifying the campaign
Content and infrastructure remained consistent for a long time span, providing an effective way to easily fingerprint this phase of the campaign:
Unicode content (primary). Invisible Unicode tag characters in the range U+E0000-U+E007F – specifically U+E0020 – spliced inside keywords. Legitimate mail rarely ever carries these code points: the one routine exception, the England/Scotland/Wales flag emojis, is easily excluded.
Lure and brand pattern. Sender (header / P2) domains assembled from a small finance vocabulary – capital, fund/funding, loan, loc, lend, finance, business, express, growth, solutions, choice, hedge, pillar – recombined into fresh, disposable domains and rotated.
Envelope (P1) pattern. The bulk of mail is relayed through a single email-marketing platform, recognizable by envelope shape rather than any one name:
per-account subdomains shaped em-<digits>.<brand-domain> (regex em-\d+\.), where a small set of reused account numbers fans out across hundreds of brand domains; and
the platform’s shared sending pool, shaped acems<N>[.]com and emsd<N>[.]com (e.g. emsd4[.]com, s9.acems10[.]com). Across the measured activity, ~98.5% of messages matched this envelope pattern, and ~99.8% matched the envelope pattern or the platform’s tracking-URL pattern (below).
Tracking-URL pattern. Click/tracking links on the platform’s domains activehosted[.]com and acemlnd[.]com.
Sending-origin pattern. The bulk of daily volume – about 92% across two measured weeks – originated from a single /24 network block, 173.236.20[.]0/24.
For a high-precision rule, look for the Unicode content pattern combined with the finance-brand pattern, using the sender infrastructure patterns as corroboration.
However, this is just a phase in a long-running broader campaign, that keeps adapting and evolving. The campaign was observed months earlier following a different set of behaviors and continued even after the usage of the specific technique was dropped. During these shifts in behavior, one signature may no longer describe the campaign, while another still matches.
Is there a detection gap?
The potential gap for mail-defense pipelines is whether Unicode tag characters are normalized or flagged before content detections run. In Defender, our filter stack can take a picture of message contents, extract visible text through OCR, and run analysis over that extracted text to avoid these types of tricks. Implementations vary, so defenders should test how these characters are handled in their own pipelines. For MDO protection, over 99% of messages were flagged by layers that did not depend on catching the tag characters directly, including sender, IP, URL and domain reputations, ML spam/phishing classification, brand-impersonation detection, authentication checks and more.
Emerging techniques don’t stay in one domain
ASCII smuggling earned its reputation as an AI attack, hiding instructions from people while leaving them visible to models. This campaign shows the same technique being repurposed for a different objective: obscuring phishing content from detection systems while remaining readable to the intended target.
The broader lesson is that security techniques rarely stay confined to a single domain. As AI-era attack methods become better understood, threat actors may adapt them for use in more traditional threats such as phishing and spam. This case illustrates how techniques that emerge in AI security research can quickly cross over into established attack ecosystems, reinforcing the need for defenders to view emerging threats through a cross-domain lens.
Mitigation and protection guidance
The core defensive principle is simple: normalize before you match. Any content that will be evaluated by keyword, signature, or regex logic should first have invisible and non-rendering Unicode code points stripped or folded, so that splicing them into a word no longer defeats the match.
Recommended controls
Strip or normalize Unicode tag characters (U+E0000-U+E007F) – and other zero-width / invisible code points – from email subject and body text before applying spam and phishing content signatures.
Treat the presence of tag-block characters as a strong anomaly signal. Outside known legitimate tag-sequence uses such as certain subdivision flag emojis, these code points are rare in ordinary mail and can be a high-value anomaly signal.
Look for the behavioral fingerprint. The observed activity had a distinctive shape: bulk volume from churning, finance-themed disposable domains, on a strict weekday-on / weekend-off schedule. A sudden spike of tag-block characters concentrated on finance-themed senders, switching on and off weekly, is a high-confidence campaign indicator.
Apply the same normalization upstream of AI ingestion. The same control that defeats this evasion also reduces XPIA / ASCII-smuggling exposure for AI assistants that ingest email content.
Microsoft protections
Microsoft Defender for Office 365 has heuristic detections in place to flag these the tactics employed in this type of campaign. The detection that first surfaced the spike continues to flag messages carrying Unicode tag-block characters, and the financially themed sending domains are being tracked and blocked as they rotate. Microsoft uses layered email protections, including standard and OCR content analysis, sender and domain reputation, URL detonation and reputation, bulk-mail detection, and anti-phishing models, to reduce reliance on any single signal that an attacker can try to evade.
Microsoft Defender for Office 365 prompt injection protection further helps protect against emails that contain prompt injection attempts, including cases where invisible characters are used to hide instructions from users while exposing them to AI systems. The same normalization and detection principles that reduce ASCII-smuggling-based prompt injection risk also help blunt this email-borne reuse of the technique for phishing evasion. Investments in AI security and traditional email security increasingly reinforce one another.
Coverage depends on product licensing, configuration, and telemetry.
Advanced hunting
These queries run against the EmailEvents Advanced Hunting table (and EmailUrlInfo for URL joins). They hunt the campaign by its infrastructure fingerprint – the finance-vocabulary brand senders and the marketing-platform envelope shape – rather than by the invisible tag characters, as the mail body is not exposed through the table’s columns. These queries are starting points and may require environment-specific tuning. The proactive defense is implemented with multiple layers of the enterprise mail-filtering pipeline.
1. Infrastructure pattern – finance-vocabulary senders relayed with the campaign’s envelope shape. Combines the brand-domain pattern (a header sender built from three or more adjacent finance/brand keywords, e.g. digital+capital+boost) with the envelope (MAIL FROM) shape em-<digits> / acems<digits> / emsd<digits> – the durable fingerprint that held across the entire period we measured.
// Finance/brand vocabulary the operator recombines into disposable domains.
let kwds = @"(capital|fund|hedge|express|solutions|choice|lend|growth|loan|loc|finance|business|pillar|advance|boost|catalyst|digital|direct|elevate|guardian|harbor|online|pulse|rocket|rush|united|wave|way|surge|swift|elite)";
EmailEvents
| where Timestamp > ago(30d)
| where EmailDirection == "Inbound"
// Header sender domain made of 3 or more adjacent finance/brand tokens.
| where SenderFromDomain matches regex strcat("(?i)", kwds, kwds, kwds)
// Envelope (MAIL FROM) shape: em-[digits] | acems[digits] | emsd[digits].
| where SenderMailFromDomain matches regex @"(?i)(em-|acems|emsd)\d"
| sort by Timestamp desc
For extra corroboration you can scope to the single dominant /24 that carried the bulk of this campaign’s volume, 173.236.20[.]0/24, by adding | where ipv4_is_in_range(SenderIPv4, “173.236.20.0/24”). Like the tracking URLs, that network block is shared platform space (it also carries unrelated legitimate newsletters), so use it to scope, never as a standalone filter.
2. Pivot on the platform tracking URLs. Start from the click/tracking links and join back to the mail events. Useful for scoping, but treat it as corroboration, not a verdict: the tracking domains activehosted[.]com and acemlnd[.]com are shared by every legitimate customer of the same marketing platform, so the URL on its own is not a malicious indicator. The finance-brand filter is what keeps this on the campaign; drop it only if you deliberately want a wider search.
let kwds = @"(capital|fund|hedge|express|solutions|choice|lend|growth|loan|loc|finance|business|pillar|advance|boost|catalyst|digital|direct|elevate|guardian|harbor|online|pulse|rocket|rush|united|wave|way|surge|swift|elite)";
EmailEvents
| where Timestamp > ago(30d)
| where EmailDirection == "Inbound"
| where SenderFromDomain matches regex strcat("(?i)", kwds, kwds, kwds)
| join kind=inner (
EmailUrlInfo
| where Timestamp > ago(30d)
| where UrlDomain endswith "activehosted.com" or UrlDomain endswith "acemlnd.com"
| distinct NetworkMessageId
) on NetworkMessageId
| sort by Timestamp desc
3. Filter for prompt injection detection in emails
The feature used in the query below is available for Microsoft Defender for Office 365 Plan 2 or Microsoft 365 E5 customers.
EmailEvents
| where DetectionMethods has "Prompt Injection Protection"
MITRE ATT&CK techniques observed
This campaign exhibits the following MITRE ATT&CK® techniques. The table includes MITRE ATT&CK for phishing/evasion behavior and MITRE ATLAS for the AI-security technique class related to prompt obfuscation.
Invisible Unicode tag characters (U+E0000-U+E007F) spliced into high-signal keywords to break signature and keyword matching and alter downstream tokenization.
Bulk-registered, rotating sender domains used by the campaign. See representative sample in Table 1.
Envelope (P1) sender shaped em-<digits>.<brand> or shared pool acems<N>[.]com / emsd<N>[.]com
Infrastructure pattern
Reputation-laundering relay through a legitimate email-marketing platform
Sending IPv4 block 173.236.20[.]0/24
Infrastructure (IPv4)
Single /24 that carried ~92% of the measured activity volume; legitimate shared email-marketing-platform egress space – a strong scoping/corroboration signal, not a standalone block indicator
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.
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.
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.
The conversation around AI-powered threats has focused heavily on the attacker side. What models can do, what vulnerabilities they can find, how fast they can chain exploits together. But the more important question for security practitioners is simpler and harder. Is your detection posture ready for what’s already happening?
AI has lowered the barrier to entry for sophisticated attacks. Threat actors don’t need to be experts to leverage LLMs for obfuscation, exploit development, or chaining attack steps that previously required deep manual skill. The speed and volume of attacks is increasing as a result. Detection engineering is part of how defenders respond. And most organizations are further behind than they realize, especially because many detection engineering programs live in their own siloed “ivory tower”, detached from the realities of what SOC analysts are handling.
At Intezer, AI-powered detection engineering runs as part of a closed loop with automated, forensic triage and investigation. Every alert investigated across the environment feeds new signal back into detection logic, so coverage improves continuously instead of drifting between quarterly tuning cycles. Detection working in concert with triage and investigation is what a fully optimized security environment looks like against AI-powered attackers. In this article, we’ll focus on how to improve detection engineering practices in general.
Why your current detection posture isn’t keeping pace
The fundamental problem is that most detection programs were built for a world where attack volume was bounded by attacker expertise. That constraint is being removed. LLM-augmented attacks can move faster, produce more permutations, and adapt more readily to your environment than traditional campaigns. A detection posture built on static indicators and periodic tuning cycles can’t keep up.
There are three places this shows up in practice.
Covering one sub-technique doesn’t cover the technique
First, most organizations are only covering technique-level MITRE ATT&CK mappings, not sub-techniques. When you claim T1059 is covered because you have a rule for T1059.001, you’re exposing yourself to real risk hiding beneath that coverage number. Sub-techniques carry distinct behaviors that may exist in your environment and go completely undetected. High-level coverage scores look good in reports and obscure what’s actually happening. The risk lives at the sub-technique level.
IOCs are brittle indicators
Second, IOC-based detections are becoming a liability at scale. IP addresses, file hashes, domains are valuable in incident response but brittle as primary detection logic. Their half-life is short, adversaries burn them readily, and maintaining a large list of active IOCs creates noise without proportionate signal. Organizations that lead with IOCs end up toggling rules on and off constantly, adding friction without improving coverage. The maintenance cost compounds without a meaningful security return.
Pulling logs is not the same as pulling useful logs
Third, telemetry that looks healthy often isn’t. A Windows Event ID 4688 without command-line logging enabled is an example. You’re paying to ingest it, it shows up in your coverage maps, but it provides no actionable data when something fires. Unmapped or broken telemetry creates the appearance of coverage where none actually exists. Before you write a new rule, validate that the data it depends on actually contains what you think it does.
What behavioral detection actually means in practice
Behavioral detections are built around what attackers do across a campaign, not what artifacts they happened to leave behind in a specific incident. Techniques, sequences, tool patterns, execution chains persist across campaigns, across threat actors, and even across malware families. A behavioral detection written well today has a much longer useful life than any IOC-based rule.
The shift to behavioral detection isn’t just a philosophy, it requires specific changes to how rules are built and maintained.
Score based detection
Score-based detection logic is one of the most underused approaches in enterprise SIEMs. If you’re running Splunk, Sumo Logic, or Cortex XDR, score-based rules let you assign weighted values to individual signals and alert when combinations cross a threshold. Individual signals that are weak in isolation, a process executing from an unusual path, a network connection to an uncommon destination, a scheduled task created outside business hours, become meaningful together. Noise goes down. True positive rate goes up. And the system stays tunable as your environment changes.
Permutation testing
Permutation testing is the other discipline most detection programs skip. LLMs make it straightforward to generate attack variants at volume. Defenders should be doing the same before releasing rules. If a detection rule only catches one specific implementation of a technique, an attacker using a slightly different toolchain or execution order will evade it. Testing rules against a range of permutations before production deployment closes gaps that post-deployment tuning will miss.
The detection engineering cycle has to get faster
The traditional cycle, write a rule, deploy it, wait for something to fire, tune reactively when it generates too many false positives, is too slow for the current threat environment. By the time you’ve finished tuning a rule for last quarter’s threat, new attack patterns are already in the wild.
The cycle needs to compress at every stage. Prototype rules should be tested in isolated environments before they reach production. Sandboxes and virtual machines can be spun up quickly in the same pipeline as rule development, giving you a controlled validation environment. Rules that are tuned before deployment don’t flood the SOC on their first day, and analysts who aren’t buried in false positives from new rules are analysts who can actually investigate real threats.
Continuous monitoring closes the loop. Every alert that fires, every verdict and every outcome feeds information back into the detection posture. Which rules are generating signal? Which ones are generating noise? Where are the coverage gaps that no existing rule addresses? Without this feedback loop, detection engineering becomes a periodic exercise rather than a continuously improving system.
A well integrated feedback loop investigates every single alert a detection creates, resolves false positives from critically important detections while continuously tuning the behavioral model to secure your organization and security detection pipeline.
Coverage benchmarks worth using
Coverage benchmarks help set realistic expectations and give teams a concrete target. Based on what we see across enterprise environments:
Less than 30% MITRE ATT&CK coverage is immature. Organizations in this range typically have out-of-the-box rules, minimal customization, and significant gaps across Initial Access, Execution, and Lateral Movement.
30 to 45% represents a decent in-house SOC. Rules exist, there’s some customization, but detection engineering is not a dedicated discipline and tuning is reactive.
45 to 60% is strong. Dedicated attention to detection posture, some behavioral logic, and active management of the detection lifecycle.
60 to 70% is top-tier. Behavioral detection is primary, coverage is continuously maintained, and the feedback loop between investigation and detection is functioning.
Anything above 70% is usually inflated. Scores at this level typically reflect mapping sprawl across multiple MITRE versions, technique-level claims that obscure sub-technique gaps, or rules that are mapped but broken. Validate the underlying data before trusting the number.
The goal isn’t 100% coverage. That number isn’t achievable or meaningful. The goal is systematic, maintainable coverage of the techniques most relevant to your environment and your crown jewels, with the sub-technique depth to catch how those techniques are actually executed.
How AI changes things for attackers and defenders
Mythos focused attention on a specific capability and that is autonomous chaining of exploit steps that previously required human guidance at each stage. A skilled researcher can still walk an LLM through finding a vulnerability, reaching exploit code, and overtaking an instruction pointer, but that process requires human direction at each transition. What makes autonomous chaining meaningful is that it removes the human from the loop on the attacker side.
The detection engineering response isn’t a new category of rule. It’s the same disciplines applied with more rigor and at higher speed. Attackers using LLMs are still executing against endpoints, still writing to disk or running in memory, still making network connections, still creating processes. The behaviors are recognizable. What changes is the volume of variants and the speed at which new campaigns emerge.
Score-based logic handles volume well because it doesn’t require a rule per variant. Permutation testing handles new variants better than reactive tuning because gaps are found before deployment rather than after. Behavioral coverage handles campaign evolution better than IOC maintenance because the underlying techniques persist even as the tooling changes.
This is where an integrated model matters most. AI-powered detection engineering delivers the most value when it doesn’t operate in isolation, and at Intezer it runs on the same loop as automated triage and investigation. The platform investigates 100% of alerts across endpoint, identity, cloud, network, and SIEM, and every verdict feeds directly back into detection, surfacing noisy rules, broken telemetry, and coverage gaps as they happen rather than at the next review. Detection, triage, and investigation reinforcing one another is what produces a fully optimized security environment, one that keeps pace as attacker AI accelerates.
The organizations that fare best against AI-powered threats will be the ones that already had a functioning detection engineering program, one built on behavioral logic, continuous feedback, and validated telemetry, before the threat landscape changed. Catching up under pressure is possible, but it’s harder and slower than building the discipline now.
The attacker’s AI is getting faster. The detection engineering cycle should be too.
Cardiac monitoring provider iRhythm has been hit by a data theft followed by an extortion attempt.
In a filing with the Securities and Exchange Commission (SEC), iRhythm revealed it was contacted by someone on June 9 who claimed to have stolen sensitive information, including proprietary data, patient PHI, and other personal information. That person demanded payment in exchange for not publishing the data.
iRhythm provides ambulatory cardiac monitoring and analysis (for example using the Zio patch) and has reportedly processed over two billion hours of heartbeat data from more than twelve million patients.
In the filing, the company said the data was obtained through social engineering and is from “certain third-party-hosted business applications”, without revealing any further details about the amount of data.
On its own website, iRhythm also doesn’t disclose much about the nature of the stolen data, but does seem to imply no financial data was affected:
“We have not identified any impact to our products, our clinical or medical device systems, our connections to customers, our manufacturing and distribution operations, patient safety, or our ability to meet patient needs. In addition, we do not store or retain individual financial account information or payment card information.
As we actively investigate, we will notify individuals affected by this incident in accordance with applicable law and take steps as needed to protect and remediate the impact to them.“
However, the SEC filing adds that iRhythm determined that the incident is significant, “in light of the volume of the potentially affected data.” Together with the extortionist’s claims that they have patients’ medical data, that makes the breach one worth noting if you have used iRhythm’s services.
Even without payment data, healthcare breaches have serious downstream effects:
Attackers can craft highly convincing emails, texts, or calls that reference specific procedures or monitoring episodes (for example, “about your recent Zio patch recording”) to trick patients into sharing more data or paying fake bills.
The breached data can be used to create a fake identity, insurance fraud, or medical identity theft.
Exposure of cardiac and other health‑related information can be deeply sensitive and may have employment/insurance ramifications, especially if data is posted publicly or sold to data brokers.
Healthcare breach data tends to circulate for years, and victims may face sporadic fraud and phishing attempts long after the headlines fade.
How to stay safe
If you’ve used iRhythm’s services, keep an eye on your post, email, and patient portals for official breach notifications from iRhythm or your healthcare provider.
In the US, breaches of protected health information that meet certain criteria must be reported to patients and regulators. iRhythm has promised to “notify individuals affected by this incident in accordance with applicable law and take steps as needed to protect and remediate the impact to them.”
To stay out of the hands of phishers and scammers:
When you receive a communication about the data breach, verify through other channels that it really came from iRhythm. Go directly to iRhythm’s official website or patient portal, or call a known phone number to confirm the communication is genuine.
Be extra suspicious of emails or texts that claim to offer compensation, refunds, or other financial consequences related to this incident.
Change passwords for your iRhythm‑linked portals and your cardiology or hospital patient portals, especially if you reused those passwords elsewhere.
Log into your health insurer’s portal and check claims on a regular basis.
If you see anything suspicious, report it immediately to your insurer and provider and ask them to flag your account for possible identity theft.
Do not provide personal or financial information over the phone just because the caller knows details about you which they may have obtained from the stolen data.
Let’s face it, an incognito window can only do so much.
Breaches, dark web trading, credit fraud. Malwarebytes Identity Theft Protection monitors for all of it, alerts you fast, and comes with identity theft insurance.
He walked into the lobby with a fake badge clipped to his shirt. He had bought it online the week before. It was not perfect, and it did not need to be. From a few feet away, it looked close enough: a logo, a name, a photo, and a lanyard. The kind of thing most people glance at for half a second before their brain decides, “Looks fine.”
Attackers are increasingly targeting collaboration platforms like Microsoft Teams. Learn the risks and key steps to strengthen your organization's security.
Login
