#PacketHunters – The passkey holds, or who controls the instructions?

Executive summary: passkey enrollment phishing uses a security setup request as a pretext to obtain access or approval for registering an attacker-controlled credential. The defensive task is to protect registration, constrain alternative authentication routes and make support requests independently verifiable. Strong passkey authentication does not, by itself, establish that a new credential was authorized.

I like passkeys, really! I get considerably less enthusiastic when somebody adds “so phishing is solved” to the end of the sentence.

A solid security control deserves an accurate explanation, otherwise, we send people into a new procedure carrying a rather dangerous assumption: anything involving this new security feature must be safe.
Then somebody phones to help them set it up, ay carramba!

In its July 2026 analysis, Okta described a phishing kit deployed since April against Microsoft 365 users: a caller directs the target through pages imitating Microsoft authentication and passkey enrollment. An operator controls which screens appear, adapting them to password and MFA challenges, including one-time codes and number matching.

Okta reconstructed the flow from kit code. Its assessment is that the fake enrollment screens keep the user occupied while an attacker, having gained access through the earlier steps, registers a passkey they control on the real account.

Okta explicitly states that it did not directly observe Microsoft account compromises. The analysed kit also did not handle federation to third-party identity providers such as Okta; calling this a confirmed Microsoft account breach would overstate the report.
So, right now the technical distinction matters because authentication and enrollment answer different questions.

During authentication, a passkey proves possession of a private key associated with an account. WebAuthn scopes that credential to a relying party, with browser and server checks tying its use to permitted origins.
A copied Microsoft logo on an unrelated domain cannot make the browser use Microsoft’s credential there (that’s clear, right?) and the private key is not handed to the website. That protection is real – at least real as not in the Matrix.

Enrollment is where the service accepts a new credential for the account. Before doing that, it needs sufficient evidence that the person adding it is entitled to do so. A cryptographically valid key can still belong to somebody who should never have been allowed to register it.

That is why I want to inspect the permission to add the next key.
Which authentication method can establish it?
What happens during first-time setup, or when somebody claims to have lost every existing authenticator?

Having a passkey available also leaves a separate policy question: if the account still accepts a password and a phishable second factor, that route remains relevant. FIDO’s deployment guidance treats login and recovery together for precisely this reason.

My reading of the case goes a little beyond the registration screen, as a new security procedure also creates a new credible story.

Think about a rollout from the employee’s side: something is changing.
There will be unfamiliar screens + IT may send instructions + colleagues will ask whether everyone has finished. In that setting, “I haven’t seen this before” loses some of its usefulness as a warning: unfamiliarity is part of the legitimate change.
An impersonator offering to help can fit neatly into that expectation.
The employee may be trying to do exactly what the organization asked: complete the security upgrade and get back to work.

I find it hard to blame someone for trusting a procedure we have announced without explaining how to verify the person delivering it. “Follow IT’s instructions” leaves quite a lot riding on those two letters.

Before a rollout, I want employees to know where its authoritative instructions live and how to reach support independently. An unexpected caller should be easy to check without using a number, link or transfer supplied by that same caller. Whoever owns the rollout also needs to tell the helpdesk that people are allowed to stop and verify – a policy becomes difficult to follow when the queue rewards speed and treats questions as an inconvenience.

Then, 4 things 4 into the work queue:

• inspect registration policy – in Entra, review Conditional Access targeting the Register security information user action. Where users already have a trusted passkey, require phishing-resistant authentication to add another. Protect first-time setup and recovery separately, with explicit identity checks and controlled exceptions. Test the policy on your actual enrollment paths before enforcement

• test the support verification route – have someone find the rollout instructions and contact the real helpdesk without assistance from the person making the request. If that takes a treasure hunt through the intranet, fix it before the announcement goes out.

• make credential additions reviewable – decide who investigates an unexpected new authentication method, what registration context they can see, and how an employee reports one. I would test that handoff with a controlled event (an alert nobody owns is another unread message)

• rehearse the interruption – use an authorised exercise in which supposed support offers help with an expected security change. Observe whether the employee pauses and reaches a known channel, and whether that channel actually helps. Debrief the point where the request became credible – that is useful material for improving both the procedure and the training

The code angle

I’ would ‘dstart with the registration event. A dashboard saying that someone has a passkey does not tell me who added the next credential.

These read-only KQL queries run in Log Analytics or Sentinel Logs when Microsoft Entra audit events are collected in the AuditLogs table. The activity names and fields are documented by Microsoft. 5 6

