Microsoft Security Experts Blog articles

EDR coexistence by design: A practical starting point to Defender

Raae_ — Thu, 30 Apr 2026 17:27:14 GMT

Co-authors: Kayla Rohde & Kenneth Johnson

Having multiple cybersecurity technologies, controls, systems, and stakeholders operating together without conflict is not a temporary inconvenience. It is how real environments operate and a practical way to make progress without disruption.

Complexity exists because businesses are complex. Endpoint platforms already deployed, are relied upon 24/7. Moreover, contracts and operational dependencies make them challenging to change. On the other hand, many organizations already own Microsoft licensing that entitles them to Defender endpoint capabilities, including the ability to run Microsoft Defender for Endpoint in passive mode with EDR capabilities enabled.

Increasingly, organizations are finding that coexistence can deliver meaningful security outcomes. In addition, when designed with purpose, coexistence allows teams to being realizing the value of their existing Microsoft licensing, strengthen detection and response, and build confidence in Defender under real-world operating conditions.

In practice, once teams see the depth of signal, investigation quality, and platform integration that Defender provides, most will migrate over and use it as their primary endpoint security platform once the technical, operational, and economic timing makes sense.

Side-by-side is not standing still

A common assumption is that side by side deployment exists only as a short bridge to replacement. That assumption does not hold up in real environments.

Experienced teams use coexistence as a controlled transition model that produces immediate security outcomes while preserving operational stability.

Running Defender alongside an existing prevention platform allows organizations to:

Activate endpoint telemetry and behavioral detections already included in licensing
Expand investigative depth without disrupting the current prevention layer
Validate detection coverage before making enforcement changes
Build operational familiarity with Defender workflows under real conditions
Maintain visibility during periods of architectural change

Coexistence is not about running two tools. It is about sequencing risk reduction with intent.

What Passive Mode actually means for your SOC

One of the most persistent points of confusion is what “passive mode” actually entails.

When Defender operates in passive mode:

It is not the real‑time blocking engine
Another platform remains the primary prevention control
EDR capabilities continue to collect telemetry, generate detections, and support investigation

For seasoned practitioners, this distinction matters. Many of the most consequential security decisions happen after execution, when responders need clarity, context, and speed. Defender endpoint capabilities contribute directly in that phase, regardless of which tool owns real‑time blocking. This is why coexistence works. It preserves prevention continuity while materially improving detection and response.

Turning licensed capability into operational advantage

The real value of Defender for Endpoint in a coexistence model is not just what it observes on the endpoint. It is how that signal connects across the Microsoft security platform to produce a more complete picture of attacker behavior.

Even in passive mode, MDE is not a standalone sensor. Endpoint telemetry feeds into a system that correlates identity, email, cloud, and data signals into a unified investigation experience. That is where the advantage compounds.

As organizations begin to operationalize MDE in coexistence scenarios, endpoint telemetry does more than generate alerts. It enriches incidents with process level and device context, then ties that activity to identity signals such as risky sign ins, anomalous sessions, and lateral movement patterns. Email events and user interaction history align with execution timelines. Data access and sensitivity context introduce impact.

The result is not more “noise”. It is better context. What changes is not just visibility. It is decision quality. Process execution is no longer evaluated in isolation. It is tied to a user, a session, an originating communication, and the data that may have been accessed or exposed. Investigations become faster, more confident, and more defensible.

This is especially relevant for organizations already licensed for Microsoft 365 E5 or equivalent that have not enabled Defender for Endpoint. In those environments, coexistence is not introducing another tool. It is activating an intelligence layer that already exists and is not yet contributing signal.

Once that signal is connected, a suspicious process execution becomes materially richer. It can be correlated to a user’s sign in risk posture, traced back to an originating email or phishing thread, enriched with device exposure and vulnerability context, and evaluated against sensitive data access.

That is a fundamentally different investigation than what a siloed endpoint alert produces. Passive mode does not diminish this value. It enables it. Organizations can establish a unified detection and investigation layer while preserving their existing prevention controls. Isolated telemetry becomes an operational signal. Signal becomes a coordinated response.

For teams that have not yet enabled MDE, the gap is not capability. It is visibility that is already licensed, already available, and not yet being used.

From entitlement to enforcement: A resilience arc

Cyber resilience is not about assuming controls never fail. It’s about maintaining visibility, decision quality, and response speed when they do.

Using Defender Endpoint capabilities in a side‑by‑side model:

Improves resilience during periods of change
Reduces dependency on a single control plane
Allows teams to mature detection and response before altering enforcement ownership

Over time, many organizations choose to simplify. Layering builds resilience while teams learn. Platform consolidation sustains it once confidence is earned.

We focused on coexistence because it reflects where many organizations begin, not because it is where they should end. Many teams already have endpoint protection in place and licensing that entitles them to Defender Endpoint Capabilities. Coexistence allows those capabilities to be turned on, understood, and used effectively without forcing premature decisions or unnecessary disruption. It creates a practical on‑ramp that lets teams build confidence, improve detection and response, and establish operational muscle before making broader platform choices.

Learn more: MDE side-by-side guidance: https://learn.microsoft.com/en-us/defender-endpoint/mde-side-by-side

When the shield becomes the sword: How misconfigured PAM bridges the tiering model

UgurTGudekli — Wed, 15 Apr 2026 18:34:46 GMT

In the world of identity security, few tools promise as much peace of mind as Privileged Access Management (PAM). It is often referred to as the "vault" that locks away your kingdom's keys. However, in Microsoft Incident Response – the Detection and Response Team (DART) engagements, we frequently encounter a paradox: the tool used to secure Tier 0 often becomes a quick path for threat actors to compromise it.

In a recent DART engagement, a threat actor moved from a compromised helpdesk workstation to full domain compromise in under four hours. They didn't use a zero-day. They used the organization's PAM server.

We have seen this story play out in real-time. An organization invests heavily in Active Directory (AD) Tiering and a premium PAM solution. They feel secure. Yet, during an incident, we trace the threat actor’s path and find they didn't burn a zero-day or crack a complex algorithm. They simply walked across a bridge the organization built themselves: a PAM server positioned in Tier 1 that held the keys to Tier 0.

This isn't a failure of the product; it's a failure of positioning. This post shares what DART sees on the front lines, why "intermediaries" are the most critical link in your chain, and how to deploy PAM without rolling out a red carpet for threat actors.

The foundation: A quick refresher on tiering model and PAM, PIM, and PAW concepts

Before we dive into the threat actor’s tactics and techniques, let’s revisit the ground rules and define a few key concepts. The Active Directory Tiering Model is built on a simple premise: prevent credential theft propagation; ensuring that credentials with administrative access to higher-tier systems are never exposed on lower-tier systems where a threat actor may already have a foothold.

Tier 0 is your control plane: Domain Controllers, PKI, and the identities that manage your authentication plane.

Tier 1 houses your application servers and data.

Tier 2 is the high-risk environment: user workstations and devices exposed to the internet.

The golden rule of tiering is strictly one-way: higher tier admins must never expose their credentials to lower tier systems, and lower tiers must never have management access to higher tiers. The core purpose of this separation is to ensure that a compromised workstation cannot yield Domain Admin credentials. However, operational tools that bridge these tiers often inadvertently break this definitional boundary.

PAM (Privileged Access Management): Solutions designed to securely vault credentials and broker administrative sessions, ensuring access to critical systems is monitored and controlled.

PIM (Privileged Identity Management): Tools that manage the lifecycle of elevated roles, typically by enforcing time-bound, Just-In-Time (JIT) access to eliminate standing privileges.

PAW (Privileged Access Workstation): Highly hardened, dedicated devices used exclusively for sensitive administrative tasks, physically or logically isolating tier admins from high-risk activities like email and web browsing.

Figure 1: Administration with dedicated tiered accounts

The front-line reality: the shared intermediary trap

Imagine this scenario: A threat actor compromises a standard workstation (Tier 2) through a phishing email. Their goal is the Domain Controller (Tier 0). In a properly tiered environment, this path is blocked; there are no credentials on the workstation to steal, and no direct privilege escalation route to the Domain Controller.

But then the threat actor finds an intermediary system.

In many environments, we see a single PAM session host used by everyone. The Tier 1 admins use it to manage application servers, and the Tier 0 admins use it to manage Domain Controllers. This convergence creates a "Shared" or "Dirty" Intermediary.

The attack path

The foothold: The threat actor compromises a standard Tier 2 workstation.
The escalation: The threat actor moves laterally and escalates privileges by exploiting common lower-tier misconfigurations (such as Helpdesk scenarios or exposed privileged service accounts) to compromise a Tier 1 administrator account who has full control over the Tier 1 PAM Host.
The pivot: Because the PAM Session Host resides in Tier 1, the threat actor uses those compromised Tier 1 admin rights to seamlessly gain full control of the underlying operating system of the PAM host itself.
The compromise: The threat actor simply waits for a Tier 0 admin to initiate a session. Because the threat actor already has full administrative control over the underlying server, it is a given that they can extract the Tier 0 credentials the moment that session begins.
Note: A threat actor at this stage does not need to exploit any weakness in the PAM software itself. Because the session host logically resides within the Tier 1 boundary, any identity or system with administrative rights over that tier holds ultimate authority over the host. This administrative control provides the means to modify the host's configuration, bypass security agents, and disable runtime protections before a privileged session ever begins. Once this foundational control is established, credential material processed by the operating system for outbound privileged sessions becomes accessible. This is not a PAM product failure; it is an architectural placement failure
Game over: The threat actor replays those credentials to take over the Domain Controller.

Here is how that compromise looks architecturally:

Figure 2: Single PAM host architecture

The core concept: PAM is an intermediary

To understand why the scenario above happens, we have to look at how Microsoft defines Privileged Access Intermediaries.

As detailed in our Privileged access intermediaries guidance, an intermediary is any system that stands between a user and a target resource. This includes VPNs, Jump Servers, and PAM solutions.

The Golden Rule of intermediaries

The security assurance of the target is only as good as the security assurance of the intermediary.

If you manage a Tier 0 asset (like a Domain Controller) through a PAM server, that PAM server becomes a Tier 0 asset. If that PAM server allows logins from Tier 1 users or is reachable from Tier 2 workstations, you have effectively downgraded your Domain Controllers to the security level of a workstation.

You cannot have a "Tier 1" server managing "Tier 0" assets. The math simply doesn't work. Each type of intermediary serves a different role, so the security controls won’t be identical. However, some basics apply to all of them, like quickly patching appliances, firmware, operating systems, and applications.

Figure 3: Security impact of different PAM approaches

Third-party PIM/PAM solutions are often deployed on-premises or as a Virtual Machine (VM) in an Infrastructure as a Service (IaaS) environment and are usually reachable only from internal (intranet) systems. Even if they aren’t exposed to the internet, one stolen credential could let a threat actor reach them through VPN or other remote access methods.

The hidden risk: the "master key" service account

The attack path above assumes a threat actor waits for a human administrator to arrive. But there is a second, more direct risk and it doesn’t require patience at all. It’s not just about where users log in; it’s about the power the software holds.

Consider the Password Reset scenario. A key feature of PAM is automatically rotating Domain Admin passwords, so human admins never need to know them; credentials are simply injected into the session. However, to perform this action, the PAM Service Account itself requires massive privileges (typically Domain Admin or equivalent) to reset those target passwords.

Here is the trap: If your PAM Core or Vault resides in Tier 1 (or is treated as such) but manages Tier 0 credentials, you have effectively granted Domain Admin rights to a Tier 1 asset.

A threat actor doesn't even need to wait for a human administrator to log in. If they compromise the underlying server where the PAM service runs, they can extract the Service Account’s credentials. Since this account has the power to reset Domain Admin passwords, the threat actor instantly elevates to Tier 0; no session required, no waiting, no noise.

This reinforces the golden rule: If a Service Account manages Tier 0, the system it runs on is Tier 0. The two attack vectors: hijacking a session and stealing the service account. Both stem from the same root cause: architectural misplacement. Fix the placement, and you eliminate both.

Practical checklist: are you exposed?

In DART engagements, we use this checklist to rapidly assess if a PAM deployment is a security asset or a liability. Use this to validate your own environment:

The intermediary check: Does any server used to manage Domain Controllers allow inbound RDP, SMB or other management connections from standard workstations or Tier 1 servers? (If yes, you are bridged).
The identity check: Do you use the same "Admin" account to log into the PAM portal for both Tier 0 and Tier 1 tasks? (If yes, you are exposing credentials).
The reachability check: Can your PAM Vault/Core be reached from the general user network? (It should only be reachable from management zones).
The isolation check: Are your Tier 0 Session Hosts logically and technically treated as Tier 0 assets?

What good looks like: The tiered PAM architecture

How do we fix this? We don't throw away PAM; we align it with the Enterprise Access Model.

In DART, we advocate for a tiered PAM deployment. This doesn't necessarily mean buying three different PAM vaults. It means strictly segregating the session hosts and the control plane.

The architecture of isolation

Tier 0 Control Plane: The core of your PAM (the Vault, the Policy Manager) holds the keys to the kingdom. Therefore, it must be treated as Tier 0. It should only be manageable by Tier 0 admins from Tier 0 workstations.
Segregated Session Hosts: You must have separate session host infrastructure for each tier.

- Tier 1 Session Host: Accessible from Tier 1, manages Tier 1. Blocked from talking to Domain Controllers.
- Tier 0 Session Host: Accessible only from Tier 0 PAWs, manages Tier 0. Totally isolated from the rest of the network.

This diagram illustrates a PAM deployment that respects the tiering model:

Figure 4: Separate PAM host architecture

For a deeper dive into reconciling these paradigms, review Intermediaries in Securing Privileged Administration and Microsoft's guide on Partitioning Administrative Privileges.

FAQ: Clearing the confusion

Q: Does PAM always belong in Tier 0?

A: If the PAM system manages Tier 0 credentials or provides access to Tier 0 assets, yes. The components that touch Tier 0 (Vault, Brokers, Session Hosts) must be secured at Tier 0 standards.

Q: Can we use a single "hardened" session host for all tiers to save costs?

A: In DART's experience, no. "Hardening" is often a configuration state that drifts or is bypassed by zero-days. Architecture beats configuration. If you bridge the network tiers, a compromised Tier 1 admin account is all a threat actor needs to gain OS-level control of that host and from there, access to Tier 0 sessions is a matter of patience, not sophistication.

Q: If we have PAM, do we still need the Tiering Model?

A: Absolutely. PAM doesn’t replace Tiering; when implemented correctly, it adds another layer of security and/or governance. Tiering keeps credentials and admin access separated, so threat actors can’t easily move sideways or reuse stolen hashes. PAM provides workflow, rotation, and audit trails.

Q: What is the most common mistake you see?

A: We frequently see organizations approach PAM as a "magic stick", believing it secures everything about credential hygiene. Yet, because they assume the tool secures itself, they treat this critical infrastructure as just another Tier-1 asset. It gets patched like a standard file server and monitored like a print server, rather than being hardened and isolated as a Tier-0 component. This mindset doesn't secure the environment; it creates a fragile bridge that threat actors can easily cross.

Q: Our PAM vendor says their session host is hardened out of the box. Why is this still a risk?

A: PAM vendors are right that a well-configured session host with Credential Guard enabled, application control enforced, and remote management restricted is considerably harder to exploit than a stock Windows Server. Some vendors use Kerberos constrained delegation with S4U2Proxy, meaning the machine account rather than the Domain Admin’s actual credentials authenticates to the target, which limits direct credential exposure. These are meaningful controls and we don’t dismiss them. However, application-layer hardening is defeated by OS-layer control. If the PAM host is domain-joined and sits in a Tier 1 OU, a Tier 1 Domain Admin has Group Policy, software deployment rights, and Active Directory machine account control over that host. They can push a GPO to disable Credential Guard, deploy a driver via software distribution, or alter the machine’s configuration before the next reboot, all using entirely legitimate AD administration tools. The vendor’s hardening is irrelevant once the threat actor controls the tier the machine lives in. This is precisely why tier placement is not a PAM configuration decision; it is an Active Directory architecture decision.

Q: We’re cloud-first and use Entra ID. Does AD Tiering still apply to us?

A: The specific tier labels change, but the principle does not. Microsoft’s Enterprise Access Model is the cloud-era evolution of AD Tiering, built around the same core concept: Control Plane (equivalent to Tier 0), Management Plane (Tier 1), and User Access / Data Plane (Tier 2). In an Entra ID environment, your Control Plane includes Global Administrators, Privileged Role Administrators, and the Conditional Access policies that govern them. A PAM or PIM solution managing those identities must be treated with the same isolation discipline. Hybrid environments, where on-premises AD and Entra ID are synchronized, carry the additional risk that a compromise of either plane can propagate to the other through synchronization. If anything, hybrid environments make strict intermediary placement more critical, not less.

Conclusion

PAM is a powerful tool in the defender’s arsenal; but like any powerful tool, its effectiveness depends entirely on how it is positioned. The threat actors we encounter in DART engagements don’t look for the most sophisticated path to Domain Admin. They look for the most trusted one. A PAM server in the wrong tier isn’t a hardened barrier; it’s a trusted bridge with a gold-plated sign.

By aligning your PAM deployment with the principles of Privileged Access Administration, treating session hosts and service accounts as the tier of the assets they manage, not the zone they physically sit in, you close the bridge before a threat actor finds it.

Build your architecture like a threat actor will find it. Because they will.

Stay secure, stay tiered.

Hunting Infostealers - Trusted Platform Abuse

FeliciaCarter — Wed, 15 Apr 2026 16:00:00 GMT

In this part of the “Hunting Infostealers” series, we explore the growing abuse of trusted communication services and software ecosystems—including messaging platforms like WhatsApp and seemingly benign PDF converter tools—to propagate malware and deploy credential stealers such as Eternidade Stealer, lowering user suspicion and complicating detection. Throughout the blog, we map observed activity to Microsoft Defender XDR coverage and provide actionable guidance to help organizations detect, mitigate, and respond to infostealers.

Platform Abuse (WhatsApp, PDF Converters)
Since late 2025, Platform abuse has become an increasingly prevalent tactic in the modern threat landscape, wherein adversaries deliberately exploit the legitimacy, scale, and user trust associated with widely used applications and services. By weaponizing platforms such as WhatsApp and seemingly benign PDF conversion tools, threat actors are able to disguise malicious activity within normal user behavior, enabling efficient malware delivery, lateral propagation, and evasion of traditional security controls.

WhatsApp Abused to Deliver Eternidade Stealer

During the third week of November 2025, Microsoft Defender Experts (DEX) identified a WhatsApp platform abuse campaign that leverages a multi-stage infection chain and worm-like propagation techniques to distribute malware. The activity begins with the execution of an obfuscated Visual Basic script, which drops a malicious batch file that launches multiple PowerShell instances to download additional payloads from adversary-controlled command-and-control domains. These payloads include a Python script responsible for WhatsApp Web–based dissemination of the malware in a worm-like manner, as well as a malicious MSI installer that ultimately delivers the Eternidade Stealer. To ensure successful execution, the batch script also installs the required Python dependencies on the compromised system.

The Python script establishes communication with a remote server and leverages the open-source project WPPConnect to automate message sending from hijacked WhatsApp accounts. As part of this process, it harvests the victim’s entire contact list while filtering out groups, business contacts, and broadcast lists. The malware then collects, for each contact, the associated WhatsApp phone number, name, and an indicator showing whether the contact is saved. This information is exfiltrated to an attacker-controlled server via an HTTP POST request. In the final stage of this propagation mechanism, the malware sends a malicious attachment to all harvested contacts, using a predefined messaging template populated with time-based greetings and contact names to increase the likelihood of interaction.

The malicious MSI installer drops several components, including encrypted payload files with .dmp and .tda extensions, an AutoIt executable, and a script loader disguised as a .log file. Despite its benign appearance, the .log file functions as an AutoIt-based malicious script that conducts environment reconnaissance, performs anti-detection checks, and loads payloads in memory using large hex-encoded binary blobs to initialize native components. The encrypted .tda file acts as an injector and employs a process hollowing technique to execute the final payload. Specifically, the injector reads the .dmp file, decrypts the embedded payload, and injects the Eternidade Stealer into svchost.exe, allowing the malware to run stealthily under the guise of a trusted system process.

Eternidade Stealer, a Delphi-based credential stealer, continuously monitors active windows and running processes for strings associated with banking portals, payment services, and cryptocurrency exchanges and wallets. These include, but are not limited to, Bradesco, BTG Pactual, MercadoPago, Stripe, Binance, Coinbase, MetaMask, and Trust Wallet, highlighting its focus on harvesting sensitive financial and cryptocurrency-related information

WhatsApp Abuse to Deliver Eternidade Stealer Attack Chain

Malicious Crystal PDF installer campaign

In late September 2025, Microsoft Defender Experts (DEX) discovered a malicious campaign conducted by an unknown threat actor centered on an application masquerading as a PDF editor named Crystal PDF. The campaign leveraged malvertising and search engine optimization (SEO) poisoning techniques, using misleading advertisements to lure users into downloading a malicious payload.

The attack chain begins when a user clicks the download button for the PDF editor on crystalpdf[.]com. The request is redirected to one of two actor-controlled domains, from which the CrystalPDF.exe payload is downloaded. Users most likely arrived at this website through deceptive advertisements distributed via Google Ads, which served as the primary lure for the campaign. Microsoft suspects that Google Ads were used based on the URL format observed in telemetry: hxxps://smartdwn[.]com/download?v=<GUID>&campaign_id=<ID#>&utm_source=google_b2b&subid=<domainSource>&kw=true&gad_source=5&gad_campaignid=<ID#>&gclid=<>.

When CrystalPDF.exe is downloaded and executed on the device, it performs several actions to establish persistence and enable further activity. A copy of the CrystalPDF.exe payload is created in the AppData\Local\Temp\crys directory, and a malicious scheduled task is created to ensure continued execution on the compromised device. In addition, a second binary named Crystal PDF.exe (note the space in the filename) is dropped in the user’s Desktop folder.

The attacker configures the payload to run daily at 7:15 AM local system time using a scheduled task named Crystal_updater. When triggered, this scheduled task launches the malicious CrystalPDF.exe, which initiates network connections to three command-and-control domains: negmari[.]com, ramiort[.]com, and strongdwn[.]com.

The secondary executable, Crystal PDF.exe, stored in the Desktop directory, establishes network connections to multiple cloudconvert[.]com-related domains. CloudConvert is a legitimate service used to convert files into different formats, including converting various document types into PDF files. Analysis of this file indicates that it is a clean file and is designed to appear as a legitimate application that leverages CloudConvert to provide document-to-PDF conversion functionality.

Despite presenting itself as a legitimate PDF conversion and merging tool, CrystalPDF.exe ultimately functions as an information stealer. It covertly hijacks Firefox and Chrome browsers and attempts to access sensitive files located in the AppData\Roaming directory, which stores user-specific configuration and profile data that must persist across sessions. This includes cookies and session data, sign-in and credential caches, and profile settings. By harvesting credentials, tokens, and session cookies stored in the browser, the attacker can bypass standard authentication mechanisms and impersonate the user to gain unauthorized access to accounts and services that the user is authorized to use.

Crystal PDF Installer Attack Chain

Mitigation and protection guidance

Microsoft recommends the following mitigations to reduce the impact of trusted platform abuse used to deliver infostealers as discussed in this report. These recommendations draw from established Defender blog guidance patterns and align with protections offered across Microsoft Defender XDR.

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

Strengthen user awareness & execution safeguards

Educate users on social‑engineering lures, including malvertising redirect chains, fake installers, and ClickFix‑style copy‑paste prompts.

Control outbound traffic & staging behavior

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

Protect against cross‑platform payloads

Harden endpoint defenses around LOLBIN abuse, such as wscript.exe executing Visual Basic scripts.
Evaluate activity involving AutoIt and process hollowing, common in platform‑abuse campaigns.

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.
Run EDR in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach.
Enable network protection and web protection in Microsoft Defender for Endpoint to safeguard against malicious sites and internet-based 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.
Allow investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume.
Turn on tamper protection features to prevent attackers from stopping security services. Combine tamper protection with the DisableLocalAdminMerge setting to prevent attackers from using local administrator privileges to set antivirus exclusions.
Microsoft Defender XDR customers can also implement the following attack surface reduction rules to harden an environment against LOLBAS techniques used by threat actors:

