The Attacker Now Enrols the Passkey: Why Phishing-Resistant MFA Stopped Being the Answer This Month

Week of 31 August 2026 | Compiled by Team Paringa

Two disclosures in August moved the identity conversation on. The problem is no longer whether an authenticator can be phished. It is what an attacker does with the authenticated session once they are inside it.

What Happened This Week

🔴 iAuthFlow v2: a $10k phishing kit that plants its own passkey and outlives your password reset

On 20 August 2026, Abnormal Security published research on iAuthFlow v2, a commercially sold phishing toolkit advertised on a Russian-language cybercrime forum at a $10,000 base price with capability modules sold separately. The Register covered it on 21 August. SecurityWeek followed.

The delivery mechanism is browser-in-the-middle rather than the more familiar reverse-proxy AiTM. The victim believes they are completing a normal login on their own device, while the attacker's infrastructure relays the whole interaction through a separate browser session under attacker control. Everything the victim does, including any MFA step, happens inside the attacker's browser.

The innovation is what happens after authentication. Holding an authenticated session, the kit drives the target platform's own passkey enrolment flow and registers an attacker-controlled passkey on the victim's account. That credential is a first-class, legitimate authenticator as far as the identity provider is concerned. The demos focused on Google, and the seller advertises packages for Microsoft, iCloud and LinkedIn.

The consequence is the part that breaks standard incident response. A password reset does not remove it. Session revocation does not remove it. Rotating the primary MFA factor does not remove it. Unless the responder specifically audits the account's registered authenticators and deletes the unfamiliar one, the attacker retains durable, MFA-satisfying access through the front door. Most helpdesk and IR runbooks in use today do not include an authenticator inventory step.

Sources: The Register, Abnormal AI, SecurityWeek

Add "enumerate and validate every registered authenticator" to your account-compromise runbook this week. It is a ten-minute change and it is currently the only reliable eviction step. The deeper point is architectural. Every one of these attacks works because the platform issues a durable, replayable credential to whoever happens to be holding an authenticated session, and cannot tell whether that session belongs to the human or to a browser in a datacentre. Password, OTP, push, FIDO2 key, passkey: they differ in how hard they are to phish, not in whether a credential exists to be stolen, replayed or quietly re-issued. The design question your architects should be asked is simple. If no credential is ever issued in the first place, what is the attacker holding at the end of the session? Enrolment is now an attack surface, so treat authenticator registration as a privileged operation with its own approval and alerting, not as a self-service convenience.

🟡 Pass-the-Passkey: FIDO2 is not broken, the operating system around it is

SpecterOps principal researcher Michael Grafnetter presented Pass-the-Passkey at Black Hat USA on 5 August 2026, with follow-up coverage through the month. The research does not break FIDO2 cryptography. It goes around it, abusing Windows event logs, Google Password Manager and Windows Hello to recover or reuse synced passkey material and bypass what organisations have been buying as phishing-resistant MFA. Microsoft assigned CVE-2026-34348 to the Windows logging issue, vendor CVSS 6.5, with a security update.

Synced passkeys are the weak seam. The moment a credential is portable across devices so that users do not get locked out, it becomes a thing that lives in a cloud account, syncs to endpoints and can be recovered by malware with local access. The usability requirement and the security claim pull in opposite directions.

Then there is the fallback problem. Organisations that deploy passkeys almost never remove the alternatives, because helpdesk volume would spike. So OTP, push and SMS recovery paths remain live, and attackers simply socially engineer users down to the weakest enabled method. A passkey deployment with an SMS recovery path is protected to the strength of SMS.

Sources: The Hacker News

The compliance framing is where this bites. Boards and regulators have been told "phishing-resistant MFA" is a binary control that is either in place or not. August made that untrue. If your control narrative says phishing-resistant MFA is deployed, someone will now ask which fallback methods remain enabled, whether passkeys are device-bound or synced, and how you detect a rogue enrolment. Have those three answers ready before an auditor or an insurer asks. Also stop treating endpoint compromise and identity compromise as separate incident types. Pass-the-Passkey collapses them into one.