First, check what your logs contain

Run this inventory first.
It surfaces the activity labels and results present in the last 14 days, including setup steps and unsuccessful attempts.

// registration_event_inventory.kql
// PacketHunters / Baited.io
// Discover registration-related activity labels and results.
// Requires: Entra AuditLogs in Log Analytics or Sentinel Logs.
AuditLogs
| where TimeGenerated >= ago(14d)
| where OperationName contains "security info"
or OperationName contains "passkey"
or OperationName contains "FIDO"
or ActivityDisplayName contains "security info"
or ActivityDisplayName contains "passkey"
or ActivityDisplayName contains "FIDO"
| summarize Events = count(), LastSeen = max(ActivityDateTime)
by OperationName, ActivityDisplayName, Result, LoggedByService
| order by Events desc

Then use this query to list successful security-info registrations across authentication methods.
Inspect each event to establish which method was added.

// registration_review.kql
// PacketHunters / Baited.io
// List successful security-info registrations across methods.
// Success records the operation; authorisation needs checking.
AuditLogs
| where TimeGenerated >= ago(14d)
| where OperationName in~ (
"User registered security info",
"Admin registered security info")
| where Result =~ "success"
| project ActivityDateTime, OperationName,
InitiatedBy, TargetResources, AdditionalDetails,
CorrelationId, AuditEventId = Id, EntraTenantId = AADTenantId
| order by ActivityDateTime desc

The full TargetResources array stays in the result, so the query does not assume its first entry is the affected user. The recorded initiator can be a user or an application; it does not establish which human approved the change.

Inspect the target account and method in TargetResources and AdditionalDetails. Compare the time and initiator with the approved request and surrounding sign-ins, then verify authorisation through a known channel. A nearby sign-in does not prove a shared session.

Check coverage with a controlled registration. “Get passkey creation options” is a setup step, not completed enrollment. Empty results can reflect missing ingestion, retention limits or a different event path. I would use these rows to choose what needs checking; they are not a list of confirmed attacks.

🤓 FAQ

• Is having a passkey enough?
  No. Its phishing resistance is valuable, but enrollment, alternative sign-in methods and recovery still need appropriate controls. Practicing verification supports those controls; it cannot compensate for a registration policy that permits the wrong person to add a credential.

• Does enrollment abuse mean passkey cryptography was broken?
• An unauthorized credential registration does not by itself demonstrate a cryptographic flaw in WebAuthn. The account service must establish who is entitled to add that credential.

• How should an employee verify an enrollment request?
  Pause the unexpected conversation. Open the known support portal or use a helpdesk number obtained independently. Confirm the request and the approved procedure before continuing.

• Does the KQL query identify malicious passkeys?
  No. It lists successful security-info registrations for review across authentication methods. Inspect the method details and establish authorisation separately; a successful event is not a verdict about intent.

🤔 TL;DR

Passkeys resist phishing at authentication. Accepting another credential is a separate decision: the service must establish who is entitled to add it.

The Okta report describes a kit and its intended flow. Activity dates to April 2026; Okta explicitly says it did not directly observe Microsoft account compromises.

A rollout gives fake support a believable opening. Tell people who announces the change, where the approved procedure lives and how to verify a request through a known channel.

Protect registration, fallback and recovery. Review Entra policy, make credential additions reviewable and practise stopping an unexpected support request.

The KQL produces review leads. A successful registration event does not prove consent or compromise. Check the method, account and authorisation behind it.

I would keep the passkeys and be much more demanding about the instructions around them. Before signing off the rollout, I want somebody to answer one question with evidence.

🤖 AI Citations

Primary sources and technical references behind the analysis and the audit queries.

1. Vishing actors target Entra passkey enrollment — Okta — July 2026 kit analysis, activity since April, and the explicit limit on directly observed compromises.

2. Web Authentication: An API for accessing Public Key Credentials — W3C — Relying-party scope, origin verification and the distinction between registration and authentication.

3. Passkeys: The Journey to Prevent Phishing Attacks — FIDO Alliance — Deployment guidance covering phishing resistance, alternative sign-in routes and account recovery.

4. Protect security info registration with Conditional Access policy — Microsoft — The Register security information user action, authentication strength and testing policies before enforcement.

5. Microsoft Entra audit log categories and activities — Microsoft — Documented registration activity names and the need to distinguish setup activity from completed registration.

6. Azure Monitor Logs reference: AuditLogs — Microsoft — The fields retained by the KQL queries, including initiator, target resources, result and correlation identifiers.