o Block execution of potentially obfuscated scripts

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

o Block JavaScript or VBScript from launching downloaded executable content

Microsoft Defender XDR detections

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

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

Tactic	Observed activity	Microsoft Defender coverage
Execution	- Payloads downloaded using PowerShell	Microsoft Defender for Endpoint - Suspicious Powershell download or encoded command execution
Persistence	- Registry Run key created - Scheduled task created for recurring execution	Microsoft Defender for Endpoint - Anomaly detected in ASEP registry - Suspicious Scheduled Task Launched
Defense Evasion	- Unauthorized code execution facilitated by DLL sideloading and process injection - Python script execution - Renamed AutoIT interpreter binary and AutoIT script	Microsoft Defender for Endpoint - An executable file loaded an unexpected DLL file - A process was injected with potentially malicious code - Suspicious Python binary execution - Rename AutoIT tool
Discovery	- System information queried using WMI and Python	Microsoft Defender for Endpoint - Suspicious System Hardware Discovery - Suspicious Process Discovery - Suspicious Security Software Discovery

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 the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender XDR Threat analytics

Malicious Crystal PDF installer campaign

Hunting queries

Microsoft Defender XDR

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

Use the following queries to identify activity related to WhatsApp Abused to Deliver Eternidade Stealer

// Identify the files dropped from the malicious VBS execution DeviceFileEvents | where InitiatingProcessCommandLine has_all ("Downloads",".vbs") | where FileName has_any (".zip",".lnk",".bat") and FolderPath has_all ("\\Temp\\")

// Identify batch script launching powershell instances to drop payloads DeviceProcessEvents | where InitiatingProcessParentFileName == "wscript.exe" and InitiatingProcessCommandLine has_any ("instalar.bat","python_install.bat") | where ProcessCommandLine !has "conhost.exe"

// Identify AutoIT executable invoking malicious AutoIT script DeviceProcessEvents | where InitiatingProcessCommandLine has ".log" and InitiatingProcessVersionInfoOriginalFileName == "Autoit3.exe"

Use the following queries to identify activity related to Malicious CrystalPDF Installer Campaign

// Identify network connections to C2 domains DeviceNetworkEvents | where InitiatingProcessVersionInfoOriginalFileName == "CrystalPDF.exe"

// Identify scheduled task persistence DeviceEvents | where InitiatingProcessVersionInfoProductName == "CrystalPDF" | where ActionType == "ScheduledTaskCreated

Indicators of compromise

Indicator	Type	Description
2c885d1709e2ebfcaa81e998d199b29e982a7559b9d72e5db0e70bf31b183a5f 6168d63fad22a4e5e45547ca6116ef68bb5173e17e25fd1714f7cc1e4f7b41e1 3bd6a6b24b41ba7f58938e6eb48345119bbaf38cd89123906869fab179f27433 5d929876190a0bab69aea3f87988b9d73713960969b193386ff50c1b5ffeadd6 bdd2b7236a110b04c288380ad56e8d7909411da93eed2921301206de0cb0dda1 495697717be4a80c9db9fe2dbb40c57d4811ffe5ebceb9375666066b3dda73c3 de07516f39845fb91d9b4f78abeb32933f39282540f8920fe6508057eedcbbea	SHA-256	Payloads related to WhatsApp malware campaign
598da788600747cf3fa1f25cb4fa1e029eca1442316709c137690e645a0872bb 3bc62aca7b4f778dabb9ff7a90fdb43a4fdd4e0deec7917df58a18eb036fac6e c72f8207ce7aebf78c5b672b65aebc6e1b09d00a85100738aabb03d95d0e6a95	SHA-256	Payloads related to Malicious Crystal PDF installer campaign
hxxps://empautlipa[.]com/altor/installer.msi	URL	Used to deliver VBS initial access payload (WhatsApp Abused to Deliver Eternidade Stealer)
Negmari[.]com Ramiort[.]com Strongdwn[.]com	Domain	C2 servers (Malicious Crystal PDF installer campaign)

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.

References

Infostealers Strike Again: Malicious Installers Pass Through EDRs Undetected

SpiderLabs IDs New Banking Trojan Distributed Through WhatsApp

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.

Hunting Infostealers - Python Stealers

FeliciaCarter — Wed, 08 Apr 2026 16:00:00 GMT

In this next part of the “Hunting Infostealers” series, we’ll cover Python information stealers. The proliferation of Python stealers over the past year has become an escalating concern in the cybersecurity landscape. This gravitation towards Python is largely driven by the ease of use of the language and the availability of tools and frameworks which allow for quick development, even for individuals with limited knowledge of coding. Typically, Python infostealers are distributed via phishing emails to infiltrate systems. The sensitive information they collect includes, but is not limited to login credentials, session cookies, authentication tokens, credit card numbers, and crypto wallet data. To evade detection, threat actors utilize legitimate services such as Telegram for command-and-control communications, obfuscate their code, and use signed and living off the land binaries. Due to the growing threat of Python-based infostealers, it is important that organizations protect their environment by being aware of the tactics, techniques, and procedures used by the threat actors who deploy this type of malware.

One of the most notable Python-based infostealers seen in 2025 was PXA Stealer. It harvests sensitive data from infected systems such as login credentials, financial information, and browser data. It is linked to Vietnamese-speaking threat actors who target government and education entities. It is primarily delivered via phishing campaigns that use social engineering to trick users into downloading malicious files onto their computer. Throughout the blog, we map observed activity to Microsoft Defender XDR coverage and provide actionable guidance to help organizations detect, mitigate, and respond to infostealers operating without borders.

PXA Stealer: Campaign 1

In October 2025, Microsoft Defender Experts (DEX) identified a campaign involving PXA Stealer. The attack begins with a phishing email with a malicious URL. Some of the observed URLs contained in the emails were hxxp://concursal[.]macquet[.]de/uid_page=244739642061129 and hxxps://tickets[.]pfoten-prinz[.]de/uid_page=118759991475831. The URLs have the same format, but with different domain names and values for the uid_page key. When the user clicks the URL, they are taken to a blank web page that contains JavaScript to download a ZIP file from a remote location, such as allecos[.]de, once the page is fully loaded. The files contained in the ZIP file that are used to execute the next payload include an executable (renamed WinWord.exe) masquerading as a Word document with the same name as the ZIP file, a malicious DLL named msvcr100.dll, and several files used in a series of commands concatenated with “&&” that ultimately execute an obfuscated Python script that loads PXA Stealer and PureRAT. When the renamed WinWord.exe file is executed, msvcr100.dll is sideloaded which leads to the execution of the concatenated command line via cmd.exe. The command line does the following: opens a benign decoy Word document to delay the users’ suspicion and sandbox analysis, uses certutil.exe to decode a base64-encoded blob hidden in DA 성형외과 재무 보고서.pdf which results in a ZIP file named Invoice.pdf (contains Python environment, renamed Python interpreter named svchost.exe, and an obfuscated Python script named images.png), uses another file named images.png (renamed WinRAR.exe) to extract the contents of Invoice.pdf, deletes Invoices.pdf and the renamed WinRAR file, then uses svchost.exe (renamed pythonw.exe) to execute images.png with a Telegram bot identifier that’s used to fetch and execute the next payload. When images.png is executed, it creates a Registry Run key named Windows Update Service to re-execute itself when the user logs in. The script downloads PXA Stealer from urlvanish[.]com (URL shortener), which redirects to bagumedios[.]cloud, then executes the infostealer in its memory space.

Before collecting information, the stealer downloads a DLL from Dropbox. The DLL is injected into a Chrome process to bypass Chrome’s App-Bound Encryption (ABE) so sensitive browser information can be stolen. After that, it collects the installed AV products and browser information such as login credentials, cookies, autofill data, and credit card information. That information is archived into a ZIP file with a file name that follows the format "[CountryCode_IPAddress] ComputerName.zip", then it’s exfiltrated using Telegram.

Once the exfiltration is complete, images.png downloads another payload from hxxps://bagumedios[.]cloud/assets/media/others/ADN/pure and injects it into cvtres.exe. The payload is a commercially available remote access trojan named PureRAT which proceeds to connect to its command-and-control (C2) server 157.66.27[.]11 (located in Vietnam) over port 56001 after injection. After that, cvtres.exe uses WMI to collect installed AV products, connected cameras, and the Windows OS version. It sends the collected information to its C2 server.

PXA Stealer (Campaign 1) Attack Chain

PXA Stealer: Campaign 2

In late December 2025, DEX identified another PXA Stealer campaign. This attack also begins with a phishing email that delivers a ZIP archive that masquerades as a PDF, image, or Word document. Some similar TTPs were noted for the second campaign where the use of Living Off-the Land Binaries (LOLBINs) was invoked, such as certutil.exe. The Certutil application is a native Windows application that allows for displaying Certification Authority (CA) configuration information, configure Certificate Services, and backup and restore CA components. The program also verifies certificates, key pairs, and certificate chains.

The capability used in Campaign 2 used the decode parameter in Certutil on an encoded PDF. The decoded PDF was then presented to an application with a file extension of “.png”. Further investigation of this application identified command line behavior typical to that of a WinRAR, with a password protected ZIP archive. This obfuscation allowed the application to continue to perform un-archiving steps, ultimately leading to python modules being loaded on the device. Once the Python modules were available, additional activity such as scheduled tasks were created paving the way for update scripts to be deployed on affected hosts. Communication to C2 infrastructure was then initiated through the svchost (Python interpreter) process to connect and transmit data to the attacker via hxxp://195.24.236[.]116/recover/getlink?id=sunset and hxxp://195.24.236[.]116/recover/links/sunset.txt

PXA Stealer (Campaign 2) Attack Chain

Mitigation and protection guidance

Microsoft recommends the following mitigations to reduce the impact of the Python‑based infostealers discussed in this report. These recommendations draw from established Defender blog guidance patterns and align with protections offered across Microsoft Defender XDR.

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

Strengthen user awareness & execution safeguards

Educate users on social‑engineering lures, such as phishing emails.

Control outbound traffic & staging behavior

Inspect network egress for POST requests to newly registered or suspicious domains—a key indicator for Python‑based stealer campaigns.
Detect transient creation of ZIP archives under ephemeral directories, followed by outbound exfiltration attempts.
Block direct access to known C2 infrastructure where possible, informed by your organization’s threat‑intelligence sources.

Protect against Python‑based stealers

Harden endpoint defenses around LOLBIN abuse, such as certutil.exe decoding malicious payloads.
Evaluate abnormal activity involving known processes and files with suspicious file extensions, such as a Python interpreter masquerading as svchost.exe executing a Python script disguised as a PNG file.

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.
Run EDR in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach.
Enable network protection and web protection in Microsoft Defender for Endpoint to safeguard against malicious sites and internet-based 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.
Allow investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume.
Turn on tamper protection features to prevent attackers from stopping security services. Combine tamper protection with the DisableLocalAdminMerge setting to prevent attackers from using local administrator privileges to set antivirus exclusions.
Microsoft Defender XDR customers can also implement the following attack surface reduction rules to harden an environment against LOLBAS techniques used by threat actors:

o Block execution of potentially obfuscated scripts

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

o Block JavaScript or VBScript from launching downloaded executable content

Microsoft Defender XDR detections

Tactic	Observed activity	Microsoft Defender coverage
Execution	- Encoded PowerShell commands downloading payload	Microsoft Defender for Endpoint - Suspicious Powershell download or encoded command execution - Suspicious script launched
Persistence	- Registry Run key created - Scheduled task created for recurring execution	Microsoft Defender for Endpoint - Anomaly detected in ASEP registry - Suspicious Scheduled Task Launched
Defense Evasion	- Unauthorized code execution facilitated by DLL sideloading and process injection - Renamed Python interpreter executes obfuscated Python script - Decode payload with certutil	Microsoft Defender for Endpoint - An executable file loaded an unexpected DLL file - A process was injected with potentially malicious code - Suspicious Python binary execution - Suspicious certutil activity Microsoft Defender Antivirus - Obfuse' malware was prevented (Trojan:Script/Obfuse!MSR)
Credential Access	- Credential and Secret Harvesting	Microsoft Defender for Endpoint - Possible theft of passwords and other sensitive web browser information - Suspicious access of sensitive files - Suspicious process collected data from local system
Discovery	- Information queried using WMI and Python	Microsoft Defender for Endpoint - Suspicious System Hardware Discovery - Suspicious Process Discovery - Suspicious Security Software Discovery - Suspicious Peripheral Device Discovery
Collection	- Sensitive browser information compressed into ZIP file for exfiltration	Microsoft Defender for Endpoint - Compression of sensitive data - Suspicious Staging of Data - Suspicious archive creation

Threat intelligence reports

Microsoft Defender XDR Threat analytics

Hunting queries

Microsoft Defender XDR

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

Use the following queries to identify activity related to PXA Stealer: Campaign 1

// Identify activity initiated by renamed python binary DeviceProcessEvents | where InitiatingProcessFileName endswith "svchost.exe" | where InitiatingProcessVersionInfoOriginalFileName == "pythonw.exe"

// Identify network connections initiated by renamed python binary DeviceNetworkEvents | where InitiatingProcessFileName endswith "svchost.exe" | where InitiatingProcessVersionInfoOriginalFileName == "pythonw.exe"

Use the following queries to identify activity related to PXA Stealer: Campaign 2

// Identify malicious Process Execution activity DeviceProcessEvents | where ProcessCommandLine has_all ("-y","x",@"C:","Users","Public", ".pdf") and ProcessCommandLine has_any (".jpg",".png")

// Identify suspicious process injection activity DeviceProcessEvents | where FileName == "cvtres.exe" | where InitiatingProcessFileName has "svchost.exe" | where InitiatingProcessFolderPath !contains "system32"

Indicators of compromise

Indicator	Type	Description
9d867ddb54f37592fa0ba1773323e2ba563f44b894c07ebfab4d0063baa6e777	SHA-256	Payloads related to PXA Stealer: Campaign 1
08a1f4566657a07688b905739055c2e352e316e38049487e5008fc3d1253d03b
5970d564b5b2f5a4723e548374d54b8f04728473a534655e52e5decef920e733
59855f0ec42546ce2b2e81686c1fbc51e90481c42489757ac03428c0daee6dfe
a5b19195f61925ede76254aaad942e978464e93c7922ed6f064fab5aad901efc
e7237b233fc6fda614e9e3c2eb3e03eeea94f4baf48fe8976dcc4bc9f528429e
59347a8b1841d33afdd70c443d1f3208dba47fe783d4c2015805bf5836cff315
e965eb96df16eac9266ad00d1087fce808ee29b5ee8310ac64650881bc81cf39
hxxps://allecos[.]de/Documentación_del_expediente_de_derechos_de_autor_del_socio.zip	URL	Used to deliver initial access ZIP file (PXA Stealer: Campaign 1)
	URL
hxxps://bagumedios[.]cloud/assets/media/others/ADN/pure	URL	Used to deliver PureRAT payload (PXA Stealer: Campaign 1)
hxxp://concursal[.]macquet[.]de/uid_page=244739642061129	URL	URL contained in phishing email (PXA Stealer: Campaign 1)
hxxps://tickets[.]pfoten-prinz[.]de/uid_page=118759991475831	URL	URL contained in phishing email (PXA Stealer: Campaign 1)
hxxps://erik22[.]carrd.co	URL	Used in make network connection and subsequent redirection in (PXA Stealer: Campaign 2)
hxxps://erik22jomk77[.]card.co	URL	Used in make network connection and subsequent redirection in (PXA Stealer: Campaign 2)
157.66.27[.]11	IP Address	PureRAT C2 server (PXA Stealer: Campaign 1)
157.66.27[.]11	IP Address	PureRAT C2 server (PXA Stealer: Campaign 1)
195.24.236[.]116	IP Address	C2 server (PXA Stealer: Campaign 2)
bagumedios[.]cloud	Domain	C2 server (PXA Stealer: Campaign 1)

Microsoft Sentinel

References

A Vietnamese threat actor's shift from PXA Stealer to PureRAT | Huntress

Ghost in the Zip | New PXA Stealer and Its Telegram-Powered Ecosystem | SentinelOne

Information-Stealing Malware Distribution Campaign Using Emails Disguised as Copyright Infringement Notices – wizSafe Security Signal -Guideposts to Safety and Security- IIJ

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.

Hunting Infostealers - macOS Threats

FeliciaCarter — Wed, 01 Apr 2026 16:00:00 GMT

The “Hunting Infostealers” blog series covers the ever-evolving threat of infostealers. Infostealers have gone from simple credential theft to subscription-based threats (i.e., Malware-as-a-Service) driving modern cybercrime. Threat actors target sensitive information such as browser data, cookies, and session tokens that can later be used for account takeovers or to fuel data breaches, ransomware attacks, and supply chain attacks. In this blog series, Microsoft Defender Experts examine how modern infostealers operate across operating systems and delivery channels by blending into legitimate ecosystems and evading conventional defenses.

In this first part of the series, we highlight the rise of macOS-specific infostealers—including families such as DigitStealer, MacSync, and Atomic macOS (AMOS)—that abuse native utilities, user-initiated execution flows, and social-engineering techniques like “ClickFix” installers to harvest credentials and sensitive data. Throughout the blog, we map observed activity to Microsoft Defender XDR coverage and provide actionable guidance to help organizations detect, mitigate, and respond to infostealers.

macOS Threats

Since late 2025, Microsoft Defender Experts (DEX) has observed macOS targeted infostealer campaigns delivered through social engineering techniques, including ClickFix style prompts and malicious DMG downloads. These attacks rely on user interaction to initiate execution and are designed to steal credentials, session material, and infrastructure secrets that can enable account takeover, financial theft, and follow on compromise of cloud and developer resources. Once executed, the malware abuses trusted macOS functionality to collect a wide range of personal, financial, and enterprise related information. Stolen data can include browser authentication material, operating system credential stores, access keys used for cloud services, and artifacts commonly present on developer or administrator workstations.

The potential impact of this threat extends beyond the infected device. Compromised credentials and session material can enable attackers to take over online accounts, access cloud and enterprise resources, steal cryptocurrency assets, and perform follow on intrusion activity without needing to maintain persistence on the original system. In organizational environments, this can lead to broader security incidents, including unauthorized access to internal services, cloud environments, or third-party platforms.

DigitStealer

In November 2025, Microsoft Defender Experts (DEX) identified a macOS infostealer campaign tracked as DigitStealer, delivered via a spoofed “DynamicLake” lure. The infection chain begins when users browse to a deceptive domain such as dynamiclake[.]org and download an unsigned disk image DynamicLake.dmg, then follow a “drag‑into‑Terminal” execution path that helps bypass Gatekeeper protections.

Dynamiclake[.]org landing page that delivers the unsigned disk image.

Once mounted, DigitStealer executes a Bash-based dropper that uses native tooling (notably curl) to retrieve staged payloads from Cloudflare Pages such as hxxps://b93b559cf522386018e24069ff1a8b7a[.]pages[.]dev/703d2315783f48c0563836f02a3421ed.aspx. In subsequent stages, the malware performs host profiling with system_profiler and uses AppleScript/JXA to drive credential theft and collection, staging artifacts in temporary locations (commonly under /tmp) before compressing content into ZIP archives for outbound transfer.

For exfiltration and C2, DigitStealer uses HTTPS POSTs to structured endpoints and API routes such as /api/grabber, /api/log, and /api/poll, where /api/poll is used for beaconing/tasking while upload routes handle stolen archives. Persistence is established via a macOS LaunchAgent, which can retrieve follow‑on instructions via DNS TXT records (observed use of dig + curl) and immediately execute newly fetched payloads via JXA.

In higher‑value (crypto‑focused) scenarios, DigitStealer targets wallet workflows including Ledger Live, and has been observed manipulating user friction and visibility by suppressing prompts (TCC-related behavior) and tampering with wallet application assets (e.g., Ledger Live.app.asar) to facilitate hijacking.

MacSync

In December 2025, Microsoft Defender Experts (DEX) identified a fileless macOS infostealer campaign referred to as MacSync Stealer, commonly delivered via malvertising and ClickFix-style lures that instruct users to copy/paste commands into Terminal rather than running a traditional installer. DEX has broadly observed these macOS-targeted infostealer campaigns delivered through ClickFix prompts and malicious DMG downloads in late 2025.

Webpage instructing users to copy and run a command in terminal

During observed MacSync activity, no standalone binaries are dropped. Instead, execution is driven by an in‑memory pipeline that invokes curl with TLS verification disabled, streaming the response directly through decoding/decompression (e.g., curl … | base64 -d | gunzip) without writing intermediate files to disk. This technique reduces disk artifacts and pushes detection toward process/network telemetry rather than file hashes.

MacSync then leverages osascript to indirectly invoke shell execution (e.g., sh -c) to blend into legitimate macOS automation, while harvesting a wide set of artifacts across browsers and credential stores. High‑signal targeted files include Chrome databases (Cookies / Login Data / Web Data), Firefox stores (cookies.sqlite / logins.json / key4.db /cert9.db), macOS Keychains (*.keychain-db), and developer/cloud secrets including SSH keys, AWS credentials, Kubernetes config files, plus shell history such as .zsh_history.(Observed in telemetry write‑up you provided.)

Staging and exfiltration are similarly low‑footprint: data is staged under /tmp using the pattern /tmp/sync[0-9]{7}, compressed using the built‑in ditto utility, and exfiltrated via HTTP POST to attacker infrastructure using a legitimate macOS browser user‑agent. Requests use custom headers (including an API key) to authenticate and manage tasking. Post‑exfiltration cleanup deletes staged directories, reinforcing the transient nature of the intrusion.

Atomic Stealer (AMOS)

In January 2026, Microsoft Defender Experts (DEX) observed active exploitation by Atomic macOS Stealer (AMOS), a highly automated and full‑featured macOS infostealer capable of progressing from initial user interaction to persistent command‑and‑control within minutes. Telemetry shows a modular, high‑throughput campaign optimized for credential harvesting, cryptocurrency theft, and long‑term operator control using exclusively native macOS tooling.

Initial access was achieved through redirect‑based delivery chains that guided victims through multiple intermediary domains—alliai[.]com and alli‑ai[.]pro—before downloading a malicious disk image (AlliAi.dmg) hosted on newly registered infrastructure (ai[.]foqguzz[.]com). Upon execution, the unsigned application launched under App Translocation, indicating execution from an untrusted path and effectively bypassing Gatekeeper enforcement.

Immediately after launch, the trojanized application executed its embedded binary (observed as FXSound) via xpcproxy, establishing outbound network connectivity to attacker‑controlled infrastructure (day.foqguzz[.]com) and spawning a staged Bash loader. The loader decoded and executed a Base64‑encoded script and used curl as an ingress tool transfer mechanism to retrieve next‑stage payloads from hxxp://217.119.139[.]117/d/dayd96331, completing a classic multi‑stage stager pattern.

Once staged, AMOS executed a large modular AppleScript payload via osascript, driving extensive system discovery and data collection. Harvested artifacts included macOS Keychains (for example ~/Library/Keychains/login.keychain‑db), browser credentials and session data from Chrome, Edge, Safari, and Firefox (including SafariCookies.binarycookies), Apple Notes databases, desktop and document files, and deep inspection of browser‑based cryptocurrency wallets through IndexedDB enumeration and targeted extension directory scanning. System metadata was collected via system_profiler to uniquely identify compromised hosts and support operator tasking.

Stolen data was staged under /tmp/17936/, compressed using the built‑in ditto utility into /tmp/out.zip, and exfiltrated via HTTP POST requests to hxxp://217.119.139[.]117/log. Exfiltration requests included custom headers—such as buildid, username, and cid—to uniquely identify victims and manage backend processing. AMOS incorporated retry logic and backoff mechanisms to ensure reliable data transfer before deleting local staging artifacts.

