Read-only and still hostile: Resource Graph as a tenant scout

Not every incident changes something. Sometimes the attacker just reads, and reading the whole tenant is exactly how a targeted attack begins.

How the attack works

A compromised identity holds broad Reader across the tenant. The attacker turns to Azure Resource Graph, the KQL query service that indexes every resource across all subscriptions, and maps the environment in minutes. A first broad query returns every resource type the principal can read. Follow-up queries enumerate managed identities and Key Vault resources with their access configs, hunting for credential-bearing targets, then network interfaces, security groups, and public IPs to find reachable and lateral paths. Dozens of distinct queries fire in minutes from a principal whose baseline is zero. Nothing is modified, so traditional alerts stay quiet. The Azure Activity log records each Microsoft.ResourceGraph operation. This maps to T1580, Cloud Infrastructure Discovery, and T1526, Cloud Service Discovery.

Why it works

Broad Reader is handed out widely, so any compromised low-value identity becomes a full-tenant scout. Read-only access feels benign, which is exactly why the recon goes unanswered.

How to fix it

Waiting for a write or an exfiltration event means the attacker already holds the map and has chosen the highest-value target. The non-obvious move is to treat the recon as a live precursor: strip the over-broad Reader, scope the principal to least privilege, and revoke its active sessions so the in-flight queries stop now. You cannot firewall a managed query service per principal. Durably, trim Reader sprawl tenant-wide and add detection for anomalous bulk Resource Graph queries, and assume the tenant map is already in adversary hands.

Practice it

We built this as a GraphLattice Range scenario so security teams learn to act on read-only recon instead of waiting for the write.