Elevate your protection with expanded Microsoft Defender Experts coverage
Co-authors: Henry Yan, Sr. Product Marketing Manager and Sylvie Liu, Principal Product Manager Update (5/20): Microsoft Defender Experts for Servers is now available as a standalone SKU, with a new onboarding experience within Microsoft Defender. Visit our documentation to get started with Defender Experts for Servers. Security Operations Centers (SOCs) are under extreme pressure due to a rapidly evolving threat landscape, an increase in volume and frequency of attacks driven by AI, and a widening skills gap. To address these challenges, organizations across industries are relying on Microsoft Defender Experts for XDR and Microsoft Defender Experts for Hunting to bolster their SOC and stay ahead of emerging threats. We are committed to continuously enhancing Microsoft Defender Experts services to help our customers safeguard their organizations and focus on what matters most. We are excited to announce the general availability of expanded Defender Experts coverage. With this update, Defender Experts for XDR and Defender Experts for Hunting now deliver around the clock protection and proactive threat hunting for your cloud workloads, starting with hybrid and multicloud servers in Microsoft Defender for Cloud. Additionally, third-party network signals from Palo Alto Networks, Zscaler, and Fortinet can now be used for incident enrichment in Defender Experts for XDR, enabling faster and more accurate detection and response. Extend 24/7, expert-led defense and threat hunting to your hybrid and multicloud servers As cloud adoption accelerates, the sophistication and frequency of cloud attacks are on the rise. According to IDC, in 2024, organizations experienced an average of more than nine cloud security incidents, with 89% reporting an increase year over year. Furthermore, cloud security is the leading skills gap with almost 40% of respondents in the O’Reilly 2024 State of Security Survey identifying it as the top area in need of skilled professionals. Virtual machines (VMs) are the backbone of cloud infrastructure, used to run critical applications with sensitive data while offering flexibility, efficiency, and scalability. This makes them attractive targets for attackers as compromised VMs can be used to potentially carry out malicious activities such as data exfiltration, lateral movement, and resource exploitation. Defender Experts for XDR now delivers 24/7, expert-led managed extended detection and response (MXDR) for your hybrid and multicloud servers in Defender for Cloud. Our security analysts will investigate, triage, and respond to alerts on your on-premises and cloud VMs across Microsoft Azure, Amazon Web Services, and Google Cloud Platform. With Defender Experts for Hunting, which is included in Defender Experts for XDR and also available as a standalone service, our expert threat hunters will now be able to hunt across hybrid and multicloud servers in addition to endpoints, identities, emails, and cloud apps, reducing blind spots and uncovering emerging cloud threats. Figure 1: Incidents from servers in Defender for Cloud investigated by Defender Experts Incident enrichment for improved detection accuracy and faster response By enriching Defender incidents with third-party network signals from Palo Alto Networks (PAN-OS Firewall), Zscaler (Zscaler Internet Access and Zscaler Private Access), and Fortinet (FortiGate Next-Generation Firewall), our security analysts gain deeper insights into attack paths. The additional context helps Defender Experts for XDR identify patterns and connections across domains, enabling more accurate detection and faster response to threats. Figure 2: Third-party enrichment data in Defender Experts for XDR report In this hypothetical scenario, we explore how incident enrichment with third-party network signals helped Defender Experts for XDR uncover lateral movement and potential data exfiltration attempts. Detection: Microsoft Defender for Identity flagged an "Atypical Travel" alert for User A, showing sign-ins from India and Germany within a short timeframe using different devices and IPs, suggesting possible credential compromise or session hijacking. However, initial identity and cloud reviews showed no signs of malicious activity. Correlation: From incident enrichment with third-party network signals, Palo Alto firewall logs revealed attempts to access unauthorized remote tools, while Zscaler proxy data showed encrypted traffic to an unprotected legacy SharePoint server. Investigation: Our security analysts uncovered that the attacker authenticated from a managed mobile device in Germany. Due to token reuse and a misconfigured Mobile Device Management profile, the device passed posture checks and bypassed Conditional Access, enabling access to internal SharePoint. Insights from third-party network signals helped Defender Experts for XDR confirm lateral movement and potential data exfiltration. Response: Once malicious access was confirmed, Defender Experts for XDR initiated a coordinated response, revoking active tokens, isolating affected devices, and hardening mobile policies to enforce Conditional Access. Flexible, cost-effective pricing Defender Experts coverage of servers in Defender for Cloud is priced per server per month, with charges based on the total number of server hours each month. You have the flexibility to scale your servers as needed while ensuring cost effectiveness as you only pay for Defender Experts coverage based on resources you use. For example, if you have a total of 4000 hours across all servers protected by Defender for Cloud in June (June has a total of 720 hours), you will be charged for a total of 5.56 servers in June (4000/720 = 5.56). There is no additional charge for third-party network signal enrichment beyond the data ingestion charge through Microsoft Sentinel. Please contact your Microsoft account representative for more information on pricing. Get started today Defender Experts coverage of servers in Defender for Cloud will be available as an add-on to Defender Experts for XDR and Defender Experts for Hunting. To enable coverage, you must have the following: Defender Experts for XDR or Defender Experts for Hunting license Defender for Servers Plan 1 or Plan 2 in Defender for Cloud You only need a minimum of 1 Defender Experts for XDR or Defender Experts for Hunting license to enable coverage of all your servers in Defender for Cloud. If you are interested in purchasing Defender Experts for XDR or the add-on for Defender Experts coverage of servers in Defender for Cloud, please complete this interest form. Third-party network signals for enrichment are available only for Defender Experts for XDR customers. To enable third-party network signals for enrichment, you must have the following: Microsoft Sentinel instance deployed Microsoft Sentinel onboarded to Microsoft Defender portal At least one of the supported network signals ingested through Sentinel built-in connectors: Palo Alto Networks (PAN-OS Firewall) Zscaler (Zscaler Internet Access and Zscaler Private Access) Fortinet (FortiGate Next-Generation Firewall) If you are an existing Defender Experts for XDR customer and are interested in enabling third-party network signals for enrichment, please reach out to your Service Delivery Manager. Learn more Technical Documentation Microsoft Defender Experts for XDR Microsoft Defender Experts for Hunting Third-party network signals for enrichment Plan Defender for Servers deployment Defender Experts Ninja TrainingEDR coexistence by design: A practical starting point to Defender
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-sideMicrosoft Defender Experts - S.T.A.R. Series
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 SecurityWhen Trust Becomes the Attack Vector: Analysis of the EmEditor Supply-Chain Compromise
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.
Microsoft Defender Experts Disrupt Jasper Sleet’s Insider Access Campaign
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. 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 JamodkarCharting the Future of SOC: Human and AI Collaboration for Better Security
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.
Cloud forensics: Why enabling Microsoft Azure Key Vault logs matters
Co-authors - Christoph Dreymann - Abul Azed - Shiva P. Introduction As organizations increase their cloud adoption to accelerate AI readiness, Microsoft Incident Response has observed the rise of cloud-based threats as attackers seek to access sensitive data and exploit vulnerabilities stemming from misconfigurations often caused by rapid deployments. In this blog series, Cloud Forensics, we share insights from our frontline investigations to help organizations better understand the evolving threat landscape and implement effective strategies to protect their cloud environments. This blog post explores the importance of enabling and analyzing Microsoft Azure Key Vault logs in the context of security investigations. Microsoft Incident Response has observed cases where threat actors specifically targeted Key Vault instances. In the absence of proper logging, conducting thorough investigations becomes significantly more difficult. Given the highly sensitive nature of the data stored in Key Vault, it is a common target for malicious activity. Moreover, attacks against this service often leave minimal forensic evidence when verbose logging is not properly configured during deployment. We will walk through realistic attack scenarios, illustrating how these threats manifest in log data and highlighting the value of enabling comprehensive logging for detection. Key Vault Key Vault is a cloud service designed for secure storage and retrieval of critical secrets such as passwords or database connection strings. In addition to secrets, it can store other information such as certificates and cryptographic keys. To ensure effective monitoring of activities performed on a specific instance of Key Vault, it is essential to enable logging. When audit logging is not enabled, and there is a security breach, it is often difficult to ascertain which secrets were accessed without comprehensive logs. Given the importance of the assets protected by Key Vault, it is imperative to enable logging during the deployment phase. How to enable logging Logging must be enabled separately for each Key Vault instance either in the Microsoft Azure portal, Azure command-line interface (CLI) or Azure PowerShell. How to enable logging can be found here. Alternatively, it can be configured within the default log analytics workspace as an Azure Policy. How to use this method can be found here. By directing these logs to a Log Analytics workspace, storage account, or event hub for security information and event management (SIEM) ingestion, they can be utilized for threat detection and, more importantly, to ascertain when an identity was compromised and which type of sensitive information was accessed through that compromised identity. Without this logging, it is difficult to confirm whether any material has been accessed and therefore may need to be treated as compromised. NOTE: There are no license requirements to enable logging within Key Vault, but Log Analytics charges based on ingestion and retention for usage of that service (Pricing - Azure Monitor | Microsoft Azure) Next, we will review the structure of the Audit Logs originating from the Key Vault instance. These logs are located in the AzureDiagnostics table. Interesting fields Below is a good starting query to begin investigating activity performed against a Key Vault instance: AzureDiagnostics | where ResourceType == 'VAULTS' The "operationName" field is of particular significance as it indicates the type of operation that took place. An overview of Key Vault operations can be found here. The "Identity" field includes details about the identity responsible for an activity, such as the object identifier and UPN. Lastly, the “callerIpAddress” shows which IP address the requests originate from. The table below displays the fields highlighted and used in this article. Field name Description time Date and time in UTC. resourceId The Key Vault resource ID uniquely identifies a Key Vault in Azure and is used for various operations and configurations. callerIpAddress IP address of the client that made the request. Identity The identity structure includes various information. The identity can be a "user," a "service principal," or a combination such as "user+appId" when the request originates from an Azure PowerShell cmdlet. Different fields are available based on this. The most important ones are: identity_claim_upn_s: Specifies the upn of a user identity_claim_appid_g: Contains the appid identity_claim_idtyp_s: Shows what type of identity was used OperationName The name of the operation, for instance SecretGet Resource Key Vault Name ResourceType Always “VAULTS” requestUri_s The requested Key Vault API call contains valuable information. Each API call has its own structure. For example, the SecretGet request URI is: {vaultBaseUrl}/secrets/{secret-name}/{secret-version}?api-version=7.4. For more information, please see: https://learn.microsoft.com/en-us/rest/api/keyvault/?view=rest-keyvault-keys-7.4 httpStatusCode_d Indicates if an API call was successful A complete list of fields can be found here. To analyze further, we need to understand how a threat actor can access a Key Vault by examining the Access Policy and Azure role-based access control (RBAC) permission model used within it. Access Policy permission model vs Azure RBAC The Access Policy Permission Model operates solely on the data plane, specifically for Azure Key Vault. The data plane is the access pathway for creating, reading, updating, and deleting assets stored within the Key Vault instance. Via a Key Vault Access Policy, you can assign individual permissions and grant access to security principals such as users, groups, service principals, and managed identities, at the Key Vault scope with appropriate Control Plane privileges. This model provides flexibility by granting access to keys, secrets, and certificates through specific permissions. However, it is considered a legacy authorization system native to Key Vault. Note: The Access Policies permission model has privilege escalation risks and lacks Privileged Identity Management support. It is not recommended for critical data and workloads. On the other hand, Azure RBAC operates on both Azure's control and data planes. It is built on Azure Resource Manager, allowing for centralized access management of Azure resources. Azure RBAC controls access by creating role assignments, which consist of a security principal, a role definition (predefined set of permissions), and a scope (a group of resources or an individual resource). RBAC offers several advantages, including a unified access control model for Azure resources and integration with Privileged Identity Management. More information regarding Azure RBAC can be found here. Now, let’s dive into how threat actors can gain access to a Key Vault. How a threat actor can access a Key Vault When a Key Vault is configured with Access Policy permission, privileges can be escalated under certain circumstances. If a threat actor gains access to an identity that has been assigned the Key Vault Contributor Azure RBAC role, Contributor role or any role that includes 'Microsoft.KeyVault/vaults/write' permissions, they can escalate their privileges by setting a Key Vault access policy to grant themselves data plane access, which in turn allows them to read and modify the contents of the Key Vault. Modifying the permission model requires 'Microsoft.Authorization/roleAssignments/write' permission, which is included in the Owner and User Access Administrator roles. Therefore, a threat actor cannot change the permission model without one of these roles. Any change to the authorization mode will be logged in the Activity Logs of the subscription, as shown in the figure below: If a new Access Policy is added, it will generate the following entry within the Azure Activity Log: When Azure RBAC is the permissions model for a Key Vault, a threat actor must identify an identity within the Entra ID tenant that has access to sensitive information or one capable of assigning such permissions. Information about Azure RBAC roles for Key Vault access, specifically those who can access Secrets, can be found here. A threat actor that has compromised an identity with an Owner role is authorized to manage all operations, including resources, access policies, and roles within the Key Vault. In contrast, a threat actor with a Contributor role can handle management operations but does not have access to keys, secrets, or certificates. This restriction applies when the RBAC model is used within a Key Vault. The following section will examine the typical actions performed by a threat actor after gathering permissions. Attack scenario Let's review the common steps threat actors take after gaining initial access to Microsoft Azure. We will focus on the Azure Resource Manager layer (responsible for deploying and managing resources), as its Azure RBAC or Access Policy permissions determine what a threat actor can view or access within Key Vault(s). Enumeration Initially, threat actors aim to understand the existing organizations' attack surface. As such, all Azure resources will be enumerated. The scope of this enumeration is determined by the access rights held by the compromised identity. If the compromised identity possesses access comparable to that of a reader or a Key Vault reader at the subscription level (reader permission is included in a variety of Azure RBAC roles), it can read numerous resource groups. Conversely, if the identity's access is restricted, it may only view a specific subset of resources, such as Key Vaults. Consequently, a threat actor can only interact with those Key Vaults that are visible to them. Once the Key Vault name is identified, a threat actor can interact with the Key Vault, and these interactions will be logged within the AzureDiagnostics table. List secrets / List certificates Operation With the Key Vault Name, a threat actor could list secrets or certificates (Operation: SecretList and CertificateList) if they have the appropriate rights (while this is not the final secret, it indicates under which name the secret or certificate can be retrieved). If not, access attempts would appear as unsuccessful operations within the httpStatusCode_d field, aiding in detecting such activities. Therefore, a high number of unauthorized operations on different Key Vaults could be an indicator of suspicious activity as shown in the figure below: The following query assists in detecting potential unauthorized access patterns. Query: AzureDiagnostics | where ResourceType == 'VAULTS' and OperationName != "Authentication" | summarize MinTime = min(TimeGenerated), MaxTime = max(TimeGenerated), OperationCount=count(), UnauthorizedAccess=countif(httpStatusCode_d >= 400), OperationNames = make_set(OperationName), make_set_if(httpStatusCode_d, httpStatusCode_d >= 400), VaultName=make_set(Resource) by CallerIPAddress | where OperationNames has_any ("SecretList", "CertificateList") and UnauthorizedAccess > 0 When a threat actor uses a browser for interaction, the VaultGet operation is usually the first action when accessing a Key Vault. This operation can also be performed via direct API calls and is not limited to browser use. High-Privileged account store Next, we assume a successful attempt to access a global admin password for Entra ID. Analyzing Secret retrieval When an individual has the identifier of a Key Vault and has SecretList and SecretGet access rights, they can list all the secrets stored within the Key Vault (OperationName SecretList). In this instance, this secret includes a password. Upon identifying the secret name, the secret value can be retrieved (OperationName SecretGet). The image below illustrates what appears in the AzureDiagnostics table. The HTTP status code indicates that these actions were successful. The requestUri contains the name of the secret, such as "BreakGlassAccountTenant" for the SecretGet operation. With this information, one can ascertain what secret has been accessed. The requestUri_s format for the SecretGet operation is as follows: {vaultBaseUrl}/secrets/{secret-name}/{secret-version}?api-version=7.4 When the browser accesses the Key Vault service through the Azure portal, additional API calls are often involved due to the various views within the Key Vault services in Azure. The figure below illustrates this process. When someone accesses a specific Key Vault via a browser, the VaultGet operation is followed by SecretList. To further distinguish actions, SecretListVersion will also be used, as the Key Vault service shows different versions of a Secret, which may indicate direct browser usage. The final SecretGet Operation retrieves the actual secret. When using the Key Vault, SecretList operations can be accompanied by SecretGet operations. This is less common for emergency accounts since these accounts are infrequently used. Setting up alerts when certain secrets are retrieved can assist in identifying unusual activity. Entra ID Application certificate store In addition to storing secrets, certificates that provide access to Entra ID applications can also be managed within a Key Vault. When creating an Entra ID application with a certificate for authentication, you can automatically store that certificate within a Key Vault of your choice. Access to such certificates could allow a threat actor to leverage the access rights of the associated Entra ID application and gain access to Entra ID. For instance, if the Entra ID application possesses significant permissions, the extracted certificate could be utilized to exercise those permissions. Various Entra ID roles can be leveraged to elevate privileges; however, for this scenario, we assume the targeted application holds the "RoleManagement.ReadWrite.Directory" permission. Consequently, the Entra ID application would have the capability to assign the Global Admin role to a user account controlled by the threat actor. We have also described this scenario here. Analyzing Certificate retrieval The figure below outlines the procedure for a threat actor to download a certificate and its private key using the Key Vault API. First, the CertificateList operation displays all certificates within a Key Vault. Next, the SecretGet operation retrieves a specific certificate along with its private key (the SecretGet operation is required to obtain both the certificate and its private key). When a threat actor uses the browser through the Azure portal, the sequence of actions should resemble those in the figure below: When a Certificate object is selected within a specific Key Vault view, all certificates are displayed (Operation: CertificateList). Upon selecting a particular certificate in this view, the operations CertificateGet and CertificateListVersions are executed. Subsequently, when a specific version is selected, the CertificateGet operation will be invoked again. When "Download in PFX/PEM format" is selected, the SecretGet Operation downloads the Certificate and private key within the Browser. With the downloaded certificate, the threat actor can sign in as the Entra application and utilize the assigned permissions. Key Vault summary Detecting misuse of a Key Vault instance can be challenging, as operations like SecretGet can be legitimate. A threat actor might easily masquerade their activities among legitimate users. Nevertheless, unusual attributes, such as IP addresses or peculiar access patterns, could serve as indicators. If an identity is known to be compromised and has utilized Key Vaults, the Key Vault logs must be checked to determine what has been accessed to respond appropriately. Coming up next Stay tuned for the next blog in the Cloud Forensics series. If you haven’t already, please read our previous blog about hunting with Microsoft Graph activity logs.
Sploitlight: Hunting Beyond the Patch
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" OR 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") 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
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. 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. Further Reading Defender for Cloud AI Threat Protection Advanced Hunting in Microsoft Defender XDR OWASP Top 10 for LLM Applications Found a better pattern? Post it. The threat surface is new, but the hunt discipline isn’t.Delivering more threat hunting insights with Microsoft Defender Experts’ newest capabilities
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. 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. 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. Register for Microsoft Ignite >
