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 a suspicious pattern where a user authenticates via device code and, within a short timeframe (two hours), registers a new device to their account. This behavior is indicative of the 'ARToken' persistence pattern, where an adversary uses a stolen session to bind a rogue device to the victim's account, potentially to mint a Primary Refresh Token (PRT) for persistent access.
This rule detects scenarios where a user completes a device-code authentication flow, followed immediately (within 10 minutes) by the registration of an unmanaged, non-compliant device to their account. This behavior is indicative of potential token theft (e.g., EvilTokens) where an adversary uses a stolen token to register their own device as a persistent, unmanaged entity, bypassing standard corporate device enrollment controls.
Detects the reuse of a session or refresh token within a short timeframe (<= 900 seconds) where the source IP location, device identifier, or User-Agent string has materially changed. This behavior is indicative of Adversary-in-the-Middle (AiTM) attacks, where a session cookie has been stolen and replayed from an attacker's infrastructure to hijack a legitimate user's session.
Detects sign-in events within Microsoft Entra ID (formerly Azure AD) that utilize the 'deviceCode' authentication protocol. This OAuth 2.0 flow is designed for devices with limited input (e.g., smart TVs, IoT devices, CLI tools) but is frequently abused by attackers in 'device code phishing' campaigns to obtain access tokens by tricking users into entering a code on a malicious site.
Detects instances where a user authenticates via the OAuth 2.0 device code flow followed shortly by a new device registration. The rule flags registrations where the device name shape is uncommon compared to historical data or where there is a mismatch between the IP address used for the authentication and the registration, indicating potential device code phishing or account takeover.
Detects instances where a user account registers a new Multi-Factor Authentication (MFA) method (such as TOTP or Authenticator app) shortly (within 30 minutes) after a high-risk or potentially anomalous sign-in event. This pattern is commonly associated with adversary-in-the-middle (AiTM) phishing attacks where an attacker captures an authenticated session and uses it to enroll a secondary, attacker-controlled MFA device for persistent account access.
Detects anomalous activity where a successful device-code authentication is immediately followed by rapid multi-device registration or Intune enrollment. This pattern is consistent with GhostCode-style attacks involving Primary Refresh Token (PRT) theft and rogue device registration to bypass conditional access policies.
Correlates a successful OAuth device-code sign-in with a subsequent Device Registration Service event for the same user within 30 minutes, excluding known legitimate device-code applications (Azure CLI, Azure PowerShell, Visual Studio, VS Code) and requiring both events to have succeeded. The registration match is scoped strictly to the Device Registration Service resource (not the broader Microsoft Authentication Broker app, which fires on routine token refresh/broker activity unrelated to registering a new device). The correlation is further restricted to cases where the device-registration event originates from a different IP address or city than the original device-code sign-in -- the pattern expected when an attacker uses a stolen token to register their own device and mint a Primary Refresh Token, versus a legitimate user completing device enrollment from their own network shortly after a CLI/developer login.
Detects the addition or update of federated identity credentials (FIC) on Entra ID applications or service principals that do not match an approved list of OIDC issuers. This technique, known as Workload Identity Federation, can be abused by adversaries for stealthy, token-less, secret-free persistence.
Detects the creation of a new application secret or credential in a cloud environment followed by an immediate authentication attempt using that credential from an IP address that has not been observed performing successful authentication within the specified lookback window. This behavior is indicative of potential unauthorized persistence or the use of compromised credentials by an adversary.
Detects modifications to AWS IAM trust relationships, specifically the creation or update of SAML providers, OIDC providers, or the update of role trust policies containing wildcard principals. These actions are indicative of an attacker attempting to establish a durable, credential-less persistence mechanism via federated identity manipulation.
Detects anomalous GCP IAM Service Account Credential API calls where a principal impersonates multiple distinct service accounts within a short time window. This behavior often indicates a credential delegation chain or a multi-stage privilege escalation attempt within a GCP environment.
Detects the creation or modification of federated identity credentials within Azure Active Directory (Entra ID). This technique allows external services like GitHub Actions, Kubernetes, or other identity providers to authenticate as an application without stored secrets, bypassing traditional secret-rotation and credential-scanning security controls. The rule identifies potential unauthorized persistence by highlighting external or unrecognized issuers.
This rule detects non-interactive sign-in events using AzureAD tokens from unmanaged devices. This pattern is indicative of potential session or refresh token hijacking, where an adversary replays a stolen session token from their own environment. While a single event is not definitive for impossible travel, it serves as a high-confidence seed for identifying compromised sessions when combined with other indicators.
This rule monitors Azure AD and Office 365 non-interactive sign-in logs to identify anomalous spikes in activity from previously unseen applications or devices. It uses a 30-day baseline to determine if a sign-in pair (User/App/Device) is known. It further flags sign-ins from unrecognized locations (ASN/Country), flagging them with higher severity. This behavior is often indicative of automated credential abuse or token exploitation.
Detects instances where a user grants an OAuth application consent to high-risk scopes (such as mail reading, file access, or directory reading) without administrator oversight. This behavior is a common indicator of OAuth abuse where an attacker lures a user into granting excessive permissions to a malicious application, providing the attacker persistent access to the user's data.
This rule detects the reuse of the same user's refresh token from two different countries within a 15-minute window. This behavior is a strong indicator of token theft or session hijacking, commonly associated with AiTM phishing, infostealer malware, or session cookie extraction, where an adversary uses stolen credentials from a remote location.
Detects a potential Primary Refresh Token (PRT) or device code phishing attack by identifying a two-step authentication sequence: first, a successful user sign-in via device code flow, followed shortly by a subsequent sign-in from a different, unmanaged, or untrusted device. This behavioral pattern often indicates an adversary using stolen device code session data to authenticate a new device session.
Detects the addition of a federated identity credential to an Azure AD / Entra ID application. Adversaries may use this technique to establish persistent, secretless access to an application's service principal by configuring trust with an external OIDC issuer under their control (e.g., a malicious GitHub repository or personal OIDC provider).
Detects the addition of a federated identity credential to an Azure AD / Entra ID application. Adversaries may use this technique to establish persistent, secretless access to an application's service principal by configuring trust with an external OIDC issuer under their control (e.g., a malicious GitHub repository or personal OIDC provider).
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.
Page 3 of 22