> ## Content Index
> Fetch the complete content index at: https://f4n6.co.uk/llms.txt
> Use this file to discover other available public pages before exploring further.

# New Phishing Toolkit Uses Passkeys to Maintain Access After Password Resets
- URL: https://f4n6.co.uk/security-feed/new-phishing-toolkit-uses-passkeys-to-maintain-access-after-password-resets/
- Published: 2026-08-21T15:00:40.000Z
- Updated: 2026-08-21T15:00:40.000Z
- Author: Jeff Davies
- Tags: #security-feed

## 1\. Executive summary

A new phishing-as-a-service (PhaaS) toolkit dubbed **iAuthFlow V2**, first advertised on a Russian-language cybercrime forum at $10,000 for the base package, demonstrates a technique that defeats the standard incident-response playbook for credential phishing: after relaying a victim's authentication through an attacker-controlled remote browser, the toolkit silently registers an attacker-controlled **passkey** on the victim's account. Because a passkey is a registered credential rather than a derived token, a password reset and session revocation do not remove it, leaving the attacker with persistent access. The analysis is **single-sourced** (Abnormal Security), based on the seller's forum posts and demonstrations rather than active deployment or reverse-engineering of the malware; no MITRE actor profile is available and attribution is unconfirmed. EMEA financial services should treat this as a credible emerging technique that invalidates the assumption that password reset alone remediates a phishing compromise.

## 2\. Regulatory framing

No specific DORA/NIS2 article is directly engaged by this item. The trigger test is not met: while a phishing compromise could eventually lead to an ICT-related incident, the item describes a toolkit and technique, not an incident at a regulated entity. Generic mappings to incident-management or reporting articles would apply to virtually any security event and are excluded as compliance-checkbox padding.

## 3\. Technical analysis & attack chain

**Confidence caveat:** The entire attack chain below is derived from a single source — Abnormal Security's analysis of the iAuthFlow V2 seller's forum posts and demonstrations. Abnormal did not acquire or execute the malware. No independent corroboration of the toolkit's capabilities has been identified. Gemini and Copilot summaries referenced in the source disagree on or omit the passkey functionality. Treat all claims below as **single-sourced; verify before enforcement**.

### Attack chain (postulated by Abnormal Security)

1. **Initial phishing.** The target is phished via standard social engineering and lands on an attacker-controlled web page displayed in the target's own browser. The target must be fooled into entering credentials — the attack does not bypass the need for user interaction.
2. **Dual-browser relay.** Unseen by the target, the attacker maintains a separate but connected second browser environment on the attacker's server. Credentials and authentication responses entered by the target are relayed in real time to this remote browser, which interacts with the legitimate service (demonstrated against a Gmail account).
3. **Device fingerprint application.** The malware immediately applies a device fingerprint to the target's browser session. Each keystroke/entry from the target is logged.
4. **Silent passkey registration.** The malware silently adds a ready-made, attacker-controlled passkey to the victim's account during the authenticated session. All interactions are relayed through the second browser environment.
5. **User-authenticated passkey approval.** Google (via the second browser, proxied through the initial phishing page) prompts the target to authenticate. If the initial phish succeeds, the target authenticates — unknowingly approving the attacker-controlled passkey registration as part of the flow.
6. **Persistence post-remediation.** When the victim discovers the compromise and performs a password reset plus session revocation, the attacker's passkey survives. Google's password reset revokes app passwords and OAuth tokens with Gmail scopes, but does not remove registered passkeys. The attacker regains access by selecting "try another way" at login and authenticating with the passkey — no password knowledge required.

### Key technical observations

- **Target platform demonstrated:** Gmail (Google). The technique is not necessarily limited to Google but the source only describes the Gmail use case.
- **Persistence mechanism:** Attacker-controlled passkey registered as a credential on the account. This is a credential, not a session token — it is not invalidated by password change, session revocation, or OAuth token revocation.
- **What standard remediation does NOT cover:** Per Google's own documentation cited by Abnormal, changing a password revokes app passwords and OAuth tokens with Gmail scopes, but "some authorized devices and third-party connections may remain signed in." Registered passkeys are not in the revocation scope of a password reset.
- **Toolkit pricing and distribution:** Base toolkit offered at $10,000 on a Russian-language cybercrime forum; additional modules sold separately. This price point suggests a targeted/enterprise-focused buyer base rather than mass-criminal use.
- **No MITRE ATT&CK actor profile** is available for iAuthFlow V2\. Attribution to any specific threat actor is unconfirmed.

## 4\. Mitigation & containment

### P1 — Within 24 hours (containment if a phishing compromise is suspected)

