Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
41 detections
Filters
Last updated
All Time
Detection languages
26
8
6
1
Contributors
41
Categories
20
10
6
4
4
Platforms
40,151
7,368
6,547
3,915
3,691
41
Products / Services
9
7
7
4
4
MITRE Techniques
13
8
7
5
5
CVEs
9
IDS Classtypes
3
2
1
IDS Protocols
3
1
Detects cross-region GraphApiAuditEvents calls for the same AccountObjectId/ApplicationId occurring faster than plausible travel time, indicating a replayed/stolen session token.
Detects Outlook sign-ins that reuse the same SessionId roughly every 8 hours while source IP/ASN change, consistent with attackers replaying a stolen AiTM-captured session token through rotating residential proxy infrastructure.
Detects SilentDataCollector uploading AES-CBC encrypted, specifically-named archives (desktop_files, pass_V, wallet_V, filelist.zip.encrypted, documents<n>.zip) to the compromised WordPress C2.
Detects StopAndProtect campaign base64-encoded payload files staged in WordPress upload directories, requiring multiple named .b64 filenames or a base64 blob in a wp-content/uploads path context
Detects centralized automation collecting mail across 3+ tenants within a short synchronized window, consistent with coordinated mailbox collection infrastructure.
Detects AiTM reverse-proxy pages injecting the ServerData=$Config script alongside a redirUrl/api.country.is capture script and a rewritten login.microsoftonline.com authorize path hosted on a non-Microsoft domain, used to steal OAuth2 session tokens and bypass MFA.
Detects sustained spikes in AI/LLM API spend or token consumption for a given API key relative to its own dynamic rolling baseline, which may indicate a stolen/hijacked API key being resold or abused via gray-market proxy services (token jacking).
Detects users or applications whose AI API token consumption or spend is sustained above a dynamic baseline across multiple consecutive time buckets rather than a single burst, which may indicate token jacking, credential theft, or abuse of stolen AI API keys via gray-market proxy services.
Detects non-interactive token refreshes occurring at anomalously consistent short intervals or from previously unseen IPs/devices, consistent with AiTM stolen session token replay used to maintain persistent access.
Detects cloud app account activity indicating that usage alerting or audit logging has been disabled, which could allow attackers to hide token jacking or unauthorized AI resource consumption.
Detects operations that remove, disable, delete, or update billing limits, spending limits, usage alerts, spend notifications, billing thresholds, or cost alerts on AI service accounts, which may indicate an attacker attempting to remove financial guardrails to enable unrestricted abuse of stolen AI API credentials.
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 successful passkey/WebAuthn authentication or signing events where the User Verification (UV) flag is unset/false or no UV assertion accompanies a device-key signature, scoped to relying parties/credentials where UV is policy-required, or corroborated by a missing biometric/user-presence event or a static (unchanged) signature counter. This reduces noise from relying parties or lower-risk contexts that legitimately do not require UV on every assertion.
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 successful passkey/WebAuthn authentication or signing events where the User Verification (UV) flag is unset/false or no UV assertion accompanies a device-key signature, scoped to relying parties/credentials where UV is policy-required, or corroborated by a missing biometric/user-presence event or a static (unchanged) signature counter. This reduces noise from relying parties or lower-risk contexts that legitimately do not require UV on every assertion.
Page 2 of 2