Four Labs on One Attack Chain
How four public labs fit one common cloud-identity pattern on a single map: phishing that gets through, a compromised Entra account, the order of containment, identity hardening that shrinks the next mess, and a parallel path where an AI agent is steered by untrusted content.
My last two posts stayed close to one problem at a time. Report-Only First was about preventing account takeover with Entra ID controls written as code. Order of Operations picked up where prevention runs out: what to do in the first hour when a user account is compromised anyway.
Those labs were never meant to sit alone. Put next to the phishing-detector work and a newer prompt-injection lab, they follow one pattern a lot of cloud identity attacks share. I put that pattern on a single page: One attack chain, four labs.
This post is how to read that map, what each lab is for, and what I would take from the sequence if I were responsible for identity somewhere else.
How to read the map
Side by side, the labs follow a common cloud-identity pattern: a phishing URL gets past a filter, an attacker signs in as the user, responders have to contain it in the right order, and identity controls make the next attempt harder. A fourth lab covers a newer entry point - instructions hidden in content an AI agent reads, not a link a person clicks.
How to read this: the arrows are thematic, not one incident I traced end to end. The labs don't share data or code. Each one is a lab (synthetic or public data); status and limits live in the repo and in the captions on the map. Solid arrows show a common attack sequence. Dashed arrows show a related idea. No arrow means one lab's results prove anything about another lab.
1. Phishing gets through
The first node is phishing-detector-adversarial-robustness. It trains URL-only phishing detectors, attacks them with cheap, realistic edits a phisher who owns their domain can make, and measures what defenses buy and cost. Public data; attacks rewrite strings offline; no URL is visited. The useful finding for this map is narrower than "ML is fragile": classifiers leaned on URL features an attacker could flip. Longer write-up: the adversarial ML phishing case study.
2. Account is compromised
The second node is the draft IR runbook: entra-account-compromise-ir. It covers a compromised Microsoft Entra ID user account from first alert to lessons learned, with 12 KQL queries for Microsoft Sentinel and Log Analytics, a flow diagram, and a 90-minute tabletop at a fictional company. Steps map to NIST SP 800-61 Rev. 2, and most map to MITRE ATT&CK technique IDs.
Same status as in the Order of Operations post: none of the queries has been run against a real workspace or tenant, and the runbook hasn't been exercised. The queries pass an offline check that they parse and only use documented tables and columns. That's all that's been proven so far.
Map edge in: a phish that gets through can lead to a stolen sign-in. Edge out: responders who invent the order of disable, revoke, and reset in the moment burn the first hour. For a team exercise without a tenant, there is a Tabletop in a Box pack from the same material.
3. Harden identity
The third node is azure-entra-identity-hardening: baseline Entra ID controls in Terraform. Conditional Access starts in report-only mode. Every policy excludes a break-glass group. Security operators get eligible roles through PIM instead of standing admin rights. The code passes static checks (terraform fmt, terraform validate, tflint, checkov) and has not been applied to a tenant yet.
The arrows between compromise and harden go both ways on purpose: lessons from the response inform which controls to enforce, and controls shrink what responders clean up next time. That loop matters more to me as a leader than any single policy name. Longer write-up: Report-Only First. For the decisions without the Terraform: Security Decision Cards.
4. AI agent is manipulated (parallel path)
The fourth node sits on a dashed path, not in the phishing-to-containment line. prompt-injection-lab is a tool-using IT helpdesk agent for the fictional company Fabrikam. It measures how often prompt injection makes the agent misuse its tools, and how much simple prompt-level defenses help. Synthetic data only (fabrikam.example); nothing touches a real account, mailbox, or network. Cases are tagged to OWASP LLM Top 10, OWASP Agentic Top 10, and MITRE ATLAS.
The parallel edges are why it belongs here. Same idea, new target: untrusted input that steers a machine instead of a person. Agents act with identities too, so least privilege still applies - an MFA reset or send-email tool is a privileged action whether a model chose it or not. Treat the findings the way the repo asks: small local models, synthetic cases, limits listed next to the results.
What I'd take from the sequence
If I were reading this map as a security leader rather than as the person who built the labs, I'd take four decisions, not four tools.
Decide what "good enough" means for the first filter. URL-only detectors and content filters fail in different ways. Know which layer you are measuring before you declare a win.
Decide the first three containment steps before the incident. Disable, revoke, reset - in that order, as close together as possible - should not be a debate at 2 a.m. The person on call needs the access to take them.
Decide that identity changes ship like code. Report-only first. Break-glass exclusions on every policy. Eligible admin rights instead of standing ones. Review in a pull request, not in the portal after something breaks.
Decide that AI agents inherit the same identity rules. If an agent can reset MFA or send mail, it has a privileged identity. Prompt defenses help. They do not replace least privilege, logging, or an IR path when the agent is steered.
None of that requires pretending these four repos are one product. They aren't. The value of the map is the pattern: entry, compromise, response, hardening, and a parallel entry through agents.
What's next
Still waiting on the Entra labs: a dedicated test tenant, real sign-in and audit data for the queries, and a tabletop with a few people so the gaps feed back into the runbook. The prompt-injection lab will get the same treatment as the phishing lab - write up what held, what didn't, and what I would not claim yet.
If you own identity or tool-using agents in your organization, here's the question I'd take from the map: can your team point to where a phish, a compromised cloud account, the first hour of response, and an agent that can act with privilege each live in your stack - and which of those four you have actually rehearsed?