Monthly news - July 2026
Microsoft Defender Monthly news - July 2026 Edition This is our monthly "What's new" blog post, summarizing product updates and various new assets we released over the past month across our Defender products. In this edition, we are looking at all the goodness from June 2026. We are now including news related to Defender for Cloud in the Defender portal. For all other Defender for Cloud news, have a look at the dedicated Defender for Cloud Monthly News here. 🚀 New Virtual Ninja Show episode: Redefining identity security for the modern enterprise One policy engine to govern them all: Securing agentic AI with Microsoft Purview Building a modern detection pipeline with ContentOps Securing local AI agents with Microsoft Defender Microsoft Defender: Extending critical protection for emerging threats in Team Weekly Security News: We publish a short 1ish minute video every week with updates across our Microsoft Security stack. Subscribe to our YouTube channel, so you don't miss the next episode. Actionable threat insights (find all of them here) Securing AI agents: When AI tools move from reading to acting Chromium extension uses AI‑related branding to redirect browser search Photo ZIP campaign targeting hospitality industry delivers Node.js implant for persistent access Microsoft Defender Two Workbooks capabilities in the unified Microsoft Defender portal moved to GA: Advanced Hunting connector - build custom dashboards directly on top of Advanced Hunting (XDR) dat. Query XDR tables and visualize them in Workbooks for richer investigations and reports. Workspace filter / multi-workspace experience - scope and filter workbooks by workspace, with workspace selection integrated into the workbook itself rather than relying on the global selector. MTO Tenant Groups let MSSPs and large enterprises organize their multitenant view in Microsoft Defender by grouping tenants logically (e.g., by region, business unit, or customer cohort). Learn more here. Custom Detections support in Microsoft Sentinel Repositories. Custom Detections can now be managed as code in Microsoft Sentinel Repositories, the same way customers already manage analytic rules, playbooks, parsers and workbooks. Detection engineers connect a GitHub or Azure DevOps repo to their workspace; Custom Detections placed in the repo are reconciled on every commit. A standalone Bicep path via the Microsoft Security Bicep extension lets teams deploy from any CI/CD pipeline (ADO Pipelines, GitHub Actions, custom runners). (General Availability) The following advanced hunting schema tables are now generally available: The CloudAuditEvents table contains information about cloud audit events for various cloud platforms protected by the organization's Defender for Cloud. The CloudDnsEvents table contains information about DNS activity events from cloud infrastructure environments. The CloudProcessEvents table contains information about process events in multicloud hosted environments. (Public Preview) The AgentsInfo table in advanced hunting is now available in preview. The AIAgentsInfo table is transitioning to this new table, which provides a unified schema that supports agent inventory and governance for all agent types, including Copilot Studio, Microsoft Foundry, Microsoft 365 Copilot, third-party, and endpoint-discovered agents. Microsoft Agent 365 customers should use the AgentsInfo table today. The AIAgentsInfo table remains accessible until July 1, 2026. Update your queries to use AgentsInfo before this date. For more information, see Advanced hunting schema - Naming changes. For all other Sentinel News, have a look at the "What's new in Microsoft Sentinel blog post - June edition" Identity Security (Public Preview) The Identity Security dashboard now includes a new Human identities card that shows your human identities by source (Entra ID, SaaS, and on-premises), giving you a single view of where your human identities live. For more information, see Identity Security dashboard. (Public Preview) On the Coverage and maturity page, the Review and improve coverage side panel for SaaS Identities now includes an Observed column and a Show Only Observed Applications toggle. By default, the panel shows only SaaS applications detected in your environment. Turn off the toggle to see other supported SaaS applications you can onboard to expand your identity coverage. For more information, see Coverage and maturity. New alerts were added to the Defender for Identity security alerts related to Microsoft Entra ID, Active Directory as well as other identity providers. For a full list of those new alerts, check out our documentation. Recent ShinyHunters attacks on Salesforce show how OAuth tokens and connected apps are being weaponized to bypass MFA at scale. The upgraded Salesforce connector for Defender for Cloud Apps helps detect these attacks faster, with richer connected-app context and investigation-ready signals. Customers already using the connector are advised to enable the additional events in the Salesforce console for tighter protection, and eligible customers not yet using it are advised to connect Salesforce. Learn more. Microsoft Defender for Endpoint / Microsoft Defender Vulnerability Management (Public Preview) Local AI agent discovery: as part of the Defender AI agents experience, Microsoft Defender now automatically discovers supported local AI agents running on onboarded Windows & macOS devices. Discovered agents appear as assets in the AI agent inventory, exposure map, and advanced hunting, giving security teams visibility into local AI agent usage across the organization. For more information, see Discover local AI agents. (Preview) Local AI agent runtime protection on Windows endpoints is now available in public preview. Microsoft Defender inspects the agent loop (user prompts, tool calls, and tool responses) and can block risky activity before it executes, helping stop prompt injection and unsafe agent actions at the device level. Blocked and audited events appear as alerts in Microsoft Defender to support incident correlation and investigation workflows. The new version of the Defender deployment tool for Windows streamlines onboarding and enhances security by: Bundling the onboarding package directly into the tool's executable. Generating a key during deployment package creation that is required for running the tool. Enabling users to configure an expiry date for the package to reduce the risk of unauthorized use. In addition: You have the option of downloading the package as either an .exe or a .zip file, whichever best suits your organization's needs. A new Deployment packages page in the Defender portal facilitates management of downloaded packages by providing centralized visibility into all the packages and their current status. Now generally available: Selective Response Actions enables organizations to tailor high-impact security operations on devices during onboarding. It provides precise control over how response actions are applied on Tier-0 systems and other high-value assets, helping maintain operational stability while delivering strong protection. The new exposure score model in Defender Vulnerability Management is now generally available. This model improves risk prioritization and recommendation impact accuracy by incorporating exploit prediction data (EPSS) and asset context factors such as internet-facing status and criticality. More details here. Microsoft Secure Score now includes the Reduce unnecessary inbound internet exposure on internet-facing devices recommendation, which helps identify devices that are accessible from the public internet and may represent unnecessary attack surface. This recommendation provides centralized visibility into internet-facing devices across the environment. Many predefined SaaS application classification rules were added to the critical assets list. Have a look at our documentation for the full list. These classifications require onboarding to Microsoft Defender for Cloud Apps.
Security Copilot RBAC for Embedded Experience in Unified Security Platform
Introduction The evolution of Security Operations Centers (SOC) is increasingly driven by AI-powered capabilities that improve efficiency, accuracy, and response time. Microsoft Security Copilot represents a significant advancement in this space by embedding AI-driven assistance directly within security platforms such as Microsoft Defender XDR, Microsoft Sentinel, and Microsoft Entra. The concept of embedded experience is central to this transformation. Rather than operating as a standalone interface, Security Copilot is integrated within existing security tools, allowing analysts to invoke AI-generated insights directly during investigations. This reduces the need for tool switching and accelerates decision-making. The purpose of this document is to define and explain the Role-Based Access Control (RBAC) model required to securely enable this embedded experience. It provides a structured understanding of how access is governed across multiple layers, how these layers interact, and how organizations can align permissions with SOC workflows while maintaining a least-privilege security posture. Understanding Embedded Experience Security Copilot in embedded mode operates within the context of the host platform. When invoked from Defender or Sentinel, it does not function independently but instead consumes data already accessible to the user. This model ensures that Copilot enhances visibility without expanding access boundaries. This behavior is governed by an On-Behalf-Of (OBO) model, where Security Copilot leverages the permissions of the authenticated user. It does not introduce new entitlements or override existing RBAC configurations. As a result, the insights generated by Copilot are always limited to what the user is already authorized to see, reinforcing Zero Trust principles and preventing unauthorized data exposure. Prerequisites for Embedded Experience To enable Security Copilot in an embedded environment, organizations must establish foundational prerequisites that ensure seamless and secure operation. First, access to underlying platforms such as Microsoft Defender XDR, Microsoft Sentinel, and Microsoft Entra must already be provisioned. Since Copilot is not a standalone data source, it cannot function without these integrations. Second, RBAC alignment across identity, platform, and service layers must be configured correctly. Misalignment can lead to incomplete results, restricted functionality, or inconsistent analyst experiences. Finally, governance processes such as access review, monitoring, and adherence to least privilege principles should be implemented. These controls ensure that Copilot usage remains compliant, auditable, and aligned with organizational security policies. RBAC Framework for Security Copilot Security Copilot adopts a multi-layer RBAC model consisting of three tightly integrated layers. These layers collectively determine whether a user can access Copilot features and what data they can retrieve. RBAC Layer Mapping RBAC Layer Role Type Purpose Example Roles Access Impact Security Copilot Platform Feature access control Determines who can use Copilot capabilities Security Copilot Owner, Security Copilot Contributor Enables use of Copilot features but does not grant data access Microsoft Entra ID Identity and directory governance Controls access to identity data and reports Security Reader, Reports Reader, Security Administrator Governs identity insights and directory visibility Service-Specific RBAC Data access control Defines access to security data within services Defender Security Reader, Sentinel Reader Determines what Copilot can retrieve and present This layered approach ensures that no single role grants full access. All three layers must align for complete functionality. Security Copilot Platform Roles Security Copilot platform roles control who can interact with the Copilot interface and execute AI-driven workflows. The Security Copilot Owner role provides administrative control over Copilot configuration, including access management and platform-level settings. This role is typically assigned to administrators responsible for governance and operational enablement. The Security Copilot Contributor role enables analysts to run prompts, perform investigations, and interact with Copilot features during daily SOC operations. However, this role does not grant visibility into security data by itself. This clear separation ensures that Copilot remains a controlled interface layer rather than a source of privilege escalation. Microsoft Entra ID Roles Microsoft Entra roles govern access to identity-related data, which is critical for security operations involving user behavior, sign-in logs, and directory insights. Roles such as Security Reader provide read-only visibility into security data, while Reports Reader enables access to reporting and analytics capabilities. In certain advanced cases, the Security Administrator role may be required for configuration-level actions. The document emphasizes avoiding excessive privilege assignment, particularly the use of Global Administrator roles for daily operations, as this conflicts with least privilege principles. Service-Specific RBAC Roles Service-level roles determine the data sources that Security Copilot can access when embedded in platforms. In Microsoft Defender XDR, roles such as Security Reader allow access to alerts, incidents, and endpoint data. In Microsoft Sentinel, Sentinel Reader provides access to log data, analytics, and incidents. In Microsoft Entra, roles like Reports Reader provide access to identity insights. Copilot cannot retrieve or analyze data beyond what these roles permit. The output it generates is always constrained to the user’s effective permissions across these services. Unified RBAC Behavior in Embedded Experience In an embedded scenario, all three RBAC layers are evaluated simultaneously. When a SOC analyst invokes Copilot in Defender, the system validates whether the user has permission to use Copilot, access identity data, and retrieve Defender-specific insights. Only when all these conditions are satisfied does Copilot provide a comprehensive output. This ensures that Copilot responses are both contextually rich and access-compliant, eliminating the risk of unauthorized data exposure while maintaining operational efficiency. Security Copilot Core Use Cases Security Copilot enables a layered set of capabilities that span both analyst interaction patterns and agent-driven execution models. These use cases collectively enhance SOC efficiency, decision-making, and operational scalability. Use Case Mapping Table Use Case Description Embedded / Agent Example Value to SOC Summarization Transforms complex alerts, incidents, and telemetry into structured, human-readable insights by correlating signals across multiple sources Summarizing a Defender XDR incident involving endpoint, identity, and cloud alerts into a unified attack narrative Reduces analyst fatigue and significantly accelerates triage by eliminating manual data aggregation Guided Response Provides contextual, step-by-step investigative guidance and recommended remediation actions based on observed patterns and threat intelligence Suggesting investigation paths in Sentinel, including pivoting to identity logs, device timeline, and lateral movement indicators Improves consistency in investigations and enables less experienced analysts to operate effectively Script Analysis Evaluates scripts, queries, and command-line activities to identify malicious patterns, errors, or optimization opportunities Analyzing PowerShell scripts or KQL queries used in threat hunting scenarios to detect obfuscation or suspicious logic Enhances detection accuracy and reduces the risk of missing critical indicators Reporting Generates structured incident summaries, executive reports, and compliance-ready documentation with contextual insights Producing incident summaries for leadership or compliance teams with both technical and business context Improves communication, supports audit readiness, and reduces manual reporting overhead Agent-Driven SOC Use Cases (Expanded Capabilities) With the introduction of Security Copilot agents, the platform extends beyond assistance into orchestrated, intelligence-driven operations across SOC workflows. Agent-Based Use Case Description Real Agent Example SOC Impact Dynamic Threat Detection Continuously analyzes telemetry to identify previously undetected or weak signals across the attack surface Dynamic Threat Detection Agent correlates signals across Defender workload telemetry to surface hidden threats Improves detection coverage and reduces the likelihood of missed attacks Threat Intelligence Correlation & Briefing Aggregates internal and external intelligence sources to generate contextual threat insights aligned to organizational risk Threat Intelligence Briefing Agent produces structured intelligence reports based on attack patterns and exposure context Enhances situational awareness and supports proactive defense strategies Advanced Threat Hunting Enables hypothesis-driven and AI-assisted threat hunting by generating queries, exploring telemetry, and correlating historical data Advanced Threat Hunting Agent builds and executes queries across Defender and Sentinel datasets for proactive investigation and telemetry exploration Accelerates threat discovery and reduces reliance on manual query development Security Analysis & Threat Prioritization Performs AI-driven analysis of security telemetry to identify high-risk patterns, prioritize threats, assess risk exposure, and recommend investigative actions Security Analyst Agent analyses password spray attacks, ransomware activity, malware campaigns, identity abuse, and other security risks by generating telemetry-driven assessments and recommendations Improves analyst productivity, prioritizes high-impact threats, and enables faster decision making Security Triage Automation Automates alert prioritization and classification by adding contextual enrichment and reducing noise Security Triage Agent / Phishing Triage Agent evaluates alerts and distinguishes between real threats and false positives Reduces alert fatigue and improves prioritization accuracy in high-volume environments End-to-End Investigation Orchestration Performs multi-step investigation by gathering signals, correlating activity, and building attack timelines Security Analyst Agent investigates incidents across identity, endpoint, email, cloud, and data signals to produce a consolidated incident narrative Reduces Mean Time to Investigate (MTTI) and ensures consistent investigation outcomes Cross-Domain Threat Correlation Connects signals across identity, endpoint, cloud, email, and data domains to identify multi-stage attack chains Agents operating across Defender, Entra, Sentinel, and Security Copilot correlate activities such as phishing leading to identity compromise and lateral movement Breaks down silos and enables holistic threat visibility across the environment Remediation & Response Enablement Identifies vulnerable assets and supports remediation workflows through contextual recommendations Agents integrated with endpoint and policy systems suggest patching actions, containment actions, and configuration changes based on detected risks Improves response effectiveness and strengthens overall security posture Each of these use cases operates within the RBAC boundaries defined earlier, ensuring secure and context-aware outputs. Mapping Use Cases to SOC Processes The four core use cases align directly with SOC operational stages, enabling a consistent and repeatable analysis model. Summarization plays a significant role during the detection and triage phase, where analysts need quick clarity on incoming alerts. Instead of manually analyzing raw data, Copilot provides a structured overview, helping analysts determine priority and relevance. Guided response becomes critical during the investigation and response phase, where decision-making speed is essential. By suggesting next steps and correlating data points, Copilot assists analysts in navigating complex attack scenarios. Script analysis supports both threat hunting and investigation, allowing analysts to validate scripts, queries, or automation logic. This reduces the risk of overlooking malicious behavior embedded in scripts. Reporting aligns with the post-incident and compliance phase, where structured documentation is required. Copilot generates summaries that can be shared with leadership or compliance teams, ensuring clarity and consistency. Together, these use cases create a continuous cycle of detection, investigation, response, and reporting, fully integrated with SOC workflows. Summary Security Copilot’s embedded experience represents a transformative shift in how AI is integrated into security operations. By embedding intelligence directly within platforms such as Defender and Sentinel, it enhances analyst productivity while maintaining strict governance controls. The three-layer RBAC model, consisting of Security Copilot roles, Microsoft Entra roles, and service-specific roles, ensures that access is both secure and compliant with least privilege principles. The On-Behalf-Of model further guarantees that Copilot does not expand access beyond existing permissions. The inclusion of structured use cases such as summarization, guided response, script analysis, and reporting enables organizations to operationalize Copilot effectively across SOC processes. When RBAC is properly aligned and integrated with SOC workflows, Security Copilot becomes a powerful enabler of faster investigations, improved accuracy, and enhanced security posture—all while maintaining strict control over data access and governance.Closing the loop on container security: From code to runtime in the AI era
Containers are the backbone of modern cloud-native apps — and increasingly, the infrastructure powering AI, from AI assistants to a new wave of intelligent agents. They also blur the line between build, deploy, and runtime: a single code change can become a running workload in minutes. A misconfiguration committed in the morning can be deployed in minutes and exploited before noon. At that speed, container security can no longer be a point-in-time check, it has to work as one continuous loop. The numbers back this up. For the first time, 31% of breaches now begin with an attacker exploiting a software vulnerability — overtaking stolen credentials as the most common way in — and 15% of attack techniques are now accelerated by generative AI, with adversaries using it to find gaps and write malware faster at every stage. Source: Verizon 2026 Data Breach Investigations Report (incidents Nov 2024–Oct 2025). Over the last few quarters, Microsoft Defender for Cloud has been evolving to offer you this continuous security, end to end. Explore container security’s new capabilities across posture, shift-left, runtime, multicloud coverage, and operations. Collectively they form a more comprehensive approach to container security — one that offers security right during developing a code to a running pod across Azure, AWS, and GCP. There is a second reason why container security matters more in 2026: containers are increasingly where AI runs. Many AI workloads — from model-serving APIs to retrieval systems and intelligent agents — now live as pods on AKS, EKS, and GKE (the managed Kubernetes services from Azure, AWS, and Google), often connected to some of an organization’s most sensitive models and data. As those crown jewels move into the cluster, the same posture, code‑to‑runtime, and runtime protections described in this post extend to AI workloads. The contest is increasingly AI against AI: attackers use it to find and reach the cluster faster, while defenders use it to push back — surfacing the risks that matter most and turning runtime findings into AI‑assisted code fixes. One platform, code to runtime A container finding is not treated as an isolated issue; it is connected to the identity it runs under, the registry and code repository it came from, and the cluster where it is running - all unified under one Microsoft Defender platform. Container posture and shift-left security are now redesigned for least vulnerabilities in production Conventional container security posture offered challenges to scale: a single grouped recommendation could stack thousands of findings under one bucket, making ownership, exemptions, and risk scoring too coarse to act on. That experience is now evolved. We have rebuilt the experience so that each finding is its own recommendation — per software, per image, per container. If two CVEs in the same image belong to two different teams, they can now be triaged, exempted, and reported separately. The grouped recommendations are deprecated and will be removed on July 30, 2026, We suggest updating any automation, export rules, and ServiceNow integrations to target the new per-finding recommendations before that date. That per-finding precision becomes even more powerful once you connect each finding to its source code and to the runtime resources it impacts. Defender for Cloud — part of Microsoft Defender suite — connects this code-to-runtime chain end-to-end. For example, an image built through Azure DevOps or GitHub, pushed to ACR, ECR, Google Artifact Registry, Docker Hub, or JFrog, and pulled by AKS, EKS, or GKE is one continuous evidence chain — traceable from a running container back to the pull request (PR) and line of code that introduced the risk. With GitHub Advanced Security integrated (GA), secrets, code, and dependency findings join the same attack story. The developer-first Defender for Cloud CLI runs the same scanner locally or in any CI/CD pipeline, with consistent exit codes for gating. In this diagram, you can see how we have embedded container security at every stage of the software development lifecycle (SDLC), not just the endpoints. At Code, GitHub Advanced Security and the Defender for Cloud CLI catch secrets, vulnerable dependencies, and insecure code before commit. At Build, the same scanner runs as a CI/CD gate — in GitHub Actions, Azure DevOps, Jenkins, or Bitbucket — failing the pipeline on critical findings. At Ship, registry scanning and Gated Deployment block risky or misconfigured images at the cluster door. And at Runtime, the sensor enforces anti-malware and binary-drift policy on the live workload. No stage is left as a blind spot, and a finding can be traced forward to the running pod or backward to the developer who introduced it. Visibility without enforcement only creates backlog. Gated Deployment — a Kubernetes admission controller — uses the same vulnerability signal, you trust, to block risky images at the cluster level. It supports phased rollout (audit, then deny), targets rules by cluster, namespace, pod, image, or label, and runs across AKS (including AKS Automatic), EKS, and GKE. A newer extension gates on Kubernetes misconfigurations too. Posture practitioners also get KSPM at container granularity — Kubernetes security posture management, available through both Defender for Containers and Defender CSPM — and, on Azure, a new actionable recommendation, Upgrade Azure Kubernetes Service Version (preview), that helps you remediate vulnerabilities in AKS-managed system pods. Coverage that matches containers’ evolution Historically, many container security programs concentrated on managed Kubernetes clusters in AKS, EKS, and GKE. The 2026 reality is broader: a growing share of production runs on serverless container platforms that abstract the cluster away, many sensitive workloads sit behind private, network-isolated clusters, and platform teams increasingly standardize on hardened or distroless base images. The surfaces that were blind spots are now part of the same posture graph as everything else. Serverless compute posture is now generally available across AWS Lambda, Azure Functions, and Web Apps, while Serverless containers posture (preview) takes the same idea to Azure Container Apps, ACI, and AWS Fargate. Together, they bring more of today’s cloud-native production footprint into the same posture graph. Coverage also improves where platform teams are standardizing on locked-down environments. The long-standing gap around private EKS and GKE clusters is closed, bringing some of the hardest-to-reach environments into the same security model. Scanning now works on hardened images from Docker Hardened or Minimus, and runtime protection supports BottleRocket on EKS — with the full feature set also available in Azure Government, which matters for teams running regulated workloads. Runtime threat protection that prevents, not just detects Posture closes the door on attackers; runtime threat protection guards the room if they still succeed. The key shift is that the Defender for Containers sensor now adds prevention on top of detection. The goal is simple: stop malicious code before it runs. Anti-malware detection and prevention (GA) scans container workloads and Kubernetes nodes and, based on the policies you define, blocks malicious execution instead of only alerting. Those alerts then flow into Microsoft Defender XDR’s unified incident model. The second is binary drift detection and prevention (preview). Containers are meant to be immutable. When a process starts from a binary that was not part of the original image, that is drift — and one of the highest-signal indicators of compromise in cloud-native workloads. Defender detects drifts and, with policy enabled, can now also block the drifted process before it executes. Anti-malware and Drift policies can be scoped by cloud, cluster, namespace, image, or label, with allow-lists for legitimate cases. Anti-malware policies can alert, block, or ignore — scoped to clusters, namespaces, pods, labels, or images. Rounding out runtime protection, DNS-based threat detection (GA) catches command-and-control beaconing, DGA traffic, and exfiltration over DNS. A unified approach to container security Step back, and the bigger picture is simple. The same platform that secured your VMs and identities now extends across AKS, EKS, GKE, private clusters, serverless containers, and serverless compute. The same Code-to-Runtime chain that once tied Infrastructure as Code (IaC) findings to running infrastructure now connects Dockerfile commits — through CI/CD and any major registry — to the running pod. Admission control turns posture findings into prevention at deploy time, and runtime protection actively blocks. That is a continuous container security loop living inside Microsoft Defender — not a checklist bolted onto Kubernetes. And it rebalances the fight: as attackers use AI to find and exploit gaps faster, the durable answer is security teams using AI of their own — protecting and triaging at machine speed. If you’ve already enabled container security with Microsoft, the clearest next step is to strengthen the core lifecycle stages first: Code + build: connect GitHub Advanced Security and integrate the Defender for Cloud CLI into your pipelines so findings are caught early and CI/CD gates can fail builds before an image is pushed. Ship: stand up Gated Deployment in audit mode on a non-production cluster, tune it, then flip to deny; extend it to Kubernetes misconfigurations. Run: enable the Defender for Containers sensor, extend it to private EKS and GKE clusters, then tune anti-malware and binary-drift rules in Block mode — starting with your crown-jewel namespaces. Extend protection: turn on serverless compute posture for Lambda, Functions, and Web Apps, and enable serverless container posture for Container Apps, ACI, or Fargate.Better together with Azure WAF + Microsoft Defender for Storage + Defender for Azure SQL Databases
Authored by: Fernanda_Vela​ , saikishor​, Yura_Lee​ Reviewed by: YuriDiogenes​, Mohit_Kumar​, Amir_Dahan​, eitanbremler​ , Kitt_Weatherman​ Introduction Often, customers ask why additional workload protection is needed when a web application firewall is already in place. Azure Web Application Firewall (WAF) serves as a critical control at the application edge, inspecting inbound HTTP/S traffic and blocking common web-based exploits before they reach backend services. However, modern attack paths are no longer limited to the web entry point. Attackers increasingly target components that bypass HTTP/S inspection altogether such as direct access to storage and SQL through SDKs, native integration tools, private endpoints, or compromised identities and third-party integrations. This is where Microsoft Defender for Cloud complements WAF. While WAF focuses on securing the application boundary, Defender for Cloud extends protection into the resource layer by providing Cloud-Native Application Protection Platform (CNAPP) capabilities, including security posture management and workload protection. Using resource-native signals, it helps identify misconfigurations and detect suspicious control-plane and data-plane activity that would otherwise remain invisible to perimeter controls. The Azure Networking Security blog post “Zero Trust with Azure Firewall, Azure DDoS Protection, and Azure WAF: A practical approach” highlights WAF’s role in inspecting inbound HTTP/S traffic, detecting malicious request patterns (such as OWASP Top 10 vulnerabilities), and reducing direct exposure of backend endpoints by enforcing a controlled application entry point. Building on that foundation, this blog focuses on a “better together” approach that combines WAF with Microsoft Defender for Cloud protecting storage and database. Through practical scenarios and posture insights, we will underline how these controls together: Reduces attack surface at the application entry point Continuously improves security posture through configuration and exposure analysis Detects and responds to threats targeting storage accounts and SQL databases beyond the web perimeter By the end of this post, you will understand how Defender for Cloud’s Storage and SQL protections extend the visibility provided by WAF, enabling protection not only at the edge, but also across the underlying data services. Together, these controls form a cohesive model that addresses both external attack vectors and internal or indirect access paths. Note: This is not a deep configuration guide for rule tuning, nor a replacement for official product documentation. It is intended to help architects and security teams align responsibilities and understand how these services reinforce each other. Architecture: The architecture below shows the traffic flow and where each service fits in the lab used in this blog to simulate the attacks. Azure Application Gateway with WAF is the internet-facing entry point, inspecting inbound HTTP/S traffic before it reaches the backend. Behind it, Azure Firewall provides both network- and application-layer inspection for inbound and outbound flows. In the backend subnet, multiple VMs host the workload. For our demonstration, we focus on a single host running: OWASP Juice Shop (port 3000), An upload API that writes to Azure Storage (port 8080) An API that connects to Azure SQL Database (port 5000). This setup allows us to simulate realistic attack paths originating both from the internet and from within the network. Figure 1: Architecture that shows resources with Application Gateway with WAF, Azure Firewall Premium and inbound traffic Note: The patterns in this blog apply to both Azure WAF platforms: Application Gateway WAF and Azure Front Door WAF. The lab uses Application Gateway WAF for the demonstration. Now, let’s head to the next section where we dive deep into these services to understand their capabilities with some attacks, alerts and insights. Azure Web Application Firewall at the Edge As we may have understood by now, Azure WAF is the first layer of protection, inspecting external web traffic for malicious patterns. Each incoming request is evaluated against its rulesets to either allow, block or log this traffic by using its managed and custom rulesets. Now, what are these rulesets? Azure WAF uses managed rule sets like the Default Rule Set (DRS) (version 2.2 as of this writing), which incorporate OWASP Top 10 protections and Microsoft threat intelligence to block common attacks (SQL injection, XSS, remote file inclusion, etc.) in real time. Additional managed sets include a Bot Protection rule set (to guard against malicious bots scraping content) and HTTP DDoS rule set (to detect Layer 7 DDoS patterns). Beyond the built-ins, you can define custom WAF rules for application-specific needs—blocking or allowing traffic based on attributes like geolocation, IP ranges, or specific URL paths. Now let’s talk about an example scenario. In our lab, Azure WAF is protecting multiple backend services on different paths and ports. When an external attacker tries to exploit the Juice Shop app with a crafted XSSattack, Azure WAF immediately detects the malicious pattern and blocks the request at the gateway as seen below. Figure 2: An XSS attack on the juiceshop website, immediately results in a 403 Forbidden as WAF catches this attack in the application layer. However, WAF’s inspection is inherently limited to traffic it can see, primarily, the HTTP/S flows it fronts. Let’s say our attacker changes tactics: instead of trying to force malicious code through the web interface, they obtain a stolen storage key or credentials through phishing and attempt to access the Azure Storage account directly via APIs. This request never goes through WAF, so WAF cannot assess or block it. In such a case, Microsoft Defender for Storage’s threat detection monitors for such suspicious activity, for example by raising an alert about the unusual direct access or flagging a malware file uploaded to a blob container. Likewise, if our attacker exploited a weakness in application code to run malicious SQL commands on the database (whether through potentially harmful application or a suspicious service account), Defender for SQL monitors for and alerts anomalous query patterns or suspicious logins. This illustrates why WAF and Defender for Cloud are complementary: WAF stops web attacks at the door, while Defender for Cloud watches for threats that get inside or come through alternate doors. Figure 3: Single-host lab architecture with Azure Application Gateway (WAF) and resource‑level protection Figure 3 illustrates the key distinction: WAF inspects and protects the application entry point, while Defender for Cloud provides visibility into the resources themselves. Together, they cover both the path into the application and the behavior within the environment—forming a complete protection model across layers. Because not all access to storage and databases may flow through the application gateway, you also need resource-level posture and threat detection to see and stop activity that never appears in WAF logs. Cloud Security Posture Management with Defender for Cloud With the edge covered, the next challenge is reducing risk that originates from misconfiguration and resource exposure. Most successful attacks originate from exposed services and misconfigurations rather than direct application-layer exploits. Microsoft Defender for Cloud’s storage and database protection provide security posture insights that help identify and prioritize these security gaps at the resource level. Defender for Cloud has visibility insights that capture the resources’ misconfigurations on the control and data plane via the Recommendations view in the Azure portal, as shown in the example below: Figure 4: Juice Shop’s storage account and SQL server recommendations Figure 4 is a list of recommendations organized by risk level for this particular environment. The security team should harden the “defendertestsai” storage asset by preventing shared access keys, and the “juiceshop” SQL database by provisioning an Entra administrator. Each recommendation will also provide guidance to remediate these findings. The “Data & AI Dashboard” in Defender for Cloud, with Defender CSPM, will also provide security posture insight into storage, database and AI resources by surfacing their risks, alerts and sensitive data discovery all in one dashboard. Figure 5: Juice Shop’s Sensitive data discovery and Data threat detection dashboard in Defender for Cloud’s “Data&AI section”. Under Data closer look, in Figure 5, you can see in this example, starting from the left, sensitive information found in scanned resources, level alerts for databases and storage resources based on severity, templatized queries from the Cloud Security Explorer, and a graph displaying all internet exposed data resources below. These powerful insights on data resources all come from Defender for Cloud, designed to help customers harden their environment by priority through visibility across their entire data ecosystem based on risk level. Figure 6: Juice Shop’s attack path “Internet exposed Azure VM with high severity vulnerabilities allows lateral movement to Critical Storage used by Azure AI Foundry”. Attack paths are potential avenues in which an attacker can infiltrate and compromise data. In Figure 6 above, we see insight into not only the storage account itself, but the context around it: an internet exposed storage account is connected to other assets like a virtual machine and a managed identity that has permissions to manipulate data. These Defender for Cloud security posture insights complement WAF and complete the defense-in-depth security approach: harden the data services so that even if an attacker reaches them the blast radius is smaller, and the likelihood of compromise is reduced. Defender for Cloud’s advanced threat protection Even in well-secured environments, attackers often interact directly with storage accounts or databases through identities, APIs, or trusted internal paths. Reducing exposure is critical but not sufficient. Detection is required once an attacker begins interacting with data Defender for Cloud’s advanced threat protection for Storage and SQL surfaces resource-level security alerts such as suspicious access patterns, anomalous queries, and malware detections—often with richer context than perimeter telemetry alone. Let’s use a malware alert for a storage account in the Defender portal as an example: Figure 7: Juice Shop’s storage account security alert “Malicious blob uploaded to storage account”. Malware scanning is a common requirement for teams that process user uploads or must meet security benchmarks. In this lab, Juice Shop allows users to upload files (for example, feedback attachments), and the upload API writes those files to Azure Blob Storage. Azure WAF inspects the HTTP request that delivers the upload headers, parameters, payload patterns and blocks web-layer attacks like XSS or SQLi. Scanning blob contents after they land is a different job, performed at the resource layer by Defender for Storage. With Defender for Storage malware scanning enabled, each uploaded blob is scanned; if the verdict is malware, Defender for Cloud raises an alert such as “Malicious blob uploaded to storage account” as shown in figure 7. Then, with Defender for Storage’s automated malware remediation, the malicious blog is set to soft-delete for quarantine and further analysis. SQL databases are high-value targets for data access, privilege escalation, and exploitation of vulnerable applications. Database protection in Defender for Cloud has the visibility to provide customers with control plane and data plane level insight to alert on suspicious activity such as anomalous logons, unusual client applications, and injection-like query patterns. For example, here’s a potential SQL injection alert for a database in the Defender portal: Figure 8: Juice Shop’s database security alert on a potential SQL injection. These alerts typically include investigation context such as the client application, client principal name, and the statement or pattern in question, along with severity to help you prioritize, as shown in Figure 8. From there, analysts can use recommended response actions (for example, to contain risky access paths or harden the database) to reduce the chance of repeat activity. In practice, Defender for Cloud threat detection gives SOC teams prioritized, resource-specific alerts with the context needed to investigate quickly and take action at the storage and database layers. Conclusion Azure Application Gateway with WAF is a necessary control to reduce application-layer risk at the edge. But defense in depth requires the assumption that some threats will reach or target data services directly. By layering Microsoft Defender for Storage and Microsoft Defender for SQL on top of Azure WAF, you add continuous posture insights to reduce preventable exposure, plus threat protection that detects suspicious activity at the resource layer. Operated together, these services provide stronger prevention, better detection coverage, and clearer response paths than single control alone.Monthly news - May 2026
Microsoft Defender Monthly news - May 2026 Edition This is our monthly "What's new" blog post, summarizing product updates and various new assets we released over the past month across our Defender products. In this edition, we are looking at all the goodness from April 2026. We are now including news related to Defender for Cloud in the Defender portal. For all other Defender for Cloud news, have a look at the dedicated Defender for Cloud Monthly News here. 🚀 New Virtual Ninja Show episode: The future of identity protection with Predictive Shielding Network-layer data protection with Microsoft Entra GSA and Purview DLP Data lake federation: hunt across external data without ingesting it Weekly Security News: We publish a short 1ish minute video every week with updates across our Microsoft Security stack. Subscribe to our YouTube channel, so you don't miss the next episode. Actionable threat insights CVE-2026-31431: Copy Fail vulnerability enables Linux root privilege escalation across cloud environments Email threat landscape: Q1 2026 trends and insights Cross‑tenant helpdesk impersonation to data exfiltration: A human-operated intrusion playbook Detection strategies across cloud and identities against infiltrating IT workers Dissecting Sapphire Sleet’s macOS intrusion from lure to compromise Microsoft Defender Blog post: Containing a domain compromise: How predictive shielding shut down lateral movement (Public Preview) You can now view the current status of automatic attack disruption and predictive shielding actions related to a specific incident. You view this data in the Activities tab of the incident page. Learn more We made several enhancements across the Advanced hunting experience, read this blog post for all the details. (Public Preview) The AIAgentsInfo table in advanced hunting now includes additional columns that provide deeper visibility into AI agents operating in your Microsoft 365 environment. These fields expand coverage beyond Copilot Studio to all agent types, including Microsoft Foundry, third-party marketplace, and custom line-of-business agents. (Generally Available) Built-in alert tuning rules are now generally available. Built-in alert tuning rules suppress alerts from common benign activity in Defender for Endpoint and Defender for Office 365 without affecting Automated Investigation and Response (AIR) investigations and email notifications. Microsoft Defender Experts for XDR customers can now see Defender Experts as a distinct entry in the Microsoft Defender portal navigation menu. This feature adds to the existing home page status card as in-portal experiences that provide consistent and predictable access to the service. Learn more Blog post: Simplifying AWS defense with Microsoft Sentinel UEBA Call to action: update automation by July 1, 2026 - Account Name is now consistently the UPN prefix for analytics rule alerts! Microsoft Sentinel is updating how the account entity's Account Name value is populated for analytics rule alerts when the full UPN is mapped into Account Name. This change improves consistency for downstream automation rules and Logic Apps playbooks. For more information, including before and after examples, read the blog article Update: Changing the Account Name Entity Mapping in Microsoft Sentinel. For all other Sentinel News, have a look at the "What's new in Microsoft Sentinel blog post - April edition" Microsoft Defender for Endpoint / Microsoft Defender Vulnerability Management (Public Preview) You can now view the current status of automatic attack disruption and predictive shielding actions related to a specific incident. You view this data in the Activities tab of the incident page. Learn more Microsoft Secure Score now includes the Ensure devices are updated to Secure Boot 2023 certificates and boot manager, which helps identify devices that haven't yet transitioned to the new Secure Boot 2023 certificates required ahead of the June 2026 expiration. To learn more about the recommendation, see Assess Secure Boot status with Microsoft Defender (blog). Microsoft Defender for Identity (Public Preview) Custom account correlation rules. Custom account correlation rules let you link accounts that belong to the same identity, such as privileged accounts with unique naming conventions. You can correlate accounts that don't share strong identifiers such as account ID, SID, object ID, or UPN by defining rules based on UPN prefix, UPN suffix, domain UPN, or employee ID. For more information, see Create custom account correlation rules. (Generally Available) The Automatic Windows event-auditing configuration for sensors v3.x is now generally available. Automatic Windows event-auditing streamlines deployment by automatically applying the required auditing settings to new sensors and correcting misconfigurations on existing ones.Microsoft Defender: New Advanced hunting enhancements
Co-author: Jeremy Tan As a security analyst who actively hunts for critical threats, one of the most frustrating things that can happen is hitting a limit mid-query or encounter an experience that doesn’t behave as expected. The resulting friction and time spent troubleshooting or navigating takes valuable focus away from the investigation itself. To address this, we’ve made several enhancements across the experience to ensure investigations can scale seamlessly so analysts can stay focused on finding and stopping threats without interruption. These updates are based on your feedback and our commitment to continually improve the experience for analysts and customers alike. Scaling Investigations with Expanded Limits We’ve made several enhancements across the experience to expand limits and better support large-scale investigations so analysts can query, explore, and act on more data with fewer constraints. Results limitation increase (Preview) We have heard your feedback on the need for larger data sets and are excited to announce that the results limitation in advanced hunting has been raised from 30,000 to 100,000 records. Now, queries returning up to 100,000 results will display all available data. If a query exceeds this threshold, results are truncated as before, but the increase allows for more comprehensive analysis and improved incident response. Records limitation picker (Preview) One common challenge in advanced hunting has been the risk of running queries that return overwhelming result sets, consuming excessive resources and potentially hitting system limits. The new records limitation picker addresses this by allowing you to explicitly set how many rows a query should return, directly from the editor toolbar. Choose from predefined limits: 1,000, 5,000, or 10,000, 30,000 and 100,000 rows. Select the maximum system limit (currently 100,000 records). Define a custom value as needed. The selected limit applies alongside any KQL-defined row limitations, with the lower value always taking precedence. Your choice persists across page refreshes, navigation, and browser restarts. By default, tenants start at the maximum row limit, but you can tailor your selection via page preferences. This enhancement greatly improves performance and prevents unexpected limitations, making hunting safer and more efficient. Partial results on size limit (GA) Previously, queries that exceeded the 64 mb results size limit would fail outright, forcing analysts to modify their queries and rerun them. With the latest update, partial results are now provided when the size limit is reached: Queries return the maximum records that fit within the 64 MB cap. A clear message bar indicates when results are partial due to size constraints. This allows you to act on available data immediately, without repeating query adjustments. This improvement speeds up investigations and provides valuable data even in scenarios where limits are reached. Enhanced UI for Faster, More Intuitive Investigations We’ve made significant enhancements to the user experience delivering a more streamlined interface that helps analysts move through incidents with greater clarity, act with confidence, and spend less time searching and more time responding. Hear from one of our customers: “The recent updates to the Defender Advanced Hunting experience have gone a long way toward decluttering the interface and lowering the barrier for analysts and engineers who were previously more comfortable working exclusively in Microsoft Sentinel in the Azure portal. By simplifying navigation, reducing unnecessary visual noise, and adding pinnable tabs, the XDR portal now feels more familiar. This usability improvement has helped shift long-standing Sentinel users toward the XDR experience without forcing a change in how teams think about their data or workflows.” -Matt McCullogh, Senior SIEM Engineer, Best Buy Query details side pane: enhanced visibility and troubleshooting (GA) Understanding query execution and troubleshooting errors has often required tedious trial and error. The new query execution details side pane surfaces rich, actionable metadata for every query—successful or failed. With this feature, you can: View execution time breakdowns, data sources, scopes, and resource utilization. Examine response characteristics and detailed error information. Navigate tabs such as overview, raw statistics, and errors for comprehensive diagnostics. Access the side pane easily after running a query, or even from error messages in failure scenarios. This transparency makes it far easier to investigate issues and optimize your hunting experience. Improved error-handling for Advanced hunting queries (GA) Advanced hunting now provides improved output messages, including clearer error messages that explain query failures and actionable suggestions for common issues. This update simplifies troubleshooting and helps reduce downtime with complex queries. Simpler Navigation, More Powerful Hunting Alongside these updates, the Advanced hunting UI has received several enhancements focused on usability and streamlined workflows. Users can now easily filter results with a single click, making data exploration more efficient and responsive and enhanced configuration of the schema tree now allows for collapsing or expanding all nodes with ease. Additionally, the page layout has been thoughtfully restructured, organizing components in a more intuitive manner for a modern, cohesive experience that makes advanced hunting both powerful and easy to use. Rename tabs (GA) Another notable usability enhancement is the ability for users to rename their working tabs within advanced hunting. This feature enables users to organize their work sessions more efficiently, allowing for clear identification of ongoing investigations and queries without requiring them to save their work as long-term functions or queries. By simply renaming tabs, users can quickly switch between tasks and keep their workspace well-structured, further improving workflow and productivity. Saving KQL functions to log analytics workspace (GA) In addition to the above enhancements, we are delighted to introduce the ability to save KQL functions directly from the advanced hunting page into your log analytics workspace. To utilize this feature: Pick a folder under shared functions → Sentinel workspace functions. Functions saved in this folder are available for use in workbooks, analytics rules, and for execution in advanced hunting. Note: functions saved here are not available in custom detection rules. This new capability empowers you to build reusable logic and streamline your security workflows across Microsoft Sentinel and advanced hunting. Conclusion These enhancements represent our continued commitment to supporting your security investigations with robust, flexible, and efficient tools. We look forward to your feedback and to bringing even more improvements in the future. Learn more about the new advanced hunting enhancements in our documentation.
Defending Container Runtime from Malware with Microsoft Defender for Containers
In cloud-native environments, malware protection is no longer traditional antivirus — it is runtime workload security, ensuring containerized applications remain safe throughout their lifecycle. Many organizations focus on scanning container images before deployment. While image scanning is important, this does not stop runtime attacks. Image scanning protects before deployment, but malware detection protects during execution. Malware can enter cloud environments through container images, compromised CI/CD pipelines, exposed services, or misuse of legitimate administrative tools, making runtime malware detection an essential security control rather than an optional enhancement. Runtime Malware detection and Prevention acts as the last line of defence when preventive controls fail. If malware executes successfully inside a container, it may attempt Privilege escalation, Container escape and Host compromise. Antimalware in Defender for Containers Defender for Containers antimalware, powered by Microsoft Defender Antivirus cloud protection, near-real-time malware detection directly into container environments. The antimalware feature is available via Helm with sensor version 0.10.2 for AKS, GKE, and EKS. Defender for Containers Sensor Defender for Containers Antimalware provides: Runtime monitoring of container activity Malware detection on Container Workloads Malware detection for Kubernetes nodes Alerts integrated into Defender XDR Anti-malware detection and blocking - Microsoft Defender for Cloud | Microsoft Learn Container antimalware protection in Defender for Containers is powered by three main components: 1) Defender Sensor - version 0.10.2 installed via Helm or arc-extension The Defender sensor runs inside the Kubernetes cluster and monitors workload activity in real time. It provides: Runtime visibility into container processes Binary execution monitoring Behavioral inspection Alert and Block Malware execution Multicloud Support (Azure Kubernetes Service, AWS EKS, GCP GKE) Prerequisites: Ensure the following components of the Defender for containers plan are enabled: Defender sensor Security findings Registry access Kubernetes API access To Install Defender Sensor for Antimalware, ensure there are sufficient resources on your Kubernetes Cluster and outbound connectivity. In addition to the core sensor memory and CPU requirements, you need: Component Request Limit CPU 50m 300m Memory 128Mi 500Mi All sensor components use outbound-only connectivity (no inbound access required). To install Defender for Containers sensor follow the guidance here To Verify the sensor deployed successfully on all nodes, use the commands as screenshot below: You should see the collectors pods in Running state with 3/3 containers. 2) Antimalware Policy Engine Policies define what happens when malware is detected: Alert only Block execution Ignore (allowlisted cases) Policies can be scoped to Azure subscriptions, AWS Accounts and GCP Projects and also to Specific clusters, Namespaces, Pods, Images, Labels or workloads. This allows organizations to reduce false positives while enforcing strict security where needed. Host vs Workload Protection — How Sensor Covers Both Antimalware Rules can be applied to Resource scopes: Scope What Is Protected Workload (Container) Processes inside containers Host (Node) Kubernetes node OS and runtime Default rules include: Default antimalware workload rule Default antimalware host rule This matters because attackers often escape containers and target kubelet, container runtime, and node filesystem. Blocking malware at both workload and host layers prevents cluster takeover. To configure the Antimalware policy follow the guidance here To verify the antimalware policy is deployed to the cluster, login to your K8s cluster and use the commands as screenshot below: 3) Cloud Protection (Microsoft Defender Antivirus Cloud) Defender for Containers Sensor integrates with Microsoft Defender Antivirus cloud protection, which provides Global threat intelligence, Machine learning classification, Reputation scoring, Zero-day detection. When suspicious binaries appear, cloud analysis determines whether they should be allowed or blocked. To test Malware detection and blocking, upload an EICAR file to a running Container on your cluster. If policy action = Block Malware, the sensor performs enforcement. Blocking actions include, Killing malicious process and Generates Defender for Cloud alert as below: The malware is detected and execution is blocked. Defender for Cloud Alerts are also available in Defender XDR portal. Security Operations teams can further investigate the infected file by navigating to the Incidents and Alerts section in the Defender portal. When a container or pod is determined to be compromised, Defender XDR enables Security Operations Team to take response actions. For more details : Investigate and respond to container threats in the Microsoft Defender portal Binary Drift Detection and Prevention : Containers are expected to be immutable. Running containers should only execute binaries that came from the original container image. This is extremely important because most container attacks involve Curl/wget downloading malware, Crypto miners dropped post-compromise, Attack tools installed dynamically. For more details refer Binary drift detection and blocking Defender detects runtime drift, such as New binaries downloaded after deployment Files written into container filesystem Tools installed via reverse shell Payloads dropped by attackers To Configure drift detection and prevention policy follow the guidance here . When a drift is detected on a container workload, Defender for Container sensor detects drift and prevents it from being drifted. To test drift prevention, deploy a container and introduce a drift in the running container. The drift will be detected by the sensor and prevents drift, and alert is generated as shown in the screenshot below: References: Anti-malware detection and blocking Install Defender for Containers sensor using Helm Binary drift detection and blocking Investigate and respond to container threats in the Microsoft Defender portal Reviewed by: Eyal Gur, Principal Product Manager, Microsoft Defender for CloudFrom signal to strategy: Closing attack paths with identity intelligence
Compromised credentials remain one of the most common entry points for attackers. In the first half of 2025 alone, identity-based attacks surged more than 32% and its estimated that 97% of them are password focused. While that scale is overwhelming, it only takes a single exposed account to give an attacker a foothold from which they can move laterally towards the critical assets they are after. At today’s attack scale, identity signals need to be connected with broader context to stop attacks earlier in the kill chain. Today we are excited to share more about how Microsoft Defender can help security professionals proactively understand how identity-related risks, like leaked credentials, relate back to critical assets, helping security professionals proactively close potential entry points before they can be exploited. Understanding leaked credentials and attack paths: Leaked credentials refer to valid usernames and passwords that have been exposed beyond their intended scope. Whether this exposure occurs as part of a data breach, phishing attack, or postings on dark web forums, the result is the same: an attacker may be using legitimate credentials to access your organization. Similarly, attack paths describe the sequence of misconfigurations, permissions, and trust relationships that an attacker can chain together to move from an initial foothold to high‑value resources. Rather than relying on a single vulnerability, attackers tend to think in graphs, following paths of least resistance to systematically escalate privileges and expand access. This makes identities the primary control plane they target and leaked credentials as an extremely common entry point. The recent Microsoft digital defense report put this into focus, stating that more than 61% of attack paths lead to a sensitive user. These user accounts have elevated privileges or access to critical resources meaning that if they were to be attacked or misused it would significantly impact the organization. Microsoft’s differentiated approach Most solutions stop at the alert and can only tell you that a password was exposed, found, or leaked. That information matters, but it is incomplete, it describes an event, not the risk. The real differentiation starts with the next question: what does this exposure mean for my environment right now. Not every exposed password creates the same level of risk. Context is what determines impact. Which identity does the password belong to? What assets can that identity access? Does that access still exists? And are those assets truly sensitive? That is why exposed password detection is a starting point, not an end state. Effective protection begins when organizations move beyond technical alerts and toward an identity-aware understanding. This shift from detection to context is where better decisions are made and where meaningful security value is created. This is why we took our identity alerts a step further, connecting these risks with broader security context to reveal how an initial identity signal can lead to sensitive users, critical assets, and core business operations. This perspective moves security beyond isolated alerts to prioritized, actionable insight that shows not just if risk exists, but how identity‑based threats could unfold and where to intervene to stop them before they have impact. In the case of leaked credentials, Microsoft continuously scans for exposed accounts across public and private breach sources. If a match is found, Microsoft’s Advanced Correlation Engine (MACE) automatically identifies the affected user within your organization and surfaces the exposure with clear severity and context. By bringing this powerful detection into Defender, teams can investigate and respond with better context, allowing leaked credentials to be evaluated alongside endpoint, email, and app activity, giving teams additional context needed to prioritize response. Additionally, for Microsoft Entra ID accounts we can go a step further validating whether the discovered credentials actually corresponds to a real, usable password for an identity in the tenant. This confirmation further reduces unnecessary noise and gives defenders an early signal - often before any malicious activity begins. Next, Microsoft Defender steps in to correlate these signals with your organization’s unique security context. Connecting the alert and associated account with other signals and like unusual authentications, lateral movement attempts, or privilege escalations, elevating the isolated alert into a complete story about any potential incidents related to that vulnerability. At the same time, Microsoft Exposure management is analyzing the same data to create a potential attack path related to the exposed credentials. By tracing permissions, consents, and access relationships, Attack Paths show exactly which routes an attacker could take and what controls will break that path. When these capabilities work together, visibility becomes action. MACE identifies who is exposed, Defender connects other signals into an incident level view and Attack Paths reveal where the attacker could go next. The result is a single, connected workflow that transforms early exposure data into prioritized, measurable risk reduction. Conclusion Leaked credentials should be treated as the beginning of a story, not an isolated event. Microsoft Defender is uniquely able to enrich security teams visibility and understanding of Identity-related threats from initial exposure to detection, risk prioritization, and remediation. This connected visibility fundamentally changes how defenders manage identity risk, shifting the focus from reacting to individual alerts to continuously reducing exposure and limiting blast radius. One leaked password doesn’t have to become a breach. With Microsoft’s identity security capabilities, it becomes a closed path, and a measurable step toward greater resilience. Learn more about attack paths and the new leaked credentials capabilities in Defender.Microsoft Defender for Cloud Customer Newsletter
What's new in Defender for Cloud? Now in public preview, Microsoft Security Private Link allows for private connectivity between Defender for Cloud and your workloads. For more information, see our public documentation. Blogs of the month In January, our team published the following blog posts we would like to share: Guarding Kubernetes Deployments: Runtime gating for vulnerable images now GA Architecting Trust: A NIST-Based Security Governance Framework for AI Agents Defender for Cloud in the field Revisit the announcement on the CloudStorageAggregatedEvents table in XDR’s Advanced Hunting experience. Storage aggregated logs in XDR’s advanced hunting Visit our YouTube page GitHub Community Update your Defender for SQL on machines extension at scale Update Defender for SQL extension at scale Visit our GitHub page Customer journey Discover how other organizations successfully use Microsoft Defender for Cloud to protect their cloud workloads. This month we are featuring Toyota Leasing Thailand. Toyota Leasing Thailand, a financial services subsidiary of Toyota, provides financing, insurance and mobility services and is entrusted with sensitive personal data. Integrating with Defender, Entra and Purview, Security Copilot provided the SOC and the IT team a unified view, streamlined operations and reporting to reduce response times on phishing attacks from hours to minutes. Join our community! We offer several customer connection programs within our private communities. By signing up, you can help us shape our products through activities such as reviewing product roadmaps, participating in co-design, previewing features, and staying up-to-date with announcements. Sign up at aka.ms/JoinCCP. We greatly value your input on the types of content that enhance your understanding of our security products. Your insights are crucial in guiding the development of our future public content. We aim to deliver material that not only educates but also resonates with your daily security challenges. Whether it’s through in-depth live webinars, real-world case studies, comprehensive best practice guides through blogs, or the latest product updates, we want to ensure our content meets your needs. Please submit your feedback on which of these formats do you find most beneficial and are there any specific topics you’re interested in https://aka.ms/PublicContentFeedback. Note: If you want to stay current with Defender for Cloud and receive updates in your inbox, please consider subscribing to our monthly newsletter: https://aka.ms/MDCNewsSubscribeMonthly news - January 2026
Microsoft Defender Monthly news - January 2026 Edition This is our monthly "What's new" blog post, summarizing product updates and various new assets we released over the past month across our Defender products. In this edition, we are looking at all the goodness from December 2025. Defender for Cloud has its own Monthly News post, have a look at their blog space. 🚀 New Virtual Ninja Show episode: Advancements in Attack Disruption Vulnerability Remediation Agent in Microsoft Intune Microsoft Defender (Public Preview) The following advanced hunting schema tables are now available for preview: The CampaignInfo table contains contains information about email campaigns identified by Microsoft Defender for Office 365 The FileMaliciousContentInfo table contains information about files that were processed by Microsoft Defender for Office 365 in SharePoint Online, OneDrive, and Microsoft Teams General Availability of the Security Alert Triage Agent (previously named Phishing Triage Agent): this agent autonomously analyzes user‑reported phishing emails to determine whether they’re true threats or false positives, dramatically reducing manual triage workload. It continuously learns from analyst feedback and provides clear, natural‑language explanations for every verdict, giving SOC teams both speed and transparency. We're excited to share it is now generally available and, very soon, will expand to also triage cloud and identity alerts! Learn more on our docs. Public Preview of Dynamic Threat Detection Agent: Announced at Ignite, this always‑on agent hunts for unseen threats by continuously correlating telemetry and creating new, context‑aware detections on the fly—closing gaps traditional rules can’t see. We're excited to share it is now in Public Preview! Learn more on our docs. Public Preview of Threat Hunting Agent: Announced at Ignite, this agent gives every analyst the power to investigate like an expert by turning natural‑language questions into guided, real‑time hunts that surface hidden patterns, reveal meaningful pivots, and eliminate the need to write complex queries. We're excited to share it is now in Public Preview! Learn more on our docs. General Availability of the Threat Intelligence Briefing Agent: this agent delivers daily, tailored intelligence briefings directly in Microsoft Defender—automatically synthesizing Microsoft’s global threat insights with your organization’s context to surface prioritized risks, clear recommendations, and relevant assets so teams can shift from reactive research to proactive defense in minutes. We're excited to share it is now generally available! Learn more on our docs. (General Availability) The hunting graph in advanced hunting is now generally available. It also now has two new predefined threat scenarios that you can use to render your hunts as interactive graphs. (General Availability) Advanced hunting now supports custom functions that use tabular parameters. With tabular parameters, you can pass entire tables as inputs. This approach lets you build more modular, reusable, and expressive logic across your hunting queries. Learn more Note: The Phishing Triage Agent has since been expanded and is now called the Security Alert Triage Agent. Learn more at aka.ms/SATA Microsoft Defender for Endpoint (Public Preview) Triage collection: Use triage collection to prioritize incidents and hunt threats with the Sentinel Model Context Protocol (MCP) server. Microsoft Defender for Identity New ADWS LDAP search activity is now available in the 'IdentityQueryEvents' table in Advanced Hunting. This can provides visibility into directory queries performed through ADWS, helping customers track these operations and create custom detection based on this data. (Public Preview) New properties for 'sensorCandidate' resource type in Graph-API. Learn more here. Microsoft Defender for Cloud Apps Integration of Defender for Cloud Apps permissions with Microsoft Defender XDR Unified RBAC is now available worldwide. For more information, see Map Microsoft Defender for Cloud Apps permissions to the Microsoft Defender XDR Unified RBAC permissions. To activate the Defender for Cloud Apps workload, see Activate Microsoft Defender XDR Unified RBAC. (Public Preview) The Defender for Cloud Apps app governance unused app insights feature helps administrators identify and manage unused Microsoft 365-connected OAuth apps, enforce policy-based governance, and use advanced hunting queries for better security. This feature is now available for most commercial cloud customers. For more information, see Secure apps with app hygiene features.
