Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
8 detections
Filters
Last updated
All Time
Detection languages
4
3
1
Contributors
8
Categories
7
5
3
2
1
Platforms
7
5
3
Products / Services
10,808
9,795
6,757
4,421
3,770
MITRE Techniques
5
5
5
2
2
CVEs
8
IDS Classtypes
1
IDS Protocols
1
Detects abuse of Google Cloud Authenticator device-management API calls associated with the Pass-ta-key attack, where an attacker-controlled key is introduced or a device is de-registered without a legitimate biometric/attestation ceremony. Covers device/register with keys/genpair, device/add_uv_key, and device/forget commands observed in cloud authenticator device-management event logs. To reduce false positives, device/add_uv_key and device/forget calls only alert when they lack an associated preceding hardware attestation or biometric ceremony event, and legitimate user-initiated new-device enrollment (following a known legitimate sign-in with a prior MFA/biometric ceremony on the requesting device) and legitimate account-recovery flows are excluded.
Detects new-device passkey bootstrap via PRF exchange and encrypted passkey download correlated with an anomalous signal (no prior authentication history on the device, new geolocation/ASN, or missing user-presence confirmation on the trusted device), consistent with an attacker abusing the one-time cross-device sync bootstrap flow to sync a victim's passkeys to an attacker-controlled device.
Detects the Silver Pass-ta-key attack chain where a device or UV key registration event (device/register, keys/genpair, device/add_uv_key) on the cloud authenticator is followed within a short window by a successful login to a high-value account from a device with no prior authentication history. To reduce false positives from legitimate device enrollment-then-use, the rule additionally requires either that the registration lacked an expected attestation/biometric ceremony, or that the subsequent login originated from a geolocation/ASN inconsistent with the user's normal authentication pattern, consistent with fully automated authentication using an attacker-registered UV key without human interaction.
Detects OAuth2 token requests scoped to Google's secureidentity.action, used for passkey/security-domain-secret operations. Chrome's own sync/passkey process routinely requests this scope from the browser, so those requests (identified by a Chrome User-Agent) are excluded. Remaining matches indicate the token request did not originate from the legitimate Chrome browser process (e.g. a non-browser client, script, or tool crafting the request directly), which is anomalous and warrants investigation for possible passkey/security-domain-secret abuse or token reuse across devices.
Detects new-device passkey bootstrap via PRF exchange and encrypted passkey download correlated with an anomalous signal (no prior authentication history on the device, new geolocation/ASN, or missing user-presence confirmation on the trusted device), consistent with an attacker abusing the one-time cross-device sync bootstrap flow to sync a victim's passkeys to an attacker-controlled device.
Detects the Silver Pass-ta-key attack chain where a device or UV key registration event (device/register, keys/genpair, device/add_uv_key) on the cloud authenticator is followed within a short window by a successful login to a high-value account from a device with no prior authentication history. To reduce false positives from legitimate device enrollment-then-use, the rule additionally requires either that the registration lacked an expected attestation/biometric ceremony, or that the subsequent login originated from a geolocation/ASN inconsistent with the user's normal authentication pattern, consistent with fully automated authentication using an attacker-registered UV key without human interaction.
Detects OAuth2 token requests scoped to Google's secureidentity.action, used for passkey/security-domain-secret operations. Chrome's own sync/passkey process routinely requests this scope from the browser, so those requests (identified by a Chrome User-Agent) are excluded. Remaining matches indicate the token request did not originate from the legitimate Chrome browser process (e.g. a non-browser client, script, or tool crafting the request directly), which is anomalous and warrants investigation for possible passkey/security-domain-secret abuse or token reuse across devices.
Detects a network connection to Google's passkey enclave or caBLE hybrid-transport domain (*.ua5v.com) that should be correlated with EDR process telemetry to confirm the source process is non-browser, unsigned, or otherwise anomalous rather than the legitimate Chrome browser.