For persistence, AMOS installed a root‑level LaunchDaemon (for example /Library/LaunchDaemons/com.<random>.plist) that re‑executed a Base64‑decoded AppleScript payload at system startup. This established a botnet‑style polling loop to endpoints such as /api/v1/bot/joinsystem/<botid>/<macOS_version> and /api/v1/bot/actions/<botid>, enabling operators to issue commands including doshell, repeat, enablesocks5, and uninstall. The observed activity demonstrates a mature macOS stealer architecture optimized for stealth, scalability, and continuous remote control.

Shared Characteristics Across macOS Infostealer Campaigns

Despite differences in tooling and maturity, DigitStealer, MacSync Stealer, and Atomic macOS (AMOS) exhibit a converging macOS infostealer tradecraft driven by user‑initiated execution, fileless delivery, and deep abuse of native macOS frameworks. All three campaigns rely on social engineering—such as malvertising, redirect chains, or ClickFix‑style prompts—to coerce users into mounting unsigned DMGs or executing commands directly in Terminal, effectively bypassing Gatekeeper through explicit user action.

Payload delivery is predominantly fileless and multi‑stage, leveraging native utilities such as curl piped through Base64 decoding and decompression for in‑memory execution. Extensive use of AppleScript and JavaScript for Automation (JXA), alongside additional living‑off‑the‑land binaries (system_profiler, dscl, ditto, and shell interpreters), enables attackers to execute complex workflows while blending malicious activity into legitimate system automation.

All three campaigns aggressively harvest credentials and sensitive artifacts from browsers, macOS Keychains, and developer or cloud environments, while explicitly probing cryptocurrency wallets to prioritize financially valuable victims. Stolen data is staged temporarily (commonly under /tmp), compressed using built‑in archiving utilities, and exfiltrated via HTTP or HTTPS POST requests that mimic legitimate browser traffic, followed by immediate cleanup. Where persistence is required, campaigns rely on LaunchAgents or LaunchDaemons and dynamic tasking mechanisms (such as C2 polling or DNS‑based updates) to maintain access without redeployment.

Taken together, these behaviors highlight why macOS has become an increasingly attractive target: growing adoption in enterprise and developer environments, a rich set of built‑in automation and scripting capabilities that favor living‑off‑the‑land tradecraft, persistent user trust in installer and Terminal workflows, and the widespread presence of browser‑based and native cryptocurrency wallets on a single host. These factors have enabled the rise of scalable, high‑volume macOS infostealer ecosystems that rival traditional Windows‑centric campaigns in both sophistication and impact.

General macOS Infostealer Attack Chain

Mitigation and protection guidance

Microsoft recommends the following mitigations to reduce the impact of the macOS‑focused threats discussed in this report. These recommendations draw from established Defender blog guidance patterns and align with protections offered across Microsoft Defender XDR.

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

Strengthen user awareness & execution safeguards

Educate users on social‑engineering lures, including malvertising redirect chains, fake installers, and ClickFix‑style copy‑paste prompts common across macOS stealer campaigns such as DigitStealer, MacSync, and AMOS.
Discourage installation of unsigned DMGs or unofficial “terminal‑fix” utilities; reinforce safe‑download practices for consumer and enterprise macOS systems.

Harden macOS environments against native tool abuse

Monitor for suspicious Terminal activity—especially execution flows involving curl, Base64 decoding, gunzip, osascript, or JXA invocation, which appear across all three macOS stealers.
Detect patterns of fileless execution, such as in‑memory pipelines using curl | base64 -d | gunzip, or AppleScript‑driven system discovery and credential harvesting.
Leverage Defender’s custom detection rules to alert on abnormal access to Keychain, browser credential stores, and cloud/developer artifacts, including SSH keys, Kubernetes configs, AWS credentials, and wallet data.

Control outbound traffic & staging behavior

Inspect network egress for POST requests to newly registered or suspicious domains—a key indicator for DigitStealer, MacSync, and AMOS.
Detect transient creation of ZIP archives under /tmp or similar ephemeral directories, followed by outbound exfiltration attempts.
Block direct access to known C2 infrastructure where possible, informed by your organization’s threat‑intelligence sources.

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.
Run EDR in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach.
Enable real-time protection for macOS in Microsoft Defender Antivirus.
Enable real-time behavior monitoring for macOS in Microsoft Defender Antivirus.
Enable network protection for macOS in Microsoft Defender for Endpoint.
Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
Allow investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume.
Turn on tamper protection features to prevent attackers from stopping security services. Combine tamper protection with the DisableLocalAdminMerge setting to prevent attackers from using local administrator privileges to set antivirus exclusions.

Microsoft Defender XDR detections

Tactic	Observed activity	Microsoft Defender coverage
Execution	- Execution of various commands and scripts via osascript and sh	Microsoft Defender for Endpoint - Suspicious piped command launched - Suspicious AppleScript activity - Suspicious script launched
Persistence	- LaunchAgent or LaunchDaemon for recurring execution	Microsoft Defender for Endpoint - Suspicious Pslist modifications - Suspicious launchctl tool activity Microsoft Defender Antivirus - Trojan:AtomicSteal.F
Defense Evasion	- Delete data staging directories	Microsoft Defender for Endpoint - Suspicious path deletion
Credential Access	- Credential and Secret Harvesting - Cryptocurrency probing	Microsoft Defender for Endpoint - Suspicious access of sensitive files - Suspicious process collected data from local system - Unix credentials were illegitimately accessed
Collection	- Sensitive browser information compressed into ZIP file for exfiltration	Microsoft Defender for Endpoint - Compression of sensitive data - Suspicious Staging of Data - Suspicious archive creation
Exfiltration	- Exfiltration through curl	Microsoft Defender for Endpoint - Suspicious file or content ingress - Network connection by osascript

Threat intelligence reports

Microsoft Defender XDR Threat analytics

Hunting queries

Microsoft Defender XDR

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

Use the following queries to identify activity related to DigitStealer

// Identify suspicious DynamicLake disk image (.dmg) mounting DeviceProcessEvents | where FileName has_any ('mount_hfs', 'mount') | where ProcessCommandLine has_all ('-o nodev' , '-o quarantine') | where ProcessCommandLine contains '/Volumes/Install DynamicLake'

// Identify data exfiltration to DigitStealer C2 API endpoints. DeviceProcessEvents | where InitiatingProcessFileName has_any ('bash', 'sh') | where ProcessCommandLine has_all ('curl', '--retry 10') | where ProcessCommandLine contains 'hwid=' | where ProcessCommandLine endswith "api/credentials" or ProcessCommandLine endswith "api/grabber" or ProcessCommandLine endswith "api/log" | extend APIEndpoint = extract(@"/api/([^\s]+)", 1, ProcessCommandLine)

Use the following queries to identify activity related to MacSync

// Identify exfiltration of staged data via curl DeviceProcessEvents | where InitiatingProcessFileName =~ "zsh" and FileName =~ "curl" | where ProcessCommandLine has_all ("curl -k -X POST -H", "api-key: ", "--max-time", "-F file=@/tmp/", ".zip", "-F buildtxd=")

Use the following queries to identify activity related to Atomic Stealer (AMOS)

// Identify suspicious AlliAi disk image (.dmg) mounting DeviceProcessEvents | where FileName has_any ('mount_hfs', 'mount') | where ProcessCommandLine has_all ('-o nodev', '-o quarantine') | where ProcessCommandLine contains '/Volumes/ALLI'

Indicators of compromise

Indicator	Type	Description
3e20ddb90291ac17cef9913edd5ba91cd95437da86e396757c9d871a82b1282a da99f7570b37ddb3d4ed650bc33fa9fbfb883753b2c212704c10f2df12c19f63	SHA-256	Payloads related to DigitStealer campaign
42d51feea16eac568989ab73906bbfdd41641ee3752596393a875f85ecf06417	SHA-256	Payload related to Atomic Stealer (AMOS)
217.119.139[.]117	IP Address	AMOS C2 server (AMOS campaign)
dynamiclake[.]org	Domain	Deceptive domain used to deliver unsigned disk image. (DigitStealer campaign)
booksmagazinetx[.]com goldenticketsshop[.]com	Domain	C2 servers (DigitStealer campaign)
b93b559cf522386018e24069ff1a8b7a[.]pages[.]dev 67e5143a9ca7d2240c137ef80f2641d6[.]pages[.]dev	Domain	CloudFlare Pages hosting payloads. (DigitStealer campaign)
barbermoo[.]coupons barbermoo[.]fun barbermoo[.]shop barbermoo[.]space barbermoo[.]today barbermoo[.]top barbermoo[.]world barbermoo[.]xyz	Domain	C2 servers (MacSync Stealer campaign)
alli-ai[.]pro	Domain	Deceptive domain that redirects user after CAPTCHA verification (AMOS campaign)
ai[.]foqguzz[.]com	Domain	Redirected domain used to deliver unsigned disk image. (AMOS campaign)
Day[.]foqguzz[.]com	Domain	C2 server (AMOS campaign)

Microsoft Sentinel

References

MacSync Stealer Evolves: From ClickFix to Code-Signed Swift Malware — Jamf Threat Labs

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.

When Trust Becomes the Attack Vector: Analysis of the EmEditor Supply-Chain Compromise

Parth_Jamodkar — Tue, 10 Mar 2026 16:00:00 GMT

Attackers compromised the upstream distribution mechanism for EmEditor, a widely used Windows text editor. Instead of delivering malware through phishing or malicious domains, the attackers manipulated server-side logic on the official download site to selectively serve a trojanized installer to public users while preserving legitimate content for administrators.

This campaign highlights two recurring challenges in defending modern environments:

Upstream trust abuse: Malicious payloads delivered from legitimate, trusted domains.
Selective evasion: Conditional logic designed to evade validation, monitoring, and routine testing.

Why this matters more now

Attackers increasingly favor techniques that “live off trust” rather than exploit obvious weaknesses. As organizations harden email gateways, enforce attachment scanning, and restrict macro execution, supply-chain compromises provide an attractive alternative path to initial access.

In this case, the attack required no user interaction beyond installing trusted software and relied entirely on legitimate operating system components for execution. This combination significantly reduced detection opportunities and increased the likelihood of successful compromise.

1. Scope and unique insight

This is not a traditional malware delivery campaign. The distinguishing characteristics include:

Server-side conditional manipulation rather than client-side redirection
Weaponization of a legitimate MSI installer
Use of Windows Installer custom actions to execute in-memory payloads
Credential theft via named pipe injection without dropping additional executables.

The investigation demonstrates how endpoint, network, and installer telemetry must be correlated to uncover attacks that intentionally blur the line between legitimate and malicious activity.

Server-side conditional tampering enabling selective MSI delivery.

Attackers compromised the software distribution pipeline to selectively serve a trojanized MSI installer to public users while preserving legitimate behavior for administrators. The malicious installer abused Windows Installer execution, in-memory PowerShell staging, and command-and-control infrastructure to enable credential access.

2. Technical analysis

Discovery and investigation overview

The activity was identified through proactive threat hunting across Microsoft Defender telemetry, focusing on anomalous installer behavior and unexpected PowerShell execution chains originating from trusted software installs.

Multiple signals converged during investigation:

PowerShell execution spawned from msiexec.exe
Network connections from installer-initiated processes to suspicious domains.
Browser process injection without corresponding file creation events

Together, these indicators pointed to a compromised installer rather than a post-installation infection vector.

2.1 Upstream breach: server-side tampering

The initial compromise occurred on a public-facing WordPress environment associated with the EmEditor download infrastructure. Attackers likely gained access via a vulnerable plugin or exposed administrative interface and deployed a web shell to maintain persistence.

Rather than modifying core WordPress files or defacing the site, the attackers injected conditional PHP logic into a theme-level file (footer.php). This logic dynamically altered download behaviour based on visitor context:

Authenticated administrators were served the legitimate EmEditor MSI.
Unauthenticated public visitors were redirected to a trojanized MSI hosted under /wp-content/uploads/.

This split-view evasion technique allowed attackers to weaponize the official domain while avoiding detection by internal validation workflows, routine administrative testing, and automated integrity checks.

2.2 Trojanized MSI installer behavior

The malicious installer closely resembled the legitimate EmEditor MSI in name and functionality but embedded a custom action that executed during installation.

Key characteristics included:

Execution via msiexec.exe -Embedding
Silent spawning of powershell.exe
In-memory execution using Invoke-RestMethod piped to Invoke-Expression

The MSI was digitally signed, but not by the legitimate Emurasoft certificate. Instead, it used a certificate issued to a non-trusted publisher that nonetheless reduced user suspicion.

During installation, Windows cached the MSI in C:\Windows\Installer\, enabling silent re-execution and complicating forensic reconstruction.

2.3 Command-and-control infrastructure

The PowerShell stager connected to attacker-controlled infrastructure using multiple fallback paths to ensure reliability:

Primary endpoint: emeditorjp[.]com
Mirror endpoint: emeditorde[.]com, emeditorgb[.]com, emeditorsb[.]com
Second-stage delivery: cachingdrive[.]com

Connections were observed over HTTP, HTTPS, and TCP, indicating deliberate redundancy. This infrastructure delivered a second-stage payload designed to operate entirely in memory.

2.4 Credential access and browser injection

The second-stage payload targeted browser processes, including chrome.exe and msedge.exe, using named pipe injection techniques.

By injecting directly into existing browser processes, the malware avoided creating new processes or dropping additional files. This enabled access to:

Browser-stored credentials
Authentication cookies
Active session tokens for web and enterprise services

The absence of obvious malware artifacts strongly suggests that credential theft and session hijacking were the primary objectives.

Impact and targeting

Potential targets: Enterprises and individual users installing EmEditor during the affected window.
Industries: Broad, including technology, professional services, and regulated sectors
Impact: Credential compromise, session hijacking, potential lateral movement
Scope: Limited in time but high impact due to trusted distribution channel

3. Mitigation and protection guidance

3.1 What to do now if you’re affected.

Organizations that suspect exposure should take immediate steps to contain potential compromise:

Isolate affected endpoints from the network
Block known malicious domains and IP addresses at DNS and firewall layers.
Force credential resets for users on impacted systems.
Review active browser sessions and revoke tokens where possible.
Conduct full endpoint scans using Microsoft Defender XDR

3.2 Defending against similar attacks.

To reduce exposure to supply-chain attacks of this nature, organizations should consider the following measures:

General security practices

Enforce multi-factor authentication across cloud and enterprise services.
Limit browser-stored credentials and encourage password managers with strong protections.
Monitor software installation activity for anomalous child process behavior.

Endpoint and installer protections

Enforce stricter code-signing validation policies.
Monitor msiexec.exe spawning scripting engines such as PowerShell.
Apply attack surface reduction rules to limit abuse of living-off-the-land binaries.

Microsoft Defender XDR coverage

Microsoft Defender XDR provides coordinated detection and investigation across endpoints, identities, email, and cloud applications. Relevant protections include:

Detection of suspicious PowerShell execution chains
Network-based indicators tied to known malicious infrastructure.
Behavioral monitoring of browser process injection
Cross-domain correlation to identify installer abuse patterns.

Customers are encouraged to review applicable detections and hunting guidance within Microsoft Defender XDR to proactively identify similar activity.

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

Advance Hunting queries - Microsoft Defender XDR

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

1) Detects malicious MSI downloads originating from WordPress upload paths or matching known hashes.

DeviceFileEvents | where FileName endswith ".msi" | where FileOriginUrl has_any ("/wp-content/uploads/","/uploads/MSI/","emeditor-core") or SHA256 in ("4bea333d3d2f2a32018cd6afe742c3b25bfcc6bfe8963179dad3940305b13c98","3d1763b037e66bbde222125a21b23fc24abd76ebab40589748ac69e2f37c27fc") | project Timestamp, DeviceName, FileName, FolderPath, FileOriginUrl, InitiatingProcessFileName, InitiatingProcessCommandLine, SHA256 | order by Timestamp desc

2) Correlate PowerShell stager with C2 infrastructure

DeviceProcessEvents | where FileName =~ "powershell.exe" | where ProcessCommandLine has_all ("irm", "iex") | join kind=inner ( DeviceNetworkEvents | where RemoteUrl has_any ( "cachingdrive.com", "emeditorde.com", "emeditorgb.com", "emeditorjp.com", "emeditorsb.com" ) ) on DeviceId | project Timestamp, DeviceName, ProcessCommandLine, InitiatingProcessFileName, RemoteUrl, RemoteIP, Protocol | order by Timestamp desc

Indicator Of Compromise:

Indicator	Type	Description
4bea333d3d2f2a32018cd6afe742c3b25bfcc6bfe8963179dad3940305b13c98	File hash (SHA-256)	Trojanized EmEditor MSI installer delivered via compromised WordPress infrastructure
3d1763b037e66bbde222125a21b23fc24abd76ebab40589748ac69e2f37c27fc	File hash (SHA-256)	Secondary malicious MSI variant associated with the same campaign
hxxps://cachingdrive[.]com	Domain	Second-stage payload delivery infrastructure
hxxps://emeditorde[.]com	Domain	Stager and command-and-control infrastructure (mirror)
hxxps://emeditorgb[.]com	Domain	Stager and command-and-control infrastructure (regional variant)
hxxps://emeditorjp[.]com	Domain	Primary stager and command-and-control endpoint
hxxps://emeditorsb[.]com	Domain	Stager and command-and-control infrastructure (regional variant)
147.45.50[.]54	IP address	Hosting IP associated with cachingdrive[.]com
46.28.70[.]245	IP address	Hosting IP associated with emeditorde[.]com
5.101.82[.]159	IP address	Hosting IP associated with emeditorgb[.]com
5.101.82[.]118	IP address	Hosting IP associated with emeditorjp[.]com

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI maps) 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.

References

[Important] Follow-up: Security Incident Notice Regarding the EmEditor Installer Download Link – EmEditor (Text Editor)

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.

Cloud forensics: Forensic readiness and incident response in Azure Virtual Desktop

Dan_Weinstock — Tue, 03 Feb 2026 17:00:00 GMT

Co-authors: Dan Weinstock and Christoph Dreymann

Azure Virtual Desktop (AVD) has rapidly become a core tool for enabling remote work at scale. Consequently, it’s also emerging as a target for threat actors. Recent Microsoft Incident Response engagements show that threat actors are exploiting AVD deployments for lateral movement and persistence. By hijacking legitimate AVD user accounts, they gain what is essentially a trusted “endpoint” inside the network without having to install malware.

Why does this matter to incident responders?

AVD intrusions can be stealthy and fast-moving, and responders must be prepared to detect and investigate suspicious AVD usage quickly. AVD’s architecture is not the same as a typical endpoint or server, so traditional forensic approaches alone may fall short.

This blog post focuses on how to build forensic readiness in AVD and outlines investigation strategies to handle AVD-related incidents. We’ll cover the unique forensic challenges AVD presents, methods to collect critical data and best practices to allow incident responders to approach AVD investigation with confidence.

Real-World Threat Actor Behaviors in AVD

To put theory into context, consider some real threat actor behaviors Microsoft Incident Response – the Detection and Response Team (DART) has observed in AVD environments:

Threat actors used stolen helpdesk credentials with AVD access to log in from a foreign IP address.
In another case, threat actors compromised identities, leveraged their AVD sessions to pivot into on-premises resources using the AVD Virtual Machine (VM) as a steppingstone to RDP into other machines for lateral movement.
Another threat actor accessed the browser in AVD to search internal SharePoint sites for sensitive data and intellectual property.

Once threat actors hijack a legitimate, often poorly monitored AVD session, they gain a privileged execution environment without needing to deploy traditional malware.

This enables threat actors to perform identity discovery, pivot across cloud/on-premises boundaries, exfiltrate data, and stage ransomware operations, emphasizing the necessity for robust logging, monitoring, and least-privilege configurations in virtual desktop environments.

Forensic Challenges Unique to AVD

Incident responders should enable forensic readiness by combining cloud-native and traditional methods to investigate, enable core logs for visibility, and understand how profiles are distributed across VMs and remote storage.

AVD from the lens of a Threat Hunter

An understanding of AVD architecture is essential for detection and response. AVD’s distinctive management of user sessions, profiles, and application delivery presents specific benefits and complexities when monitoring adversary activity. The system has the following fundamental components:

Session Hosts – AVD’s multi-session architecture allows multiple users (or threat actors) to share a single underlying VM. Because these hosts are often ephemeral – frequently spun up and deallocated – offline evidence such as event logs or memory artifact can be lost quickly without proactive collection. When FSLogix is in use, user profiles are stored as VHDs in remote storage, rather than on the session host; browsing history, downloads, registry hives (i.e., NTUSER.DAT), MRU lists, and startup files live in these offloaded containers.
Workspaces, Application Groups, & Host pools
- Workspaces serve as the top-level container, grouping resources and providing users with a single-entry point to their virtual desktops and applications.
- Application Groups determine which apps or desktops are published and define who can access them, shaping both user experience and permissions.
- Host Pools, on the other hand, are collections of session hosts – virtual machines that supply the compute power needed for user sessions.
Azure Storage Accounts & FSLogix VHDs – because FSLogix stores each user’s profile as a VHD or VHDX file on Azure Files or a similar storage solution, investigators must know how to identify and export these VHDs and analyze them using tools like Autopsy or Eric Zimmerman’s utilities to recover user-centric artifact (i.e., browser history, downloads, NTUSER.DAT registry hives). This process is crucial when FSLogix is enabled, as no user data remains on the AVD host after logout.

Figure 1: AVD Components

The following illustration demonstrates the relationship between the key components discussed above:

Figure 2: Relationships between key components

Further information on that can be found within Azure Virtual Desktop for the enterprise - Azure Architecture Center.

This clarifies that AVD is not simply "another VM"; rather, it is an Infrastructure-as-a-Service (IaaS) offering with a corresponding shared responsibility model, in which customers are accountable for identity management and the deployment of individual Azure resources.

Logging Considerations

Many actions such as user session brokering and application publishing are logged not on the VM but in Azure – if logging is enabled. By default, Azure Monitor diagnostics logs for AVD are not turned on. If an organization hasn’t enabled these, responders may lack crucial logs like when sessions started/ended, which applications were opened, or from what client IP address. Entra ID handles AVD authentication and therefore, Entra ID sign-in logs will provide further details and should be retained appropriately as well.

Forensics implication: Misconfigured or missing diagnostic settings can hide evidence.

Log sources

The following table outlines various sources that provide comprehensive insights in the event of an incident:

Artifact / Log Source	Location & Access Method
Host Forensics artifact	On the AVD session host VM.
AVD Diagnostic Logs *(WVD tables in Log Analytics)**	Azure Log Analytics workspace (if AVD Diagnostic Settings were enabled for Host Pools, Workspaces, and App Groups). Access via Kusto queries in the Logs blade or via Microsoft Sentinel. Key tables: WVDFeeds - Shows what published applications were visible. Also shows ClientIP and ClientType. WVDConnections - Shows Client IP address, clientType, ConnectionType, ResourceAlias and which host they connected to. WVDCheckpoints - Find which published App was used and Path for execution of Published App
Entra ID Sign-In Logs	Entra ID (Azure AD) tenant logs. Access via Azure Portal > Entra ID > Sign-in logs, or query the SigninLogs table in Sentinel/Log Analytics.
Endpoint Detection and Response (EDR) Telemetry, for example Microsoft Defender for Endpoint (MDE)	Specifically for MDE, Looking at Microsoft 365 Defender portal (Devices section) or via Advanced Hunting queries (DeviceProcessEvents, DeviceNetworkEvents). This requires the AVD session host VMs to be onboarded as monitored devices in MDE.*
Network Flow Logs (NSG and Firewall logs)	Azure Network Watcher’s NSG flow logs (if enabled on the VM’s subnet/NIC) stored in a storage account or Log Analytics; and/or Azure Firewall logs if an Azure Firewall is in the path. These may also be surfaced via Microsoft Sentinel.
FSLogix User Profile Container (VHD/VHDX)	Stored on Azure Storage (Azure Files share or NetApp Files). Access by locating the user’s profile .vhd(x) in the storage account and downloading it (i.e., via Azure Storage Explorer or generating an SAS URL).

