Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
14 detections
Filters
Last updated
All Time
Detection languages
11
3
Contributors
14
Categories
11
5
2
2
1
Platforms
39,169
6,860
6,378
3,772
3,516
14
Products / Services
5
2
2
2
2
MITRE Techniques
9
5
5
3
3
CVEs
7
Detects email from a new hire (within 30 days of hire date) combining personal-crisis pretext language with an explicit request to use a personal or unmanaged device, corroborated by a non-compliant or untrusted device sign-in, consistent with PurpleDelta's device-substitution social-engineering pattern.
Detects email communications from a recently-created account (within 60 days of account creation) requesting redirection of payroll or business payments to a personal bank account under a fabricated 'bank account under review' pretext, consistent with PurpleDelta payment-fraud tradecraft.
Detects an applicant identity submitting an abnormally high volume of job applications across many companies within a rolling window, corroborated by resume or portfolio content reused across multiple applicant identities — consistent with PurpleDelta fabricated-persona application tempo.
Detects a single source device or IP maintaining genuinely time-overlapping sign-in sessions under two or more distinct user identities, excluding known shared/kiosk devices and shared VPN egress points, consistent with a single PurpleDelta operator working multiple jobs simultaneously.
Detects accounts authenticating from compromised webmail/CMS infrastructure that pivot, within a tight time window and matching source IP, to authenticate against internal virtualization-management systems — the lateral-movement pattern Jewelbug used to reach a national webmail estate's backing infrastructure.
Detects sign-ins from the same user account occurring from two different countries within a short time window, where the implied travel velocity exceeds physically achievable speeds, indicating impossible travel or anomalous geolocation change consistent with a hijacked account or API key credential, with special attention to sudden access from China-based infrastructure.
Detects developer accounts whose daily count of API key creation or model provisioning operations exceeds their own 15-day historical per-user baseline plus several standard deviations, excluding service principals/apps, which may indicate compromised credentials being abused to provision or harvest AI API keys for resale (token jacking).
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 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 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 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 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.