- Do NOT assume a password reset remediates the compromise. After any confirmed or suspected credential phishing incident, **enumerate and review all registered passkeys** on the affected account. In Google Workspace: Admin Console → Security → Authentication → Passkeys; or via the user's Google Account → Security → Passkeys. Remove any unrecognised passkey.
- Revoke all active sessions, app passwords, and OAuth tokens in addition to the password reset — but verify passkeys separately, as these survive token revocation.
- Force re-enrolment of MFA and review all trusted devices.

### P2 — Within 72 hours (detection and hardening)

- Audit passkey registrations across the estate. For Google Workspace environments, use the Admin SDK Directory API or Security Investigation Tool to enumerate passkeys across users and flag accounts with recently added passkeys that do not correlate to known device enrolment events.
- Alert on passkey registration events that occur outside of expected device-management workflows or that originate from IP addresses / geographies inconsistent with the user's profile.
- Review IdP/SSO configuration: if passkeys are supported, ensure registration events are logged, alertable, and require step-up authentication or admin approval for new passkey enrolment where the platform supports it.
- Update incident-response runbooks for credential phishing: add an explicit step to audit and remove unrecognised passkeys. Document that password reset + session revocation is insufficient when passkey-based persistence is possible.

### P3 — Within 7 days (strategic controls)

- Evaluate whether passkey registration should be restricted to managed/enrolled devices only, where the identity platform supports device-bound passkeys or hardware-backed attestation.
- Brief SOC and help-desk teams: a user reporting a phishing compromise must trigger a passkey audit, not just a password reset.
- Monitor underground forums (Russian-language cybercrime forums, including the Exploit forum referenced in the source) for iAuthFlow V2 updates, additional modules, or customer discussions that may reveal targeting preferences or new platform support.

## 5\. Indicators of compromise

No atomic indicators of compromise (IPs, domains, hashes, URLs) are present in the source material. The source references Abnormal's analysis as including IOCs, but none are reproduced in the provided text.

### Behavioural indicators

| Behaviour                                                                                                                             | Where to observe                                                                               | Confidence                                                                               |
| ------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
| New passkey registered on an account shortly after a credential entry event or suspected phishing click                               | IdP / identity provider audit logs (e.g., Google Workspace Admin audit, Azure AD sign-in logs) | Medium — single-sourced; derived from analysis of seller posts, not observed in the wild |
| Passkey-based authentication ("try another way") from an IP address, device, or geography inconsistent with the user's normal profile | IdP authentication logs, geo-IP correlation in SIEM                                            | Medium — single-sourced                                                                  |
| Account access persists after password reset and session revocation                                                                   | IdP sign-in logs showing successful auth events post-reset                                     | Medium — single-sourced; this is the defining behavioural signature of the technique     |

## 6\. Detection

Insufficient indicators to author detection rules. The source material does not contain distinctive strings, file names, registry keys, command-line artefacts, or network signatures attributable to the iAuthFlow V2 toolkit itself. Detection should focus on the behavioural indicators in §5 — specifically, alerting on passkey registration events and passkey-based authentication from anomalous contexts via SIEM correlation rules against IdP audit logs.

## 7\. Sources

- SecurityWeek, "New Phishing Toolkit Uses Passkeys to Maintain Access After Password Resets," https://www.securityweek.com/new-phishing-toolkit-uses-passkeys-to-maintain-access-after-password-resets/, 2026-08-21
- Abnormal Security (analysis referenced by SecurityWeek; original report URL not provided in source material)

## 8\. Adverse Trace position

**Severity: Medium.** The technique is credible and operationally significant — it defeats the most common phishing remediation playbook (password reset + session revocation) by exploiting passkeys as a persistence vector. However, the analysis is entirely single-sourced (Abnormal Security), based on seller forum posts rather than observed in-the-wild deployment, and no IOCs or independent corroboration are available. The $10,000 price point limits the immediate attacker population but signals a trend toward credential-phishing toolkits that are resilient to standard remediation. **Client impact:** EMEA financial services using Google Workspace or any IdP that supports user-managed passkeys should update incident-response procedures immediately to include passkey auditing post-compromise. **Next steps:** Adverse Trace will monitor for independent confirmation, IOC publication by Abnormal or other researchers, and any observed in-the-wild deployment. We will issue an updated advisory if corroborating evidence emerges.

---

[Read the original source →](https://www.securityweek.com/new-phishing-toolkit-uses-passkeys-to-maintain-access-after-password-resets/?ref=f4n6.co.uk)

*Published via PulseTrace — Adverse Trace threat intelligence.*