Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
461 detections
Filters
Last updated
All Time
Detection languages
276
67
44
26
23
Contributors
167
111
62
17
9
Categories
238
219
140
83
78
Platforms
338
217
143
29
23
Products / Services
286
157
50
38
27
MITRE Techniques
18,123
15,639
12,581
8,394
6,215
CVEs
13
5
3
2
1
IDS Classtypes
5
3
2
IDS Protocols
9
Detects instances where an IAM user or role attempts to assume a role in a different AWS account (Cross-Account) without providing a valid ExternalID. This often indicates unauthorized attempts to access or abuse cross-account trust relationships, which is a common technique for lateral movement or privilege escalation in cloud environments.
Detects successful sign-in events in Entra ID where MFA is marked as satisfied, but no interactive MFA challenge (e.g., Push, FIDO2, SMS) was recorded as completed in the authentication details. This behavior, when correlated with a new IP, device, or user-agent relative to a 30-day baseline, is highly indicative of session token replay or AitM (Adversary-in-the-Middle) attacks attempting to bypass MFA requirements.
This rule detects potential account compromise by identifying 'impossible travel' scenarios where successful logins for the same user occur from different geolocations within a short timeframe (less than 1 hour), specifically when at least one authentication event uses a refresh or session token rather than interactive MFA. It correlates these suspicious logins with previous endpoint infostealer detections on the same device within the last 72 hours, indicating that the token may have been stolen by malware.
Detects anomalous OAuth 2.0 device authorization grant sign-in activity within Microsoft 365. The rule identifies suspicious token redemption behavior where the initial device code request and the subsequent token redemption occur from disparate IP addresses or utilize different user-agent strings, which is indicative of EvilTokens or similar adversary-in-the-middle (AiTM) device-code phishing frameworks.
Detects sign-in events to high-privileged cloud management consoles (e.g., Azure Portal, Microsoft Entra, Intune, Okta, AWS, GCP) originating from sessions with elevated risk or anomalous characteristics. The detection monitors for factors such as the use of anonymized IP addresses, unmanaged devices, sessions marked as 'atRisk' by identity providers, or non-interactive service-based access to management APIs that deviate from standard administrative workflow patterns.
Detects the use of sts:AssumeRole or sts:GetFederationToken to request temporary security credentials in a different AWS account than the one initiating the request. This can indicate cross-account privilege escalation or lateral movement using identity federation or assumed roles.
Detects the use of sts:AssumeRole or sts:GetFederationToken to request temporary security credentials in a different AWS account than the one initiating the request. This can indicate cross-account privilege escalation or lateral movement using identity federation or assumed roles.
Detects successful authentication attempts using legacy protocols or non-interactive refresh tokens for user accounts previously flagged within a 14-day window as being involved in infostealer or credential exposure events.
Detects potential Adversary-in-the-Middle (AiTM) phishing activity where a user successfully authenticates to Microsoft 365 with MFA, followed shortly by a session from a different IP address reusing the same session ID without a repeated MFA challenge.
Detects repeated, silent authentication events in Microsoft 365 where MFA challenges are absent, consistent with the use of stolen session or refresh tokens (e.g., EvilTokens) to maintain persistent, unauthorized access to user accounts.
Detects the granting of OAuth application permissions or app role assignments in Azure AD/Entra ID that include high-privilege scopes such as Mail.Read, Directory.ReadWrite.All, or offline_access. This behavior is characteristic of consent phishing attacks, where adversaries trick users into granting permissions to a malicious application to maintain persistent access to resources like email or tenant directories.
Detects successful authentication events by a service principal (e.g., an AI agent or automated application) that have been flagged by Azure AD Identity Protection as having anomalous risk characteristics, such as unfamiliar locations, unexpected travel patterns, or unfamiliar sign-in features.
This rule monitors for suspicious activity related to AI service accounts and API keys. It detects potential account or key compromise by identifying impossible travel sign-ins coupled with AI API usage, simultaneous usage of a single API key from multiple disjoint network locations, and sudden, high-volume activity from previously dormant service account API keys.
Detects instances where a user account consents to an OAuth application requesting high-privilege or sensitive scopes such as Mail.Read, Files.ReadWrite.All, or offline_access. This behavior is a common indicator of consent phishing attacks, where adversaries trick users into granting persistent access to their cloud resources via malicious OAuth applications.
Detects the granting of high-privilege permissions (e.g., mail.read, files.readwrite) to a newly registered OAuth application (less than 24 hours old), followed by high-volume API activity from that same application within one hour. This behavior is indicative of an illicit OAuth consent grant attack, where an adversary lures a user into granting permissions to a malicious application to maintain persistent access to cloud resources or perform data exfiltration.
Detects a suspected EvilTokens attack sequence where a user clicks a phishing URL and subsequently initiates a browser session to the Microsoft device-code authorization page (devicelogin) within 15 minutes, with the phishing lure domain appearing in the browser context.
Detects potential abuse of stolen OAuth session tokens, where refresh tokens are used to authenticate after a user has performed a password reset. This rule identifies accounts that continue to sign in from previously unseen devices or IP addresses within 24 hours post-password reset, a technique consistent with session persistence mechanisms used by adversary tools and platforms like EvilTokens.
Detects OAuth application consent events in Entra ID where the application display name mimics legitimate services like Salesforce or Data Loader while requesting high-risk API scopes (full_access, offline_access, api). This behavior is characteristic of phishing-driven OAuth grant campaigns, such as those observed by the ShinyHunters group.
Monitors SaaS application integration service accounts (e.g., Salesforce connected apps) by establishing baselines for API call volume and accessed object types. The rule alerts on anomalous spikes in usage or deviations in the scope of accessed data objects, which could indicate the abuse of compromised OAuth tokens following a vendor supply-chain compromise.
Detects anomalous service principal activity characterized by multiple, rapidly issued, and overlapping OAuth tokens within a short time window. This pattern is associated with automated/agentic token orchestration (e.g., JADEPUFFER/Storm-3168 campaign) rather than standard manual operator activity, specifically when leveraging the python-requests user agent.
Detects Microsoft Entra ID sign-in events where a user authenticates from a known residential proxy ASN, matching the user's historical geography but using a new, unrecognized device fingerprint. This behavior is indicative of session token replay attacks, where an adversary uses stolen session cookies to bypass standard authentication.
Page 4 of 22