detection
54 TopicsIngest Microsoft XDR Advanced Hunting Data into Microsoft Sentinel
I had difficulty finding a guide that can query Microsoft Defender vulnerability management Advanced Hunting tables in Microsoft Sentinel for alerting and automation. As a result, I put together this guide to demonstrate how to ingest Microsoft XDR Advanced Hunting query results into Microsoft Sentinel using Azure Logic Apps and System‑Assigned Managed Identity. The solution allows you to: Run Advanced Hunting queries on a schedule Collect high‑risk vulnerability data (or other hunting results) Send the results to a Sentinel workspace as custom logs Create alerts and automation rules based on this data This approach avoids credential storage and follows least privilege and managed identity best practices. Prerequisites Before you begin, ensure you have: Microsoft Defender XDR access Microsoft Sentinel deployed Azure Logic Apps permission Application Administrator or higher in Microsoft Entra ID PowerShell with Az modules installed Contributor access to the Sentinel workspace Architecture at a Glance Logic App (Managed Identity) ↓ Microsoft XDR Advanced Hunting API ↓ Logic App ↓ Log Analytics Data Collector API ↓ Microsoft Sentinel (Custom Log) Step 1: Create a Logic App In the Azure Portal, go to Logic Apps Create a new Consumption Logic App Choose the appropriate: Subscription Resource Group Region Step 2: Enable System‑Assigned Managed Identity Open the Logic App Navigate to Settings → Identity Enable System‑assigned managed identity Click Save Note the Object ID This identity will later be granted permission to run Advanced Hunting queries. Step 3: Locate the Logic App in Entra ID Go to Microsoft Entra ID → Enterprise Applications Change filter to All Applications Search for your Logic App name Select the app to confirm it exists Step 4: Grant Advanced Hunting Permissions (PowerShell) Advanced Hunting permissions cannot be assigned via the portal and must be done using PowerShell. Required Permission AdvancedQuery.Read.All PowerShell Script # Your tenant ID (in the Azure portal, under Azure Active Directory > Overview). $TenantID=”Your TenantID” Connect-AzAccount -TenantId $TenantID # Get the ID of the managed identity for the app. $spID = “Your Managed Identity” # Get the service principal for Microsoft Graph by providing the AppID of WindowsDefender ATP $GraphServicePrincipal = Get-AzADServicePrincipal -Filter "AppId eq 'fc780465-2017-40d4-a0c5-307022471b92'" | Select-Object Id # Extract the Advanced query ID. $AppRole = $GraphServicePrincipal.AppRole | ` Where-Object {$_.Value -contains "AdvancedQuery.Read.All"} # If AppRoleID comes up with blank value, it can be replaced with 93489bf5-0fbc-4f2d-b901-33f2fe08ff05 # Now add the permission to the app to read the advanced queries New-AzADServicePrincipalAppRoleAssignment -ServicePrincipalId $spID -ResourceId $GraphServicePrincipal.Id -AppRoleId $AppRole.Id # Or New-AzADServicePrincipalAppRoleAssignment -ServicePrincipalId $spID -ResourceId $GraphServicePrincipal.Id -AppRoleId 93489bf5-0fbc-4f2d-b901-33f2fe08ff05 After successful execution, verify the permission under Enterprise Applications → Permissions. Step 5: Build the Logic App Workflow Open Logic App Designer and create the following flow: Trigger Recurrence (e.g., every 24 hours Run Advanced Hunting Query Connector: Microsoft Defender ATP Authentication: System‑Assigned Managed Identity Action: Run Advanced Hunting Query Sample KQL Query (High‑Risk Vulnerabilities) Send Data to Log Analytics (Sentinel) On Send Data, create a new connection and provide the workspace information where the Sentinel log exists. Obtaining the Workspace Key is not straightforward, we need to retrieve using the PowerShell command. Get-AzOperationalInsightsWorkspaceSharedKey ` -ResourceGroupName "<ResourceGroupName>" ` -Name "<WorkspaceName>" Configuration Details Workspace ID Primary key Log Type (example): XDRVulnerability_CL Request body: Results array from Advanced Hunting Step 6: Run the Logic app to return results In the logic app designer select run, If the run is successful data will be sent to sentinel workspace. Step 7: Validate Data in Microsoft Sentinel In Sentinel, run the query: XDRVulnerability_CL | where TimeGenerated > ago(24h) If data appears, ingestion is successful. Step 8: Create Alerts & Automation Rules Use Sentinel to: Create analytics rules for: CVSS > 9 Exploit available New vulnerabilities in last 24 hours Trigger: Email notifications Incident creation SOAR playbooks Conclusion By combining Logic Apps, Managed Identities, Microsoft XDR, and Microsoft Sentinel, you can create a powerful, secure, and scalable pipeline for ingesting hunting intelligence and triggering proactive detections.6Views0likes0CommentsSentinel Data Connector: Google Workspace (G Suite) (using Azure Functions)
I'm encountering a problem when attempting to run the GWorkspace_Report workbook in Azure Sentinel. The query is throwing this error related to the union operator: 'union' operator: Failed to resolve table expression named 'GWorkspace_ReportsAPI_gcp_CL' I've double-checked, and the GoogleWorkspaceReports connector is installed and updated to version 3.0.2. Has anyone seen this or know what might be causing the table GWorkspace_ReportsAPI_gcp_CL to be unresolved? Thanks!260Views1like2CommentsIncident Missing Entities
Good morning! I would like to have some clarification on how entities work. Yesterday I found out that if I have 2 entities of the same type (In this particular case, two entities of the type Account), with the same identifier (originally, both share the identifier 'Name'), Sentinel appears to throw away one of them, or both in some instances, and when the alert generates an incident, the entities defined won't appear. I have switched out the identifier on both account types to something different, but until an incident gets triggered, I can't confirm if this will fix the original issue. So my questions are An analytic rule can or can't have two entities of the same type defined? If yes, that means that they need to have different identifiers. Is this a correct asumption? Some identifiers expect a certain type of value to be assigned, that means that eventually, I can ran out of identifiers for my entities or face the added complexity of dealing with types when returning values from my KQL query What could happen if I map an identifier to something that matches the type but not what that identifier represents? in this case, for Account, we have the identifier ObjectGuid. If I assign a value type string to it, that is not a guid, wouldn't that mess up something else in the background? Example, incident grouping If I move instead to use Sentinel Entities, which appear to be the 'general' option, I could only use one, since I only have 'entity' as available identifier, looping back to the problem of can have only one type of identifier for identity type. Thanks in advance267Views0likes2CommentsIdentityInfo with analytics KQL query
Hi, I'm currently trying to create a KQL query for an alert rule in Sentinel. The log source upon which the alert rule is based, only contains the SAMAccountName, which prevents me from mapping it to an Account entity in the alert. I'm therefore trying to use the IdentityInfo table to lookup the AadUserId of the user, using the SAMAccountName. The issue I'm running into is that I want my query to run every 10 minutes, and look up data from the past 10 minutes, as this is most suitable given the nature of the alert and the log source. This however causes the lookup in the IdentityInfo table to also only check data from the last 10 minutes, which doesn't work as the data in that table may be much older and therefor fail the lookup of the AadUserId of the user. According to the documentation, the IdentityInfo table is refreshed every 14 days, so for it to work I'd have to create a query that checks all logging, including that of the log source, from the past 14 days, which is not what I want. Hopefully some of you have suggestions or ideas on how to make this work. Thanks a lot! Marek626Views0likes8CommentsPlaybook when incident trigger is not working
Hi I want to create a playbook to automatically revoke session user when incident with specifics title or gravity is created. But after some test the playbook is'nt run autimacally, it work when I run it manually. I did'nt find what I do wrong. See the image and the code bellow. Thanks in advance! { "definition": { "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#", "contentVersion": "1.0.0.0", "triggers": { "Microsoft_Sentinel_incident": { "type": "ApiConnectionWebhook", "inputs": { "host": { "connection": { "name": "@parameters('$connections')['azuresentinel']['connectionId']" } }, "body": { "callback_url": "@{listCallbackUrl()}" }, "path": "/incident-creation" } } }, "actions": { "Get_incident": { "type": "ApiConnection", "inputs": { "host": { "connection": { "name": "@parameters('$connections')['azuresentinel-1']['connectionId']" } }, "method": "post", "body": { "incidentArmId": "@triggerBody()?['object']?['id']" }, "path": "/Incidents" }, "runAfter": {} }, "Send_e-mail_(V2)": { "type": "ApiConnection", "inputs": { "host": { "connection": { "name": "@parameters('$connections')['office365']['connectionId']" } }, "method": "post", "body": { "To": "email address removed for privacy reasons", "Subject": "Ceci est un test", "Body": "</p> <p class="\"editor-paragraph\"">@{body('Get_incident')?['id']}</p> <p class="\"editor-paragraph\"">@{body('Get_incident')?['properties']?['description']}</p> <p class="\"editor-paragraph\"">@{body('Get_incident')?['properties']?['incidentNumber']}</p> <p>", "Importance": "Normal" }, "path": "/v2/Mail" }, "runAfter": { "Get_incident": [ "Succeeded" ] } } }, "outputs": {}, "parameters": { "$connections": { "type": "Object", "defaultValue": {} } } }, "parameters": { "$connections": { "type": "Object", "value": { "azuresentinel": { "id": "/subscriptions/xxxx/providers/Microsoft.Web/locations/xxxxx/managedApis/xxxxxxx", "connectionId": "/subscriptions/xxxxxxx/resourceGroups/xxxxxx/providers/Microsoft.Web/connections/azuresentinel-Revoke-RiskySessions1", "connectionName": "azuresentinel-Revoke-RiskySessions1", "connectionProperties": { "authentication": { "type": "ManagedServiceIdentity" } } }, "azuresentinel-1": { "id": "/subscriptions/xxxxxx/providers/Microsoft.Web/locations/xxxx/managedApis/xxx", "connectionId": "/subscriptions/xxxxxxx/resourceGroups/xxxxx/providers/Microsoft.Web/connections/xxxx", "connectionName": "xxxxxx", "connectionProperties": { "authentication": { "type": "ManagedServiceIdentity" } } }, "office365": { "id": "/subscriptions/xxxxxx/providers/Microsoft.Web/locations/xxxxx/managedApis/office365", "connectionId": "/subscriptions/xxxxx/resourceGroups/xxxxxx/providers/Microsoft.Web/connections/o365-Test_Send-email-incident-to-xxxx", "connectionName": "o365-Test_Send-email-incident-to-xxxxx" } } } } }Solved2.4KViews0likes2CommentsUnknown Behaviour Involving GroupsService in OfficeActivity
I have spotted a few hundred events with the following KQL query in my environment. This is the result of one of the entries. It looks like a regular legitimate behaviour by Microsoft but I don't seem to find any documentation about it. Can anyone share the insight of it? Thank you!55Views0likes0CommentsLookup data from the last == ingestion_time()
Howdy! In "Analytics rule wizard - Create a new Scheduled rule" under Query scheduling you have to fill out "Lookup data from the last" What time field is Sentinel looking at when determine which events to include in the lookup data? Is it ingestion_time()? Is it TimeGenerated? How does it know?203Views1like3CommentsDaily "Network Port Sweep detected on port x" but no Source IP
For a couple of months we have been getting "Network Port Sweep was detection by multiple IPs" with ports 135 and 445 mostly. The KQL attached lists a load of Destination IPs but no Source IP (see example below) All these are inside our network, and so not coming from outside the network where the firewall would block such scans. We suspect it is one of our network tools such as Solarwinds but without the Source IP it is difficult to prove anything. // The query_now parameter represents the time (in UTC) at which the scheduled analytics rule ran to produce this alert. set query_now = datetime(2024-06-24T03:01:10.2587643Z); let lookback = 1h; let threshold = 20; _Im_NetworkSession(starttime=ago(lookback), endtime=now()) | where NetworkDirection == "Inbound" | summarize make_set(DstIpAddr, 100) by DstPortNumber | where array_length(set_DstIpAddr) > threshold Tried to modify the query, this is the KQL I have tried. set query_now = datetime(2024-01-26T07:47:48.3756000Z); let lookback = 1h; let threshold = 20; _Im_NetworkSession(starttime=ago(lookback), endtime=now()) | where NetworkDirection == "Inbound" | summarize make_set(DstIpAddr, 100), make_set(SrcIpAddr, 100) by DstPortNumber | where array_length(set_DstIpAddr) > threshold Anyone got any suggestions on how we can track down what is causing this alert in Sentinel?2.2KViews0likes7Comments