logic apps
3 TopicsDetecting 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: let LookbackPeriod = 7d; let NeverActiveDevice = DeviceInfo | where TimeGenerated > ago(LookbackPeriod) | where OnboardingStatus == "Onboarded" | project DeviceName, DeviceId, TimeGenerated, SensorHealthState | summarize make_set(SensorHealthState) by DeviceId | where not(set_has_element(set_SensorHealthState, "Active")) | lookup kind=inner (DeviceInfo | project DeviceName, DeviceId, TimeGenerated, SensorHealthState) on DeviceId | summarize arg_max(TimeGenerated, *) by DeviceId; let PreviousActiveDevices = DeviceInfo | project DeviceName, DeviceId, TimeGenerated, SensorHealthState, OnboardingStatus | where TimeGenerated > ago(LookbackPeriod) | summarize arg_max(TimeGenerated, *) by DeviceId, SensorHealthState | sort by DeviceId asc, TimeGenerated asc | serialize | extend PrevState = prev(SensorHealthState) | extend PrevState_deviceId = prev(DeviceId) | where DeviceId == PrevState_deviceId | where PrevState == "Active" and SensorHealthState != "Active" | extend DaysInactive = datetime_diff('day', now(), TimeGenerated); union PreviousActiveDevices, NeverActiveDevice | project-reorder TimeGenerated, DeviceId, DeviceName, PrevState, SensorHealthState, DaysInactive | extend DaysInactive = iff(isnotempty(DaysInactive), tostring(DaysInactive), strcat("Not Active in ", toint(LookbackPeriod/1d), " days")) 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.Issue with Logic Apps running MANY times after enabling it
Hey guys! Anyone seen this problem before? This has happened to me a lot. I'll build out some logic (most of the time a schedule trigger that might run either every 5 mins or 1 hour) - go to enable it then it runs a million times over. Some of them I've just noticed have returned to a normal state after they've all run. There's enough runs to use a lot of resources that trying to edit another logic app fails! But I have no idea why it's doing this?! The trigger Any help appreciated! Thanks Dan3.8KViews0likes6CommentsWrong MDATP Logic App Connector Auth. endpoint for USgov
I'm trying to create a logic app that will trigger when a new WDATP alert occurs inside of a USgov region using the MDATP connector in the logic app designer. When I click the "Sign in" button it takes me to the authentication URL at https://login.microsoftonline.com/ which is not the proper authentication endpoint for USgov (it should redirect me to https://login.microsoftonline.us) This causes an error response letting me know that I'm making a request to a public endpoint instead of the government endpoint, and that the application must send the user to the right endpoint. I've spent hours looking for ways to change the authentication endpoint to the USgov one in the Microsoft Defender ATP logic app connector and I'm out of ideas. Has anyone encountered this issue and was able to edit the connector's request? or found a workaround? I'd love to hear from someone, thank you!2.1KViews0likes1Comment