* Onboard non-persistent virtual desktop infrastructure (VDI) devices - Microsoft Defender for Endpoint | Microsoft Learn

Enabling diagnostic logs

Enabling diagnostic logs in AVD Azure resources offers valuable insights into session activities and remote application usage for detecting anomalies, tracing threat actor activity, and supporting forensic investigations. For threat hunting, the most relevant log tables include:

WVDFeeds – shows which published applications were available, including ClientIP and ClientType details.
WVDConnections – lists information such as Client IP address, clientType, ConnectionType, ResourceAlias, and host connection data.
WVDCheckpoints – indicates which published application was accessed and supplies its execution path.

You can enable these logs via the diagnostics settings for Host Pool, Application Group, and Workspace Azure resources. If an incident occurs, these logs help determine exactly what a threat actor interacted with, which is vital for assessing whether additional logs should be collected.

Figure 3: Diagnostic log examples

Forensic Data Collection Strategies

When an incident is suspected in an AVD environment, investigators need a plan for acquiring and preserving evidence:

Live vs. Offline Collection – disk and memory artifact can be captured either from a running system or from an offline snapshot. Live collection can recover volatile data like memory (RAM) but might miss user profile content when FSLogix is in use. In such cases, focus on offline acquisition by generating a snapshot of the relevant disk or file share and downloading the associated VHD. For live or offline captures, you can leverage widely used forensic tools such as Velociraptor (for remote collection across endpoints) or disk forensics tools like Autopsy to extract and analyze forensic data.
Disk Snapshots – to acquire disks for offline collection and analysis, create a snapshot of the AVD Host VM disk and export it to your designated collection and analysis environment. The high-level steps are captured here.
Storage account VHD Extraction – if FSLogix is enabled, user profiles are stored as VHD containers in Azure Storage. To review user data such as browser history, downloads, NTUSER.DAT, MRU lists, startup folders, and other profile artifacts you have to download the VHD that matches the username within the Azure Storage account. More about Storage account forensics can be found within Cloud forensics: Why enabling Microsoft Azure Storage Account logs matters.

Figure 4: File share

Artifact Analysis: What to Look for on a Host

Once the user’s profile VHD and VM Host disk snapshot are acquired, analysts should focus on:

Browser Data – cached web history, downloads, and session cookies can reveal malicious downloads or credential collection attempts. Threat actors frequently exploit post-breach browser access to scrape credentials, hijack sessions, or implant malicious extensions.
User Registry Hives – files like NTUSER.DAT contain valuable user-specific configuration settings and MRU (Most Recently Used) lists that can reveal executed commands or opened documents.
Startup Items and Temporary Directories – malicious payloads or scripts often persist by storing components in startup folders or system temp directories. These may be visible only within the user VHD if FSLogix is in use.
Jump Lists and Shell Bags – these systems cache file access and folder navigation actions, offering timelines and insights into threat actoractivities.

Threat Hunting in AVD Environments

Threat hunting in AVD environments requires three critical dimensions: Identity, Azure platform, and host/endpoint artifact. Each layer provides unique signals and telemetry that, when correlated, help uncover malicious activity and reduce dwell time.

Identity – investigate authentication patterns, privilege escalations, and anomalous sign-ins across Entra ID and related identity providers.
Azure – examine control-plane operations, resource configurations, and subscription-level activities for indicators of compromise or persistence mechanisms.
Host/Endpoint Artifacts – analyze session hosts for forensic traces such as browser history, file events, and registry changes that may reveal lateral movement or payload deployment.

By combining insights from these components, defenders can build a threat-hunting strategy tailored for AVD’s distributed architecture.

Figure 5: Threat hunting in AVD

Core Hunting Objectives

When hunting in AVD environments, start with three fundamental questions:

Where did the threat actor log in from? – identify unusual or foreign IP addresses and devices accessing your host pools.
What did they do once inside? – track actions within the session host, such as which applications were launched, commands executed, or files accessed.
Where did they go next? – look for lateral movement to other resources (cloud or on-premises) and evidence of persistence (i.e., credential artifacts, backdoor accounts).

These questions form the basis for iterative, hypothesis-driven hunts, allowing you to “follow the thread” and adapt as you uncover new evidence – be it new accounts, unexpected machines, or suspicious process trees.

The following diagram illustrates a standard hunting process from the initial event through hunting within the entire environment and cross-domain correlation:

Figure 6: Investigation Analysis Pathway

Today’s security tools can make this process easier. Microsoft Sentinel combines Entra ID logs, AVD diagnostics, and MDE events into one place, so you can use KQL queries and workbooks to link related data, like joining Sign-in Logs and WVDConnections using the same user and timestamp.

With MDE’s Advanced Hunting feature, you can query across endpoints; for example, you might review all AVD host devices for certain indicators or activity patterns, such as listing processes that ran during a suspected breach. The aim is to build a complete picture of the incident.

Sample Hunting Queries

Below are example Sentinel queries tailored to address the core hunting objectives. These should be adapted to your environment and replace dummy values with real user names, host identifiers, or IP ranges.

Where did the threat actor log in from?

Hunt for the suspicious user in the Entra Sign-in logs:

SigninLogs | where TimeGenerated >= ago(7d) //update to reflect specific time period of interest | where UserPrincipalName has "<<Suspicious User>>" | where AppDisplayName has "Azure Virtual Desktop | project-reorder TimeGenerated, UserPrincipalName, AppDisplayName, ResultType, ClientAppUsed, DeviceDetail, IPAddress, UserAgent | summarize FirstDate=min(TimeGenerated), LastDate=max(TimeGenerated), count() by UserPrincipalName, AppDisplayName, ClientAppUsed, IPAddress, UserAgent

Sign-in events to AVD always use the below Entra Applications. Both the application name and ID can be hunted on:

Figure 7: AVD Entra Application IDs

What did they do once inside?

To investigate a potential security incident within AVD, it is important to review the user activity within the diagnostic logs. Therefore, we are looking next into the diagnostic logs tables WVDFeeds, WVDConnections, and WVDCheckpoints to get a better understanding of what has happened:

WVDFeeds

Displays the published applications that are accessible, as well as the ClientIP and ClientType information.

WVDFeeds | where TimeGenerated >= ago(7d) //update to reflect specific time period of interest | where UserName has <<UserName>> //splitting the IP as the ClientIP is shown with port i.e. 1.1.1.1:54282 | extend ClientIP = tostring(split(ClientSideIPAddress, ":")[0]) | summarize FirstDate = min(TimeGenerated), LastDate = max(TimeGenerated), count() by UserName, ClientOS, ClientType, ClientIP

WVDConnections

Displays the Client IP address, client type, connection type (Desktop or App), resource alias, and the host (from the host pool) to which the client has connected.

WVDConnections | where TimeGenerated >= ago(7d) //update to reflect specific time period of interest | where UserName has <<UserName>> | project-reorder TimeGenerated, UserName,ClientSideIPAddress, ClientOS, ConnectionType, SessionHostName, SessionHostPoolType, State | sort by TimeGenerated asc

WVDCheckpoints

Determine which published application was utilized. It shows also the Operation conducted when a session was started.

WVDCheckpoints | where TimeGenerated >= ago(7d) //update to reflect specific time period of interest | extend ConnectionStage = tostring(Parameters.connectionStage) | extend AppFileName = tostring(Parameters.filename) //It is only populated when it published App and not Desktop Session | extend Operation= Name | project-reorder TimeGenerated, UserName, ActivityType, Source, Operation, AppFileName, ConnectionStage

Advanced Hunting in Microsoft Defender for Endpoint

Now that the AVD host has been identified, you can then deep dive further by focusing on EDR and host forensic logs. If MDE Advanced Hunting is enabled, the following tables helps often to understand what happened on a system:

DeviceNetworkEvents
DeviceProcessEvents
DeviceRegistryEvents

Further tables within MDE and the Device Timeline help to get a full picture of what happened.

Lateral Movement

After gaining access to an AVD session host, threat actors often attempt lateral movement to expand their foothold or establish persistence. This can involve pivoting to other session hosts, Azure resources, or even on-premises systems.

Focus on the following tables/log sources:

Firewall logs (On premise / Cloud)
DeviceNetworkEvents (Cloud: Defender)
DeviceProcessEvents (Cloud: Defender)
DeviceRegistryEvents (Cloud: Defender)
NSG logs (Diagnostic Logs)
Windows EventsLogs (Collected host logs)

Best Practices for AVD Forensic Readiness

The following measures enhance forensic processes for Azure Virtual Desktop:

Implement an endpoint detection and response product – deploy an endpoint detection and response (EDR) solution to provide advanced detection and response capabilities on AVD VMs.
Enable and export comprehensive logging – activate diagnostic logging for all host pools, workspaces, and application groups. Ensure these logs are exported to a Log Analytics workspace or a security information and event management (SIEM) platform such as Microsoft Sentinel.
Develop forensic workflows for AVD – establish and document clear forensic workflows for AVD incident response. This should cover the entire process, from detecting suspicious activity, through live or offline evidence acquisition, to verifying FSLogix profile stores, exporting VHDs, and analyzing collected artifacts.

Security Recommendations for Azure Virtual Desktop

When implementing AVD, it is vital to follow recommended security practices. These strategies complement the best practices for forensic readiness and ensure that both proactive and reactive security measures are in place.

Review Microsoft AVD Security Guidance – utilize the official Microsoft documentation for Azure Virtual Desktop security to guide your deployment and operational security policies. The resource provides up-to-date recommendations on securing your AVD environment.

Enable MFA on all users – implement multi-factor authentication (MFA) for every user accessing Azure Virtual Desktop to ensure an additional layer of security beyond just passwords.
- Where possible, implement phish-resistant MFA for maximum protection. If full adoption isn’t practical, prioritize high-risk accounts and critical roles first.

Enable Conditional Access – utilize Conditional Access policies to proactively manage and mitigate risks before granting access to your AVD environment. This helps ensure only legitimate users and trusted devices can connect to your resources.
- Regularly review Conditional Access policies for exceptions and minimize them wherever possible. Implement detection and alerting for any changes to CAP configurations to maintain a strong security posture.

More information can be found in the following article from Microsoft - Security recommendations for Azure Virtual Desktop - Azure Virtual Desktop | Microsoft Learn

Conclusion

As the threat landscape evolves, cloud-hosted virtual desktops become both enablers of productivity and channels for threat actor persistence. By applying robust logging configurations, understanding the unique forensic challenges of FSLogix and AVD, and enhancing your threat hunting capabilities, you can achieve higher levels of forensic readiness. This preparedness not only accelerates investigations when incidents occur but also strengthens the overall security posture of your organization. Proactive planning today is essential to respond to tomorrow’s threats with confidence and clarity.

Microsoft Defender Experts Disrupt Jasper Sleet’s Insider Access Campaign

Mukta_Agarwal — Wed, 28 Jan 2026 23:21:36 GMT

By: Mukta Agarwal and Parth Jamodkar

Threat actors are increasingly infiltrating organizations by securing legitimate jobs, often through falsified credentials or insider recruitment.

Recently, Microsoft Defender Experts, powered by Microsoft Threat Intelligence, successfully thwarted a sophisticated campaign by Jasper Sleet (formerly Storm-0287), a North Korean state-sponsored threat actor known for stealthy infiltration tactics. Rather than compromising victims directly, these actors pose as job applicants or contractors, infiltrating organizations to gain long-term insider access under false identities. Organizations in the information technology segment throughout the United States have been the primary targets for Jasper Sleet. However, as this threat actor has grown more sophisticated and expanded their reach, other industries including consumer retail, healthcare, financial services, critical manufacturing, and energy across different regions have also become targets.

The challenge

Jasper Sleet leveraged social engineering and identity fraud to bypass traditional security controls. By impersonating remote IT contractors, the actors blend into legitimate workflows, using shared devices for MFA and VPN services to mask their origin. These tactics enabled persistence through long-lived sessions and authentication tokens, creating a high risk of privilege abuse and data exfiltration if left undetected.

Indicators observed during investigation

Shared devices for MFA: During authentication analysis, it was observed that a single device was repeatedly used to complete multifactor authentication (MFA) for multiple user accounts within the same tenant. MFA is intended to enforce strong identity assurance by binding authentication to a unique user-device pairing. When this control is circumvented, it raises a security concern. Further investigation revealed consistent technical signals across these events, including identical session identifiers, common ISP, and geolocation. Such behavior is strongly indicative of fraudulent personas operating from shared workstations, pooled environments such as Azure Virtual Desktop (AVD), or compromised devices.
Suspicious login patterns: Initial access attempts originated from US or Western IP addresses to simulate remote work, followed by logins from Russian, Chinese, or other Asian IPs and often linked to VPN services such as Astrill. Certain sessions exhibited AVD-like login patterns originating from Russian-based instances.
Session persistence: Long-lived authentication sessions, (such as non-password based) cookies and tokens allow malicious insiders to maintain access even after password resets, as these tokens often remain valid without re-authentication.

Together, these behaviors pointed to a stealthy, long-term operation designed to blend in with legitimate activity and maintain persistent access through pre-existing privileges associated with IT roles.

Behavioral indicators mappings

Defender Experts response

Defender Experts took a proactive approach by meticulously analyzing the suspicious behavioral patterns and successfully uncovering multiple customers who had been impacted by the Jasper Sleet campaign. Upon identification, we immediately reached out to the affected organizations through managed response and Defender Expert Notifications, ensuring they were promptly informed about the threat and the necessary actions to be taken. Recognizing the potential for broader impact, we also issued proactive threat advisories to all Defender Experts customers. We actively engaged with the customers, initiating collaborative sessions to validate the attack vectors, discuss findings, and the recommended steps. This open channel of communication fostered a collective defense posture, where shared intelligence and real-time feedback between Defender Experts and customer teams amplified the speed and effectiveness of the response.

Actions included:

Immediate alerts to affected organizations via Defender Experts Notifications titled “Microsoft Defender Experts: Potential malicious activity linked to threat actor observed in your environment”, which included observed indicators and recommendations.
Proactive threat advisories to all Defender Experts customers (subject- Microsoft Defender Experts Threat Advisory: Jasper Sleet), informing them of key adversarial tactics, impact, and encouraging them to remain vigilant and review their own environments for similar indicators of compromise.
Direct collaboration with customers to facilitate joint sessions aimed at validating attack vectors and discussing findings.

Outcome and impact

The coordinated and transparent partnership between Defender Experts and our customers played a critical role in containing the threat before it could escalate. Customers responded promptly by disabling compromised contract employee accounts, effectively mitigating the risk of further misuse. Through these actions, customers addressed immediate risks and strengthened their long-term security posture by implementing best practices and incorporating lessons learned from the incident.

This case highlights the significant value of robust collaboration between Defender Experts and customers in countering sophisticated, targeted cyber-attacks, demonstrating that collective efforts enhance the ability to defend against evolving threats. Together, we are stronger and more capable of defending against evolving threats.

Customers reported that timely alerts and expert guidance prevented downstream compromise and strengthened their security posture. Some of the testimonials from the customers:

“A big thank you to the Microsoft team for all their efforts and coordination in detecting this, which has been immensely helpful.”

“Appreciate Defender Experts for finding this. You guys just signed next year’s renewal with this"

Key takeaways (public safe metrics)

Impact Area	Metric
Alerts and logs analyzed	>10,000 correlated logs and events
Organizations protected	40 + enterprise tenants
Defender proactive notifications	Over 200+ sent
Time to notify	< 30 mins, immediately after first detection

Reference

Jasper Sleet: North Korean remote IT workers’ evolving tactics to infiltrate organizations | Microsoft Security Blog

Stay vigilant - Stay protected
Learn more about how Microsoft Defender Experts can help safeguard your organisation against sophisticated threats. Partner with Microsoft Defender Experts to stay ahead of advanced threats and protect your organization with confidence.

Microsoft Defender Experts for XDR - Expert-led monitoring and response across your extended detection and response
Microsoft Defender Experts for Hunting - Proactive threat hunting to identify and stop attacks before they impact your business.

By: Mukta Agarwal and Parth Jamodkar

Microsoft Defender Experts - S.T.A.R. Series

Raae_ — Wed, 25 Mar 2026 20:21:06 GMT

Co-author: Samantha Gardener

To stay ahead of today’s sophisticated cyber threats, organizations must embrace a proactive defense strategy that includes these three pillars: emerging trends, adaptive strategies, and actionable insights.

Threat actors are increasingly leveraging AI-driven attacks, supply chain compromises, and identity-based exploits. Modern strategies focus on zero trust principles, continuous threat hunting, and leveraging advanced threat intelligence to predict and neutralize risks before they escalate. By integrating real-time analytics, automated response capabilities, and cross-platform visibility, security teams can transform insights into decisive action to help ensure resilience against evolving attack vectors and safeguard critical assets in an ever-changing landscape

Our popular S.T.A.R. webinar series features panels of our experts who discuss trends, strategies, and insights that will help you defend against today’s sophisticated threats.

Gain Expert Insights: Learn from Microsoft Defender Experts who share their knowledge on the latest threats and trends in cybersecurity.
Bolster their Security Program: Receive actionable guidance and strategies to effectively combat emerging threats and strengthen defenses.
Meet the Experts: Get to know the Defender Experts and understand their roles in safeguarding organizations.

For additional insights, some episodes are accompanied by informative blogs that include even include real-world threat hunting patterns

Microsoft Defender Experts - S.T.A.R. series episodes

Episode 1 - November 2024

Crafting Chaos: The Amplified Tactics of Social Engineering - Hunt, Halt, and Evict

Ep. 1- Crafting Chaos: The Amplified Tactics of Social Engineering

Description

Explore amplified tactics of social engineering with our Defender Experts. We cover Quick Assist email spam floods, RMM tool abuse, and the ClickFix Powershell copy/paste technique. We highlight how attackers leverage legitimate services like SharePoint, Dropbox, and Google Drive for phishing campaigns.

Key Topics:

Quick Assist Email Spam Flood: Abusing QuickAssist to gain initial access and deploy ransomware.
RMM Tools: Increased abuse of RMM tools for delivering trojans or infostealers.
ClickFix Powershell Copy/Paste: Users tricked into copying and pasting malicious code.
Abuse of File Hosting Platforms: Using legitimate services for phishing campaigns.
Advanced Hunting Queries: KQL queries for detecting suspicious activities.

Video Link

Episode 1 - Crafting Chaos: The Amplified Tactics of Social Engineering - Hunt, Halt, and Evict

Episode 2 - February 2025

Rise of Infostealers, ClickFix, and More

Ep. 2 – Rise of InfoStealers

Description

Delve into the latest threat landscape, featuring notorious actors like Hazel Sandstorm, Sangria Tempest, and Midnight Blizzard. Understand the insidious ClickFix technique, a social engineering marvel that exploits users' natural tendencies to click prompts and buttons. Learn more about the growing trend of renamed binaries and how adversaries are using them to evade detection.

Key Topics:

Infostealers Unveiled: Functions and examples of infostealers like LummaStealer, DarkGate, and DanaBot.
ClickFix Technique: Combining phishing, malvertising, and malicious scripting.
Identity Compromise: Techniques like AiTM, BiTM, and BiTB attacks.
Advanced Hunting Queries: KQL queries for detecting suspicious activities

Video Link

Episode 2 - Rise of Infostealers, ClickFix, and More

Episode 3 - June 2025

The Case Against ClickFix

Ep. 3 – Case Against ClickFix

Description

Deep dive into the ClickFix technique, a rising social engineering threat that manipulates users into executing malicious scripts through fake prompts like CAPTCHA verifications.

Key Topics

How adversaries are leveraging ClickFix to deploy infostealers, remote access tools, and loaders, while also evading detection through renamed binaries and obfuscated scripting.

Technique:

ClickFix combines phishing, malvertising, and drive-by compromises with fake CAPTCHA overlays. Users are tricked into copying and executing malicious commands via the Windows Run dialog.

Compromise:

ClickFix mimics identity compromise tactics by hijacking user trust, using spoofed interfaces, clipboard hijacking, and executing obfuscated scripts via LOLBins like PowerShell, mshta, and rundll32.

Advanced Hunting Queries (AHQs):

Suspicious RunMRU registry entries.
Use of LOLBins and obfuscated PowerShell commands.
Indicators such as shortened URLs, fake CAPTCHA text, and encoded payloads.

Video Link

Episode 3 - The Case Against ClickFix

Episode 4 - Aug 2025

Post-Breach Browsers: The Hidden Threat You’re Overlooking

Ep. 4- Post-Breach Attacks on Modern Browsers

Description

Modern browsers aren’t just attack entry points; they’re post-breach goldmines. In this episode, Microsoft Defender Experts are joined by JBO, the architect behind cross-platform research at Microsoft Defender and a leading voice in offensive security, exploitation, and vulnerability research.

Key Topics:

Post-Breach Tradecraft
How adversaries weaponize browser memory, debugging ports, and extensions to maintain access and evade detection.
Detection That Cuts Through the Noise
Spot stealthy abuse: anomalous COM calls, rogue child processes, TLS key leaks, and more.
Expert-Led Defense
JBO and the Defender Experts team bring real-world insights from the frontlines, including techniques used to uncover and mitigate browser-based threats across Windows, macOS, and Linux.

If you think browser security ends at patching, think again. This episode is your essential guide to defending against the post-breach browser threatscape.

Video Link

Episode 4 - Post-Breach Browsers: The Hidden Threat You’re Overlooking

Learn more – read the blog

Post-breach browser abuse: a new frontier for threat actors | Microsoft Community Hub

Modern browsers are among the most complex and trusted applications on any endpoint. While they are often discussed in the context of initial access (through phishing, drive-by downloads, or zero-day exploits) this post focuses on a less explored but increasingly relevant threat vector: post-breach browser abuse.

Episode 5 – October 2025

TCC You Later: Spotlights Metadata Mischief in macOS

Ep. 5 - TCC You Later

Description

Threat actors are exploiting overlooked macOS features. Join our experts as they discuss trends, strategies, and insights that will help you defend against this new attack vector.

Key Topics:

Understand how AI features and Spotlight indexing expose sensitive metadata, while weaknesses in TCC controls increase exploitation potential.
Learn how unsigned Spotlight plugins can bypass privacy safeguards, granting access to confidential files and Apple Intelligence data.
Defend better by strengthening detection for anomalous Spotlight activity, enforce patching, and manage updates through Intune for proactive defense.

Video Link

Episode 5 - TCC You Later: Spotlights Metadata Mischief in macOS

Episode 6 – February 2026

Shai Hulud 2.0 - Breaking the Supply Chain Chaos Engine

Ep. 6 – Halting Shai Hulud 2.0 with MISA partner Ontinue

Description

Together with our MISA partner, Ontinue, we will unlock supply-chain attacks and drill into campaigns like “Shai Hulud.” Learn how attackers abuse trust and developer workflows, why detection is challenging, and gain practical insight on using Microsoft Defender to strengthen CI/CD and supply-chain security.

Key Topics

Evolution of Software Supply‑Chain Attacks: NotPetya, CCleaner, ASUS ShadowHammer, SolarWinds, 3CX, to XZ Utils.

NPM Ecosystem Risks & Abuse: Why attackers target Node Package Manager (NPM).

Breaking down ‘Shai Hulud’: Attack flow & detection, scripts, lifecycle hooks, automated propagation

Why is detection hard: trust abuse vs. exploit abuse.

Defend Better: Hunting queries, GitHub security, Defender tools

Locking down your supply chain: CI/CD hardening, credential rotation, SBOM-based scanning, agentless code scanning, optimize Defender.

Video Link

Episode 6 - Shai Hulud 2.0: Breaking the Supply Chain Chaos Engine

Episode 7 – March 2026

Runtime Reality Check – from poisoned packages to AI workloads as adversaries

Episode 7 – Runtime Reality Check – from poisoned packages to AI workloads as adversaries. - YouTube

Description

Cloud attackers are gaining the insider advantage. In this latest S.T.A.R. video episode, our team reveals how the latest attacks are bypassing perimeters to strike directly in cloud runtimes.

Key Topics

