Custom detections are now the unified experience for creating detections in Microsoft Defender
As we continue to deliver on our vision to simplify security workflows for the SOC, we are making custom detections the unified solution for building and managing rules over Defender XDR and Sentinel data. While analytics rules remain available, we recommend using custom detections for access to new features and enhancements. Benefits of unified custom detections Adopting custom detections as the primary method for rule management helps streamline operations and enhance security. You can refer to this page for a full list of the benefits. Some highlights include: Single experience – One interface for managing detections across all data sources, and the ability to create rules across SIEM and XDR without additional ingestion costs. Cost reduction – Write a detection combining XDR and Sentinel data without extra Sentinel ingestion costs. Faster detection – Near real-time streaming technology. Custom detection reduces Kusto cluster load and allows unlimited number of NRT rules. Built-in XDR functions – Expand functionality previously only available in XDR to use in SIEM detections, such as FileProfile(), SeenBy(), DeviceFromIP() and AssignedIPAddresses(). Native XDR remediation actions – Native XDR remediation actions are available to be configured to automatically run when a custom detection fires. The new experience for unified rules management Custom detection is the default wizard when creating a detection from advanced hunting. If your use case still requires using an analytics rule, you can click on the “create analytics rule” button from the custom detection wizard. FAQs Q: Should I stop using analytics rules? A: While we continue to build out custom detections as the primary engine for rule creation across SIEM and XDR, analytics rules may still be required in some use cases. You are encouraged to use the comparison table in our public documentation to decide if analytics rules is needed for a specific use case. No immediate action is necessary for moving existing analytics rules to detection rules. Q: Are any immediate actions required? A: No action is currently necessary. Custom detections should be used when suitable for a scenario, as we will continue to invest in new capabilities for this feature. Q: Will custom detections have feature parity with Analytics Rules? A: Yes, we are working toward parity. Learn more about adopting custom detections Please refer to our public documentation for a detailed and updated comparison. 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 >Monthly news - November 2025
Microsoft Defender Monthly news - November 2025 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 October 2025. Defender for Cloud has its own Monthly News post, have a look at their blog space. ⏰ Microsoft Ignite 2025 November 18-20, register now! 🚀 New Virtual Ninja Show episode: What’s new for Microsoft Teams protection in Defender for Office 365 Microsoft Defender Custom detections are now the unified experience for creating detections in Microsoft Defender! Read this blog for all the details. How Microsoft Defender helps security teams detect prompt injection attacks in Microsoft 365 Copilot. We’re excited to share that Microsoft Defender now provides visibility into prompt injection attempts within Microsoft 365 Copilot and helps security teams detect and respond to prompt injection attacks more efficiently and at a broader context, with insights that go beyond individual interaction. Microsoft Defender Experts for Hunting reports now include an Emerging threats section that details the proactive, hypothesis-based hunts we conducted in your environment. Each report also now includes investigation summaries for nearly every hunt that Defender Experts conduct in your environment, regardless of whether they identified a confirmed threat. Microsoft Defender Experts for XDR reports now include a Trends tab provides you with the monthly volume of investigated and resolved incidents for the last six months, visualized according to the incidents' severity, MITRE tactic, and threat type. This section gives you insight into how Defender Experts are tangibly improving your security operations by showing important operational metrics on a month-over-month basis. Threat Intelligence Export is now available in Microsoft Sentinel. Traditionally, Microsoft Sentinel has supported importing threat intel from external sources (partners, governments, ISACs, or internal tenants) via Structured Threat Information eXpression (STIX) via Trusted Automated eXchange of Intelligence Information (TAXII). With this new export feature, you can now share curated threat intel back to trusted destinations. This empowers security teams to contribute threat intel to other organizations in support of collective defense, or to their own central platform to add or enrich threat intelligence. Microsoft Defender for Identity We’re excited to announce that the Defender for Identity Unified Sensor (v3.x) is now generally available (GA). The unified sensor provides enhanced coverage, improved performance across your environment and offering easier deployment and management for domain controllers. Learn more on how to active it in our docs.. Microsoft Defender for Office 365 📘 Email Authentication SecOps Guide (New learn doc) - visit & bookmark our short link: https://aka.ms/authguide The following docs article has been updated with with Compauth Codes: Message Headers Reference New blog series: Best practices from the Microsoft Community Defender for Office 365: Migration & Onboarding Onboarding to Microsoft Defender for Office 365 is often treated as a quick setup task, but it should be seen as a critical opportunity to establish strong security foundations. In my roles supporting incident response and security operations in Microsoft 365, I have observed that onboarding is often underestimated. - Purav Desai, Dual Microsoft Security MVP (Most Valuable Professional) This blog covers four key areas that are frequently missed, but they are essential for a secure and auditable deployment of Defender for Office 365. Before diving into the technical details, it is important to clarify a common misconception about Defender for Office 365 protections. Safeguarding Microsoft Teams with Microsoft Defender for Office 365 As organizations rely more on Microsoft Teams for daily collaboration, securing this platform has become a top priority. Threat actors are increasingly targeting Teams chats and channels with phishing links and malicious files, making it critical for IT admins and security professionals to extend protection beyond email. Enter Microsoft Defender for Office 365, now armed with dedicated Teams protection capabilities. Microsoft Defender for Office 365 enables users to report suspicious messages, brings time-of-click scanning of URLs and files into Teams conversations, and provides rich alerts and hunting insights for SecOps teams. As a collaborative piece between Pierre Thoor, a Microsoft Security MVP, and the Defender for Office 365 Product Engineering Team, this guides with accompanying videos emphasize a proactive, user-driven approach to threat detection and response, turning everyday Teams interactions into actionable security signals for SecOps. Microsoft Defender for Endpoint End of Windows 10 Support: What Defender Customers Need to Know As of October 14, 2025, Microsoft officially ended support for Windows 10. This means that Windows 10 devices will no longer receive security or feature updates, nor technical support from Microsoft. While these devices will continue to operate, the lack of regular security updates increases vulnerability to cyber threats, including malware and viruses. Applications running on Windows 10 may also lose support as the platform stops receiving updates. Endpoint Security Policies can now be distributed via MTO's (Multi Tenant Organization) Content Distribution capability. This capability moved from Public Preview to General Availability (GA). With this capability, you can create content distribution profiles in the multi-tenant portal that allow you to seamlessly replicate existing content - such as custom detection rules and now, endpoint security policies - from a source tenant to designated target tenants. Once distributed, the content runs on the target tenant, enabling centralized control with localized execution. You can read the announcement blog for public preview, as the content shares valuable insights. (Public Preview) Streamlined connectivity support for US government environments (GCC, GCC High, DoD). Learn more in our docs. (General Availability) Isolation exclusions. The Isolation exclusions feature is now generally available. Isolation exclusions allow designated processes or endpoints to bypass the restrictions of network isolation, ensuring essential functions continue while limiting broader network exposure. Learn more in our docs. Microsoft Defender Vulnerability Management (Public Preview) Microsoft Secure Score now includes three new Attack Surface Reduction (ASR) based proactive recommendations that help organizations prevent common endpoint attack techniques including web-shell persistence, misuse of system tools, and Safe Mode based evasion. (Public Preview) You can now use CVE exceptions to exclude specific Common Vulnerabilities and Exposures (CVEs) from analysis in your environment. CVE exceptions allow you to control what type of data is relevant to your organization and to selectively exclude certain data from your remediation efforts. For more information, see Exceptions in Microsoft Defender Vulnerability Management and Create, view, and manage exceptions. For more information, see Exceptions in Microsoft Defender Vulnerability Management and Create, view, and manage exceptions. Microsoft Security Blogs The new Microsoft Security Store unites partners and innovation On September 30, 2025, Microsoft announced a bold new vision for security: a unified, AI-powered platform designed to help organizations defend against today’s most sophisticated cyberthreats. But an equally important story—one that’s just beginning to unfold—is how the Microsoft Security Store is bringing this vision to life through a vibrant ecosystem of partners, developers, and innovators—all contributing together to deliver more value and security to our customers. Security Store is the gateway for customers to easily discover, buy, and deploy trusted security solutions and AI agents from leading partners—all verified by Microsoft Security product teams to work seamlessly with Microsoft Security products. Inside the attack chain: Threat activity targeting Azure Blob Storage Azure Blob Storage is a high-value target for threat actors due to its critical role in storing and managing massive amounts of unstructured data at scale across diverse workloads and is increasingly targeted through sophisticated attack chains that exploit misconfigurations, exposed credentials, and evolving cloud tactics. Investigating targeted “payroll pirate” attacks affecting US universities Microsoft Threat Intelligence has identified a financially motivated threat actor that we track as Storm-2657 compromising employee accounts to gain unauthorized access to employee profiles and divert salary payments to attacker-controlled accounts, attacks that have been dubbed “payroll pirate”. Disrupting threats targeting Microsoft Teams Threat actors seek to abuse Microsoft Teams features and capabilities across the attack chain, underscoring the importance for defenders to proactively monitor, detect, and respond effectively. Harden your identity defense with improved protection, deeper correlation, and richer context Expanded ITDR features—including the new Microsoft Defender for Identity sensor, now generally available—bring improved protection, correlation, and context to help customers modernize their identity defense.Detecting browser anomalies to disrupt attacks early
Uncover the secrets of early attack disruption with browser anomaly detections! This blog post explores how Microsoft Defender XDR leverages advanced techniques to identify unusual browser activities and stop cyber threats in their tracks. Learn about the importance of monitoring unusual browser activities, session hijacking, Business Email Compromise (BEC), and other critical attack paths. With real-world examples and insights into the systematic approach used by Defender XDR, you'll gain a deeper understanding of how to enhance your organization's security posture. Don't miss out on this essential read for staying ahead of cyber threats!GenAI vs Cyber Threats: Why GenAI Powered Unified SecOps Wins
Cybersecurity is evolving faster than ever. Attackers are leveraging automation and AI to scale their operations, so how can defenders keep up? The answer lies in Microsoft Unified Security Operations powered by Generative AI (GenAI). This opens the Cybersecurity Paradox: Attackers only need one successful attempt, but defenders must always be vigilant, otherwise the impact can be huge. Traditional Security Operation Centers (SOCs) are hampered by siloed tools and fragmented data, which slows response and creates vulnerabilities. On average, attackers gain unauthorized access to organizational data in 72 minutes, while traditional defense tools often take on average 258 days to identify and remediate. This is over eight months to detect and resolve breaches, a significant and unsustainable gap. Notably, Microsoft Unified Security Operations, including GenAI-powered capabilities, is also available and supported in Microsoft Government Community Cloud (GCC) and GCC High/DoD environments, ensuring that organizations with the highest compliance and security requirements can benefit from these advanced protections. The Case for Unified Security Operations Unified security operations in Microsoft Defender XDR consolidates SIEM, XDR, Exposure management, and Enterprise Security Posture into a single, integrated experience. This approach allows the following: Breaks down silos by centralizing telemetry across identities, endpoints, SaaS apps, and multi-cloud environments. Infuses AI natively into workflows, enabling faster detection, investigation, and response. Microsoft Sentinel exemplifies this shift with its Data Lake architecture (see my previous post on Microsoft Sentinel’s New Data Lake: Cut Costs & Boost Threat Detection), offering schema-on-read flexibility for petabyte-scale analytics without costly data rehydration. This means defenders can query massive datasets in real time, accelerating threat hunting and forensic analysis. GenAI: A Force Multiplier for Cyber Defense Generative AI transforms security operations from reactive to proactive. Here’s how: Threat Hunting & Incident Response GenAI enables predictive analytics and anomaly detection across hybrid identities, endpoints, and workloads. It doesn’t just find threats—it anticipates them. Behavioral Analytics with UEBA Advanced User and Entity Behavior Analytics (UEBA) powered by AI correlates signals from multi-cloud environments and identity providers like Okta, delivering actionable insights for insider risk and compromised accounts. [13 -Micros...s new UEBA | Word] Automation at Scale AI-driven playbooks streamline repetitive tasks, reducing manual workload and accelerating remediation. This frees analysts to focus on strategic threat hunting. Microsoft Innovations Driving This Shift For SOC teams and cybersecurity practitioners, these innovations mean you spend less time on manual investigations and more time leveraging actionable insights, ultimately boosting productivity and allowing you to focus on higher-value security work that matters most to your organization. Plus, by making threat detection and response faster and more accurate, you can reduce stress, minimize risk, and demonstrate greater value to your stakeholders. Sentinel Data Lake: Unlocks real-time analytics at scale, enabling AI-driven threat detection without rehydration costs. Microsoft Sentinel data lake overview UEBA Enhancements: Multi-cloud and identity integrations for unified risk visibility. Sentinel UEBA’s Superpower: Actionable Insights You Can Use! Now with Okta and Multi-Cloud Logs! Security Copilot & Agentic AI: Harnesses AI and global threat intelligence to automate detection, response, and compliance across the security stack, enabling teams to scale operations and strengthen Zero Trust defenses defenders. Security Copilot Agents: The New Era of AI, Driven Cyber Defense Sector-Specific Impact All sectors are different, but I would like to focus a bit on the public sector at this time. This sector and critical infrastructure organizations face unique challenges: talent shortages, operational complexity, and nation-state threats. GenAI-centric platforms help these sectors shift from reactive defense to predictive resilience, ensuring mission-critical systems remain secure. By leveraging advanced AI-driven analytics and automation, public sector organizations can streamline incident detection, accelerate response times, and proactively uncover hidden risks before they escalate. With unified platforms that bridge data silos and integrate identity, endpoint, and cloud telemetry, these entities gain a holistic security posture that supports compliance and operational continuity. Ultimately, embracing generative AI not only helps defend against sophisticated cyber adversaries but also empowers public sector teams to confidently protect the services and infrastructure their communities rely on every day. Call to Action Artificial intelligence is driving unified cybersecurity. Solutions like Microsoft Defender XDR and Sentinel now integrate into a single dashboard, consolidating alerts, incidents, and data from multiple sources. AI swiftly correlates information, prioritizes threats, and automates investigations, helping security teams respond quickly with less manual work. This shift enables organizations to proactively manage cyber risks and strengthen their resilience against evolving challenges. Picture a single pane of glass where all your XDRs and Defenders converge, AI instantly shifts through the noise, highlighting what matters most so teams can act with clarity and speed. That may include: Assess your SOC maturity and identify silos. Use the Security Operations Self-Assessment Tool to determine your SOC’s maturity level and provide actionable recommendations for improving processes and tooling. Also see Security Maturity Model from the Well-Architected Framework Explore Microsoft Sentinel, Defender XDR, and Security Copilot for AI-powered security. Explains progressive security maturity levels and strategies for strengthening your security posture. What is Microsoft Defender XDR? - Microsoft Defender XDR and What is Microsoft Security Copilot? Design Security in Solutions from Day One! Drive embedding security from the start of solution design through secure-by-default configurations and proactive operations, aligning with Zero Trust and MCRA principles to build resilient, compliant, and scalable systems. Design Security in Solutions from Day One! Innovate boldly, Deploy Safely, and Never Regret it! Upskill your teams on GenAI tools and responsible AI practices. Guidance for securing AI apps and data, aligned with Zero Trust principles Build a strong security posture for AI About the Author: Hello Jacques "Jack” here! I am a Microsoft Technical Trainer focused on helping organizations use advanced security and AI solutions. I create and deliver training programs that combine technical expertise with practical use, enabling teams to adopt innovations like Microsoft Sentinel, Defender XDR, and Security Copilot for stronger cyber resilience. #SkilledByMTT #MicrosoftLearnAutomating Microsoft Sentinel: Part 2: Automate the mundane away
Welcome to the second entry of our blog series on automating Microsoft Sentinel. In this series, we’re showing you how to automate various aspects of Microsoft Sentinel, from simple automation of Sentinel Alerts and Incidents to more complicated response scenarios with multiple moving parts. So far, we’ve covered Part 1: Introduction to Automating Microsoft Sentinel where we talked about why you would want to automate as well as an overview of the different types of automation you can do in Sentinel. Here is a preview of what you can expect in the upcoming posts [we’ll be updating this post with links to new posts as they happen]: Part 1: Introduction to Automating Microsoft Sentinel Part 2: Automation Rules [You are here] – Automate the mundane away Part 3: Playbooks 1 – Playbooks Part I – Fundamentals Part 4: Playbooks 2 – Playbooks Part II – Diving Deeper Part 5: Azure Functions / Custom Code Part 6: Capstone Project (Art of the Possible) – Putting it all together Part 2: Automation Rules – Automate the mundane away Automation rules can be used to automate Sentinel itself. For example, let’s say there is a group of machines that have been classified as business critical and if there is an alert related to those machines, then the incident needs to be assigned to a Tier 3 response team and the severity of the alert needs to be raised to at least “high”. Using an automation rule, you can take one analytic rule, apply it to the entire enterprise, but then have an automation rule that only applies to those business-critical systems to make those changes. That way only the items that need that immediate escalation receive it, quickly and efficiently. Automation Rules In Depth So, now that we know what Automation Rules are, let’s dive in to them a bit deeper to better understand how to configure them and how they work. Creating Automation Rules There are three main places where we can create an Automation Rule: 1) Navigating to Automation under the left menu 2) In an existing Incident via the “Actions” button 3) When writing an Analytic Rule, under the “Automated response” tab The process for each is generally the same, except for the Incident route and we’ll break that down more in a bit. When we create an Automation Rule, we need to give the rule a name. It should be descriptive and indicative of what the rule is going to do and what conditions it applies to. For example, a rule that automatically resolves an incident based on a known false positive condition on a server named SRV02021 could be titled “Automatically Close Incident When Affected Machine is SRV02021” but really it’s up to you to decide what you want to name your rules. Trigger The next thing we need to define for our Automation Rule is the Trigger. Triggers are what cause the automation rule to begin running. They can fire when an incident is created or updated, or when an alert is created. Of the two options (incident based or alert based), it’s preferred to use incident triggers as they’re potentially the aggregation of multiple alerts and the odds are that you’re going to want to take the same automation steps for all of the alerts since they’re all related. It’s better to reserve alert-based triggers for scenarios where an analytic rule is firing an alert, but is set to not create an incident. Conditions Conditions are, well, the conditions to which this rule applies. There are two conditions that are always present: The Incident provider and the Analytic rule name. You can choose multiple criterion and steps. For example, you could have it apply to all incident providers and all rules (as shown in the picture above) or only a specific provider and all rules, or not apply to a particular provider, etc. etc. You can also add additional Conditions that will either include or exclude the rule from running. When you create a new condition, you can build it out by multiple properties ranging from information about the Incident all the way to information about the Entities that are tagged in the incident Remember our earlier Automation Rule title where we said this was a false positive about a server name SRV02021? This is where we make the rule match that title by setting the Condition to only fire this automation if the Entity has a host name of “SRV2021” By combining AND and OR group clauses with the built in conditional filters, you can make the rule as specific as you need it to be. You might be thinking to yourself that it seems like while there is a lot of power in creating these conditions, it might be a bit onerous to create them for each condition. Recall earlier where I said the process for the three ways of creating Automation Rules was generally the same except using the Incident Action route? Well, that route will pre-fill variables for that selected instance. For example, for the image below, the rule automatically took the rule name, the rules it applies to as well as the entities that were mapped in the incident. You can add, remove, or modify any of the variables that the process auto-maps. NOTE: In the new Unified Security Operations Platform (Defender XDR + Sentinel) that has some new best practice guidance: If you've created an automation using "Title" use "Analytic rule name" instead. The Title value could change with Defender's Correlation engine. The option for "incident provider" has been removed and replaced by "Alert product names" to filter based on the alert provider. Actions Now that we’ve tuned our Automation Rule to only fire for the situations we want, we can now set up what actions we want the rule to execute. Clicking the “Actions” drop down list will show you the options you can choose When you select an option, the user interface will change to map to your selected option. For example, if I choose to change the status of the Incident, the UX will update to show me a drop down menu with options about which status I would like to set. If I choose other options (Run playbook, change severity, assign owner, add tags, add task) the UX will change to reflect my option. You can assign multiple actions within one Automation Rule by clicking the “Add action” button and selecting the next action you want the system to take. For example, you might want to assign an Incident to a particular user or group, change its severity to “High” and then set the status to Active. Notably, when you create an Automation rule from an Incident, Sentinel automatically sets a default action to Change Status. It sets the automation up to set the Status to “Closed” and a “Benign Positive – Suspicious by expected”. This default action can be deleted and you can then set up your own action. In a future episode of this blog we’re going to be talking about Playbooks in detail, but for now just know that this is the place where you can assign a Playbook to your Automation Rules. There is one other option in the Actions menu that I wanted to specifically talk about in this blog post though: Incident Tasks Incident Tasks Like most cybersecurity teams, you probably have a run book of the different tasks or steps that your analysts and responders should take for different situations. By using Incident Tasks, you can now embed those runbook steps directly in the Incident. Incident tasks can be as lightweight or as detailed as you need them to be and can include rich formatting, links to external content, images, etc. When an incident with Tasks is generated, the SOC team will see these tasks attached as part of the Incident and can then take the defined actions and check off that they’ve been completed. Rule Lifetime and Order There is one last section of Automation rules that we need to define before we can start automating the mundane away: when should the rule expire and in what order should the rule run compared to other rules. When you create a rule in the standalone automation UX, the default is for the rule to expire at an indefinite date and time in the future, e.g. forever. You can change the expiration date and time to any date and time in the future. If you are creating the automation rule from an Incident, Sentinel will automatically assume that this rule should have an expiration date and time and sets it automatically to 24 hours in the future. Just as with the default action when created from an incident, you can change the date and time of expiration to any datetime in the future, or set it to “Indefinite” by deleting the date. Conclusion In this blog post, we talked about Automation Rules in Sentinel and how you can use them to automate mundane tasks in Sentinel as well as leverage them to help your SOC analysts be more effective and consistent in their day-to-day with capabilities like Incident Tasks. Stay tuned for more updates and tips on automating Microsoft Sentinel!Microsoft Sentinel’s AI-driven UEBA ushers in the next era of behavioral analytics
Co-author - Ashwin Patil Security teams today face an overwhelming challenge: every data point is now a potential security signal and SOCs are drowning in complex logs, trying to find the needle in the haystack. Microsoft Sentinel User and Entity Behavior Analytics (UEBA) brings the power of AI to automatically surface anomalous behaviors, helping analysts cut through the noise, save time, and focus on what truly matters. Microsoft Sentinel UEBA has already helped SOCs uncover insider threats, detect compromised accounts, and reveal subtle attack signals that traditional rule-based methods often miss. These capabilities were previously powered by a core set of high-value data sources - such as sign-in activity, audit logs, and identity signals - that consistently delivered rich context and accurate detections. Today, we’re excited to announce a major expansion: Sentinel UEBA now supports six new data sources including Microsoft first- and third-party platforms like Azure, AWS, GCP, and Okta, bringing deeper visibility, broader context, and more powerful anomaly detection tailored to your environment. This isn’t just about ingesting more logs. It’s about transforming how SOCs understand behavior, detect threats, and prioritize response. With this evolution, analysts gain a unified, cross-platform view of user and entity behavior, enabling them to correlate signals, uncover hidden risks, and act faster with greater confidence. Newly supported data sources are built for real-world security use cases: Authentication activities MDE DeviceLogonEvents – Ideal for spotting lateral movement and unusual access. AADManagedIdentitySignInLogs – Critical for spotting stealthy abuse of non - human identities. AADServicePrincipalSignInLogs - Identifying anomalies in service principal usage such as token theft or over - privileged automation. Cloud platforms & identity management AWS CloudTrail Login Events - Surfaces risky AWS account activity based on AWS CloudTrail ConsoleLogin events and logon related attributes. GCP Audit Logs - Failed IAM Access, Captures denied access attempts indicating reconnaissance, brute force, or privilege misuse in GCP. Okta MFA & Auth Security Change Events – Flags MFA challenges, resets, and policy modifications that may reveal MFA fatigue, session hijacking, or policy tampering. Currently supports the Okta_CL table (unified Okta connector support coming soon). These sources feed directly into UEBA’s entity profiles and baselines - enriching users, devices, and service identities with behavioral context and anomalies that would otherwise be fragmented across platforms. This will complement our existing supported log sources - monitoring Entra ID sign-in logs, Azure Activity logs and Windows Security Events. Due to the unified schema available across data sources, UEBA enables feature-rich investigation and the capability to correlate across data sources, cross platform identities or devices insights, anomalies, and more. AI-powered UEBA that understands your environment Microsoft Sentinel UEBA goes beyond simple log collection - it continuously learns from your environment. By applying AI models trained on your organization’s behavioral data, UEBA builds dynamic baselines and peer groups, enabling it to spot truly anomalous activity. UBEA builds baselines from 10 days (for uncommon activities) to 6 months, both for the user and their dynamically calculated peers. Then, insights are surfaced on the activities and logs - such as an uncommon activity or first-time activity - not only for the user but among peers. Those insights are used by an advanced AI model to identify high confidence anomalies. So, if a user signs in for the first time from an uncommon location, a common pattern in the environment due to reliance on global vendors, for example, then this will not be identified as an anomaly, keeping the noise down. However, in a tightly controlled environment, this same behavior can be an indication of an attack and will surface in the Anomalies table. Including those signals in custom detections can help affect the severity of an alert. So, while logic is maintained, the SOC is focused on the right priorities. How to use UEBA for maximum impact Security teams can leverage UEBA in several key ways. All the examples below leverage UEBA’s dynamic behavioral baselines looking back up to 6 months. Teams can also leverage the hunting queries from the "UEBA essentials" solution in Microsoft Sentinel's Content Hub. Behavior Analytics: Detect unusual logon times, MFA fatigue, or service principal misuse across hybrid environments. Get visibility into geo-location of events and Threat Intelligence insights. Here’s an example of how you can easily discover Accounts authenticating without MFA and from uncommonly connected countries using UEBA behaviorAnalytics table: BehaviorAnalytics | where TimeGenerated > ago(7d) | where EventSource == "AwsConsoleSignIn" | where ActionType == "ConsoleLogin" and ActivityType == "signin.amazonaws.com" | where ActivityInsights.IsMfaUsed == "No" | where ActivityInsights.CountryUncommonlyConnectedFromInTenant == True | evaluate bag_unpack(UsersInsights, "AWS_") | where InvestigationPriority > 0 // Filter noise - uncomment if you want to see low fidelity noise | project TimeGenerated, _WorkspaceId, ActionType, ActivityType, InvestigationPriority, SourceIPAddress, SourceIPLocation, AWS_UserIdentityType, AWS_UserIdentityAccountId, AWS_UserIdentityArn Anomaly detection Identify lateral movement, dormant account reactivation, or brute-force attempts, even when they span cloud platforms. Below are examples of how to discover UEBA Anomalous AwsCloudTrail anomalies via various UEBA activity insights or device insights attributes: Anomalies | where AnomalyTemplateName in ( "UEBA Anomalous Logon in AwsCloudTrail", // AWS ClousTrail anomalies "UEBA Anomalous MFA Failures in Okta_CL", "UEBA Anomalous Activity in Okta_CL", // Okta Anomalies "UEBA Anomalous Activity in GCP Audit Logs", // GCP Failed IAM access anomalies "UEBA Anomalous Authentication" // For Authentication related anomalies ) | project TimeGenerated, _WorkspaceId, AnomalyTemplateName, AnomalyScore, Description, AnomalyDetails, ActivityInsights, DeviceInsights, UserInsights, Tactics, Techniques Alert optimization Use UEBA signals to dynamically adjust alert severity in custom detections—turning noisy alerts into high-fidelity detections. The example below shows all the users with anomalous sign in patterns based on UEBA. Joining the results with any of the AWS alerts with same AWS identity will increase fidelity. BehaviorAnalytics | where TimeGenerated > ago(7d) | where EventSource == "AwsConsoleSignIn" | where ActionType == "ConsoleLogin" and ActivityType == "signin.amazonaws.com" | where ActivityInsights.FirstTimeConnectionViaISPInTenant == True or ActivityInsights.FirstTimeUserConnectedFromCountry == True | evaluate bag_unpack(UsersInsights, "AWS_") | where InvestigationPriority > 0 // Filter noise - uncomment if you want to see low fidelity noise | project TimeGenerated, _WorkspaceId, ActionType, ActivityType, InvestigationPriority, SourceIPAddress, SourceIPLocation, AWS_UserIdentityType, AWS_UserIdentityAccountId, AWS_UserIdentityArn, ActivityInsights | evaluate bag_unpack(ActivityInsights) Another example shows anomalous key vault access from service principal with uncommon source country location. Joining this activity with other alerts from the same service principle increases fidelity of the alerts. You can also join the anomaly UEBA Anomalous Authentication with other alerts from the same identity to bring the full power of UEBA into your detections. BehaviorAnalytics | where TimeGenerated > ago(1d) | where EventSource == "Authentication" and SourceSystem == "AAD" | evaluate bag_unpack(ActivityInsights) | where LogonMethod == "Service Principal" and Resource == "Azure Key Vault" | where ActionUncommonlyPerformedByUser == "True" and CountryUncommonlyConnectedFromByUser == "True" | where InvestigationPriority > 0 Final thoughts This release marks a new chapter for Sentinel UEBA—bringing together AI, behavioral analytics, and cross-cloud and identity management visibility to help defenders stay ahead of threats. If you haven’t explored UEBA yet, now’s the time. Enable it in your workspace settings and don’t forget to enable anomalies as well (in Anomalies settings). And if you’re already using it, these new sources will help you unlock even more value. Stay tuned for our upcoming Ninja show and webinar (register at aka.ms/secwebinars), where we’ll dive deeper into use cases. Until then, explore the new sources, use the UEBA workbook, update your watchlists, and let UEBA do the heavy lifting. UEBA onboarding and setting documentation Identify threats using UEBA UEBA enrichments and insights reference UEBA anomalies referenceIntroducing the new PowerShell Module for Microsoft Defender for Identity
Today, I am excited to introduce a new PowerShell module designed to help further simplify the deployment and configuration of Microsoft Defender for Identity. This tool will make it easier than ever to protect your organization from identity-based cyber-threats.Detecting and Alerting on MDE Sensor Health Transitions Using KQL and Logic Apps
Introduction Maintaining the health of Microsoft Defender for Endpoint (MDE) sensors is essential for ensuring continuous security visibility across your virtual machine (VM) infrastructure. When a sensor transitions from an "Active" to an "Inactive" state, it indicates a loss of telemetry from that device and potentially creating blind spots in your security posture. To proactively address this risk, it's important to detect these transitions promptly and alert your security team for timely remediation. This guide walks you through a practical approach to automate this process using a Kusto Query Language (KQL) script to identify sensor health state changes, and an Azure Logic App to trigger email alerts. By the end, you'll have a fully functional, automated monitoring solution that enhances your security operations with minimal manual effort. Why Monitoring MDE Sensor Health Transitions is Important Ensures Continuous Security Visibility MDE sensors provide critical telemetry data from endpoints. If a sensor becomes inactive, that device stops reporting, creating a blind spot in your security monitoring. Prevents Delayed Threat Detection Inactive sensors can delay the identification of malicious activity, giving attackers more time to operate undetected within your environment. Supports Effective Incident Response Without telemetry, incident investigations become harder and slower, reducing your ability to respond quickly and accurately to threats. Identifies Root Causes Early Monitoring transitions helps uncover underlying issues such as service disruptions, misconfigurations, or agent failures that may otherwise go unnoticed. Closes Security Gaps Proactively Early detection of inactive sensors allows teams to take corrective action before adversaries exploit the lapse in coverage. Enables Automation and Scalability Using KQL and Logic Apps automates the detection and alerting process, reducing manual effort and ensuring consistent monitoring across large environments. Improves Operational Efficiency Automated alerts reduce the need for manual checks, freeing up security teams to focus on higher-priority tasks. Strengthens Overall Security Posture Proactive monitoring and fast remediation contribute to a more resilient and secure infrastructure. Prerequisites MDE Enabled: Defender for Endpoint must be active and reporting on all relevant devices. Stream DeviceInfo table (from Defender XDR connector) in Microsoft Sentinel’s workspace: Required to run KQL queries and manage alerts. Log Analytics Workspace: To run the KQL query. Azure Subscription: Needed to create and manage Logic Apps. Permissions: Sufficient RBAC access to Logic Apps, Log Analytics, and email connectors. Email Connector Setup: Outlook, SendGrid, or similar must be configured in Logic Apps. Basic Knowledge: Familiarity with KQL and Logic App workflows is helpful. High-level summary of the Logic Apps flow for monitoring MDE sensor health transitions: Trigger: Recurrence The Logic App starts on a scheduled basis (e.g., weekly or daily or hourly) using a recurrence trigger. Action: Run KQL Query Executes a Kusto Query against the Log Analytics workspace to detect devices where the MDE sensor transitioned from Active to Inactive in the last 7 days. Condition (Optional): Check for Results Optionally checks if the query returned any results to avoid sending empty alerts. Action: Send Email Notification If results are found, an email is sent to the security team with details of the affected devices using dynamic content from the query output. Logic Apps Flow KQL Query to Detect Sensor Transitions Use the following KQL query in Microsoft Defender XDR or Microsoft Sentinel to identify VMs where the sensor health state changed from Active to Inactive in the last 7 days: DeviceInfo | where Timestamp >= ago(7d) | project DeviceName, DeviceId, Timestamp, SensorHealthState | sort by DeviceId asc, Timestamp asc | serialize | extend PrevState = prev(SensorHealthState) | where PrevState == "Active" and SensorHealthState == "Inactive" | summarize FirstInactiveTime = min(Timestamp) by DeviceName, DeviceId | extend DaysInactive = datetime_diff('day', now(), FirstInactiveTime) | order by FirstInactiveTime desc This KQL query does the following: Detects devices whose sensors have stopped functioning (changed from Active to Inactive) in the past 7 days. Provides the first time this happened for each affected device. It also tells you how long each device has been inactive. Sample Email for reference How This Helps the Security Team Maintains Endpoint Visibility Detects when devices stop reporting telemetry, helping prevent blind spots in threat detection. Enables Proactive Threat Management Identifies sensor health issues before they become security incidents, allowing early intervention. Reduces Manual Monitoring Effort Automates the detection and alerting process, freeing up analysts to focus on higher-priority tasks. Improves Incident Response Readiness Ensures all endpoints are actively monitored, which is critical for timely and accurate incident investigations. Supports Compliance and Audit Readiness Demonstrates continuous monitoring and control over endpoint health, which is often required for regulatory compliance. Prioritizes Remediation Efforts Provides a clear list of affected devices, helping teams focus on the most recent or longest inactive endpoints. Integrates with Existing Workflows Can be extended to trigger ticketing systems, remediation scripts, or SIEM alerts, enhancing operational efficiency. Conclusion By combining KQL analytics with Azure Logic Apps, you can automate the detection and notification of sensor health issues in your VM fleet, ensuring continuous security coverage and rapid response to potential risks.Sentinel UEBA’s Superpower: Actionable Insights You Can Use! Now with Okta and Multi-Cloud Logs!
Microsoft Sentinel continues to evolve as a cloud-native Security Information and Event Management (SIEM) and Security Orchestration, Automation, and Response (SOAR) solution, empowering security teams to detect, investigate, and respond to threats with speed and precision. The latest update introduces advanced User and Entity Behavior Analytics (UEBA), expanding support for new eligible logs, including multi-cloud sources and the Okta identity provider. This leap strengthens coverage and productivity by surfacing anomalies, actionable insights, and rich security context across entities and raw logs. Building on these enhancements, Sentinel UEBA now enables security teams to correlate activity seamlessly across diverse platforms like Azure, AWS, Google Cloud, and Okta, providing a unified risk perspective and empowering SOC analysts to quickly identify suspicious patterns such as unusual logins, privilege escalations, or anomalous access attempts. By leveraging behavioral baselines and contextual data about users, devices, and cloud resources, organizations benefit from improved detection accuracy and a reduction in false positives, streamlining investigations and accelerating threat response. For our Government Customers and for information about feature availability in US Government clouds, see the Microsoft Sentinel tables in Cloud feature availability for US Government customers. What’s New in Sentinel UEBA? Expanded Log Support: Sentinel now ingests and analyzes logs from a broader set of sources, including multi-cloud environments and Okta. This means security teams can correlate user and entity activity across Azure, AWS, Google Cloud, and Okta, gaining a unified view of risk. Actionable Insights: UEBA surfaces anomalies, such as unusual login patterns, privilege escalations, and suspicious access attempts by analyzing behavioral baselines and deviations. These insights help SOC analysts prioritize investigations and respond to threats faster. Rich Security Context: By combining raw logs with contextual information about users, devices, and cloud resources, Sentinel UEBA provides a holistic view of each entity’s risk posture. This enables more accurate detection and reduces false positives. To maximize the benefits of Sentinel UEBA’s expanded capabilities, organizations should focus on integrating all relevant cloud and identity sources, establishing behavioral baselines for users and entities, and leveraging automated response workflows to streamline investigations. Continuous tuning of UEBA policies and proactive onboarding of new log sources, such as Okta and multi-cloud environments, ensures that security teams remain agile in the face of evolving threats. By utilizing dedicated dashboards to monitor for anomalies like impossible travel and privilege changes, and by training SOC analysts to interpret insights and automate incident responses, teams can significantly enhance their threat detection and mitigation strategies while fostering a culture of ongoing learning and operational excellence. Microsoft Learn, UEBA Engine Key Practices for Maximizing UEBA To help organizations fully leverage the latest capabilities of Sentinel UEBA, adopting proven practices is essential. The following key strategies will empower security teams to maximize value, enhance detection, and streamline their operations. Integrate Multi-Cloud Logs: Ensure all relevant cloud and identity sources (Azure, AWS, GCP, Okta) are connected to Sentinel for comprehensive coverage. Baseline Normal Behavior: Use UEBA to establish behavioral baselines for users and entities, making it easier to spot anomalies. Automate Response: Leverage Sentinel’s SOAR capabilities to automate investigation and response workflows for detected anomalies. Continuous Tuning: Regularly review and refine UEBA policies to adapt to evolving threats and organizational changes. This image shows how Microsoft Sentinel UEBA analyzes user and entity behavior to detect suspicious activity and anomalies, helping security teams identify advanced threats and insider risks more accurately. Microsoft Learn, UEBA pipeline Call to Action Start by onboarding Okta and multi-cloud logs into Sentinel. Use UEBA dashboards to monitor for unusual activities, such as impossible travel, multiple failed logins, or privilege changes. Automate alerts and incident response to reduce manual workload and accelerate threat mitigation. Assess your current log sources and identity providers. Onboard Okta and multi-cloud logs into Sentinel, enable UEBA, and start monitoring behavioral anomalies. Train your SOC team on interpreting UEBA insights and automating response actions. Stay ahead of threats by continuously tuning your analytics and integrating new sources as your environment evolves. Reference Links for Sentinel UEBA Advanced threat detection with User and Entity Behavior Analytics (UEBA) in Microsoft Sentinel Enable User and Entity Behavior Analytics (UEBA) in Microsoft Sentinel Microsoft Sentinel User and Entity Behavior Analytics (UEBA) reference Investigate incidents with UEBA data What's new in Microsoft Sentinel Microsoft Sentinel documentation home About the Author: Hi! Jacques “Jack” here, Microsoft Technical Trainer. I’m passionate about empowering teams to master security and operational excellence. As you advance your skills, pair technical expertise with a commitment to sharing knowledge and ongoing training. Create opportunities to lead workshops, stay current on threats and best practices, and foster a culture of continuous learning. #SkilledByMTT #MicrosoftLearn
