Advanced Hunting Query Help
Hey y'all, I'm trying to write a query that can be used to determine the number of times an each IOC generated an alert (file hash, URL, IP, etc). I'm using the query builder tool within Defender, and I'm looking into the AlertInfo and AlertEvidence tables, but I'm not seeing where the link exists between each of these alert records and the corresponding IOC. For instance. If I submit a custom indicator, to Block a file identified by a sha256 hash, and that file gets correctly blocked, I want to see a count for the number of times that IOC value (the hash in this instance) triggered an alert. I'm hoping the community can help me determine whether I'm missing something glaringly obvious or if there's some documentation I haven't read yet. Thanks for reading!
Deep Dive into Preview Features in Microsoft Defender Console
Background for Discussion Microsoft Defender XDR (Extended Detection and Response) is evolving rapidly, offering enhanced security capabilities through preview features that can be enabled in the MDE console. These preview features are accessible via: Path: Settings > Microsoft Defender XDR > General > Preview features Under this section, users can opt into three distinct integrations: Microsoft Defender XDR + Microsoft Defender for Identity Microsoft Defender for Endpoint Microsoft Defender for Cloud Apps Each of these options unlocks advanced functionalities that improve threat detection, incident correlation, and response automation across identity, endpoint, and cloud environments. However, enabling these features is optional and may depend on organizational readiness or policy. This raises important questions about: What specific technical capabilities are introduced by each preview feature? Where exactly are these feature parameters are reflected in the MDE console? What happens if an organization chooses not to enable these preview features? Are there alternative ways to access similar functionalities through public preview or general availability?DeviceNetworkEvents table, UDP and IGMP events
Does DeviceNetworkEvents table get all network events or are there any caveats. Want to know if Defender Agents on the Machines collect all the TCP/UDP/ICMP/IGMP events or there are any specific events which are collected or not collected. We don't see most of UDP events. For example, we have a server listening on UDP, and when a client makes UDP connection to the server, we expect to see UDP connection events in the DeviceNetworkEvents table. We only see mostly DNS UDP events. Same thing with ICMP and IGMP. We don't see IGMP events at all. Can somebody throw light on how these things work.Introducing TITAN-Powered Recommendations in Security Copilot Guided Response
In the ever-evolving landscape of cybersecurity, speed and accuracy are paramount. At Microsoft, we’re continuously investing in ways to help analysts make informed decisions under pressure. One of the most powerful of these is Guided Response: a Security Copilot-powered capability in Microsoft Defender that walks analysts through step-by-step investigation and response flows. It provides context-aware recommendations tailored to each incident, enabling teams at all levels to respond with precision and scale. Now, with the integration of Threat Intelligence Tracking via Adaptive Networks (TITAN) recommendations, Guided Response is taking a leap forward. By bringing in real-time threat intelligence (TI) to prioritize and explain suggested actions, it enables analysts to surface, prioritize, and act on the most relevant threats with clarity and efficiency. What is TITAN? TITAN represents a new wave of innovation built on Microsoft Defender Threat Intelligence capabilities, introducing a real-time, adaptive threat intelligence (TI) graph that integrates first and third-party telemetry from the unified security operations platform, Microsoft Defender for Threat Intelligence, Microsoft Defender for Experts, and customer feedback. This graph employs guilt-by-association techniques to propagate known TI labels to unknown neighboring entities (e.g., IP, file, email) at machine scale. By analyzing relationships between entities, TITAN can identify attacker infrastructure before it's leveraged in attacks, giving defenders a critical window to proactively disrupt threats. One of TITAN’s greatest strengths is its ability to learn from indicators of compromise (IOCs) observed throughout the global threat landscape. Microsoft Defender analyzes over 24 trillion security signals every day, across identities, endpoints, apps, and beyond. When a new IOC (such as an IP address, an IP range or an email sender) is identified in one environment, Microsoft Defender rapidly leverages that intelligence to protect other environments. These live, TI-based Guided Response recommendations help identify, manage and block threats before they impact your organization, turning every detection into a defense signal for the entire Microsoft ecosystem. Why bring TITAN into Security Copilot Guided Response? Security Copilot Guided Response already provides analysts with a curated set of recommendations. TITAN enhances this by introducing a new dimension: real-time, threat-intel-driven recommendations that are grounded in global telemetry and threat actor behavior. The integration improves Guided Response by: Expanding coverage to incidents that previously lacked actionable context. Prioritizing recommendations with higher confidence. Surfacing targeted triage and remediation actions based on live threat infrastructure. How it works TITAN suggestions are now integrated into Guided Response as both triage and containment recommendations. When an incident involves an entity with known malicious threat intelligence flagged by TITAN, Security Copilot automatically generates a Guided Response recommendation. Analysts receive prioritized, natural language guidance on how to triage the incident and contain specific threat entities, including: IP addresses IP ranges Internet Message-ID Email senders Real-world impact In early testing, TITAN-powered triage recommendations have shown promising results: Increased model accuracy: TITAN’s integration has helped improve the precision of Guided Response triage recommendations. Improved analyst trust: explainable, threat-intel-backed recommendations, have helped analysts gain more confidence in their response actions. Faster decision-making: TITAN’s real-time scoring and threat attribution have accelerated incident investigation and response times. Evolving Guided Response with threat intelligence TITAN recommendations mark a significant leap in our mission to empower defenders. By combining the scale of Microsoft’s Defender Threat Intelligence with the precision of Security Copilot’s Guided Response, we’re helping analysts move from reactive to proactive— responding faster, working smarter, and acting with greater confidence. Stay tuned for more updates as we continue to evolve this capability. And if you’re already using TITAN recommendations in your environment, we’d love to hear your feedback. Join the Microsoft Customer Connection Program to share your insights and help shape future Microsoft Security products and features. Learn more Check out our resources to learn more about our new approach to AI-driven threat intelligence for Guided Response, and our recent security announcements: See TITAN in action in the session delivered at Ignite Read our blog and conference paper on the TITAN architecture, accepted to KDD 2025, the premier data-mining conference. Read the Security Copilot Guided Response paper & blogCannot use union * for Defender Hunting query to Create Detection Rule, so what other workarounds?
I tried to create custom detection rule from KQL query in Defender XDR: Advance Hunting by custom various variable to be able to submit, but for this query to be able to go through remediation setting of detection rule, I need the entity identifiable columns like AccountUpn, that I need to union with IdentityInfo schema. But detection rule seems not support the union * thing as the attached pic: I searched for the same problems that seems to be occurred in all system using KQL including in Microsoft Sentinel Logs but has no workaround to bypass. So, is there any way to get through this objective without strucking with union * problem?How to use KQL to associate alerts with incidents?
There is no method I'm aware of to use KQL to query from an alertID to an incident or vice versa. Please provide kql examples for querying between XDR incidents and alerts. These queries should be independent of the SecurityIncident table which is only available when Sentinel is connected to XDR. Thank you.Protect SaaS apps from OAuth threats with attack path, advanced hunting and more
Over the past two years, nation-state attacks using OAuth apps have surged. To combat this threat and to help customers focus on the most important exposure points, Microsoft Defender for Cloud Apps introduces several new capabilities. OAuth applications are now integrated into the attack path experience within Exposure Management, providing an overview of the attack paths that a bad actor might take to access Microsoft 365 SaaS apps like Outlook and Teams. Additionally, a unified application inventory allows customers to manage both user-to-SaaS and OAuth-to-SaaS interactions with an 'action center' so that they can block or disable apps and create policies aligned to exposure points. Lastly, information about OAuth applications is now included in the Attack Surface Map and Advanced Hunting experience for comprehensive threat investigation and more effective threat hunting. OAuth Apps Pose Critical Security Threat The rise in nation-state attacks exploiting OAuth apps poses a significant threat to organizations. Protecting your SaaS apps from OAuth interactions is critical, as attackers can easily compromise your network. For example, a phishing link that impersonates a legitimate application can deceive users into granting malicious apps full access to their account. Once the user clicks “Accept,” the attacker gains full access to the organization's email, chats and files. Figure 1. Phishing link with permission request. Microsoft's research shows that 1 in 3 OAuth apps are overprivileged 1 making them prime targets for threat actors. Attackers often use phishing to compromise accounts, create malicious OAuth apps, or hijack existing ones leading to unauthorized access and causing data breaches. It's a frightening scenario, but one that can be prevented with the right tools and strategies. Learn more: investigate and remediate risky OAuth apps. Visualize Attack Paths We are excited to announce that Microsoft Defender for Cloud Apps has significantly enhanced the Exposure Management experience by integrating OAuth applications. The new attack path feature enables you to visualize how attackers could use OAuth apps to move laterally within your organization to access critical SaaS applications. By identifying, reducing, and managing the number of attack paths, you can significantly reduce your attack surface and enhance the security of your M365 services. Learn more: Explore with the attack surface map in Microsoft Security Exposure Management - Microsoft Security Exposure Management | Microsoft Learn Figure 2. Attack path shows lateral movement to service principal with sensitive permissions. Manage your SaaS Ecosystem The new “Applications” page in the Defender XDR portal offers comprehensive visibility and control over your SaaS and OAuth applications. This page provides a unified view to discover and manage all your SaaS and OAuth applications connected to services like Microsoft 365, Google, and Salesforce. With actionable insights, you can identify and prioritize applications that need your attention. The new application inventory experience allows you to easily explore metadata and insights for OAuth apps involved in attack paths or review apps as part of your periodic app review process. For example, you can identify applications with unused permissions to access Microsoft 365 by using the pre-defined insight card for “Overprivileged apps,” which automatically applies the relevant filters to display all overprivileged applications within your environment. Figure 3. OAuth apps in the Applications page of the Defender XDR portal. Investigate with Attack Surface Map and Advanced Hunting The Attack Surface Map allows customers to visualize the organizational connection to OAuth applications, including those who own the app and the permission levels. Figure 4. The user Shkedi is the owner of the MdaXspmSensitive OAuth app. All the data available in the Attack surface map is also available in advanced hunting under the Exposure Management section. Additionally, you can get detailed metadata and comprehensive insights for all applications in the new OAuthAppInfo table in advanced hunting powered by the app governance capability in Microsoft Defender for Cloud Apps. These are the same apps that are displayed on the OAuth apps tab of the applications page. Currently, the scope of the table is limited to Microsoft Entra registered apps with access to Microsoft 365. With this new table, you can write powerful queries for advanced scenarios or leverage the suggested queries to explore and hunt for privileged apps. Learn more: Investigate OAuth application attack paths in Defender for Cloud Apps - Microsoft Defender for Cloud Apps | Microsoft Learn Automatic Attack Disruption Recently we introduced automatic attack disruption capabilities that proactively disrupt malicious OAuth applications involved in active attacks, effectively stopping threats in their tracks. By onboarding Microsoft Defender for Cloud Apps, you can effortlessly thwart these attacks ensuring your organization's security remains robust and resilient. Act Today! Protect your organization from OAuth-related attacks with Microsoft Defender for Cloud Apps. Use its powerful capabilities to visualize, investigate, and remediate potential threats to safeguard your Microsoft 365 services and secure your valuable data. Start by filtering all attack paths leading to service principals with sensitive permissions to Microsoft 365 SaaS services and continue with your investigation from there. Figure 5. Attack paths show lateral movement to service principal with sensitive permissions. Alternatively, if your environment has numerous attack paths, start with the choke points experience to identify assets that are frequently involved in attacks. Then, apply the principle of least privilege to secure these critical assets. Figure 6. OAuth app choke points. Then you can further explore the interconnections of the attack paths or the choke points in the attack surface map: Figure 7. OAuth node in attack surface map. Note that everything which is available in the Attack surface map is also available in Advanced Hunting under ExposureGraphEdges and ExposureGraphNodes. You can also use the App inventory to explore specific OAuth applications and get detailed insights into API permissions, privilege level, app origin, publisher, permission type and services being accessed. Access it by selecting "Applications" under the "Assets" tab in the Defender XDR portal: Figure 8. App inventory shows in-depth visibility for OAuth app integrations. Lastly, you can hunt for risky OAuth apps. To get started, use the template below to identify all enabled, highly privileged, externally registered OAuth apps that have no verified publisher: OAuthAppInfo | where AppStatus == "Enabled" | where PrivilegeLevel == "High" | where VerifiedPublisher == "{}" and AppOrigin == “External” Figure 9. OAuth app threat hunting template. Prerequisites To access these new capabilities requires Microsoft Defender for Cloud apps license, activate Microsoft 365 app connector and enable app governance. To access all Exposure Management experiences, we recommend the following roles: Unified RBAC role: “Exposure Management (read)” under “Security posture” category Any of the Entra ID roles: Global admin, Security admin, Security operator, Global reader, Security reader Conclusion Integrating OAuth applications into Microsoft Security Exposure Management is crucial for addressing OAuth-based attacks. This integration provides a comprehensive view of potential attack paths and exposure points, enabling security teams to reduce the attack surface and mitigate risks effectively. Microsoft Defender for Cloud Apps helps visualize and prevent exploits targeting critical resources. The unified application inventory streamlines management of OAuth and user-to-SaaS interactions, while Advanced Hunting facilitates investigations. Stay ahead of threats and protect your assets with Microsoft Defender for Cloud Apps. 1. Microsoft sample data, Nov 2024