Learn how adversaries inject malicious code into dependencies and exploit package managers.
See how attackers use AI-powered attacks & compromised AI workloads to create faster-evolving threats.
Discover how Defender detects intrusions inside Kubernetes and correlates kill chain signals.
Understand hands-on skills and KQL queries you can use today to detect these threats.
Watch the kill-chain unfold and see how to close detection gaps.

Video Link
Episode 7 – Runtime Reality Check – from poisoned packages to AI workloads as adversaries. - YouTube

Learn more – read the blog

The invisible attack surface: hunting AI threats in Defender XDR | Microsoft Community Hub

As organizations embed AI across their business, the same technology that drives productivity also introduces a new class of risk: prompts that can be manipulated, data that can be leaked, and AI systems that can be tricked into doing things they shouldn’t. Attackers are already testing these boundaries, and defenders need visibility into how AI is being used - not just where it’s deployed.

Follow us for more S.T.A.R. episodes - Microsoft Defender Experts for XDR | Microsoft Security

Meet DART, the people behind Microsoft Incident Response

Zophar — Tue, 25 Nov 2025 17:00:00 GMT

When threat actors infiltrate a company to steal documents and other critical business information, Microsoft Incident Response - the Detection and Response Team (DART) responds. With more than 4,500 engagements in 2024 and more than a millennium of combined experience, these responders are the calm in the storm when a compromise occurs.

Whether they’re confronting ransomware, nation-state actors, or zero-day exploits, DART blends their knowledge and years of experience with agility, empathy, and storytelling to guide organizations from disruption to clarity.

This blog introduces the people behind DART, which includes forensic analysts, infrastructure specialists, and threat hunters whose mission is to contain attacks, restore trust, and build resilience for the future.

DART

DART isn’t just a lifeline during a crisis, they’re strategic partners in building cyber resilience before threat actors strike. Through a suite of proactive services, the team helps organizations identify vulnerabilities, harden critical systems, and prepare for the unexpected.

Proactive offerings like compromise assessments, identity reviews, and threat briefings allow customers to uncover hidden risks and receive tailored recommendations without the pressure of an active breach. By leveraging Microsoft’s vast threat intelligence and engineering access, organizations gain insights into emerging tactics and trends, ensuring their security posture evolves ahead of the threat landscape. In short, DART empowers defenders to out-think threat actors by mapping potential pathways, closing gaps, and rehearsing responses - so when the real thing happens, they’re ready.

Cyber Frontier: Real-World Insights from Microsoft & DART

The cyber threat landscape is constantly evolving, forcing defenders to rethink traditional security models. The past year, DART has observed shifts in tactics driven by the rise of AI and the relentless pursuit of identity compromise. Threat actors are no longer just exploiting vulnerabilities; they’re weaponizing automation, scaling social engineering, and monetizing stolen access in ways that blur the line between cybercrime and organized business models. In this new paradigm, resilience, global collaboration, and anticipatory defense aren’t optional; they’re survival.

Microsoft Digital Defense Report 2025[1] ranks the largest causes of cyberattacks and prominent trends:

Phishing remained the most common initial access method. While there were many changes in the threat landscape, multifactor authentication (MFA) still blocks over 99% of unauthorized access attempts, making it the single most important security measure an organization can implement.
While phishing remains a common initial access method, campaigns are moving away from simple phishing as defense approaches evolve. Threat actors increasingly leverage multi-stage attack chains that mix technical exploits and social engineering to gain unauthorized access and maintain persistence.
In more than 90% of cases where cyberattacks progressed to the ransom stage, the threat actor had leveraged unmanaged devices in the network.This highlights the impact of gaps in endpoint visibility on threat actor progression.
Just as businesses are leveraging generative AI for productivity gains, threat actors are also using AI to augment traditional cyberattacks by automating activities from vulnerability discovery to deepfake content generation.
As AI adoption becomes increasingly commonplace, these tools’ access to proprietary and sensitive data has also made AI systems an attractive target for malicious activity.
Nation-state actor and ransomware-as-a-service (RaaS) actor activity also evolved, moving away from centralized command-and-control servers and instead leveraging cover, peer-to-peer networks to avoid detection and survive through takedowns by redistributing workloads across participants.

Meet some of the DARTians

DART members are a diverse and highly skilled team of individuals with the depth of expertise and experience to solve problems quickly. They continually adjust their actions based on what they learn. They can lock down a network, isolate an endpoint, or remove a threat actor before damage is done. CISOs, security teams, and our IR people share this common passion, commitment, and goal - to protect organizations against threats. We recently interviewed several of our team members about how they got into IR work, their most memorable engagements, advice they have for customers, and more. Here are some key highlights from those interviews:

How did you get your start?

“My journey began in 2005 when I enlisted in the US Marines and was assigned to the data field, managing servers, routers, and switches, and ensuring the network kept running smoothly. That technical foundation soon led me to a cybersecurity role for the Marine Corps at Quantico, where I first tasted what it meant to defend against real threats. As a Security Operations Center (SOC) analyst, I quickly discovered that cybersecurity is both broad and deep. It opened my eyes to how vulnerabilities are exploited and how a simple oversight can become a major incident.” – Edwin

“My path into cybersecurity wasn’t exactly a straight line. During the early parts of my career, I worked in business advisory and enterprise sales and was pursuing a path to an MBA from one of the major business schools. While corporate strategy and incident response may feel worlds apart, being able to bridge both has been my tactical advantage in working with our customers to demystify the events that take place in the cyber trenches I now call home.” – Pru

“The idea of tracking digital adversaries and solving complex puzzles always fascinated me, so when an opportunity arose in 2014 to join a Cyber Warfare unit, I took it. It felt like stepping into a story told in the movies, only the stakes were real, and the learning was relentless.” – Max

Most memorable DART engagement moments

“We quickly gained trusted advisor status and were brought into the investigation. Together, we uncovered internet-facing servers with weak permissions that allowed the threat actor to pivot between on-premises and cloud environments using privileged accounts. In the end, we shut down the threat actor’s access, rebuilt compromised systems, reduced excessive permissions, and delivered a roadmap to strengthen defenses.” – Adrian

Advice for customers

"Nearly every major incident we see starts with compromised identity: weak credentials, stolen passwords, or missed phishing alerts. Enabling multi-factor authentication (MFA) is critical.” – Max

“Proactive defense pays off: Tools like Secure Score and strategies such as the tiering model can drastically reduce risk. Don’t wait until an incident to play catch up and try to fortify defenses while also putting out a fire, it is best to act now.” – Edwin

“It may sound simple or even boring, but over 99% of cyberattacks can be prevented with MFA in place. It’s the digital equivalent of locking your front door and having an alarm system, and it’s easy and inexpensive to implement.” – Pru

“Teamwork is essential: No one succeeds in cybersecurity alone. Collaboration, both within your team and across organizations, is often the deciding factor in a successful response.” – Adrian

“Tools powered by AI, like Microsoft Copilot, have become invaluable in helping to quickly analyze suspicious processes, understand command lines, and connect the dots in complex investigations.” – Max

Building a safer digital world, together

DART doesn’t just solve technical problems - they help people through some of the most challenging moments of their careers. Every compromise is a puzzle, every engagement a chance to restore trust and build resilience. What drives them isn’t just the scale or complexity of the work - it’s the impact they can make, one incident at a time.

Learn more

To learn more about Microsoft’s Incident Response capabilities and DART, please visit Microsoft Incident Response | Microsoft Security. Read the latest installment of the Cybersecurity Series. To read more about Microsoft Incident Response in action, read our latest installment of the Cyberattack Series, Retail at risk: How one alert uncovered a persistent cyberthreat.

Sources

1 Microsoft Digital Defense Report 2025 | Microsoft

Charting the Future of SOC: Human and AI Collaboration for Better Security

Sylvie_Liu — Tue, 18 Nov 2025 18:48:18 GMT

Co-authors:

Sylvie Liu, Principal Product Manager

Rajiv Bharadwaja, Principal Software Engineering Manager

Abhishek Kumar, Principal Group Manager - Security Research & Operations

Security operations centers are under pressure from unprecedented scale and complexity. Speed, precision, and consistency matter more than ever, and AI is everywhere—but hype alone doesn’t solve the challenge. This blog shares our journey and insights from building autonomous AI agents for MDR operations and explores how the shift to a GenAI-powered SOC redefines collaboration between humans and AI.

Beyond our managed services, Microsoft Defender Experts strive to be a trusted partner in SOC evolution, helping customers across the broader security ecosystem to anticipate process changes, plan for upskilling, and adopt agentic workflows with confidence.

From Vision to Reality: Building the SOC of the Future

Attackers are evolving at unprecedented speed, using AI to outpace defenses scale. Defender Experts is pioneering the transformation to build the SOC of the future by integrating advanced AI capabilities into our SOC workflows, which is critical for today’s threat landscape. We’ve seen AI deliver real results—in our earlier blog, we shared how Defender Experts applies AI to cut through noise without compromising on detecting real threats, enabling 50% of noise to be triaged automatically with high precision.

Autonomous AI agents are foundational to the SOC of the future. Our vision is a predictive, adaptive model where agentic AI and automation remove manual toil, accelerate contextual insight, and execute both single tasks and complex workflows. Analysts are elevated, acting as orchestrators of governed action, driving high-impact decisions, and continuously tuning the system for transparency and trust. Agents handle repetitive, time-intensive tasks, while humans remain the final authority for strategic outcomes. Together, this creates a SOC that moves from reactive alert handling to proactive, explainable defense. It is always auditable and under human governance.

How Microsoft Defender Experts is Pioneering This Shift

Defender Experts builds autonomous AI agents with expert knowledge, expert-defined guardrails and human-in-the-loop validation to deliver structured, trustworthy outputs that accelerate investigations without compromising quality. These AI agents are designed to drive efficiency and consistency across our MDR operations, helping us respond to the threats faster and with confidence.

As we advance this model, we’re not only improving speed and precision, we’re redefining our security operations. That means rethinking SOC analyst roles, skill composition, workflow design, the tooling support, the accompanying automation, and the evaluation and monitoring systems needed to maintain trust.

Abhishek Kumar, lead of the Defender Experts security operations team, is deeply engaged in this transformation as we build the GenAI-powered SOC. From Abhishek’s perspective “This is an exciting era for anyone in security research and operations. We are seeing a monumental shift where security analysts and threat hunters are elevating the role from handling routine tasks, to delivering high value insights. AI agents are rapidly reducing analyst fatigue and freeing up essential time, allowing experts to focus on critical thinking and contextual analysis of incidents."

Agents are not just a productivity leap, they're enabling analysts and hunters to better investigate emerging and hidden threats, develop more hypotheses, and connect clues to unravel complex campaigns. Time once spent on repetitive work is now devoted to advanced tasks like posture data analysis, traversing security graphs, and using cross-product intelligence to uncover novel threats and threat actor infrastructure.

Another way the autonomous AI agents are helping is by reducing cognitive loads on humans and enabling interactions with agents to achieve specific outcomes. For example, if there are hundreds of login attempts from unfamiliar locations, probably only one or two may be worth deeper investigations as they have additional insights attached to them which could be surfaced quickly by the agent. Similarly, an end point process tree that could take significant effort for humans to analyze can be done much faster with the agent to spot suspicious anomalies. To maximize the impact, one important skill needed by SOC analysts is to be able to craft and finetune prompts to get the right insights with GenAI.

Inside the Technology: How We Bring Autonomous Agents to Life

Behind the scenes, delivering trustworthy GenAI-based solutions at scale requires rigorous engineering and continuous collaboration with the security operations teams. We’ve built AI agents on a foundation of expert-defined guardrails, curated test sets, and deployment-time checks to ensure reliability. Engineers, security analysts and researchers collaborated to refine workflows, enhance precision, and broaden coverage as the agents adapt to real-world threats. Each workflow begins under human oversight, reinforced by efficient engineering and analyst feedback loops that accelerate development while upholding security, privacy, and compliance standards.

This transformation also demanded deep integration into Defender Experts core systems, from case management to remediation services, requiring ground-up engineering to accommodate long-running GenAI-based workflows alongside asynchronous backend processes. There is also a need for an orchestration engine that coordinates multi-layer automations, enabling rule-based logic, GenAI-powered features, and traditional AI models to work seamlessly together with the autonomous AI agents to maximize quality, efficiency and cost-effectiveness.

The impact is clear: AI agents are now running on 75% of the phishing and malware incidents landing in the Defender Experts analyst queue. The AI agents autonomously arrive at the verdict determination, justification with data-backed summaries, customer-side queries for verification, and actionable remediation steps. With this combined Human and AI agent approach, we resolve incidents nearly 72% faster while maintaining quality and transparency.

To achieve this, we follow a deliberate development and release journey. We start with internal evaluation on historic cases under strict privacy and compliance controls, establishing baselines for precision, recall, and quality. Next, we deploy the agents in “dark mode,” where agents investigate side-by-side with human analysts, enabling close monitoring and iterative improvements. From there, we move into pilot with customer design partners to validate methods and gather feedback, before expanding for broader adoption —all with human backstop for review and validation. This disciplined autonomous AI agent development approach ensures that every step balances autonomy with oversight, giving customers confidence that advanced AI capabilities are grounded in proven outcomes and designed to strengthen resilience at scale.

Preparing for the Future

Our experience developing autonomous AI agents and deploying them in real MDR operations has reinforced our vision for the SOC of the future, a collaborative model where humans remain in the driver’s seat to teach and lead, working alongside AI agents rather than being replaced by them. Together, they create faster, smarter, and more resilient security operations.

As SOC teams embrace the shift to GenAI‑powered operations, these insights reflect the journey we’ve taken and offer practical guidance to help navigate the transformation with confidence:

Anticipate Process Changes: SOC teams will not follow the same workflows as before. Prepare for evolving processes and establish a lifecycle for AI and agent adoption with confidence.
Foster Mindset Shift: Analysts used to traditional approaches often find it challenging to adopt new methods (e.g., running Kusto queries vs. writing prompts, run full end to end investigation vs. leveraging the agent output). Plan for change management and provide training to ease this transition.
Evolving SOC Skills: Analyst roles are shifting in a GenAI-powered SOC. Analysts need to build expertise in prompt engineering, moving beyond manual case investigations to focus on advanced tasks such as posture data analysis and leveraging cross-product intelligence to uncover novel threats and map threat actor infrastructure. These evolving skills position analysts as strategic decision-makers, building collaboration between humans and AI to maximize effectiveness.
Build Trust and Confidence: As security operations adopt AI agents, maintain a strong human–AI feedback loop. Guardrails and human oversight are essential for trustworthy automation.
Plan for Multi-layer AI and Automation: Automation continues to play a critical role in security operations. Explore how to orchestrate traditional automation and AI together to achieve efficiency, cost-effectiveness, and consistent quality.

As we evolve toward the SOC of the future, we’re learning what it takes to make human and AI collaboration successful, and we’ll continue sharing those insights as we reimagine security operations together.

Sploitlight: Hunting Beyond the Patch

christinefossaceca — Thu, 13 Nov 2025 17:00:00 GMT

Many people aren’t aware that Microsoft security isn't just about Microsoft, it’s also about the platforms supporting the products we build. This means our reach extends across all operating systems: iOS, Android, Linux, and macOS!

In early 2025 Microsoft disclosed CVE-2025-31199, a macOS vulnerability that abused Spotlight, macOS’s metadata importer framework to bypass Transparency, Consent, and Control (TCC). After the Defender team reported this to Apple, a patch was released that closed the hole. But, the underlying behavior behind the threat still matters to Microsoft! Once attackers learn that trusted macOS services can be redirected, they will reuse the method for nefarious purposes, so it is important to track them down. The next variant won’t look the same, and Spotlight is a commonly targeted service. [1] So, in this article, we teach you how to hunt beyond the patch!

Why Hunt for Sploitlight

Spotlight importers (.mdimporter) extend macOS indexing. They normally process metadata for search visibility. Attackers can twist that design to index protected files, extract sensitive data, or trigger code execution, perhaps with elevated system trust and privileges. Even with the patch in place, the same logic paths remain valuable targets for attackers. We recommend hunting for patterns around importers, indexing behavior, and TCC privileged binaries to help detect attempts to rebuild this chain of abuse.

Advanced Hunting Queries (AHQs)

1. Detect Unusual Spotlight Importer Activity

Looking for manual invocations of mdimport may tip you off to attacker activity

DeviceProcessEvents |where ProcessCommandLine contains "mdimport"

DeviceProcessEvents | where ProcessCommandLine contains "mdimport" | where isempty(extract(@"-(\w+)", 1, ProcessCommandLine)) == false | extend mdimportFlag = extract(@"-(\w+)", 1, ProcessCommandLine) | where mdimportFlag in~ ("r", "i", "t", "L")

Why it’s important:
A Spotlight plugin being developed or tested will be called from the command line using the mdimport utility. For a wide-sweeping query, just search for mdimport alone. However, to get more granular, you can search for it with common parameters such as "r", "i", "t", or "L".

2. Investigate Anomalous Spotlight Activity

Use this query to monitor Spotlight activity in the background

DeviceProcessEvents | where FileName in~ ("mdworker", "mdworker_shared")30 Day Timeline

Why it’s important:
The Advanced Hunting Portal creates timelines for you to quickly zoom in on abnormal behavior, and peaks can show when new Spotlight plugins are invoked.

Defender Recommendations

Establish a baseline of normal Spotlight activity before setting detection thresholds.
Tag importer activity by TCC domain to surface unexpected access.
Correlate unsigned importer drops with system events such as privilege escalation or installer execution.
Deploy these AHQs in Microsoft Defender XDR or Sentinel for continuous telemetry review.

The Bigger Picture

The point isn’t to memorize CVEs. It’s to understand the logic that made them possible and look for it everywhere else. Threat actors don’t repeat exploits; they repeat success patterns. Visibility is the only real control. If a process touches data, moves it, or indexes it, it’s part of your attack surface. Treat it that way.

👉 Join the Defender Experts S.T.A.R. Forum to see Sploitlight detection strategies and live hunting demonstrations: Defender Experts Webinar Series

[1] References:

https://theevilbit.github.io/posts/macos_persistence_spotlight_importers/

https://www.blackhat.com/docs/us-15/materials/us-15-Wardle-Writing-Bad-A-Malware-For-OS-X.pdf

https://newosxbook.com/home.html

https://www.microsoft.com/en-us/security/blog/2025/07/28/sploitlight-analyzing-a-spotlight-based-macos-tcc-vulnerability/

The invisible attack surface: hunting AI threats in Defender XDR

Raae_ — Tue, 11 Nov 2025 17:00:00 GMT

Microsoft Defender for Cloud now brings that visibility into the hunt. Its AI threat protection detects prompt injection, sensitive data exposure, and misuse of credentials in real time, correlating those signals with endpoint, identity, and cloud telemetry through Microsoft Defender XDR. The result is a single, searchable surface for investigating how both people and AI-driven systems behave under pressure.

As of 2025, Defender for AI is fully integrated into Microsoft Defender for Cloud, extending protection to AI models, prompts, and datasets across Azure AI workloads. This makes Defender for Cloud the central platform for securing enterprise AI environments. Meanwhile, Microsoft Defender Experts continues expanding across Defender XDR, offering 24/7 human-led monitoring and investigation, with full active coverage for servers within Defender for Cloud today.

For threat hunters, this evolution isn’t theoretical; it’s tactical. The same curiosity and precision that uncover lateral movement or data exfiltration now apply to AI misuse. In this post, we’ll walk through practical KQL hunts to surface suspicious AI activity, from abnormal model usage patterns to subtle signs of data exfiltration that traditional detections might miss.

The AI attack surface: old playbook, new players

Attackers aren’t reinventing the wheel; they’re repurposing it.
The top risks map neatly to the OWASP Top 10 for LLM Applications:

Prompt injection (LLM01) – Manipulating model logic through crafted inputs or poisoned context
Sensitive data disclosure (LLM06) – AI returning confidential data due to mis-scoped access
Shadow AI usage – Employees using external copilots with corporate data
Wallet abuse – API tokens or service principals driving massive, unintended consumption

It’s not about new telemetry; correlation is what matters. Defender surfaces these risks by tying AI alerts from Defender for Cloud to real user behavior across your XDR environment.

Threat hunting: from AI alerts to insight

Forget slide decks. These are practical, production-ready hunting patterns using real Defender data tables.

1. Shadow AI exfiltration detection

