Monthly 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 providers
Enhancing Security Monitoring: Integrating GitLab Cloud Edition with Microsoft Sentinel
Maximize your security operations by combining GitLab Cloud Edition with Microsoft Sentinel. This blog covers how to fill the void of a missing native connector for GitLab in Sentinel. Utilize GitLab's API endpoints, Azure Monitor Data Collection Rules, and Data Collection Endpoints, as well as Azure Logic Apps and Key Vault, to simplify log collection and improve immediate threat identification. Our detailed guide will help you integrate smoothly and strengthen your security defences.Integrating Fluent Bit with Microsoft Sentinel
This guide will walk you through the steps required to integrate Fluent Bit with Microsoft Sentinel. Beware that in this article, we assume you already have a Sentinel workspace, a Data Collection Endpoint and a Data Collection Rule, an Entra ID application and finally a Fluent Bit installation. As mentioned above, log ingestion API supports ingestion both in custom tables as built-in tables, like CommonSecurityLog, Syslog, WindowsEvent and more. In case you need to check which tables are supported please the following article: https://learn.microsoft.com/en-us/azure/azure-monitor/logs/logs-ingestion-api-overview#supported-tables Prerequisites: Before beginning the integration process, ensure you have the following: An active Azure subscription with Microsoft Sentinel enabled; Microsoft Entra ID Application taking note of the ClientID, TenantID and Client Secret – create one check this article: https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app?tabs=certificate A Data Collection Endpoint (DCE) – to create a data collection endpoint, please check this article: https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/data-collection-endpoint-overview?tabs=portal A Data Collection Rule (DCR) – fields from the Data Collection Rule need to match exactly to what exists in table columns and also the fields from the log source. To create a DCR please check this article: https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/data-collection-rule-create-edit?tabs=cli Depending on the source, it might require a custom table to be created or an existing table from log analytics workspace; Fluent Bit installed on your server or container – In case you haven’t yet installed Fluent Bit, in the following article you'll find the instructions per type of operating system: https://docs.fluentbit.io/manual/installation/getting-started-with-fluent-bit High level architecture: Step 1: Setting up Fluent Big configuration file Before we step-in into the configuration, Fluent Bit has innumerous output plugins and one of those is through Log Analytics Ingestion API both to supported Sentinel tables but also for custom tables. You can check more information about it here in Fluent Bit documentation: https://docs.fluentbit.io/manual/pipeline/outputs/azure_logs_ingestion Moving forwarder, in order to configure Fluent Bit to send logs into Sentinel log analytics workspace, please take note of the specific input plugin you are using or intend to use to receive logs and how can you use it to output the logs to Sentinel workspace. For example most of the Fluent Bit plugins allow to set a “tag” key which can be used within the output plugin so that there’s a match in which logs are intended to send. On the other hand, in a scenario where multiple input plugins are used and all are required send logs to Sentinel, then a match of type wildcard "*" could be used as well. Another example, in a scenario where there are multiple input plugins of type “HTTP” and you want to just send a specific one into Sentinel, then the “match” field must be set according to the position of the required input plugin, for example “match http.2”, if the input plugin would the 3 rd in the list of HTTP inputs. If nothing is specified in the "match" field, then it will assume "http.0" by default. For better understanding, here’s an example of how a Fluent Bit config file could look: First, the configuration file is located under the path ”/etc/fluent-bit/fluent-bit.conf” The first part is the definition of all “input plugins”, then follows the “filter plugins” which you can use for example to rename fields from the source to match for what exists within the data collection rule schema and Sentinel table columns and finally there’s the output plugins. Below is a screenshot of a sample config file: INPUT plugins section: In this example we’re going to use the “dummy input” to send sample messages to Sentinel. However, in your scenario you could leverage other’s input plugins within the same config file. After everything is configured in the input section, make sure to complete the “FILTER” section if needed, and then move forward to the output plugin section, screenshot below. OUTPUT plugins section: In this section, we have output plugins to write on a local file based on two tags “dummy.log” and “logger”, an output plugin that prints the outputs in json format and the output plugin responsible for sending data to Microsoft Sentinel. As you can see, this one is matching the “tag” for “dummy.log” where we’ve setup the message “{“Message”:”this is a sample message for testing fluent bit integration to Sentinel”, “Activity”:”fluent bit dummy input plugn”, “DeviceVendor”:”Ubuntu”}. Make sure you insert the correct parameters in the output plugin, in this scenario the "azure_logs_ingestion" plugin. Step 2: Fire Up Fluent Bit When the file is ready to be tested please execute the following: sudo /opt/fluent-bit/bin/fluent-bit -c /etc/fluent-bit/fluent-bit.conf Fluent bit will start initialization all the plugins it has under the config file. Then you’re access token should be retrieved if everything is well setup under the output plugin (app registration details, data collection endpoint URL, data collection rule id, sentinel table and important to make sure the name of the output plugin is actually “azure_logs_ingestion”). In a couple of minutes you should see this data under your Microsoft Sentinel table, either an existing table or a custom table created for the specific log source purpose. Summary Integrating Fluent Bit with Microsoft Sentinel provides a powerful solution for log collection and analysis. By following this guide, hope you can set up a seamless integration that enhances your organization's ability to monitor and respond to security threats, just carefully ensure that all fields processed in Fluent Bit are mapped exactly to the fields in Data Collection Rule and Sentinel table within Log Analytics Workspace. Special thanks to “Bindiya Priyadarshini” that collaborated with me on this blog post. Cheers!Microsoft Security in Action: Deploying and Maximizing Advanced Identity Protection
As cyber threats grow in sophistication, identity remains the first line of defense. With credentials being a primary target for attackers, organizations must implement advanced identity protection to prevent unauthorized access, reduce the risk of breaches, and maintain regulatory compliance. This blog outlines a phased deployment approach to implement Microsoft’s identity solutions, helping ensure a strong Zero Trust foundation by enhancing security without compromising user experience. Phase 1: Deploy advanced identity protection Step 1: Build your hybrid identity foundation with synchronized identity Establishing a synchronized identity is foundational for seamless user experiences across on-premises and cloud environments. Microsoft Entra Connect synchronizes Active Directory identities with Microsoft Entra ID, enabling unified governance while enabling users to securely access resources across hybrid environments. To deploy, install Microsoft Entra Connect, configure synchronization settings to sync only necessary accounts, and monitor health through built-in tools to detect and resolve sync issues. A well-implemented hybrid identity enables consistent authentication, centralized management, and a frictionless user experience across all environments. Step 2: Enforce strong authentication with MFA and Conditional Access Multi-Factor Authentication (MFA) is the foundation of identity security. By requiring an additional verification step, MFA significantly reduces the risk of account compromise—even if credentials are stolen. Start by enforcing MFA for all users, prioritizing high-risk accounts such as administrators, finance teams, and executives. Microsoft recommends deploying passwordless authentication methods, such as Windows Hello, FIDO2 security keys, and Microsoft Authenticator, to further reduce phishing risks. Next, to balance security with usability, use Conditional Access policies to apply adaptive authentication requirements based on conditions such as user behavior, device health, and risk levels. For example, block sign-ins from non-compliant or unmanaged devices while allowing access from corporate-managed endpoints. Step 3: Automate threat detection with Identity Protection Implementing AI-driven risk detection is crucial to identifying compromised accounts before attackers can exploit them. Start by enabling Identity Protection to analyze user behavior and detect anomalies such as impossible travel logins, leaked credentials, and atypical access patterns. To reduce security risk, evolve your Conditional Access policies with risk signals that trigger automatic remediation actions. For low-risk sign-ins, require additional authentication (such as MFA), while high-risk sign-ins should be blocked entirely. By integrating Identity Protection with Conditional Access, security teams can enforce real-time access decisions based on risk intelligence, strengthening identity security across the enterprise. Step 4: Secure privileged accounts with Privileged Identity Management (PIM) Privileged accounts are prime targets for attackers, making Privileged Identity Management (PIM) essential for securing administrative access. PIM allows organizations to apply the principle of least privilege by granting Just-in-Time (JIT) access, meaning users only receive elevated permissions when needed—and only for a limited time. Start by identifying all privileged roles and moving them to PIM-managed access policies. Configure approval workflows for high-risk roles like Global Admin or Security Admin, requiring justification and multi-factor authentication before privilege escalation. Next, to maintain control, enable privileged access auditing, which logs all administrative activities and generates alerts for unusual role assignments or excessive privilege usage. Regular access reviews further enable only authorized users to retain elevated permissions. Step 5: Implement self-service and identity governance tools Start by deploying Self-Service Password Reset (SSPR). SSPR enables users to recover their accounts securely without help desk intervention. Also integrate SSPR with MFA, so that only authorized users regain access. Next, organizations should implement automated Access Reviews on all users, not just privileged accounts, to periodically validate role assignments and remove unnecessary permissions. This helps mitigate privilege creep, where users accumulate excessive permissions over time. Phase 2: Optimize identity security and automate response With core identity protection mechanisms deployed, the next step is to enhance security operations with automation, continuous monitoring, and policy refinement. Step1: Enhance visibility with centralized monitoring Start by Integrating Microsoft Entra logs with Microsoft Sentinel to gain real-time visibility into identity-based threats. By analyzing failed login attempts, suspicious sign-ins, and privilege escalations, security teams can detect and mitigate identity-based attacks before they escalate. Step 2: Apply advanced Conditional Access scenarios To further tighten access control, implement session-based Conditional Access policies. For example, allow read-only access to SharePoint Online from unmanaged devices and block data downloads entirely. By refining policies based on user roles, locations, and device health, organizations can strengthen security while ensuring seamless collaboration. Phase 3: Enable secure collaboration across teams Identity security is not just about protection—it also enables secure collaboration across employees, partners, and customers. Step 1: Secure external collaboration Collaboration with partners, vendors, and contractors requires secure, managed access without the complexity of managing external accounts. Microsoft Entra External Identities allows organizations to provide seamless authentication for external users while enforcing security policies like MFA and Conditional Access. By enabling lifecycle management policies, organizations can automate external user access reviews and expirations, ensuring least-privilege access at all times. Step 2: Automate identity governance with entitlement management To streamline access requests and approvals, Microsoft Entra Entitlement Management lets organizations create pre-configured access packages for both internal and external users. External guests can request access to pre-approved tools and resources without IT intervention. Automated access reviews and expiration policies enable users retain access only as long as needed. This reduces administrative overheads while enhancing security and compliance. Strengthening identity security for the future Deploying advanced identity protection in a structured, phased approach allows organizations to proactively defend against identity-based threats while maintaining secure, seamless access. Ready to take the next step? Explore these Microsoft identity security deployment resources: Microsoft Entra Identity Protection Documentation Conditional Access Deployment Guide Privileged Identity Management Configuration Guide The Microsoft Security in Action blog series is an evolving collection of posts that explores practical deployment strategies, real-world implementations, and best practices to help organizations secure their digital estate with Microsoft Security solutions. Stay tuned for our next blog on deploying and maximizing your investments in Microsoft Threat Protection solutions.MS Defender Azure Arc Logic App
What is the best procedure for configuring a Logic App for Microsoft Defender in an Azure Arc environment? We had a very unexpected experience during onboarding—after configuring the Logic App, we missed setting a cap, and within a week, it consumed over $18K USD. I believe there must be a way to fine-tune the configuration to optimize costs. From my perspective, no organization would adopt an environment with such high costs for Microsoft Defender Plan 2 without better cost control measures in place. Could you suggest best practices or optimizations to prevent such excessive consumption?
How to Monitor New Management Group Creation and Deletion.
I am writing this post to monitor new Management group creation and Deletion using Azure Activity Logs and Trigger Incident in Microsoft Sentinel. You can also use it to Monitor the Subscription Creation as well using this Step. By default, the Dianostic settings for at the management group level is not enabled. It cannot be enabled using Azure Policy or from the Portal interface. Use the below article to enable the "Management Group Diagnostic Settings" Management Group Diagnostic Settings - Create Or Update - REST API (Azure Monitor) | Microsoft Learn Below is the screenshot of message body if you like to forward the logs only to the Log analytic workspace where sentinel is enabled. Also make sure you enable the Diagnostic settings at the tenant management group level to track all changes in your tenant. { "properties": { "workspaceId": "<< replace with workspace resource ID>>", "logs": [ { "category": "Administrative", "enabled": true }, { "category": "Policy", "enabled": true } ] } } Once you have enabled the Diagnostic settings, you can use the below KQL query to monitor the New Management group creation and Deletion using Azure Activity Logs. //KQL Query to Identify if Management group is deleted AzureActivity | where OperationNameValue == "MICROSOFT.MANAGEMENT/MANAGEMENTGROUPS/DELETE" | where ActivityStatusValue == "Success" | extend mg = split(tostring(Properties_d.entity),"/") | project TimeGenerated, activityStatusValue_ = tostring(Properties_d.activityStatusValue), Managementgroup = mg[4], message_ = tostring(parse_json(Properties).message), caller_ = tostring(Properties_d.caller) //KQL Query to Identify if Management group is Created AzureActivity | where OperationNameValue == "MICROSOFT.MANAGEMENT/MANAGEMENTGROUPS/WRITE" | where ActivityStatusValue == "Success" | extend mg = split(tostring(Properties_d.entity),"/") | project TimeGenerated, activityStatusValue_ = tostring(Properties_d.activityStatusValue), Managementgroup = mg[4], message_ = tostring(parse_json(Properties).message), caller_ = tostring(Properties_d.caller) This log can also be used to monitor the new subscription creation as well, using the below query AzureActivity | where OperationNameValue == "Microsoft.Management" and ActivityStatusValue == "Succeeded" and isnotempty(SubscriptionId) If you need to trigger incident on sentinel, use the above query in your custom scheduled analytical rule and create alert. Note: Enabling this API on the Mangement group diagnostic logs will also be inherited by the subscriptions downstream on the specific category.
