Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
771 detections
Filters
Last updated
All Time
Detection languages
392
128
66
49
47
Contributors
296
150
91
39
27
Categories
388
258
255
124
110
Platforms
523
344
285
121
72
Products / Services
370
328
112
51
43
MITRE Techniques
18,115
15,635
12,576
8,388
6,215
771
CVEs
2
1
IDS Classtypes
15
11
3
1
1
IDS Protocols
29
Detects M365 administrative actions related to mailbox forwarding rules or OAuth application consent that occur in the absence of a Multi-Factor Authentication (MFA) claim, particularly when preceded by non-interactive session events (LogonType 0) using REST client protocols. This pattern is indicative of potential session hijacking or token replay attacks, where an adversary leverages a compromised session to establish persistence or gain ongoing access to the environment without re-authenticating.
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 potentially malicious OAuth device code sign-ins by identifying sign-in events that exhibit anomalous characteristics, such as atypical geographic locations, rare client-application combinations, unmanaged/noncompliant device status, or elevated risk signals associated with the account. This detection helps identify account compromise or malicious OAuth consent activity often associated with 'EvilTokens' or device-code phishing attacks.
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.
Detects the creation of new Entra ID applications or service principals that use display names similar to well-known SaaS vendors but lack a verified publisher status, followed within 24 hours by a consent grant for high-privilege permissions. This pattern is characteristic of OAuth-impersonation campaigns aimed at gaining persistent access to cloud resources.
Detects OAuth application consent grant events where an application name matches common 'Data Loader' naming conventions and requests high-privilege scopes (read/write/full/api). This pattern is consistent with consent phishing campaigns used by threat actors to gain persistent access to SaaS environments like M365 or Salesforce.
Detects unauthorized access to CRM platforms (Salesforce) using Salesloft or Drift OAuth tokens, where the source IP address does not match the known legitimate service provider IP ranges. This behavior is indicative of potential token theft or misuse, particularly relevant to supply-chain campaign activities.
Detects a pattern associated with ShinyHunters/UNC6040, where a user authorizes a new or rarely-used OAuth connected application shortly after performing a help-desk initiated password reset or MFA re-enrollment, originating from a different geographic location.
Detects unauthorized abuse of the OAuth 2.0 device authorization grant flow in Salesforce environments, commonly used by threat actors like ShinyHunters (UNC6240) to gain programmatic access. Attackers register malicious connected apps to impersonate legitimate tools, then use social engineering (vishing) to trick victims into approving device codes. This rule flags token issuance from non-allowlisted connected apps using the device_code grant type.
Detects OAuth application consent requests that combine broad API access scopes with persistence-enabling scopes (e.g., offline_access or refresh_token). This pattern is consistent with OAuth consent phishing attacks, where adversaries attempt to gain non-interactive, long-term access to an organization's cloud environment via malicious connected applications.
Detects AI coding assistants and LLM agent frameworks attempting to access, read, or export sensitive credential files, registry hives, or application secrets. The rule monitors both file system operations on known secret locations and process execution patterns indicative of credential dumping or API token retrieval by these tools.
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.
Detects instances where a user grants high-privilege permissions (Mail.Read, Files.ReadWrite.All, offline_access) to an OAuth application within 24 hours of a risky sign-in event. This pattern is commonly observed in AiTM (Adversary-in-the-Middle) or consent-phishing attacks designed to establish persistent access to cloud resources.
Detects the reuse of session identifiers (SessionId, DeviceId, or RefreshTokenJti) across different device fingerprints (e.g., changes in User-Agent, OS, or Browser) within a short timeframe. This behavior is indicative of session hijacking or adversary-in-the-middle (AiTM) attacks, where stolen session tokens or cookies are replayed by an attacker from a different endpoint than the original user.
Detects anomalous activities within CI/CD runner environments, specifically targeting unauthorized processes attempting to access OIDC identity tokens or executing package publication commands (e.g., npm, twine) outside of standard runner execution workflows. This technique is consistent with supply chain compromise efforts to exfiltrate identity tokens and publish malicious artifacts.
Detects potential abuse of the Microsoft Graph API by correlating device-code authentication events with subsequent high-volume activity, such as mail or file enumeration, from the same account within a short window. This pattern is indicative of ARToken-style token proxying, where an attacker intercepts an OAuth device-code token to gain unauthorized access to an user's resources.
Detects potential persistence establishment in M365 environments following anomalous or risky sign-in events. This pattern is characteristic of Adversary-in-the-Middle (AiTM) attacks where a session cookie is stolen, followed by immediate adversary actions to secure long-term access, such as MFA method registration, OAuth app consent, or mailbox rule configuration.
Detects successful OAuth 2.0 device authorization grant sign-ins using the 'Microsoft Authentication Broker' client. This pattern is commonly used in device-code phishing (GhostCode) to trick users into authorizing a malicious application, often bypassing multi-factor authentication (MFA) requirements.
Detects anomalous OAuth 2.0 device authorization grant requests where the Microsoft Authentication Broker application ID is utilized by non-standard clients, specifically the python-requests library. This pattern is indicative of the GhostCode phishing backend infrastructure, which attempts to programmatically perform device code phishing rather than relying on interactive browser-based flows.
Detects Azure AD/Entra ID sign-ins performed using the OAuth device-code flow, excluding common administrative tools like the Azure CLI or PowerShell. This flow is frequently abused in phishing campaigns (such as EvilTokens or ARToken) where attackers entice victims to enter a device code into a malicious application, allowing the attacker to gain authorized access to the victim's session.
Page 10 of 37