Office apps sending data to external AI endpoints (the #1 exfil path today).

( DeviceNetworkEvents | where RemoteUrl has_any (dynamic(["openai.com","anthropic.com","claude.ai","cohere.ai","chatgpt.com","gemini.google.com","huggingface.co","perplexity.ai"])) | where InitiatingProcessFileName in~ (dynamic(["EXCEL.EXE","WINWORD.EXE","OUTLOOK.EXE","POWERPNT.EXE","ONENOTE.EXE"])) or InitiatingProcessFileName in~ (dynamic(["chrome.exe","msedge.exe","firefox.exe","brave.exe"])) | extend Device = toupper(split(DeviceName, ".")[0]), IsOffice = InitiatingProcessFileName in~ (dynamic(["EXCEL.EXE","WINWORD.EXE","OUTLOOK.EXE","POWERPNT.EXE","ONENOTE.EXE"])) | summarize Connections = count(), IsOffice = max(IsOffice), AITime = max(Timestamp) by Device, User = InitiatingProcessAccountName ) | join kind=inner ( DeviceFileEvents | where ActionType in~ ("FileCopied","FileCreated","FileModified","FileRenamed") | extend Device = toupper(split(DeviceName, ".")[0]), Lower = tolower(strcat(FolderPath, FileName)) | extend HeuristicFlag = case( Lower has_any ("password","credential","secret","api_key") or Lower endswith ".key" or Lower endswith ".pem", "Credential", Lower has_any ("confidential","restricted","classified","sensitive"), "Classified", Lower has_any ("ssn","salary","payroll"), "PII", Lower has_any ("finance","hr","legal","executive"), "OrgSensitive", "Other" ), LabelFlag = case( SensitivityLabel has "Highly Confidential", "Classified", SensitivityLabel has "Confidential", "Sensitive", SensitivityLabel has "Internal", "Internal", isnotempty(SensitivityLabel), "Labeled", "Unlabeled" ) | where HeuristicFlag != "Other" or LabelFlag in ("Classified","Sensitive","Internal","Labeled") | summarize Files = count(), HeuristicCount = countif(HeuristicFlag != "Other"), DLPCount = countif(isnotempty(SensitivityLabel)), Types = make_set_if(HeuristicFlag, HeuristicFlag != "Other"), Labels = make_set_if(SensitivityLabel, isnotempty(SensitivityLabel)), FileTime = max(Timestamp) by Device, User = InitiatingProcessAccountName ) on Device, User | extend Delta = datetime_diff('minute', AITime, FileTime) | where abs(Delta) <= 240 | extend Priority = case( IsOffice == 1, "Critical", Labels has_any ("Highly Confidential","Confidential") or Types has "Credential" or Types has "Classified", "High", Files >= 20, "High", "Medium" ) | project Priority, Device, User, Connections, Files, HeuristicCount, DLPCount, Types, Labels, Delta | order by Priority desc, Files desc

Why it works: Correlates outbound AI traffic with sensitive file access.
Action: Block the key, review DLP coverage, fix workflow gaps.

2. Anomalous consumption patterns

Off-hours Azure OpenAI activity isn’t necessarily productivity; it might be unsanctioned automation or exfiltration.

// Azure OpenAI & LLM Off-Hours Detection - PER USER TIMEZONE // DISCLAIMER: Time zone detection is approximate, based on behavioral inference. // Validate per user/device when high-risk anomalies are flagged. // If authoritative time zone data (e.g., Entra sign-in or mailbox settings) is available, prefer that source. let MinRequestsThreshold = 500; let MinTokensThreshold = 20000; let OffHoursStart = 21; let OffHoursEnd = 5; let UserTimezones = CloudAppEvents | where Timestamp > ago(60d) | where Application has_any ("OpenAI", "Azure OpenAI", "ChatGPT", "Claude", "Gemini", "Anthropic", "Perplexity", "Microsoft 365 Copilot") | extend HourUTC = datetime_part("Hour", Timestamp) | summarize ActivityByHour = count() by AccountDisplayName, HourUTC | summarize arg_max(ActivityByHour, HourUTC) by AccountDisplayName | extend TimezoneOffset = iff((HourUTC - 14 + 24) % 24 > 12, (HourUTC - 14 + 24) % 24 - 24, (HourUTC - 14 + 24) % 24) | project AccountDisplayName, TimezoneOffset; CloudAppEvents | where Timestamp > ago(30d) | where Application has_any ("OpenAI", "Azure OpenAI", "ChatGPT", "Claude", "Gemini", "Anthropic", "Perplexity", "Microsoft 365 Copilot") | extend HourUTC = datetime_part("Hour", Timestamp), DayUTC = toint(dayofweek(Timestamp)), Tokens = toint(RawEventData.totalTokens) | join kind=leftouter (UserTimezones) on AccountDisplayName | extend TZ = coalesce(TimezoneOffset, 0) | extend HourLocal = (HourUTC + TZ + 24) % 24 | extend DayLocal = (DayUTC + iff(HourUTC + TZ >= 24, 1, iff(HourUTC + TZ < 0, -1, 0)) + 7) % 7 | extend IsAnomalous = (DayLocal in (0, 6)) or (HourLocal >= OffHoursStart or HourLocal < OffHoursEnd) | where IsAnomalous | extend IsWeekend = DayLocal in (0, 6), IsOffHours = HourLocal >= OffHoursStart or HourLocal < OffHoursEnd | summarize Requests = count(), TokensUsed = sum(Tokens), WeekendRequests = countif(IsWeekend), LateNightRequests = countif(IsOffHours and not(IsWeekend)), LocalHours = make_set(HourLocal), LocalDays = make_set(DayLocal), Applications = make_set(Application), ActionTypes = make_set(ActionType), FirstSeen = min(Timestamp), LastSeen = max(Timestamp), DetectedTZ = any(TZ) by AccountDisplayName, IPAddress | where Requests >= MinRequestsThreshold or TokensUsed >= MinTokensThreshold | extend UserTimezone = case( DetectedTZ == 0, "UTC/GMT", DetectedTZ == -5, "EST (UTC-5)", DetectedTZ == -4, "EDT (UTC-4)", DetectedTZ == -6, "CST (UTC-6)", DetectedTZ == -7, "MST (UTC-7)", DetectedTZ == -8, "PST (UTC-8)", DetectedTZ == 1, "CET (UTC+1)", DetectedTZ == 8, "CST China (UTC+8)", DetectedTZ == 9, "JST Japan (UTC+9)", DetectedTZ > 0, strcat("UTC+", DetectedTZ), strcat("UTC", DetectedTZ) ) | extend ThreatPattern = case( array_length(Applications) > 1, "Multiple LLM Services", WeekendRequests > LateNightRequests * 2, "Weekend Automation", LateNightRequests > WeekendRequests * 2, "Late-Night Automation", Requests > 500, "High-Volume Script", "Unusual Off-Hours Activity" ) | extend RiskScore = case( Requests > 1000 and TokensUsed > 100000, 100, Requests > 500 and WeekendRequests > 100, 95, TokensUsed > 50000 or Requests > 200, 85, WeekendRequests > 100, 80, Requests > 100 or TokensUsed > 20000, 70, 60 ) | extend RiskLevel = case( RiskScore >= 90, "Critical", RiskScore >= 75, "High", RiskScore >= 60, "Medium", "Low" ) | project AccountDisplayName, IPAddress, RiskLevel, RiskScore, ThreatPattern, Requests, TokensUsed, WeekendRequests, LateNightRequests, Applications, UserTimezone, LocalHours, LocalDays, ActionTypes, FirstSeen, LastSeen | sort by RiskScore desc, Requests desc

Why it works: Humans sleep. Scripts don’t. Temporal anomalies expose automation faster than anomaly models.

Action: Check grounding sources, confirm the IP, disable keys or service principals.

3. Bot-like behavior hunt

Highlights automation vs. compromise and early detection.

// ---- Tunables (adjust if needed) ---- let LookbackDays = 7d; let MinEvents = 3; // ignore trivial users let RPM_AutoThresh = 50.0; // requests/hour threshold that smells like a bot let MaxIPs_Auto = 1; // single IP suggests fixed worker let MaxApps_Auto = 1; // single app suggests fixed worker let MaxUAs_Auto = 2; // very few UAs over lookback let MaxHighTokPct = 5.0; // % of requests over 4k tokens still considered benign CloudAppEvents | where Timestamp > ago(LookbackDays) | where Application has_any ("OpenAI", "Azure OpenAI", "Microsoft 365 Copilot Chat") | extend User = tolower(AccountDisplayName) | extend raw = todynamic(RawEventData) | extend Tokens = toint(coalesce(raw.totalTokens, raw.total_tokens, raw.usage_total_tokens)) | summarize TotalRequests = count(), HighTokenRequests = countif(Tokens > 4000), AvgTokens = avg(Tokens), MaxTokens = max(Tokens), UniqueIPs = dcount(IPAddress), IPs = make_set(IPAddress, 50), UniqueApps = dcount(Application), Apps = make_set(Application, 20), UniqueUAs = dcount(UserAgent), FirstRequest = min(Timestamp), LastRequest = max(Timestamp) by User | where TotalRequests >= MinEvents | extend _dur = toreal(datetime_diff('hour', LastRequest, FirstRequest)) | extend DurationHours = iif(_dur <= 0, 1.0, _dur) | extend RequestsPerHour = TotalRequests / DurationHours | extend HighTokenRatio = (HighTokenRequests * 100.0) / TotalRequests // ---- Heuristic: derive likely automation (no lists/regex) ---- | extend IsLikelyAutomation = (UniqueIPs <= MaxIPs_Auto and UniqueApps <= MaxApps_Auto and UniqueUAs <= MaxUAs_Auto and RequestsPerHour >= RPM_AutoThresh and HighTokenRatio <= MaxHighTokPct) // ---- Techniques & risk ---- | extend IsRapidFire = RequestsPerHour > 20, IsHighVolume = TotalRequests > 50, IsTokenAbuse = HighTokenRatio > 30, IsMultiService = UniqueApps > 1, IsMultiIP = UniqueIPs > 2, IsEscalating = DurationHours < 24 and TotalRequests > 10 | where IsRapidFire or IsHighVolume or IsTokenAbuse or IsMultiService or IsMultiIP or IsEscalating | extend TechniqueCount = toint(IsRapidFire) + toint(IsHighVolume) + toint(IsTokenAbuse) + toint(IsMultiService) + toint(IsMultiIP) + toint(IsEscalating) | extend Risk = case( IsLikelyAutomation and UniqueIPs == 1 and UniqueApps == 1 and IsTokenAbuse == 0, "Low - Likely Automation", TechniqueCount >= 4, "Critical - Multi-Vector Behavior", TechniqueCount >= 3, "High - Attack Pattern", TechniqueCount >= 2, "Medium - Anomalous Behavior", "Low" ) // Custom sort: Critical > High > Medium > Low - Likely Automation > Low | extend RiskOrder = case( Risk startswith "Critical", 1, Risk startswith "High", 2, Risk startswith "Medium", 3, Risk == "Low - Likely Automation", 4, 5 ) | project Risk, User, TotalRequests, RequestsPerHour, TechniqueCount, IsLikelyAutomation, IsRapidFire, IsHighVolume, IsTokenAbuse, IsMultiIP, IsMultiService, IsEscalating, UniqueIPs, IPs, UniqueApps, UniqueUAs, HighTokenRatio, DurationHours, FirstRequest, LastRequest, RiskOrder | sort by RiskOrder asc, TotalRequests desc

Why it works: Hunting automation-like patterns that could indicate either sanctioned scripts or early-stage compromise, enabling proactive detection before alerts fire.

Action: Investigate flagged accounts immediately to confirm intent and mitigate potential AI misuse.

Operational lessons that scale beyond the lab

Custom detections > Ad hoc hunts – Turn query #1 into a scheduled detection. Shadow AI isn’t a one-off behavior.
Security Copilot ≠ search bar – Use it for triage context, not hunting logic.
Set quotas, treat them like controls – Token budgets and rate limits are as critical as firewalls for AI workloads.
Defender for Cloud Apps – Block risky generative AI apps while letting sanctioned copilots run.

Getting started with threat hunting for AI workloads

Before you run these hunts at scale, make sure your environment is instrumented for cognitive visibility. That means insight into how your AI models are being used and what data they reason over, not just how much compute they consume.

Traditional telemetry shows process, network, and authentication events. Cognitive visibility adds prompts, model responses, grounding sources, and token behavior, giving analysts the context that explains why an AI acted the way it did.

Defender for AI Services integrates with Defender for Cloud to provide that visibility layer, but the right configuration turns data collection into situational awareness.

Enable the AI services plan – Make sure Defender for AI Services is enabled at the subscription level. This activates continuous monitoring for Azure OpenAI, AI Foundry, and other managed AI workloads. Microsoft Learn →
Enable user prompt evidence – Turn on prompt capture for Defender for AI alerts. Seeing the exact input and model response during an attack is the difference between speculation and evidence. Microsoft Learn →
Validate your schema – Always test KQL queries in your workspace. Field names and event structures can differ across tenants and tiers, especially in CloudAuditEvents and AlertEvidence.
Use Security Copilot for acceleration – Let Copilot translate natural language hypotheses into KQL, then fine-tune the logic yourself. It is the fastest way to scale your hunts without losing precision. Microsoft Learn →
Monitor both sides of the equation – Hunt for both AI-specific risks such as prompt injection, model abuse, or token sprawl, and traditional threats that target AI systems such as compromised credentials, exposed storage, or lateral movement through service principals.

Visibility is only as strong as the context you capture. The sooner you enable these settings, the sooner your SOC can understand why your models behave the way they do, not just what they did.

Final thoughts: from prompts to protections

As AI becomes part of core infrastructure, its telemetry must become part of your SOC’s muscle memory. The same principles that power endpoint or identity defense (i.e. visibility, correlation, anomaly detection) now apply to model inference, token usage, and data grounding.

Defender for Cloud and Defender XDR give you that continuity: alerts flow where your analysts already work, and your hunting logic evolves without a separate stack.

Protecting AI isn’t about chasing every model. It’s about extending proven security discipline to the systems that now think alongside you.

Delivering more threat hunting insights with Microsoft Defender Experts’ newest capabilities

DillonPersaud — Mon, 03 Nov 2025 16:00:00 GMT

The cybersecurity threat landscape continues to evolve with novel attacks and techniques emerging each day. Microsoft Defender Experts for Hunting, included with Microsoft Defender Experts for XDR, helps security teams stay ahead of evolving attacks by providing proactive threat hunting, powered by Microsoft’s vast threat intelligence with 100 trillion daily signals processed by over 10,000 experts.

To date, our managed threat hunting reports have provided details about the hunts we conduct after observing suspicious activity, with full attack summary details provided for verified threats (also known as Defender Experts Notifications). Today, we are excited to announce the general availability of new capabilities that deliver deeper hunting context to our customers. More specifically, we will provide greater insight into each hunt we carry out—not just the ones that result in verified threats. And we’ll also give our customers visibility into the hypothesis-based hunts we conduct on their behalf.

Introducing investigation summaries for the hunts we conduct

Each hunt we conduct tells a story, even when no active threat is found. So, to keep you informed, you will now receive an investigation summary to go along with nearly each hunt we conduct in their environment—regardless of whether a confirmed threat was found. This summary will detail what we hunted for, why we hunted for it, and how we reached our final determination.

Beyond transparency, these summaries provide assurance that we thoroughly hunted down the threat and that your defenses remain intact. They help validate your security posture and, when applicable, highlight any previously uncovered threats during the process. Even in cases where no threat is detected, you can analyze our hunt summaries to be tangibly assured that we are continuously hunting on your behalf—keeping you informed, prepared, and ahead of new risks.

Figure 1. Screenshot of Microsoft Defender Experts for Hunting report with hunts mapped to threat categories.Figure 2. Screenshot of the Hunting report, showing the new investigation summary feature after a user clicks into a hunt.

New Emerging threats section of the Defender Experts for Hunting report

Our threat hunters constantly analyze substantial amounts of threat intelligence to hunt for new and emerging techniques. To share this information with you, we are unveiling a new section of our report titled “Emerging threats” which details the proactive, hypothesis-based hunts we’ve conducted in your environment. These hunts focus on tactics that adversaries are just beginning to adopt, meaning they might bypass traditional detection mechanisms.

This section will provide a title briefly describing each emerging threat, the severity we’ve ascribed to it, its relevant threat category, and most importantly, whether we’ve identified any evidence of impact in your environment. Additionally, by clicking into the hunt, you’ll see when we started and ended our hunt for the threat, along with a full investigation summary detailing our hunt. By surfacing these emerging threat hunts, we give you visibility into how we’re anticipating attacker behavior, validating your defenses against cutting-edge techniques, and identifying relevant suspicious activity before significant exploitation.

Figure 3. Screenshot of the Defender Experts for Hunting report’s new Emerging threats section.Figure 4. Screenshot of the Hunting report after a user clicks into an emerging threat hunt.

Conclusion

With these new capabilities, Microsoft Defender Experts for Hunting goes beyond detection to deliver transparency, assurance, and proactive defense. By surfacing investigation summaries and emerging threat insights, we help security teams validate their defenses, anticipate attacker tactics, and stay ahead of evolving risks. You can access these new capabilities by visiting your Hunting report, located in the Defender portal.

To learn more about our hunting service, visit our Microsoft Defender Experts for Hunting page, read our hunting documentation, or watch our explainer video. To learn more about our managed XDR service, visit our Microsoft Defender Experts for XDR page, or read our XDR documentation. You can also visit our Tech Community discussion space to ask questions, engage in conversations, and share your expertise and feedback.

What's next?

Join us at Microsoft Ignite in San Francisco on November 17–21, or online, November 18–20, for deep dives and practical labs to help you maximize your Microsoft Defender investments and to get more from the Microsoft capabilities you already use. Security is a core focus at Ignite this year, with the Security Forum on November 17th, deep dive technical sessions, theater talks, and hands-on labs designed for security leaders and practitioners

Featured sessions

BRK237: Identity Under Siege: Modern ITDR from Microsoft
Join experts in Identity and Security to hear how Microsoft is streamlining collaboration across teams and helping customers better protect, detect, and respond to threats targeting your identity fabric.
BRK240 – Endpoint security in the AI era: What's new in Defender
Discover how Microsoft Defender’s AI-powered endpoint security empowers you to do more, better, faster.
BRK236 – Your SOC’s ally against cyber threats, Microsoft Defender Experts
See how Defender Experts detect, halt, and manage threats for you, with real-world outcomes and demos.
LAB541 – Defend against threats with Microsoft Defender
Get hands-on with Defender for Office 365 and Defender for Endpoint, from onboarding devices to advanced attack mitigation.

Explore and filter the full security catalog by topic, format, and role: aka.ms/SessionCatalogSecurity.

Why attend?
Ignite is the place to learn about the latest Defender capabilities, including new agentic AI integrations and unified threat protection. We will also share future-facing innovations in Defender, as part of our ongoing commitment to autonomous defense.

Security Forum—Make day 0 count (November 17)
Kick off with an immersive, in person preday focused on strategic security discussions and real-world guidance from Microsoft leaders and industry experts. Select Security Forum during registration.

Cloud shadows: How attackers exploit Azure’s elasticity for stealth and scale

Pranavahebbar — Mon, 27 Oct 2025 15:00:00 GMT

Threats like password spray or adversary-in-the-middle (AiTM) are routine and too easily overlooked in an endless stream of security alerts. But what if these routine threats are only a small part of a much deeper, more sophisticated attack?

Since June 2025, Microsoft Defender Experts has been closely monitoring a sophisticated and continuously evolving attack campaign targeting poorly managed Azure cloud environments. What sets these threats apart is their use of Azure’s elasticity and interconnected structure, which allows users and attackers alike to move more easily through multi-tenant environments and avoid basic detection. By specifically targeting student and Pay-As-You-Go accounts that are improperly secured and poorly monitored, adversaries can rapidly move across tenants, weaponize ephemeral resources, and manipulate quotas—constructing a resilient and dynamic ecosystem. Their methods blend so seamlessly with legitimate cloud activity that they frequently evade basic threat detection methods, taking full advantage of trusted cloud features to ensure persistence and scale.

The campaigns demonstrate how today’s adversaries can transform even a single compromised credential into a sprawling and complex attack across multiple tenants.

Attackers no longer simply establish static footholds; instead, every compromised account becomes a possible springboard, every tenant a new beachhead. Their arsenal is thoroughly cloud-native: rapidly deploying short-lived virtual machines, registering OAuth applications for ongoing access, manipulating service quotas to expand their attack infrastructure, and abusing machine learning workspaces for covert activity. The result is an attack ecosystem that’s agile, elusive, and built to endure in the fast-moving world of the cloud.

Why are these attacks worth watching?

These attacks represent a strategic evolution in threat actor behavior—blending into legitimate cloud activity, evading traditional detection, and exploiting the very features that drive business agility. The scale, adaptability, and persistence demonstrated in this campaign is a wake-up call: defenders must look beyond the surface, understand the full lifecycle of cloud-native attacks, and be prepared to counter adversaries who are already mastering the art of stealth and scale.

This blog doesn’t just recount what happened, it breaks down the anatomy of a cloud-scale attack. Whether you're a security analyst, cloud architect, or threat hunter, the goal is to help you recognize the signs, understand the methods, and prepare your defenses. With the cloud, organizations benefit from scale, global access, and agility. But if not properly secured, those attributes also benefit threat actors.

Resource development: exploiting the weakest links

Microsoft Defender Experts has observed ongoing, large-scale campaigns on Azure environments. Student and Pay-As-You-Go (PAYG) accounts, were exploited due to poor security hygiene. These accounts often lacked essential protections: weak or default passwords, no multi-factor authentication (MFA), and no active security monitoring or Defender for Cloud subscription.

Initial access was achieved via adversary in the middle (AiTM) attacks or password sprays against Azure User Profile Application (UPA) accounts, commonly using infrastructure hosted by M247 Europe SRL & LTD (New York) and Latitude.

Weaponizing ephemeral infrastructure

Once access was established using a compromised account, the attacker created new Resource Groups and deployed short-lived Virtual Machines (VMs). These VMs ran for as little as 3–4 hours and up to 1–2 days before being deleted. This approach enabled rapid rotation of attack infrastructure, minimal forensic footprint, and evasion of long-term detection.

From these ephemeral VMs, large-scale password spray attacks were launched (predominantly utilizing user agents—BAV2ROPC, python-requests/2.32.3, python-requests/2.32.4) against thousands of accounts across multiple Azure tenants. Operating within Azure’s ecosystem helped the campaign stay below conventional alerting thresholds. Alerts that did occur were often dismissed as false positives or benign because they originated from legitimate Azure associated IP addresses.

Scaling through multi-hop and multitenant techniques

The sophistication of this campaign lies in their multi-hop and multitenant architecture:

Multi-hop: Attacker used compromised Azure VMs to pivot and launch attacks on other accounts, masking their origin and complicating attribution.
Multitenant: By controlling multiple Azure tenants, attackers distribute their operations, scale attacks, and maintain resilience against takedowns.

This cross-tenant movement within the Azure environment allows attackers to expand their footprint more easily, making detection more challenging.

Impact: spam, financial fraud, phishing, and sextortion campaigns

Following each successful password spray attack, the campaign expanded across compromised Azure tenants. Using access gained from earlier stages, the attacker repurposed virtual machines within these tenants to send large volumes of phishing and scam emails.

These phishing campaigns were carefully crafted to deceive users in compromised tenants, often leading to financial fraud involving URL shorteners like rebrand.ly, redirecting victims to fraudulent non-work related websites such as those with personal interest, entertainment, or leisure activity content.

On those fake sites, users were prompted to:

Complete surveys or questionnaires
Provide personal information
Download malicious Android APKs such as FM WhatsApp or Yo WhatsApp

Note: The APK is a resigned WhatsApp clone trojan that exploits elevated WhatsApp permissions to harvest private data (contacts, files) while mimicking legitimate registration by communicating with official servers to evade detection. Its malicious actions are triggered via commands hosted in a compromised GitHub repo (xiaoqaingkeke/Stat), indicating a GitHub based C2.

In some cases, victims were lured to enter their mobile numbers for chat services or install additional video calling apps—further expanding the attacker’s reach and enabling data harvesting and even extortion.

Persistence and expansion

Privileged access and the infrastructure the attacker compromised, built, and used in this campaign are worthless if the attacker cannot maintain control. To maintain and strengthen their foothold, the adversary deployed multiple persistence mechanisms. Below is a summary of the persistence techniques used by the attacker, as observed by Microsoft Defender experts across compromised tenants during the investigation.

Abuse of OAuth applications

Once access to an Azure tenant was obtained, the campaign escalated by registering OAuth applications. Two distinct types of applications were observed:

Azure CLI–themed apps (named like "Azure-CLI-2025-06-DD-HH-MM-SS" and "Azure CLI") were registered with the compromised tenant as owner. The attacker added password credentials and created service principals for these apps to enable persistent backdoors (even attempted to re-enable a disabled subscription). In one instance, two custom Azure CLI apps were used to authenticate to Azure Databricks so access would survive account disables.
The attacker registered a malicious custom application named MyNewApp, which was used to send large volumes of phishing emails and was successfully traced the campaign by analysing Microsoft Graph API calls, which revealed delivery and engagement patterns

Quota manipulation

To amplify the campaign’s infrastructure, the attacker exploited compromised credentials to submit service tickets requesting quota increases for Azure VM families:

A request was made to raise the quota for the DaV4 VM family to 960 cores across multiple regions.
A guest account, added during the attack, submitted a similar request for the EIADSv5 VM family.

These actions reflect a deliberate effort to scale up the virtual machine farm, enabling broader password spray operations and phishing campaigns.

Notably, the VM farm created by the compromised user was dismantled within three hours, while the farm initiated by the guest account remained active for a full day. This highlights the risk of guest access persistence, which often remains unless explicitly revoked.

Advanced abuse in Azure: ML workspaces, Key Vaults, and beyond

The recent campaign against a poorly managed, monitored, and configurated Azure environment was marked by a sophisticated, multi-stage attack that leveraged the elasticity and trusted features of cloud-native infrastructures for stealth and scale. The attacker’s operations were not limited to simple credential theft or cross-tenant movement—they demonstrated advanced abuse of Azure’s Machine Learning (ML) services, notebook proxies, Key Vaults, and blob storage to automate, persist, and exfiltrate at scale.

ML workspaces and notebook proxies: a stealthy execution layer

The attacker repeatedly created Machine Learning workspaces (Microsoft.MachineLearningServices/workspaces/write) and deployed notebook proxies (Microsoft.Notebooks/NotebookProxies/write) using both compromised user accounts and invited guest identities.

Attackers can abuse Azure ML to run cryptominers or malicious jobs disguised as training, poison or deploy compromised models, use workspaces/notebooks for persistent RCE, and exfiltrate data via linked storage. They scale with automated pipelines and quota requests, all while blending into normal AI workflows to evade detection.

Blob storage exploitation: payload staging and data exfiltration

Simultaneously, the attacker provisioned blob storage containers (Microsoft.Storage/storageAccounts/blobServices/containers/write) to stage payloads, host malicious scripts, and store sensitive datasets. The global accessibility and high availability of blob storage made it an ideal channel for covert data exfiltration and operational agility, minimizing the likelihood of detection.

Key Vault manipulation: securing persistence

The creation and modification of Key Vaults (Microsoft.KeyVault/vaults/write) suggests a deliberate effort to store secrets, credentials, and access tokens. That allowed the attacker to automate interactions with other Azure services and maintain long-term persistence. By embedding themselves into the fabric of cloud identity and access management, they ensured continued access even if initial entry points were remediated.

Damage statistics from the campaign controlled by single attacker machine

The impact? Staggering. In a matter of days, a single attacker machine was able to:

Target nearly 1.9 million global users and compromise over 51,000 accounts.
Infiltrate 35 Azure tenants and abuse 36 subscriptions.
Spin up 154 virtual machines with 86 used specifically for password spray attacks.
Raise over 800,000 Defender alerts, flooding security teams and masking true malicious activity.
Send 2.6million spam emails.
Abuse Azure’s machine learning services, register malicious OAuth apps, and manipulate quotas to scale up attacks—all while maintaining persistence and evading detection.

Recommendations

Harden identity to prevent attackers from exploiting low-hanging student subscriptions.
Enforce MFAand password protection as most of the users often don't enroll in MFA. Investigate and auto remediate risky users/sign ins; enable token protection (where available) to reduce the blast radius of stolen cookies. Microsoft’s public AiTM guidance consolidates these defenses, and XDR’s AiTM disruption revokes cookies and disables users during active compromise.
Constrain abuse pathways in Azure.
Apply least privilege RBAC, review guest invitations, and monitor for role promotions on a schedule and via near Realtime analytics, as outlined in Microsoft’s subscription compromise post.
Watch for subscription directory/transfer changes and couple with approval style processes; remember transfer can move management (and thus logs) while billing may not change by default.
Treat quota as a credit limit and instrument alerts for large, fast, or multiregion quota consumption to spot bursts (legitimate or not). Microsoft’s ML quota docs explain defaults, VM family splits (e.g., “Nseries” GPUs default to zero), and how to request increases.

If you suspect your subscription is being misused

Start an investigation using Microsoft’s playbooks (password spray) and the hunting queries below; prioritize containment of accounts with risky sign ins and recent ARM writes.
If you’re a CSP partner, subscribe to Unauthorized Party Abuse (UPA) alerts and follow the documented response steps for compromised Azure subscriptions. These alerts help surface anomalous consumption and abuse earlier.
Clean up tenants/subscriptions you don’t need and understand transfer/cancellation mechanics (“Protect tenants and subscriptions from abuse and fraud attacks”). This both reduces your attack surface and simplifies response.
Report abuse (e.g., spam, DoS, brute force, malware) observed from Azure IPs or URLs via the MSRC reporting portal; this ensures the platform teams can act on infra being used against others.

A practical hunting mini playbook

1) Azure resource writes, role assignments, etc (last 24h) from high-risk sign-in accounts.

