MSSP Multi-Tenant Handling with Lighthouse and Defender XDR
Hello, As far as I know an MSSP providers, leverages Azure Lighthouse to call and access multiple customer workspaces, which allows to manage analytics across tenants. My questions are: In the case of moving to Defender XDR, how would this be possible in a multi-tenant MSSP scenario? Even with Lighthouse, how does Defender XDR avoid merging incidents/alerts across different customers when the same entities are involved? How does Defender XDR differentiate identical IOCs (same IP, hash, etc.) that appear in multiple customers? Can MSSPs customize correlation logic to prevent false cross-tenant merges? Content Ownership & Sharing Most MSSPs do not want to share their proprietary content (custom rules, detections, playbooks, analytics, etc.) with customers. How is Defender XDR approaching this requirement to ensure MSSPs can operate without exposing their intellectual property? Example: Customer Test 1 has a port scan incident from IP 10.10.10.10. Customer Test 2 also has a port scan incident from the same IP 10.10.10.10. In Sentinel today, these would remain separate. But in Defender XDR, would these two alerts risk being merged into a single incident because the same entity is detected across tenants? Thanks in advance for any clarification.
Advanced Hunting Custom detection rule notification cannot be customized
Hello, We have a case with both Microsoft and US cloud about the custom detection rule created by a query. The problem that we have is that I want to send the rule's notification to an email group. However, after about 2 months of investigations, I was advised below: "We can go one of two routes. Either the alerts from Defender can be ingested into sentinel based on the custom detection rule you created, or the Entra Sign-in logs can be ingested allowing Sentinel to check the logs itself." Could you please help us find an easier solution for the notification or create a feature request so that we could have the configuration of notification for custom detection rules when creating the alert?
TVM still showing outdated vulnerabilities despite applications being up to date
Hi everyone, we’re using Microsoft Defender for Endpoint with Threat & Vulnerability Management (TVM) enabled. Lately, we've noticed that certain vulnerabilities (e.g., CVEs in browsers or third-party software) continue to be flagged on devices, even though the affected applications have been updated weeks ago. Example scenario: The device is actively onboarded and reporting to Defender XDR The application has been updated manually or via software deployment The correct version appears under Software Inventory However, the CVE still shows up under Weaknesses Has anyone experienced similar behavior? Are there any best practices to trigger a re-evaluation of vulnerabilities or force a TVM scan refresh? Would a device reboot or restarting the MDE service help in this case? Any insights, suggestions, or known workarounds would be greatly appreciated. Thanks in advance!From on-premises to cloud: Graph-powered detection of hybrid attacks with Microsoft exposure graph
Enterprises face an ever-evolving landscape of cybersecurity threats that require robust and adaptive defense strategies to protect multiple threat surfaces. Many organizations manage their resources across different realms, including on-premises and cloud environments, and create complex infrastructures, where interconnections between services, resources, and identities become vital. If not managed with caution and diligence, these interconnections can pose significant risks. Threat actors may exploit them to take over realms, conduct identity theft, exfiltrate data, engage in ransomware extortion, or engage in other malicious activities. Organizations deploy a variety of solutions to safeguard their workloads, whether they are on premises, or in the cloud. Many have adopted integrated platforms that offer a unified view of their security environment. Solutions like Security Information and Event Management (SIEM) and Extended Detection and Response (XDR) are now essential. However, a significant gap emerges when dealing with attacks that span multiple layers within the enterprise, crossing various realms, where each realm lacks the context of the others, and shared entities (IP Address, User, and more) are non-existent. This limitation prevents the SOC teams from identifying the comprehensive attack chain, where the contextual correlation of low-medium confidence signals across the realms is essential, and effectively responding to such complex, multi-faceted threats. In this blog, we explain how the exposure graph, an integral part of our pre-breach security exposure solution, supercharges our post-breach threat protection capabilities to detect and respond to such multi-faceted threats. This contextual enrichment allows SOC teams to uncover and determine that the low-medium confidence signals across the realms are part of the same attack—from the earliest compromise of the first realm to the last. This is possible by correlating indicators of compromise with shared possible attack paths on the graph that cross the on-premises and move to the cloud, and vice-versa. We will emphasize on-hybrid attacks that move from on-premises environments to the cloud. Recognizing the Complexity of Hybrid Threats Exposure management solutions, such as Microsoft Exposure Management, have already identified the need to surface risks that cross these realms. These solutions are now exposing hybrid attack paths, providing the necessary context to understand and mitigate threats that span different layers and realms—in this case, on-premises and cloud—within the enterprise (read more). The exposure graph supercharges threat protection capabilities by focusing on a specific attack scenario that highlights this gap: a device compromise leading to an Azure environment takeover. In such scenarios, context is key to creating a holistic picture of the larger kill-chain. In this scenario, a device which isn’t joined to Entra is compromised using the threat actor’s payload delivery and an N-day exploit, allowing the threat actor to gain an initial foothold on the device. The threat actor then discovers an unexpired Entra session cookie residing in the browser. They perform credential theft and extract the cookie using known attack tools, with a goal to steal and assume the identity and permissions of the user that the cookie is tied to. After hijacking the cookie, the threat actor manages to compromise the user by replaying the cookie from their own device and pivoting to the cloud, successfully satisfying the multifactor authentication (MFA) requirement. The threat actor then discovers that this user is assigned with the Global Administrator Entra role, which results in a highly destructive on-premises to cloud privilege escalation. This might not be coincidental, as the user was targeted as part of a spear-phishing campaign, which resulted in the payload delivery and the initial access. The threat actor then shifts their focus to Azure, targeting the organization’s valuable data that resides in the cloud realm. They perform the elevate access operation within the Azure portal, thereby gaining privileged permissions over all Azure subscriptions in scope, allowing them to take over Azure. Finally, the threat actor commits mass data exfiltration from the discovered Azure storage accounts that reside in the Azure compromised subscriptions. This stolen data can later be sold on the dark web or used to commit ransomware extortion. Graph-based contextual detection & response In the above scenario, the threat actor’s pivot from on-premises to the cloud may easily be a blind spot, as there is no shared indication that the device sequence of events is related to the cloud sequence of events, because the former occurs in the context of the local account while the latter occurs in the context of the Entra identity. This prevents SOC teams from correlating operations across different realms (on-premises and cloud), as there are no shared entities. In addition, each realm detection capability might have low-medium confidence individually, but with context enrichment and cross-realm signal correlation, the result can be a high confidence threat detection capability that SOC teams can respond to effectively. As suspicious operations are detected within the device during the attack, including reconnaissance and discovery, credential theft, execution, and more, these detections often lack the context of the cloud user with an active logon session inside the device. Conversely, suspicious activity detected within Azure also lacks the context of previous suspected operations that occurred on the device. To bridge the gap, we utilize the Enterprise Exposure Graph to integrate both contexts and formulate a comprehensive picture of the destructive campaign, with high confidence. By enriching the XDR capabilities, we can correlate events through shared paths in the graph, allowing us to consolidate the device compromise, credential theft, and the cloud compromise and operations into a single, cohesive incident. Hybrid attack detection and response: How does this all work? The Enterprise exposure graph collects information about assets, users, secrets, workloads, and more. Secrets can be in the form of user tokens and cookies, cloud resource access keys, and more. One of the unique features of the graph is its ability to connect users and devices, using secrets (user cookies and tokens). By leveraging the capabilities of secret scanning on both on-premises and cloud machines within Microsoft Security Exposure Management (MSEM), the exposure graph surfaces connections between a device and a user. In the above attack scenario, when the ‘device’ ‘contains’ an Entra session cookie (also known as ‘entra-userCookie’ in the Microsoft exposure graph) within the browser, where the cookie ‘can authenticate as’ the user, the connection appears in the graph. For more details, please refer to our previous blog. We use these graph-based connections and context enrichments within Microsoft Defender XDR to detect destructive cross-realm attacks. By correlating events based on the connections between the endpoint device and the user's identity, we can generate a high-confidence unified alert, or an incident that correlates different alerts. This provides a comprehensive description of the attack, showing how a single threat actor moved from the device to the cloud. New Exposure Graph-based detection & response Alerts with the following titles in Microsoft Defender XDR can indicate threat activity of a hybrid attack in progress. Microsoft Defender XDR detections Initial Access Suspicious Azure sign-in by user with active session on a device involved in a credential theft attempt Privilege Escalation Suspicious Azure elevate access operation by a user with an active session on a device involved in a credential theft attempt Credential Access Suspicious Azure Storage account keys access by a user with an active session on a device involved in a credential theft attempt Collection Suspicious Azure VM snapshot downloads by a user with an active session on a device involved in a credential theft attempt Impact Suspicious Azure data store resources deletion attempt by a user with an active session on a device involved in a credential theft attempt Learn more Microsoft Security Exposure Management (MSEM) Start with Exposure Management documentation, product website, blogs Microsoft Security Exposure Management what's new page Device and user connections using cloud credentials detection blog Exposure Graph tables in Advanced Hunting: ExposureGraphEdges, ExposureGraphNodes Query the exposure graph Mitigation and Protection guidance Principle of least privilege for identities What is Conditional Access in Microsoft Entra ID? Microsoft-managed Conditional Access policies Microsoft Entra Conditional Access token protection Turn on Microsoft Entra ID protection Understanding Tokens in Microsoft Entra ID Protecting Tokens in Microsoft Entra ID Token theft playbook Endpoint detection and response in block mode - Microsoft Defender for Endpoint Use automated investigations to investigate and remediate threats - Microsoft Defender for Endpoint Microsoft Defender for Cloud documentation Protect your Azure subscriptions with Microsoft Defender for Cloud Microsoft Defender for Cloud integration into Defender XDR CloudAuditEvents table in the advanced hunting - Microsoft Defender XDRCannot 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?Can I get productName in Microsoft Graph API incident response?
When using Microsoft Graph Security API, is it possible to get the productName field directly in the incident response (e.g., from /security/incidents endpoint)? Or is it only available at the alert level via /security/incidents/{id}/alerts?
Whitelisting Pentesting tools
Hello everyone. I'm coming to you with a question that I think is pertinent. We use a pentesting tool in our environment. It generates a lot of incidents and alerts in Microsoft Defender. We have on-prem accounts (one user, one admin) so that the tool can perform this pentesting. Do you have any ideas on how to whitelist incidents linked to this user, these actions or the node machine he uses to initiate connections? So that it no longer generates or the incidents linked to these activities are automatically resolved. Thank you for your help. HKNMonthly news - March 2025
Microsoft Defender XDR Monthly news March 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 February 2025. Defender for Cloud has it's own Monthly News post, have a look at their blog space. Unified Security Operations Platform: Microsoft Defender XDR & Microsoft Sentinel (Public Preview) IP addresses can now be excluded from automated responses in attack disruption. This feature allows you to exclude specific IPs from automated containment actions triggered by attack disruption. For more information, see Exclude assets from automated responses in automatic attack disruption. (Public Preview) The PrivilegedEntraPimRoles column is available for preview in the advanced hunting IdentityInfo table. (General Available) You can now view how Security Copilot came up with the query suggestion in its responses in Microsoft Defender advanced hunting. Select See the logic behind the query below the query text to validate that the query aligns with your intent and needs, even if you don't have an expert-level understanding of KQL. We are excited to announce that we increase the Multi Tenant Organization (MTO) tenant limit - and now you can manage up to 100 tenants to your MTO view. With that, you can view incident, hunt, and see and manage all your data from one single pane of glass. This is only the first step to improve management at scale. Learn more in our docs. (General Available) Sentinel only is now in General Available for Unified Security Operations platform. Customers with no E5 license can now onboard their workspace and work in the unified platform for all features (single workspace only, for single tenant and for multi tenant) (General Available) Gov Clouds/ GCCH and DoD is now in General Available for Unified Security Operations platform. Customers with single workspace (for both multi tenant and single tenant) are now able to work in the unified platform on all features. Query assistant - KQL response explanation. The Security Copilot Query Assistant in Advanced Hunting generates KQL queries from requests in natural language, allowing hunting for threats, without having a deep knowledge in KQL and schema. With this new feature, it is possible to review the logic behind the KQL queries generated by Copilot, including a breakdown of the query. This enhancement helps validate the query aligns with the intent and needs, even without deep understanding of KQL. (Public Preview) IP addresses can now be excluded from automated containment responses triggered by automatic attack disruption. Microsoft Sentinel Threat Intelligence Ingestion rules: This feature lets you fine-tune your threat intelligence (TI) feeds before they are ingested to Microsoft Sentinel. You can now set custom conditions and actions on Indicators of Compromise (IoCs), Threat Actors, Attack Patterns, Identities, and their Relationships. Learn more in this blog post. Missed the live session? Watch our recorded webinar on "SIEM as Code", a transformative approach shaping the future of SIEM. Learn how to implement it in Microsoft Sentinel using the repositories feature and explore best practices for automation and scalability. Microsoft Defender Experts for XDR Published Scoped coverage in Microsoft Defender Experts for XDR. Microsoft Defender Experts for XDR offers scoped coverage for customers who wish to have Defender Experts cover only a section of their organization (for example, specific geography, subsidiary, or function) that requires security operations center (SOC) support or where their security support is limited. Learn more on our docs. Microsoft Defender for Identity (General Available) New Identity Guide Tour We've added an interactive guide tour in the Defender XDR portal to help you navigate identity security features, investigate alerts, and enhance your security posture with ease. (General Available) New attack paths tab on the Identity profile page. This tab provides visibility into potential attack paths leading to a critical identity or involving it within the path, helping assess security risks. For more information, see Overview of attack path within Exposure Management. (General Available) New and updated events in the Advanced hunting IdentityDirectoryEvents table. We have added and updated various events in the IdentityDirectoryEvents table in Advanced Hunting. Learn more on our docs. (General Available) Identity page enhancements such as user timeline side panel, password last change field on the UI, devices tab filters and so on. Defender for Identity integration with Entra Privileged Identity Management (PIM) - SOC can now view identities in the Defender XDR portal that are eligible to elevate to privileged roles via Entra PIM. New tag and list of user's Entra privileged roles (eligible and assigned) were added to user page and side panel in the Defender XDR portal and Identity Info table. Privileged Access Management (PAM) vendors integration with MDI – CyberArk, Delinea and BeyondTrus. The integration provide the SOC with visibility for on-prem / Entra ID privileged identities managed in the PAM solution, adding new tag on privileged identities in Defender XDR user page, side panel and Identity Info table, allowing for incident prioritization, custom detections, advanced hunting and more. SOC can also initate a remediation action to 'enforce password rotation' on compromised privileged identity directly in the XDR Defender portal. Intagration need to be enabled by the customer in the Partners portal. Go to XDR Technical Partners catalog to see the new partners integrations, and access the PAM vendors marketplace. 2 New Entra Detections and on-prem detection improvement. Entra new detections: "suspicious multiple TAP creation for the same user account" and "suspicious alternative phone number addition". Detection improvement in on-prem: "Blood hound python" - version udpate to cover FN. New recommendations for Identity Security Posture. In this blog we will focus on some key things to consider for your Active Directory (AD) footprints. Active Directory is a critical element of user authentication, and its complexity leaves many opportunities for potential misconfigurations, making it a prime target for attackers. To address these vulnerabilities, we’ve added 10 new recommendations aimed at strengthening your identity security posture and protecting against evolving threats. Microsoft Security Exposure Management The following predefined classification rules were added to the critical assets list: Azure Key Vault with high number of operations: This rule identifies and classifies Azure Key Vaults that experience a high volume of operations, indicating their criticality within the cloud environment. Security Operations Admin Device: This rule applies to critical devices used to configure, manage, and monitor the security within an organization are vital for security operations administration and are at high risk of cyber threats. They require top-level security measures to prevent unauthorized access. For more information, see, Predefined classifications Microsoft Defender for Endpoint (General Available) Aggregated reporting in Microsoft Defender for Endpoint is now generally available. For more information, see Aggregated reporting in Microsoft Defender for Endpoint. Guidance for penetration testing and breach-and-attack-simulation scenarios with Defender for Endpoint. This new article describes common challenges and potential misconfigurations that might arise during penetration testing (pen testing) or using breach and attack simulation (BAS) tools. This article also describes how to submit potential false negatives for investigation. This article describes how to use Microsoft Defender for Endpoint Security Settings Management to manage Microsoft Defender Antivirus. Microsoft Blogs Code injection attacks using publicly disclosed ASP.NET machine keys. The BadPilot campaign: Seashell Blizzard subgroup conducts multiyear global access operation Storm-2372 conducts device code phishing campaign. Threat Analytics Reports (access to the Defender XDR portal required) Activity Profile: Emerald Sleet using PowerShell to exploit targets Actor Profile: Storm-1660 Technique Profile: Code injection attacks using disclosed ASP.NET machine keys Tool Profile: GoldBackdoor Activity Profile: Forest Blizzard targeting Western civilian transportation Activity Profile: BadPilot campaign - Seashell Blizzard subgroup conducts multiyear global access operation Activity Profile: Sapphire Sleet uses fraudulent Zoom domains in recent spear-phishing activities Activity Profile: Malvertising campaign leads to info stealers hosted on GitHub Activity Profile: New Zigzag Hail phishing campaigns adapt long-running malware operation to continue targeting Japan Actor Profile: Storm-1830 Activity Profile: Phishing campaign impersonates Booking.com, delivers multiple commodity malware Activity Profile: Storm-2372 conducts device code phishing campaign Activity Profile: Threat landscape for the information technology sector in 2024 Vulnerability Profile: CVE-2025-21333 Multiple vulnerabilities found in Windows Hyper-V NT Kernel Integration VSP Vulnerability Profile: CVE-2025-21391 Activity Profile: IronSentry PhaaS launches after NakedPages shuts down Vulnerability Profile: CVE-2024-43583 - Winlogon Tool Profile: FusionDrive Vulnerability Profile: CVE-2025-21420 Vulnerability Profile: CVE-2025-21419 Activity Profile: Salt Typhoon targets telecommunications and internet service providersHow to Get the Most Out of MDVM Webinar - Q&A Overflow
This page is to address the questions that we did not have time to get to in our latest webinar: How to Get the Most Out of Microsoft Defender for Vulnerability Management (MDVM) on February 12, 2025. We will be posting answers to all questions that were submitted, so make sure to bookmark this page and check it regularly over the next week or so as we continue to update this space with answers. Thanks for your participation in our call! Check out the recording of this call here: https://youtu.be/dQL9CRKzVa8