🟡 The identity provider is the target, and Entra ID is the most exposed

Okta has documented custom phishing kits sold on a subscription basis and built specifically for live vishing calls. The attacker gets a control panel that updates the fake authentication page in real time while they are on the phone with the victim. That defeats push MFA with number matching, because the attacker tells the victim which number to select and the kit's command-and-control simultaneously renders the matching prompt in the browser. Number matching was the control that was supposed to fix push fatigue.

The scale underneath this is credential supply. Infostealers harvested 1.7 billion credentials in the first half of 2026 across more than 7.4 million unique compromised hosts, roughly 27 percent up on the previous six months. Enterprise identity exposure in stealer logs has more than doubled, from around 6 percent of infections in early 2024 to close to 14 percent by late 2025. Microsoft Entra ID appears in 79 percent of enterprise identity logs, making it the most represented identity provider in stolen-credential data by a wide margin.

Attacks against the identity layer also do not look like attacks. Activity conducted with a valid session, a valid token or a legitimately enrolled authenticator produces no sign-in anomaly, no impossible travel and no failed authentication. It looks like the user.

Sources: BleepingComputer, Infosecurity Magazine

Note what the incumbent vendors recommend when their own MFA is bypassed: a stronger authenticator. FastPass, security keys, passkeys. It is the same answer each time because it is the only answer available inside a credential-issuing model. Each stronger factor buys a shorter window before the attack pattern adapts, and August showed the adaptation cycle is now measured in months. Two things to do now. First, tighten conditional access so that a stolen session alone is not sufficient, using device-bound signals rather than network location. Second, when you next scope an identity refresh, put at least one credential-free approach on the shortlist alongside the incumbent. Not because the incumbent is bad, but because comparing two variants of the same architecture is not an evaluation.

What Identity and Security Architects Are Dealing With

The industry spent five years moving up the authenticator strength ladder: passwords, then OTP, then push, then number-matched push, then FIDO2, then passkeys. Each rung was sold as the end of phishing. Each was defeated not by cryptanalysis but by attacking the surrounding process: the session, the recovery flow, the sync mechanism, the helpdesk, and now the enrolment flow itself. The ladder has run out of rungs. There is nothing stronger than a hardware-backed FIDO2 credential, and iAuthFlow v2 works against accounts protected by one, because it does not attack the credential at all.

The pattern is consistent enough to state as a design principle. If a system issues a durable credential to a user, that credential can be captured, replayed, re-issued or added to. Phishing resistance reduces the probability of capture. It does not remove the object being captured. The architectural alternative, which the market has been slow to take seriously, is authentication where no credential is ever issued to the user in the first place: nothing to store, nothing to sync, nothing to phish, nothing to replay, and nothing an attacker can silently register on the way out. That is a different question from "which MFA should we buy," and it is the question the last three weeks have made unavoidable.

Three Things Worth Watching Next Week

1. Google and Microsoft enrolment-flow hardening — Expect step-up verification or out-of-band confirmation for passkey registration. Watch whether it is default-on or an admin toggle nobody flips.

2. iAuthFlow v2 module expansion — The seller already advertises Microsoft, iCloud and LinkedIn packages. Confirmed Entra ID enrolment in the wild would be a significant escalation for enterprise tenants.

3. Regulator and insurer language on "phishing-resistant MFA" — Cyber insurers and frameworks that treat it as a tick-box control now have a documented bypass. Expect questionnaire wording to shift towards fallback methods and enrolment controls.

Questions? hello@paringa.ai

Paringa is an Infrastructure & AI Security, Cost and Governance Specialist. We help organisations assess whether their identity architecture still holds against current attack techniques, and evaluate credential-free alternatives on evidence rather than vendor claims. | 31 August 2026 | © Paringa Ltd