let RiskySignin = SigninLogs | where TimeGenerated > ago(24h) | where RiskLevelAggregated == "high" | project RiskTime = TimeGenerated, UserPrincipalName, IPAddress; AzureActivity | where TimeGenerated > ago(24h) | where OperationNameValue has_any ( "Microsoft.MachineLearningServices/workspaces/write", "Microsoft.MachineLearningServices/workspaces/computes/write", "Microsoft.Compute/virtualMachines/extensions/write", "Microsoft.Authorization/roleAssignments/write", "Microsoft.Resources/subscriptions/resourceGroups/write", // Optional: include the VM create/update itself (not just extensions) "Microsoft.Compute/virtualMachines/write" ) or (ActivityStatusValue == "Success" and OperationNameValue == "Microsoft.Subscription/aliases/write") | extend CallerIP = coalesce(CallerIpAddress, tostring(parse_json(Properties).callerIpAddress)) | join kind=inner (RiskySignin) on $left.Caller == $right.UserPrincipalName | where TimeGenerated between (RiskTime .. RiskTime + 2h) | summarize Ops = count(), DistinctOps = dcount(OperationNameValue) by Caller, CallerIP, bin(TimeGenerated, 30m) | order by Ops desc

2) Azure Activity (Sentinel): Support ticket creation before ML service deployment for Quota abuse

//Below query shows the risky users writing support tickets which involve quota increase let RiskySignin = SigninLogs | where TimeGenerated > ago(24h) | where RiskLevelAggregated == "high" | project RiskTime = TimeGenerated, UserPrincipalName, IPAddress; AzureActivity | where TimeGenerated > ago(24h) | where OperationNameValue has_any ("supportTickets/write","usages/write") | project QuotaTime = TimeGenerated, Caller, CallerIpAddress = tostring(parse_json(Properties).callerIpAddress) | join kind=inner (RiskySignin) on $left.Caller == $right.UserPrincipalName | where QuotaTime between (RiskTime .. RiskTime + 2h)

In conclusion

The cloud offers organizations many important benefits. Unfortunately, threat actors are leveraging cloud attributes such as elasticity, scale, and interconnectedness to orchestrate persistent, multitenant attacks that evade traditional defenses. As demonstrated, even a single compromised account can rapidly escalate into a widespread attack, affecting thousands of users and tenants.

To counter those evolving threats, defenders must adopt proactive measures: enforce strong identity controls, monitor for suspicious activity, limit privileges, and regularly audit cloud resources. Ultimately, maintaining vigilance and adapting security practices to the dynamic nature of cloud environments, such as Azure, is essential to protect against increasingly stealthy and scalable adversaries and making your cloud more secure.

What's next?

Featured sessions

BRK237: Identity Under Siege: Modern ITDR from Microsoft
Join experts in Identity and Security to hear how Microsoft is streamlining collaboration across teams and helping customers better protect, detect, and respond to threats targeting your identity fabric.
BRK240 – Endpoint security in the AI era: What's new in Defender
Discover how Microsoft Defender’s AI-powered endpoint security empowers you to do more, better, faster.
BRK236 – Your SOC’s ally against cyber threats, Microsoft Defender Experts
See how Defender Experts detect, halt, and manage threats for you, with real-world outcomes and demos.
LAB541 – Defend against threats with Microsoft Defender
Get hands-on with Defender for Office 365 and Defender for Endpoint, from onboarding devices to advanced attack mitigation.

Explore and filter the full security catalog by topic, format, and role: aka.ms/SessionCatalogSecurity.

How Microsoft Defender Experts and partners like Quorum Cyber are redefining cybersecurity teamwork

Raae_ — Thu, 18 Sep 2025 16:00:00 GMT

In today’s rapidly evolving threat landscape, cybersecurity demands more than just great technology—it requires great teamwork. That’s the story behind the collaboration between Microsoft Defender Experts and MXDR partner, Quorum Cyber, joining forces to deliver end-to-end threat protection for organizations worldwide.

Microsoft-verified MXDR partner

Microsoft Defender Experts recognized the need for partner-led managed services to complement their first-party MDR (Managed Detection and Response) service.

Quorum Cyber is a trusted Microsoft solutions partner and MSSP of the Year. They are also a Microsoft-verified MDR partner, which means they passed Microsoft’s validation process to deliver services using Microsoft’s security technologies. Quorum Cyber complements Microsoft Defender Experts, MDR services with additional security operations center (SOC) capabilities, extended coverage, non-Microsoft telemetry, and 3rd party domain expertise.

“Quorum Cyber’s reputation for customer focus and security expertise made them the ideal Microsoft-verified MDR partner.” – Vivek Kumar, Microsoft

“We saw Defender Experts as a way to extend our reach and deliver even more value to customers. It wasn’t about replacing—it was about enhancing.” – Ricky Simpson, Quorum Cyber

Why teamwork matters

The Microsoft-verified MDR partner program was born out of a shared mission: to provide holistic, customer-led security solutions to address the growing security needs of organizations worldwide.

Today, cyber security needs to be a team sport. Organizations that provide security services, like Microsoft’s Defender Experts and Quorum Cyber, need to join together with customers to defend an ever-expanding attack surface against today’s sophisticated threats.

Facing the modern threat landscape together

From skill shortages to complex attacks, organizations need security providers who can adapt and collaborate.

“Hackers only need to get it right once while SecOps needs to get it right every time. Customers need an end-to-end security solution to eliminate gaps and strengthen vulnerabilities. No single provider can address the needs of every organization—everywhere. Only teamwork can get the job done.” – Vivek Kumar, Microsoft

How MDR providers working together is important for CISOs and other security leaders

Meeting real-world challenges

Modern SecOps must navigate an increasingly complex and multifaceted threat landscape. One of the most pressing challenges is the global shortage of cybersecurity professionals. Although the security workforce has grown by 9%, the gap has widened even further, with nearly 4.8 million additional professionals needed to adequately protect organizations last year. ¹

Meanwhile, adversaries are becoming more sophisticated and agile. They work in groups, using many individuals who process deep domain expertise is executing various attack techniques and tactics. In May 2024 alone, Microsoft Defender XDR detected over 176,000 incidents involving tampering with security settings, impacting more than 5,600 organizations. ²

That surge in threat activity coincides with a pivotal moment in technological evolution as organizations rapidly scale cloud operations and explore the transformative potential of generative AI. These innovations, while powerful, also expand the attack surface and the likelihood of gaps and vulnerabilities.

Comprehensive coverage across security domains

Microsoft Defender Experts brings deep integration across Microsoft’s ecosystem and manages incidents across Microsoft Defender products (Endpoint, Office 365, Identity, Cloud Apps, and Defender for Cloud/Servers).

Quorum Cyber, a Microsoft-verified partner, offers flexibility and specialized coverage to extend beyond Microsoft Defender Experts.

“What is so exciting about this approach, is that together, we created a layered defense strategy that’s greater than the sum of its parts and provides coverage for nearly all of the customers’ environment. Microsoft SDM/SecDeliveryExperts worked together with Quorum Cyber to create a nearly seamless, unified defense strategy. They not only help to eliminate the skills gap but are designed to scale easily to address nearly any volume of sophisticated threats.” – Sebastien Molendijk, Microsoft

With shared tooling, real-time communication, and complementary expertise, this teamwork eliminates blind spots and delivers coverage across an environment that includes non-Defender Experts supported technology such as 3rd party and legacy systems, custom applications, IoT, firewalls, network gear, and more. Additionally, the combined telemetry for all covered systems, Defender Experts and Quorum Cyber, enriches incident context and improves detection accuracy and hunting.

Real-world impact – Customer success stories

Proactive threat hunting is a core component of Defender Experts. Experts are not just cross-checking Indicators of Compromise (IOCs) against the environment or only validating them against known tactics, techniques, and procedures (TTPs). The hunting approach is differentiated by the 78T signals and hundreds of tracked threat actors. The intelligence informing Microsoft hunts spans across nation state, criminal activity, evolving vulnerabilities, and newly observed behaviors. That is something Defender Experts can uniquely provide customers.

One of many customer examples of this teamwork involved an organization already engaged with Quorum Cyber MDR for Microsoft E5 services. When Defender Experts engaged with the customer, the two teams co-created a solution tailored to meet the CISOs needs by combining Quorum Cyber’s analytics and monitoring with Defender Expert’s proactive threat hunting. That not only expanded coverage but provided the customer with both proactive and reactive services across nearly their entire environment.

Another example is adversary in the middle alerts, Defender Experts performs the investigation of malicious QR codes and then escalates to Quorum Cyber if malicious activity is observed. Quorum Cyber then takes delegated authority to reset the user's password, revokes their sessions, and takes other actions as needed.

Unique services

Collaboration is more than Quorum Cyber and Microsoft working as one. Quorum Cyber develops unique services including their data security service – Clarity Data. This service handles incidents generated via Microsoft Purview - DLP and IRM. It includes Quorum Cyber’s 24/7 365 SOC services to address those incidents without interfering with security signals being addressed by other analysts.

Operational flexibility

Customers have the option to divide responsibilities. For example, Microsoft manages Defender-specific alerts and Quorum Cyber manages alerts from all the other tools. Guided response playbooks allow Microsoft Defender Experts and Quorum Cyber teams to work as one to perform containment and remediation across workstreams.

“We built solutions from scratch, keeping customer outcomes at the center. The results are frictionless, powerful security models that address unique customer needs.” – Ricky Simpson, Quorum Cyber

Overcoming challenges, building trust, working as one

Like building any team, there were hurdles. From workflow alignment to incident handoffs, mutual respect and a shared commitment to customer satisfaction paved the way to building frictionless workstreams.

Teamwork thrived on technical integration. Because Defender Experts is built atop the Microsoft Defender portal and Microsoft Graph, the service is inherently designed for seamless collaboration. When Defender Experts assigns incidents, initiates proactive threat hunts, publishes investigation notes, or executes one-click remediation actions, those activities are fully integrated into both the Defender user experience and the Graph API.

That integration enables Quorum Cyber to synchronize directly with those workflows, allowing their teams to operate within their existing toolsets while customers receive real-time updates and final resolutions through platforms such as Microsoft Defender, Sentinel, or their ITSM systems.

A notable example is the ‘real-time chat’ feature within Defender Experts, which is architected to support joint participation from both customers and partners like Quorum Cyber—ensuring transparency and responsiveness throughout the incident lifecycle.

That level of tooling integration is essential to delivering a unified experience. Customers benefit from the deep expertise of Defender Experts, the broad coverage of a trusted partner like Quorum Cyber, and the operational efficiency of a tightly connected security services ecosystem. It truly represents the best of both worlds.

“Defender Experts’ use of Microsoft Graph and Defender Portal enabled seamless incident sharing, real-time chat, and synchronized updates across platforms. Live dashboards from Defender Experts offer a clear, prioritized view of incidents. That allowed Defender Experts and Quorum Cyber to work as one team to keep customers secure and do that quickly and efficiently.” – Ricky Simpson, Quorum Cyber

The bigger picture – innovation and growth

This partnership isn’t just about solving today’s problems—it’s about shaping the future. It has opened doors for Quorum Cyber to expand into new service areas, like managed data security, while reinforcing Microsoft’s commitment to flexible, scalable security solutions.

Customers don’t have to choose between Microsoft and their trusted MDR provider like Quorum Cyber—they can have both. By combining Microsoft Defender Experts with MDR providers like Quorum Cyber, organizations gain a flexible, scalable, and deeply integrated security strategy that adapts to their unique needs and can grow as they grow.

Whether you're augmenting your SOC, expanding global coverage, or navigating a transition, this “better together” model ensures your security operations are resilient, responsive, and ready for what’s next.

“We’ve proven, and our customer agree, that first-party and partner-led services can coexist and thrive together.” – Ricky Simpson, Quorum Cyber

“Customers get the best of both worlds—expertise from Defender Experts and coverage from Quorum Cyber, all delivered as it should be—in a timely and seamless way.” – Vivek Kumar, Microsoft

In summary – Microsoft Defender Experts and Quorum Cyber – the benefits are clear

End-to-End Threat Protection – Combines Microsoft Defender capabilities with Quorum Cyber extended SOC services and third-party telemetry.

Comprehensive Coverage –Protects both Microsoft and non-Microsoft environments, including legacy systems, IoT, and custom applications.

Proactive and Reactive Security –Integrates threat hunting with incident response for full-spectrum defense.

Operational Flexibility –Allows tailored division of responsibilities and coordinated remediation through guided playbooks.

Real-Time Collaboration –Enables seamless communication and incident management via shared tooling, dashboards, and chat features.

Advanced Threat Intelligence –Leverages Microsoft’s 78T signals and threat actor tracking, with partner TI, to enrich incident context and improve detection.

Complementary Services –For example, Quorum Cyber’s Clarity Data service handles Microsoft Purview incidents without disrupting other security workflows.

Unified Customer Experience –Delivers frictionless, scalable, and resilient security operations through deep integration and mutual trust.

Learn more

If you like this blog, and would like to learn more, see this insightful webinar for more details The Better Together Story of Defender Experts and Quorum Cyber - Quorum Cyber

And listen to what these experts from Quorum Cyber and Microsoft have to say about the benefits of ‘Better Together.’

Ricky Simpson | LinkedIn

Paul Caiazzo | LinkedIn

Scott McManus | LinkedIn

Raae Wolfram | LinkedIn

Sebastien Molendijk | LinkedIn

Henry Yan | LinkedIn

Vivek Kumar | LinkedIn

Next Steps

For organizations considering a multi-provider strategy, the message is clear: collaboration works. Microsoft Defender Experts and Quorum Cyber show that when service providers align around customer needs, the results are transformative.

“Microsoft Security has got you covered—whether through Defender Experts, partners like Quorum Cyber, or both.” – Vivek Kumar, Microsoft

Ready to strengthen your cyber resilience,

Join the conversation through Microsoft’s public webinar series

Explore the CTI community

Reach out to learn more about how this partnership can support your organization.

Sources

¹ ISC2-2024-Cybersecurity-Workforce-Study

² Microsoft Digital Defense Report 2024

Cloud forensics: Why enabling Microsoft Azure Storage Account logs matters

Abul_Azed — Tue, 02 Sep 2025 17:18:11 GMT

Co-authors - Christoph Dreymann - Shiva P

Introduction

Azure Storage Accounts are frequently targeted by threat actors. Their goal is to exfiltrate sensitive data to an external infrastructure under their control. Because diagnostic logging is not always fully enabled by default, valuable evidence of their malicious actions may be lost.

With this blog, we will explore realistic attack scenarios and demonstrate the types of artifacts those activities generate. By properly enabling Microsoft Azure Storage Account logs investigators gain a better understanding of the scope of the incident. The information can also provide guidance for remediating the environment and on preventing data theft from occurring again.

Storage Account

A Storage Account provides scalable, secure, and highly available storage for storing and managing data objects. Due to the variety of sensitive data that can be stored, it is another highly valued target by a threat actor.

Threat actors exploit misconfigurations, weak access controls, and leaked credentials to gain unauthorized access. Key risks include Shared Access Signature token (SAS) misuse that allows threat actors to access or modify exposed blob storages. Storage Account key exposure could grant privileged access to the data plane.

Investigating storage-related security incidents requires familiarity with Azure activity logs and Diagnostic logs. Diagnostic log types for Storage accounts are StorageBlob, StorageFile, StorageQueue, and StorageTable. These logs can help identify unusual access patterns, role changes, and unauthorized SAS token generation. This blog is centered around StorageBlob activity logs.

Storage Account logging

The logs for a Storage Account aren’t enabled by default. These logs capture operations, requests, and use such as read, write, and delete actions/requests on storage objects like blobs, queues, files, or tables.

NOTE: There are no license requirements to enable Storage Account logging, but Log Analytics charges based on ingestion and retention (Pricing - Azure Monitor | Microsoft Azure)

For more information on enabling logging for a Storage Account can be found here.

Notable fields

The log entries contain various fields which are of use not only during or after an incident, but for general monitoring of a storage account during normal operations (for a full list, see what data is available in the Storage Logs).

Once the storage log is enabled, one of the key tables within Log Analytics is StorageBlobLogs, which provides details about blob storage operations, including read, write, and delete actions. Key columns such as OperationName, AuthenticationType, StatusText, and UserAgentHeader capture essential information about these activities.

The OperationName field identifies operations on a storage account, such as “PutBlob” for uploads or “DeleteBlob” and “DeleteFile” for deletions.

The UserAgentHeader fields offer valuable insights into the tools used to access a Blob storage. Accessing blob storages through the Azure portal is typically logged with a generic user agent, which indicates the application used to perform the access, such as a web browser like Mozilla Firefox. In contrast, tools like AzCopy or Microsoft Azure Storage Explorer are explicitly identified in the logs. Analyzing the UserAgentHeader provides crucial details about the access method, helping determine how the blob storage was accessed.

The following table includes additional investigation fields,

Field name	Description
TimeGenerated [UTC]	The date and time of the operation request.
AccountName	Name of the Storage account.
OperationName	Name of the operation. A detailed list of for StorageBlob operation can be found here.
AuthenticationType	The type of authentication that was used to make this request.
StatusCode	The HTTP status code for the request. If the request is interrupted, this value might be set to Unknown.
StatusText	The status of the requested operation.
Uri	Uniform resource identifier that is requested.
CallerIpAddress	The IP address of the requester, including the port number.
UserAgentHeader	The User-Agent header value.
ObjectKey	Provides the path of the object requested.
RequesterUpn	User Principal Name of the requester.
AuthenticationHash	Hash of the authentication token used during a request. Request authenticated with SAS token includes a SAS signature specifying the hash derived from the signature part of the SAS token.

For a full list, see what data is available in the Storage Logs.

How a threat actor can access a Storage Account

Threat actors can access the Storage Account through Azure-assigned RBAC, a SAS token (including User delegated SAS token), Azure Storage Account Keys and Anonymous Access (if configured).

Storage Account Access Keys

Azure Storage Account Access Keys are shared secrets that enable full access to Azure storage resources. When creating a storage account, Azure generates two access keys, both can be used for authentication with the storage account. These keys are permanent and do not have an expiration date.

Both Storage Account Owners and roles such as Contributor or any other role with the assigned action of Microsoft.Storage/storageAccounts/listKeys/action can retrieve and use these credentials to access the storage account.

Account Access Keys can be rotated/regenerated but if done unintentionally, it could disrupt applications or services dependent on the key for authentication. Additionally, this action invalidates any SAS tokens derived from that key, potentially revoking access to dependent workflows.

Monitoring key rotations can help detect unexpected changes and mitigate disruptions.

Query: This query can help identify instances of account key rotations in the logs

AzureActivity | where OperationNameValue has "MICROSOFT.STORAGE/STORAGEACCOUNTS/REGENERATEKEY/ACTION" | where ActivityStatusValue has "Start" | extend resource = parse_json(todynamic(Properties).resource) | extend requestBody = parse_json(todynamic(Properties).requestbody) | project TimeGenerated, OperationNameValue, resource, requestBody, Caller, CallerIpAddress

Shared Access Signature

SAS tokens offer a granular method for controlling access to Azure storage resources. SAS tokens enable specific permitted actions on a resource and their duration. They can be generated for blobs, queues, tables, and file shares within a storage account, providing precise control over data access. A SAS token allows access via a signed URL.

A Storage Account Owner can generate a SAS token and connection strings for various resources within the storage account (e.g., blobs, containers, tables) without restrictions. Additionally, roles with Microsoft.Storage/storageAccounts/listKeys/action rights can also generate SAS tokens.

SAS tokens enable access to storage resources using tools such as Azure Storage Explorer, Azure CLI, or PowerShell.

It is important to note that the logs do not indicate when a SAS token was generated [How a shared access signature works]. However, their usage can be inferred by tracking configuration changes that enable the use of storage account keys option which is disabled by default.

Figure 1: Configuration setting to enable account key access

Query: This query is designed to detect configuration changes made to enable access via storage account keys

AzureActivity | where OperationNameValue has "MICROSOFT.STORAGE/STORAGEACCOUNTS/WRITE" | where ActivityStatusValue has "Success" | extend allowSharedKeyAccess = parse_json(tostring(parse_json(tostring(parse_json(Properties).responseBody)).properties)).allowSharedKeyAccess | where allowSharedKeyAccess == "true"

User delegated Shared Access Signature

A User Delegation SAS is a type of SAS token that is secured using Microsoft Entra ID credentials rather than the storage account key.

For more details see Authorize a user delegation SAS. To request a SAS token using the user delegation key, the identity must possess the  Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey  action (see Assign permissions with RBAC).

Azure Role-Based Access Control

A threat actor must identify a target (an identity) that can assign roles or already holds specific RBAC roles.

To assign Azure RBAC roles, an identity must have Microsoft.Authorization/roleAssignments/write, which allows the assignment of roles necessary for accessing storage accounts.

Some examples of roles that provide permissions to access data within Storage Account (see Azure built-in roles for blob):

Storage Account Contributor (Read, Write, Manage Access)

Storage Blob Data Contributor (Read, Write)

Storage Blob Data Owner (Read, Write, Manage Access)

Storage Blob Data Reader (Read Only)

Additionally, to access blob data in the Azure portal, a user must also be assigned the Reader role (see Assign an Azure role). More information about Azure built-in roles for a Storage Account can be found here Azure built-in roles for Storage.

Anonymous Access

If the storage account configuration 'Allow Blob anonymous access' is set to enabled and a container is created with anonymous read access, a threat actor could access the storage contents from the internet without any authorization.

Figure 2: Configuration settings for Blob anonymous access and container-level anonymous access.

Query: This query helps identify successful configuration changes to enable anonymous access

