- › Unit 42 published three ways malware already running on a Windows machine can authenticate to passkey-protected Google accounts with no user verification at all.
- › In the simplest path, the forged assertion differs from a real one by a single unset bit, and some services were not checking it.
- › Every path requires the attacker to already be executing on the device, so this is a post-compromise technique, not a break in the passkey standard.
- › Passkeys still eliminate credential phishing, which is the highest-volume identity attack you face, so the answer is not to roll them back.
- › The gap is that a passkey living in a browser profile inherits the trust level of the machine, and most rollouts quietly assumed it did not.
You have probably sat in the meeting. Someone puts up the passkey rollout plan, and somewhere around slide four a person says the thing everyone wants to hear: once this ships, credential theft stops being our problem. Nobody pushes back, because the claim is most of the way true and the room is tired.
Unit 42 spent last week showing which part of it was not.
Palo Alto’s research team published three attack paths against Chrome’s Google Password Manager cloud authenticator on Windows machines with a TPM. In each one, malware signs into a passkey-protected account with no fingerprint, no PIN, and nothing appearing on the victim’s screen. Google has quietly fixed pieces of this, and as of publication there were no CVEs assigned to any of it.
The first technique works because a forged authentication assertion and a real one differ by a single bit.
One Bit of Difference
Forging the assertion
Chrome holds a wrapped device identity key. Malware running as an ordinary user, without administrator rights, can extract that key and use ordinary Windows cryptography calls to produce a valid-looking authentication assertion. The assertion carries a User Verified flag, a single bit that is supposed to mean a human proved they were there. Malware leaves it unset, because no human was.
That is the entire difference. And some services on the receiving end were not checking the bit. eBay accepted these assertions before it started validating. The mechanism worked exactly as designed and told the truth about itself, and the party responsible for reading the answer was not reading it.
Hijacking the re-enrollment
The second path is worse in a quieter way. It forces Chrome to re-enroll the device and slips in an attacker-controlled user-verification key before the real one gets created. The service does not check whether a newly registered key came from secure hardware, so the attacker’s key becomes the legitimate one going forward.
Reading the secret out of memory
The third pulls the 32-byte Security Domain Secret, which protects synced passkey private keys, out of Chrome’s process memory during the brief window it sits there in plaintext.
Every one of these starts the same way: malware is already running on the machine.
The Jumpered Interlock
There is a safety device on most industrial presses called an interlock. The guard has to be closed before the machine will cycle. It is a genuinely good control and it has saved a lot of fingers.
It is also a switch. The press does not verify that a human being is clear of the die. It verifies that a circuit is closed. Every shop has a story about someone jumpering an interlock with a bit of wire to keep production moving, and the machine cycling happily with the guard wide open, because from the press’s point of view nothing was wrong. The signal it was built to trust was arriving on schedule.
The User Verified bit is a jumpered interlock. It does not carry proof that a person touched a sensor. It carries a claim that they did, generated by software running on a machine you have already lost.
The people who designed this were not careless. A device with malware on it is outside the threat model that passkeys were built to solve, and saying so is not a dodge. The problem is that the sales pitch traveled further than the threat model did, and a lot of rollouts got funded on the strength of the pitch.
What Passkeys Actually Bought You
Now put yourself in the shoes of someone running an intrusion campaign for money, and do the arithmetic.
Phishing scales. You buy a domain, clone a login page, send a hundred thousand emails, and harvest whatever comes back, at a marginal cost per target of roughly nothing. Against passkeys that entire business model stops working, because there is no shared secret for the victim to hand over. The credential never leaves the device and it is cryptographically bound to the real origin, so a convincing fake page collects nothing worth having.
What Unit 42 described costs enormously more. You have to land code on a specific machine first. That means an initial access broker, or a working exploit chain, or a social engineering operation that ends in execution rather than a typed password. Then you have to survive whatever endpoint detection is running long enough to do the key work.
That is not a rounding error in the adversary’s cost structure. It is the difference between a campaign that pays for itself against a random population and one that only pays against a target chosen deliberately.
So passkeys worked. They took your highest-volume identity attack and made it uneconomical. Anyone reading this research as an argument to go back to passwords has the math backwards, and we made the broader version of this case in why attackers log in instead of breaking in.
What they did not do is make endpoint compromise survivable. A passkey stored in a browser profile inherits the trust level of the machine holding it, and that was always true. Plenty of programs booked the phishing win and then went looking for endpoint budget to cut.
What to Actually Do
Validate the User Verified bit on every relying party you control
Set userVerification to required and check what came back, rather than trusting that your request settings were honored. This is a small code change and it closes the cheapest of the three paths outright.
Put privileged accounts on hardware keys, not synced passkeys
A synced passkey in a browser profile is convenient and appropriate for your general workforce. For domain admins, finance approvers, and anyone who can move money or change access, a discrete security key that never exposes its secret to the operating system removes this entire class of attack. Buy the keys. They cost less than one incident hour.
Treat re-enrollment as a privileged event
Two of the three paths run through forced re-enrollment. If your identity provider can log and alert on a device re-registering an authenticator, turn it on today, because a re-enrollment nobody requested is one of the cleanest signals in this whole chain.
Do not let the passkey rollout fund an endpoint detection cut
Every path here begins with code executing on the machine. Your endpoint detection is now the control standing between a well-resourced adversary and a credential that no longer needs a human to use. It just became more load-bearing, not less.
Ask your credential provider what you cannot rotate
Unit 42 noted that Google Password Manager offers no way to rotate or revoke an exposed Security Domain Secret separately from changing a PIN. If a secret can be stolen and cannot be rotated, your incident response plan needs an answer for that gap before you need one.
Where This Leaves You
The passkey did its job. The bit was set correctly, the assertion was well-formed, the cryptography held. What failed was an assumption sitting underneath the whole design, that the machine producing the answer was telling the truth.
Every authentication control you own rests on some version of that assumption. Go find out which of yours is a jumpered interlock.
Want a clear picture of where your organization’s people and processes are exposed? Take our free Human Attack Surface Score assessment, or contact us for a full risk assessment.
Operating on the philosophy that 'you can't build a secure system if you don't know how to break it,' Chris leads our engineering division. A top 1% National Cyber League competitor, he hardens our digital infrastructure against the very exploits he has mastered.
View Author Page →
