The passkey the attacker added to your account
Someone in your business has their account compromised. You do the right things, quickly: change the password, sign out every active session, check the mailbox rules. A day later the attacker is still reading their email, and nothing you can see explains how.
This is the gap a phishing kit currently on sale is built to exploit, and it is worth understanding because the fix is one line on a checklist rather than a change of strategy.
What the kit does
A toolkit called iAuthFlow v2 is advertised on Russian-language crime forums at around $10,000 for the base package. Abnormal Security examined the seller's documentation and demonstration videos.
It solves a problem attackers have. Steal a password and you get in, but you get locked out again the moment anyone notices. So the kit does something else once it is inside: it registers a new passkey, belonging to the attacker, on the victim's account.
A passkey is the sign-in that replaces a password with your device: a fingerprint, a face, or a phone prompt. It is bound to the genuine website, which is exactly why it resists phishing and why it has become the recommended default. But an account can hold several passkeys, on a laptop, a phone, and a security key. Adding another is a normal thing to do, and it is that normality the kit abuses.
The victim never sees it happen. They log in through a convincing fake page while the attacker's server relays each step to the real service, so every prompt looks right because it is real. After authentication completes, instead of forwarding the victim to their inbox, the kit shows a brief "Verification, Processing" screen. Behind that pause it opens the account's passkey settings and enrols its own. In the recorded demonstration the passkey was created six seconds after login.
Now change the password. The attacker's passkey still works.
The demonstrations focused on Google, with packages advertised for iCloud, LinkedIn, and Microsoft.
What is not proven
The researchers did not buy or run the kit. They watched the seller's own videos. So the claims are the seller's, and criminal sellers exaggerate.
One technical detail remains genuinely unclear: where the attacker's private key is held. Abnormal's hypothesis is a virtual authenticator in a Chromium browser, which would let registration complete without anything touching the victim's device, but they could not confirm it.
Treat the capability as plausible and unverified. It does not change what you should do, because looking for unexpected passkeys is worth doing regardless of whether this particular kit works as advertised.
This is not a reason to avoid passkeys
We have argued repeatedly, including when the NCSC made passkeys its default recommendation, that passkeys are the strongest sign-in available to a small business. That has not changed, and this story is not a counter-example.
Read what actually happened. The attacker did not defeat a passkey. They phished a login, got a session, and then used that session to enrol a credential of their own. The same session would have let them add a phone number for password resets, register a new authenticator app, or create an app password. Persistence after compromise is an old problem, and passkeys are simply the newest thing an attacker can leave behind.
If the account had been protected by a passkey rather than a password, the phishing page at the start would have had nothing usable to steal.
So the lesson is not "passkeys are unsafe". It is that recovery from a compromise has to cover every way back in, and most incident checklists were written before passkeys were one of them.
What to do
Add one line to your incident response. After any account compromise, review the account's registered sign-in methods and remove anything you cannot account for. Passkeys, authenticator apps, phone numbers, recovery email addresses, app passwords. Changing the password and revoking sessions is necessary and no longer sufficient.
Know where that screen is before you need it. In Microsoft 365 it is under security info for the user. In Google Workspace it is under the account's security settings. Find it now, while nothing is on fire, and make sure whoever would handle an incident knows the path.
Treat a new sign-in method as an event worth noticing. Both Microsoft 365 and Google Workspace can alert on a newly registered credential. It is a low-noise signal, because it happens rarely and legitimately, so it is one of the few alerts a small team can actually keep switched on.
Keep rolling out passkeys anyway. The attack here started with a phished login. That is still the front door, and passkeys are still the best lock for it.
How Steelwise can help
Reviewing what would actually happen at your business after an account compromise, and whether your response would close every way back in, is a short and well-defined piece of work. Get in touch.
Further reading
- NCSC: multi-factor authentication for online services
- FIDO Alliance: how passkeys work
- ICO: personal data breaches