4.2.1. Hunting Graphs and Blast Radius
💡 First Principle: A hunting graph renders entities as nodes and their relationships as edges, so paths become visible at a glance. Prebuilt scenarios encode the questions defenders ask most often, such as paths to critical assets and who can reach sensitive data, so you can map blast radius without writing graph queries.
In the Defender portal, the hunting graph lives inside advanced hunting (Create new > Hunting graph). Instead of writing a query, you choose a predefined scenario, supply inputs, and run it. The graph shows nodes (users, devices, IP addresses, storage accounts, key vaults, Kubernetes clusters, repositories) and edges describing relationships such as member of, has permissions to, can authenticate as, has credentials of, frequently logged in by, and routes traffic to.
| Scenario | Question it answers |
|---|---|
| Entity relationship map | What is this entity directly connected to? (blast radius starting point) |
| Attack paths to critical asset | How could an attacker reach this crown-jewel asset? |
| Paths between two entities | Can this compromised device reach that server? |
| Access to key vaults / users with access to sensitive data | Who can reach these secrets or this data? |
| Paths to domain compromise (DCSync), Kerberoast paths to critical assets, AS-REP roast paths | Which non-privileged routes lead to domain takeover? |
| Choke points to SQL data stores | Which single nodes appear in the most paths, so fixing them removes the most risk? |
Filters refine the picture: show only shortest paths, restrict source nodes to those that are critical, vulnerable, or internet-exposed, restrict targets to those holding sensitive data, or limit edge types and direction. Scenarios are tagged with MITRE tactics such as lateral movement and credential access. Prerequisites include an Entra role with advanced hunting permissions, access to the Sentinel data lake, and at least read access in Microsoft Security Exposure Management, which supplies asset context such as critical asset status. Microsoft lists about twenty scenarios in all, including OAuth apps with privileged access and attack paths to critical Kubernetes clusters.
Blast radius analysis during an incident follows a simple loop: start from the compromised entity with the entity relationship map, expand hop by hop, and stop when you reach entities with no suspicious activity and no path to anything critical. Everything inside that boundary is in scope for investigation and possibly containment. Choke points are the high-value output for remediation: a single over-permissioned group or service account that sits on many attack paths is the best place to cut.
⚠️ Exam Trap: "Identify the minimal set of changes that removes the most attack paths to your SQL databases" is the choke point scenario, not attack paths to one critical asset (which shows paths but not where they converge) and not an advanced hunting KQL query of logons.
Reflection Question: Two remediation options exist: removing a compromised user's access to one server, or removing the help-desk group's local admin rights across 300 servers. How would a hunting graph help you decide, and what would you look for?
