The Containment Runbook Now Has a Missing Step
Password reset plus session revocation was never a threat model — it was an assumption about how credentials get created, and a commodity kit sold on forums has priced that assumption at five figures.
The mechanism to understand is the enrollment path, not the authenticator. A passkey is a hardware-bound credential that cannot be replayed or relayed. That is why "phishing-resistant MFA" became shorthand for it. The property holds only if the registration ceremony is trusted. iAuthFlow v2 attacks the ceremony. After the victim authenticates through the proxy, the kit registers an authentication method on the victim's behalf and lands an attacker-controlled passkey in the account. Every check the identity provider applies to that credential then passes.
Which is why the standard runbook fails. A password reset invalidates a secret the attacker no longer needs. Session revocation kills tokens the attacker can re-mint on demand. Both steps produce clean-looking closure notes.
| Mechanism | Survives password reset | Survives session revocation | Where the evidence lives |
|---|---|---|---|
| Attacker-enrolled passkey | Yes — by design | Yes — by design | Authentication-method enrollment logs |
| OAuth consent grant | Yes | Partially | Consent grant and service principal sign-ins |
| Device-code flow abuse | No, but re-phishable | No | Device-code sign-in telemetry |
| Stolen password | No | No | Standard identity protection |
Where the sources converge
Risky Business is the primary account of the kit itself. The corroboration is directional rather than duplicative, and it points one way. Mandiant reports three Russian APT clusters migrating phishing toward OAuth flows, device codes and instant-messaging account takeover. Sublime Security profiled DOUBLOON DREDGER running device-code phishing through the EvilTokens service. Palo Alto Networks measured a 4x year-over-year increase in phishing delivered through collaboration platforms rather than email. That last number is the one to sit with. The delivery channel the gateway does not inspect feeds the enrollment path the IdP does not alert on. State and criminal tradecraft are converging on the credential lifecycle, not the credential.
A tenant that cannot produce, today, a list of every passkey enrolled in the last 90 days mapped to a known device is carrying an exposure with a published market price.
What your telemetry probably does not cover
Three gaps recur. First, credential-enrollment events are usually retained and rarely alerted on, because enrollment is a normal onboarding action. The high-fidelity alert is narrow and cheap: new authentication method registered shortly after a risky or anomalous sign-in. Second, the OAuth device-code grant is enabled by default in most tenants and used legitimately by almost nobody outside kiosk and CLI scenarios. Scoping it in Conditional Access removes an entire branch of the tree. Third, IR closure criteria are written as checklists, so validation never happens. The fix is a purple-team exercise that implants a rogue credential and measures whether responders find it and remove it.
One honest caveat. The kit's capability set is as described by researchers, and pricing on criminal forums is a marketing claim as much as a fact. Neither changes the defensive work, which is identical whether the tool costs $10,000 or is later cloned for free.
What to do
Pull 90 days of authentication-method enrollment events from Entra ID, Google Workspace and iCloud this week, reconcile each to a known user device, and open an investigation on every unmatched credential.
Rewrite the account-compromise runbook by end of sprint to require enumeration and removal of all authentication methods, app passwords, OAuth grants and registered devices before an incident can be closed.
Block or narrowly scope the OAuth device-code grant in Conditional Access and alert on device-code authentications from unmanaged networks.