incident management
80 TopicsUnifying AWS and Azure Security Operations with Microsoft Sentinel
The Multi-Cloud Reality Most modern enterprises operate in multi-cloud environments using Azure for core workloads and AWS for development, storage, or DevOps automation. While this approach increases agility, it also expands the attack surface. Each platform generates its own telemetry: Azure: Activity Logs, Defender for Cloud, Entra ID sign-ins, Sentinel analytics AWS: CloudTrail, GuardDuty, Config, and CloudWatch Without a unified view, security teams struggle to detect cross-cloud threats promptly. That’s where Microsoft Sentinel comes in, bridging Azure and AWS into a single, intelligent Security Operations Center (SOC). Architecture Overview Connect AWS Logs to Sentinel AWS CloudTrail via S3 Connector Enable the AWS CloudTrail connector in Sentinel. Provide your S3 bucket and IAM role ARN with read access. Sentinel will automatically normalize logs into the AWSCloudTrail table. AWS GuardDuty Connector Use the AWS GuardDuty API integration for threat detection telemetry. Detected threats, such as privilege escalation or reconnaissance, appear in Sentinel as the AWSGuardDuty table. Normalize and Enrich Data Once logs are flowing, enrich them to align with Azure activity data. Example KQL for mapping CloudTrail to Sentinel entities: AWSCloudTrail | extend AccountId = tostring(parse_json(Resources)[0].accountId) | extend User = tostring(parse_json(UserIdentity).userName) | extend IPAddress = tostring(SourceIpAddress) | project TimeGenerated, EventName, User, AccountId, IPAddress, AWSRegion Then correlate AWS and Azure activities: let AWS = AWSCloudTrail | summarize AWSActivity = count() by User, bin(TimeGenerated, 1h); let Azure = AzureActivity | summarize AzureActivity = count() by Caller, bin(TimeGenerated, 1h); AWS | join kind=inner (Azure) on $left.User == $right.Caller | where AWSActivity > 0 and AzureActivity > 0 | project TimeGenerated, User, AWSActivity, AzureActivity Automate Cross-Cloud Response Once incidents are correlated, Microsoft Sentinel Playbooks (Logic Apps) can automate your response: Example Playbook: “CrossCloud-Containment.json” Disable user in Entra ID Send a command to the AWS API via Lambda to deactivate IAM key Notify SOC in Teams Create ServiceNow ticket POST https://api.aws.amazon.com/iam/disable-access-key PATCH https://graph.microsoft.com/v1.0/users/{user-id} { "accountEnabled": false } Build a Multi-Cloud SOC Dashboard Use Sentinel Workbooks to visualize unified operations: Query 1 – CloudTrail Events by Region AWSCloudTrail | summarize Count = count() by AWSRegion | render barchart Query 2 – Unified Security Alerts union SecurityAlert, AWSGuardDuty | summarize TotalAlerts = count() by ProviderName, Severity | render piechart Scenario Incident: A compromised developer account accesses EC2 instances on AWS and then logs into Azure via the same IP. Detection Flow: CloudTrail logs → Sentinel detects unusual API calls Entra ID sign-ins → Sentinel correlates IP and user Sentinel incident triggers playbook → disables user in Entra ID, suspends AWS IAM key, notifies SOC Strengthen Governance with Defender for Cloud Enable Microsoft Defender for Cloud to: Monitor both Azure and AWS accounts from a single portal Apply CIS benchmarks for AWS resources Surface findings in Sentinel’s SecurityRecommendations table170Views4likes0CommentsHow to stop incidents merging under new incident (MultiStage) in defender.
Dear All We are experiencing a challenge with the integration between Microsoft Sentinel and the Defender portal where multiple custom rule alerts and analytic rule incidents are being automatically merged into a single incident named "Multistage." This automatic incident merging affects the granularity and context of our investigations, especially for important custom use cases such as specific admin activities and differentiated analytic logic. Key concerns include: Custom rule alerts from Sentinel merging undesirably into a single "Multistage" incident in Defender, causing loss of incident-specific investigation value. Analytic rules arising from different data sources and detection logic are merged, although they represent distinct security events needing separate attention. Customers require and depend on distinct, non-merged incidents for custom use cases, and the current incident correlation and merging behavior undermines this requirement. We understand that Defender’s incident correlation engine merges incidents based on overlapping entities, timelines, and behaviors but would like guidance or configuration best practices to disable or minimize this automatic merging behavior for our custom and analytic rule incidents. Our goal is to maintain independent incidents corresponding exactly to our custom alerts so that hunting, triage, and response workflows remain precise and actionable. Any recommendations or advanced configuration options to achieve this separation would be greatly appreciated. Thank you for your assistance. Best regardsSolved297Views1like6CommentsXDR advanced hunting region specific endpoints
Hi, I am exploring XDR advanced hunting API to fetch data specific to Microsoft Defender for Endpoint tenants. The official documentation (https://learn.microsoft.com/en-us/defender-xdr/api-advanced-hunting) mentions to switch to Microsoft Graph advanced hunting API. I had below questions related to it: 1. To fetch the region specific(US , China, Global) token and Microsoft Graph service root endpoints(https://learn.microsoft.com/en-us/graph/deployments#app-registration-and-token-service-root-endpoints ) , is the recommended way to fetch the OpenID configuration document (https://learn.microsoft.com/en-us/entra/identity-platform/v2-protocols-oidc#fetch-the-openid-configuration-document) for a tenant ID and based on the response, the region specific SERVICE/TOKEN endpoints could be fetched? Since using it, there is no need to maintain different end points for tenants in different regions. And do we use the global service URL https://login.microsoftonline.com to fetch OpenID config document for a tenantID in any region? 2. As per the documentation, Microsoft Graph Advanced hunting API is not supported in China region (https://learn.microsoft.com/en-us/graph/api/security-security-runhuntingquery?view=graph-rest-1.0&tabs=http). In this case, is it recommended to use Microsoft XDR Advanced hunting APIs(https://learn.microsoft.com/en-us/defender-xdr/api-advanced-hunting) to support all region tenants(China, US, Global)?145Views0likes1CommentMTO Portal MFA Prompt Not Loading
Hi We are using the mto portal to hunt across multiple tenants. My team get the "loading completed with errors" message and the prompt for "MFA Login Required". When they select this the window to authenticate opens and then closes instantly. When selecting the tenant name they can authenticate in a new tab directly to Defender in this tenant without any issue (but this does not carry over to the MTO portal). The old behaviour was that they selected "MFA Login Required" and they could authenticate to the tenants they needed to at that time. Is this happening to anyone else? Does anyone have any tips for managing multiple Defender instances using MTO? Thanks285Views0likes2CommentsMSSP 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.272Views0likes2CommentsAdvanced 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?154Views0likes1CommentTVM 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!581Views0likes2CommentsCannot 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?Solved300Views0likes4CommentsCan 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?58Views0likes0CommentsWhitelisting 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. HKN263Views0likes1Comment