AzureActivity | join kind=rightouter (AzureActivity | where TimeGenerated > ago(30d) | where OperationNameValue has "MICROSOFT.STORAGE/STORAGEACCOUNTS/WRITE" | where Properties has "allowBlobPublicAccess" | extend ProperTies = parse_json(Properties) | evaluate bag_unpack(ProperTies) | extend allowBlobPublicAccess = todynamic(requestbody).properties["allowBlobPublicAccess"] | where allowBlobPublicAccess has "true" | summarize by CorrelationId) on CorrelationId | extend ProperTies = parse_json(Properties) | evaluate bag_unpack(ProperTies) | extend allowBlobPublicAccess_req = todynamic(requestbody).properties["allowBlobPublicAccess"] | extend allowBlobPublicAccess_res = todynamic(responseBody).properties["allowBlobPublicAccess"] | extend allowBlobPublicAccess = case (allowBlobPublicAccess_req!="", allowBlobPublicAccess_req, allowBlobPublicAccess_res!="", allowBlobPublicAccess_res, "") | project OperationNameValue, ActivityStatusValue, ResourceGroup, allowBlobPublicAccess, Caller, CallerIpAddress, ResourceProviderValue

Key notes regarding the authentication methods

When a user accesses Azure Blob Storage via the Azure portal, the interaction is authenticated using OAuth and is authorized by the Azure RBAC roles configuration for the given user. In contrast, authentication using Azure Storage Explorer and AzCopy depends on the method used:

If a user interactively signs in via the Azure portal or utilizes the Device code flow, authentication appears as OAuth based.

When using a SAS token, authentication is recorded as SAS-based for both tools.

Access via Azure RBAC is logged in Entra ID Sign-in Logs, however, activity related to SAS token usage does not appear in the sign-in logs, as it provides pre-authorized access. Log analysis should consider all operations, since initial actions can reveal the true authentication method even OAuth-based access may show as SAS in logs.

The screenshot below illustrates three distinct cases, each showcasing different patterns of authentication types used when accessing storage resources.

A SAS token is consistently used across various operations, where the SAS token is the primary access method.
The example below highlighted as ‘2’ demonstrates a similar pattern, with OAuth (using assigned Azure RBAC role) serving as the primary authentication method for all listed operations.
Lastly, example number ‘3’, Operations start with OAuth authentication (using an assigned Azure RBAC role for authorization) and then uses a SAS token, indicating mixed authentication types.

Figure 3: Different patterns of authentication types

Additionally, when using certain applications such as Azure Storage Explorer with Account Access Keys authentication, the initial operations such as ListContainers and ListBlob are logged with the authentication type reported as “AccountKey”. However, for subsequent actions like file uploads or downloads, the authentication type switches to SAS in the logs.

To accurately determine whether an Account Access Keys or SAS was used, it's important to correlate these actions with the earlier enumeration or sync activity within the logs.

With this understanding, let’s proceed to analyze specific attack scenarios by utilizing the log analytics, such as the StorageBlobLogs table.

Attack scenario

This section will examine the typical steps that a threat actor might take when targeting a Storage Account. We will specifically focus on the Azure Resource Manager layer, where Azure RBAC initially dictates what a threat actor can discover.

Enumeration

During enumeration, a threat actor’s goal is to map out the available storage accounts. The range of this discovery is decided by the access privileges of a compromised identity. If that identity holds at least a minimum level of access (similar to a Reader) at the subscription level, it can view storage account resources without making any modifications. Importantly, this permission level does not grant access to the actual data stored within the Azure Storage itself. Hence, a threat actor is limited to interacting only with those storage accounts that are visible to them.

To access and download files from Blob Storage, a threat actor must be aware of the names of containers (Operation: ListContainers) and the files within those containers (Operation: ListBlobs). All interactions with these storage elements are recorded in the StorageBlobLogs table.

Containers or blobs in a container can be listed by a threat actor with the appropriate access rights. If access is not authorized, attempts to do so will result in error codes shown in the StatusCode field. A high number of unauthorized attempts resulting in errors would be a key indicator of suspicious activity or misconfiguration.

Figure 4: Failure attempts to list blobs/containers

Query: This query serves as a starting point for detecting a spike in unauthorized attempts to enumerate containers, blobs, files, or queues

union Storage* | extend StatusCodeLong = tolong(StatusCode) | where OperationName has_any ("ListBlobs", "ListContainers", "ListFiles", "ListQueues") | summarize MinTime = min(TimeGenerated), MaxTime = max(TimeGenerated), OperationCount = count(), UnauthorizedAccess = countif(StatusCodeLong >= 400), OperationNames = make_set(OperationName), ErrorStatusCodes = make_set_if(StatusCode, StatusCodeLong >= 400), StorageAccountName = make_set(AccountName) by CallerIpAddress | where UnauthorizedAccess > 0

Note: The UnauthorizedAccess filter attribute must be adjusted based on your environment. 

Data exfiltration

Let’s use the StorageBlobLogs to analyze two different attack scenarios.

Scenario 1: Compromised user has access to a storage account

In this scenario, the threat actor either compromises a user account with access to one or more storage accounts or alternatively, obtains a leaked Account Access Key or SAS token. With a compromised identity, the threat actor can either enumerate all storage accounts the user has permissions to (as covered in enumeration) or directly access a specific blob or container if the leaked key grants scoped access.

Account Access Keys (AccountKey)/SAS tokens

The threat actor might either use the storage account’s access keys or SAS token retrieved through the compromised user account provided they have the appropriate permissions or the leaked key itself may already be either an Account access key or SAS token. Access keys grant complete control while SAS key can generate a time-bound access, to authorize data transfers enabling them to view, upload, or download data at will.

Figure 5: Account key used to download/view data

Figure 6: SAS token used to download/view data

Query: This query helps identify cases where an AccountKey/SAS was used to download/view data from a storage account

StorageBlobLogs | where OperationName has "GetBlob" | where AuthenticationType in~ ("AccountKey", "SAS") | where StatusText in~ ("Success", "AnonymousSuccess", "SASSuccess") | project TimeGenerated, AccountName, OperationName, RequesterUpn, AuthenticationType, Uri, ObjectKey, StatusText, UserAgentHeader, CallerIpAddress, AuthenticationHash

User Delegation SAS

Available for Blob Storage only, a User Delegation SAS functions similar to a SAS but is protected with Microsoft Entra ID credentials rather than the storage account key.

The creation of a User Delegation SAS is tracked as a corresponding "GetUserDelegationKey" log entry in StorageBlobLogs table.

Figure 7: User-Delegation Key created

Query: This query helps identify creation of a User-Delegation Key. The RequesterUpn provides the identity of the user account creating this key.

StorageBlobLogs | where OperationName has "GetUserDelegationKey" | where StatusText in~ ("Success", "AnonymousSuccess", "SASSuccess") | project TimeGenerated, AccountName, OperationName, RequesterUpn, Uri, CallerIpAddress, ObjectKey, AuthenticationType, StatusCode, StatusText

Figure 8: User-Delegation activity to download/read

Query: This query helps identify cases where a download/read action was initiated while authenticated via a User delegation key

StorageBlobLogs | where AuthenticationType has "DelegationSas" | where OperationName has "GetBlob" | where StatusText in~ ("Success", "AnonymousSuccess", "SASSuccess") | project Type, TimeGenerated, OperationName, AccountName, UserAgentHeader, ObjectKey, AuthenticationType, StatusCode, CallerIpAddress, Uri

The operation "GetUserDelegationKey" within the StorageBlobLogs captures the identity responsible for generating a User Delegation SAS token. The AuthenticationHash field shows the Key used to sign the SAS token.

When the SAS token is used, any operations will include the same SAS signature hash enabling you to correlate various actions performed using this token even if the originating IP addresses differ.

Query: The following query extracts a SAS signature hash from the AuthenticationHash field. This helps to track the token's usage, providing an audit trail to identify potentially malicious activity.

StorageBlobLogs | where AuthenticationType has "DelegationSas" | extend SasSHASignature = extract(@"SasSignature$(.*?)$", 1, AuthenticationHash) | project Type, TimeGenerated, OperationName, AccountName, UserAgentHeader, ObjectKey, AuthenticationType, StatusCode, CallerIpAddress

In the next scenario, we examine how a threat actor already in control of a compromised identity uses Azure RBAC to assign permissions. With administrative privileges over a storage account, the threat actor can grant access to additional accounts and establish long-term access to the storage accounts.

Scenario 2: A user account is controlled by the threat actor and has elevated access to the Storage Account

An identity named Bob was identified as compromised due to an unauthorized IP login.

The investigation triggers when Azure Sign-in logs reveal logins originating from an unexpected location. This account has owner permissions for a resource group, allowing full access and role assignments in Azure RBAC. The threat actor grants access to another account they control, as shown in the AzureActivity logs.

The AzureActivity logs in the figure below show that Reader, Data Access, and Storage Account Contributor roles were assigned to Hacker2 for a Storage Account within Azure:

Figure 9: Assigning a role to a user

Query: This query helps identify if a role has been assigned to a user

AzureActivity | where Caller has "Bob" | where OperationNameValue has "MICROSOFT.AUTHORIZATION/ROLEASSIGNMENTS/WRITE" | extend RoleDefintionIDProperties = parse_json(Properties) | evaluate bag_unpack(RoleDefintionIDProperties) | extend RoleDefinitionIdExtracted = tostring(todynamic(requestbody).Properties.RoleDefinitionId) | extend RoleDefinitionIdExtracted = extract(@"roleDefinitions/([a-f0-9-]+)", 1, RoleDefinitionIdExtracted) | extend RequestedRole = case( RoleDefinitionIdExtracted == "ba92f5b4-2d11-453d-a403-e96b0029c9fe", "Storage Blob Data Contributor", RoleDefinitionIdExtracted == "b7e6dc6d-f1e8-4753-8033-0f276bb0955b", "Storage Blob Data Owner", RoleDefinitionIdExtracted == "2a2b9908-6ea1-4ae2-8e65-a410df84e7d1", "Storage Blob Data Reader", RoleDefinitionIdExtracted == "db58b8e5-c6ad-4a2a-8342-4190687cbf4a", "Storage Blob Delegator", RoleDefinitionIdExtracted == "c12c1c16-33a1-487b-954d-41c89c60f349", "Reader and Data Access", RoleDefinitionIdExtracted == "17d1049b-9a84-46fb-8f53-869881c3d3ab","Storage Account Contributor", "") | extend roleAssignmentScope = tostring(todynamic(Authorization_d).evidence.roleAssignmentScope) | extend AuthorizedFor = tostring(todynamic(requestbody).Properties.PrincipalId) | extend AuthorizedType = tostring(todynamic(requestbody).Properties.PrincipalType) | project TimeGenerated, RequestedRole, roleAssignmentScope, ActivityStatusValue, Caller, CallerIpAddress, CategoryValue, ResourceProviderValue, AuthorizedFor, AuthorizedType

Note: Refer to this resource for additional Azure in-built role IDs that can be used in this query.

The Sign-in logs indicate that Hacker2 successfully accessed Azure from the same malicious IP address.

We can examine StorageBlobLogs to determine if the user accessed data of the blob storage since specific roles related to the Storage Account were assigned to them.

The activities within the blob storage indicate several entries attributed to the Hacker2 user, as shown in the figure below.

Figure 10: User access to blob storage

Query: This query helps identify access to blob storage from a malicious IP

StorageBlobLogs | where TimeGenerated > ago (30d) | where CallerIpAddress has {{IPv4}} | extend ObjectName= ObjectKey | project TimeGenerated, AccountName, OperationName, AuthenticationType, StatusCode, StatusText, RequesterUpn, CallerIpAddress, UserAgentHeader, ObjectName, Category

An analysis of the StorageBlobLogs, as shown in the figure below, reveals that Hacker2 performed a "StorageRead" operation on three files. This indicates that data was accessed or downloaded from blob storage.

Figure 11: Blob Storage Read/Download activities

The UserAgentHeader suggests that the storage account was accessed through the Azure portal. Consequently, the SignInLogs can offer further detailed information.

Query: This query checks for read, write, or delete operations in blob storage and their access methods,

StorageBlobLogs | where TimeGenerated > ago(30d) | where CallerIpAddress has {{IPv4}} | where OperationName has_any ("PutBlob", "GetBlob", "DeleteBlob") and StatusText == "Success" | extend Notes = case( OperationName == "PutBlob" and Category == "StorageWrite" and UserAgentHeader has "Microsoft Azure Storage Explorer", "Blob was written through Azure Storage Explorer", OperationName == "PutBlob" and Category == "StorageWrite" and UserAgentHeader has "AzCopy", "Blob was written through AzCopy Command", OperationName == "PutBlob" and Category == "StorageWrite" and not(UserAgentHeader has_any("AzCopy","Microsoft Azure Storage Explorer")), "Blob was written through Azure portal", OperationName == "GetBlob" and Category == "StorageRead" and UserAgentHeader has "Microsoft Azure Storage Explorer", "Blob was Read/Download through Azure Storage Explorer", OperationName == "GetBlob" and Category == "StorageRead" and UserAgentHeader has "AzCopy", "Blob was Read/Download through AzCopy Command", OperationName == "GetBlob" and Category == "StorageRead" and not(UserAgentHeader has_any("AzCopy","Microsoft Azure Storage Explorer")), "Blob was Read/Download through Azure portal", OperationName == "DeleteBlob" and Category == "StorageDelete" and UserAgentHeader has "Microsoft Azure Storage Explorer", "Blob was deleted through Azure Storage Explorer", OperationName == "DeleteBlob" and Category == "StorageDelete" and UserAgentHeader has "AzCopy", "Blob was deleted through AzCopy Command", OperationName == "DeleteBlob" and Category == "StorageDelete" and not(UserAgentHeader has_any("AzCopy","Microsoft Azure Storage Explorer")), "Blob was deleted through Azure portal","") | project TimeGenerated, AccountName, OperationName, AuthenticationType, StatusCode, CallerIpAddress, ObjectName=ObjectKey, Category, RequesterUpn, Notes

The log analysis confirms that the threat actor successfully extracted data from a storage account.

Storage Account summary

Detecting misuse within a Storage Account can be challenging, as routine operations may hide malicious activities. However, enabling logging is essential for investigation to help track accesses, especially when compromised identities or misused SAS tokens or keys are involved.

Unusual changes in user permissions and irregularities in role assignments which are documented in the Azure Activity Logs, can signal unauthorized access, while Microsoft Entra ID sign-in logs can help identify compromised UPNs and suspicious IP addresses that ties into OAuth-based storage account access. By thoroughly analyzing Storage Account logs which details operation types and access methods, investigators can identify abuse and determine the scope of compromise. That not only helps when remediating the environment but can also provide guidance on preventing unauthorized data theft from occurring again.

Post-breach browser abuse: a new frontier for threat actors

Jonathan Bar Or (JBO) — Mon, 25 Aug 2025 17:22:36 GMT

Co-authors - Raae Wolfram | Sam Gardener

Once an attacker has gained access to a system, the browser becomes a rich source of credentials, a platform for persistence, and a stealthy channel for data exfiltration. This blog outlines key abuse techniques and provides actionable detection strategies using Microsoft Defender for Endpoint and Microsoft Defender XDR.

Why browsers matter after the breach

Post-compromise, browsers offer attackers:

Access to credentials (cookies, tokens, autofill data)

Control over peripherals (camera, microphone, location)

A trusted execution environment for evasion

A platform for persistence via extensions or debugging interfaces

These capabilities make browsers a high-value target even after initial access has been achieved.

Key abuse techniques and detection strategies

1. Credential theft via memory scraping

Attackers can extract sensitive data directly from browser memory using tools like Mimikittenz. Security team members can proactively hunt for threats with advanced hunting in Microsoft Defender.

Advanced hunting detection query:

let PROCESS_VM_READ=0x0010;

DeviceEvents

| where ActionType == "OpenProcessApiCall"

    and FileName in~ ("chrome.exe", "msedge.exe", "firefox.exe", "brave.exe", "opera.exe")

| project FileName, InitiatingProcessFileName,

DesiredAccess=tolong(parse_json(AdditionalFields).DesiredAccess)

| where binary_and(DesiredAccess, PROCESS_VM_READ) != 0

Learn more at about hunting queries: Overview - Advanced hunting - Microsoft Defender XDR | Microsoft Learn

2. TLS key logging for passive credential capture

Setting the SSLKEYLOGFILE environment variable allows attackers to dump TLS pre-master secrets, enabling decryption of HTTPS traffic.

Detection query:

DeviceRegistryEvents

| where RegistryKey =~ @"SYSTEM\CurrentControlSet\Control\Session Manager\Environment"

    and RegistryValueName =~ "SSLKEYLOGFILE"

3. Remote debugging port abuse

Chromium-based browsers support remote debugging via WebSocket. Attackers can launch browsers with flags like --remote-debugging-port and control them programmatically.

Detection queries:

DeviceProcessEvents

| where FileName in~ ("chrome.exe", "msedge.exe", "brave.exe", "opera.exe")

    and ProcessCommandLine contains "--remote"

DeviceNetworkEvents

| where RemotePort in (9222, 9223, 9229)

| where RemoteIP == "127.0.0.1"

| where InitiatingProcessFileName !in~ ("chrome.exe", "msedge.exe", "brave.exe", "opera.exe")

DeviceProcessEvents

| where FileName has_any ("chrome", "msedge", "brave", "opera")

    and ProcessCommandLine contains "--remote"

4. Persistence via malicious extensions

Attackers can sideload or auto-update malicious extensions using enterprise policies or developer mode.

Detection queries:

DeviceProcessEvents

| where ProcessCommandLine has "--load-extension"

| where FileName in~ ("chrome.exe", "msedge.exe")

DeviceRegistryEvents

| where RegistryKey has "ExtensionInstallForcelist"

| where RegistryValueData has_any ("http", "crx")

5. Anomalous child process spawning

Unexpected child processes from browsers may indicate injection, persistence, or evasion.

Detection query:

DeviceProcessEvents

| where InitiatingProcessFileName in~ ("chrome.exe", "msedge.exe", "firefox.exe", “brave.exe”, “opera.exe”)

| where FileName !in~ ("chrome.exe", "msedge.exe", "firefox.exe")

Recommendations for defenders:

Monitor for debugging flags in browser launch commands.
Alert on unexpected registry or file modifications related to extensions.
Track environment variable usage that affects browser behavior.
Investigate RWX memory pages in browser processes.
Use Defender for Endpoint to correlate these signals with broader attack chains.

Conclusion

Post-breach browser abuse is a growing concern that blends stealth, persistence, and credential access into a single threat vector. By understanding these techniques and implementing the detection strategies outlined above, defenders can close a critical visibility gap and better protect their environments.

See what our experts have to say. Watch the recorded webinar, download the presentation - and learn more about - Post-Breach Browsers: The Hidden Threat You’re Overlooking.

Welcome to the Microsoft Defender Experts Ninja Hub!

henryyan — Mon, 18 Aug 2025 15:56:51 GMT

Updated August 11, 2025

Microsoft Defender Experts for XDR

Microsoft Defender Experts for XDR is a managed extended detection and response (MXDR) service that triages, investigates, and responds to incidents for you to help stop cyberattackers and prevent future compromise. Defender Experts for XDR delivers human expertise to security teams quickly to help address coverage gaps and augment their overall security operations. The documentation links below provide more information on the service, requirements, and FAQs:

Microsoft Defender Experts for Hunting

Microsoft Defender Experts for Hunting , which is included with Defender Experts for XDR or offered separately, proactively looks for threats 24/7/365 using unparalleled visibility of cross-domain telemetry and leading threat intelligence to extend your team’s threat hunting capabilities and improve overall SOC response. The documentation links below provide more information on the service, requirements, and reporting:

Ninja Show episodes featuring Defender Experts

Season 7, Episode 8: Day in the life of a SOC analyst
Season 5, Episode 5: Improve your security posture with Microsoft Defender Experts for XDR
Season 3, Episode 4: Defender Experts for Hunting Overview

On-demand event sessions and webinars featuring Defender Experts

RSAC 2025 (NEW): Bolser your SOC with Microsoft's Managed Extended Detection and Response (MXDR)
Webinar: MDR and Generative AI: Better Together - A conversation with guest speaker Jeff Pollard

Defender Experts videos

Explainer Video: Microsoft Defender Experts for XDR
Explainer Video (NEW): Microsoft Defender Experts for Hunting
Video: Adversary in the Middle Hunting Story
Video: Get started with onboarding | Microsoft Defender Experts for XDR
Video: Get started with managed response | Microsoft Defender Experts for XDR
Video: Get started with reporting | Microsoft Defender Experts for XDR

Deep dives from the Microsoft Security blog featuring Defender Experts

Podcasts

Microsoft Security Insights Show Episode 218: Michael Melone
Microsoft Security insights Show Episode 198: Raae Wolfram
Microsoft Security Insights Show Episode 181: Brian Hooper and Phoebe Rogers: A day in the life of a Defender Experts for XDR analyst
Microsoft Security Insights Show Episode 168: Steve Lee, Defender Experts

To learn more about Defender Experts, click here.

How Microsoft Defender Experts uses AI to cut through the noise

ShailyGoel — Thu, 14 Aug 2025 17:33:20 GMT

Microsoft Defender Experts manages and investigates incidents for some of the world’s largest organizations. We understand the challenges facing our customers and are always looking for ways to respond quicker and scale our services to meet their needs.

Teaching AI to think like a security expert

We're leveraging AI to help Defender Experts expand our services and respond even faster to threats facing our customers.

AI-based incident classification allows us to filter noise up front without compromising on detecting real threats. This AI-based capability is trained by security experts, built for precision, and designed to scale and act at speed.

Our approach doesn't just rely on static rules or traditional filtering. Instead, our AI is powered by insights from hundreds of thousands of real investigations conducted by Defender Experts security analysts. These investigations form a goldmine of expert knowledge—how analysts think, what signals they trust, and how they separate benign and false positives from true threats.

We use historical intelligence to evaluate each new incident. AI-based incident classification looks at various signals, such as evidence, tenant details, context from IOCs, and TI information. It assigns a similarity score based on those signals. By using a similarity algorithm, the AI-based system compares each new incident to known outcomes from the past—deciding whether it closely resembles true positives, false positives, or is benign. At a certain threshold, it confidently assigns the grade.

If the pattern matches past false positives, the system de-grades the incident as noise. If the pattern looks similar to a known higher-risk threat, it escalates it faster. This helps us focus first on what matters most— true, actionable threats, which results in quicker response times for our customers.

Human-centric and safe

We know that trust is everything in cybersecurity. So even though AI helps us filter noise, we've built guardrails to make sure no real threats are missed:

Tiered decisioning: Incidents that are classified as noise are reviewed by Defender Expert analysts to ensure they match the classification and other criteria for noise.

Feedback loops: For continuous learning, anything classified as noise is sent to an analyst for validation so that there are no accidental misses of true threats. The feedback from them continuously improves the system.

Transparency: classification decisions are visible, helping analysts understand why something is marked as noise or not.

This approach strikes the right balance. AI does the heavy lifting up front, and our human security experts remain firmly in control of what is investigated.

Quicker response for our customers

AI-based incident classification in Defender Experts:

50% of noise is automatically triaged by AI-based incident classification with 100% precision

Our experts respond faster to meaningful threats to our customer’s environment.

“We no longer waste time chasing dead ends. The system helps us focus on what truly matters and our customers appreciate how quickly we can respond.” — Defender Experts Tier2 Analyst

What’s next?

We’re continuing to refine this system with more granular risk scoring per entity, deeper tenant-based similarity correlation, IOC based weightage, and additional real-time feedback from Defender Experts analysts.

Final thoughts

AI alone isn’t the answer—but AI guided by experts is a force multiplier. With AI-based incident classification, Defender Experts is showing what the future of SOCs can look like: faster, smarter, safer, and scalable.

AI-based classification has helped reduce 50% of the noise from the analyst queue with 100% accuracy, saving analyst time so they can focus on what matters most.

If you're a Defender Experts customer, you’re already seeing the benefit of quicker response times to true security threats.

If you're a security leader struggling with alert overload, Microsoft Defender Experts for XDR, Microsoft’s MXDR (managed extended detection and response) service, can deliver around the clock, expert-led protection.

For more information, please visit Microsoft Defender Experts for XDR | Microsoft Security