Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
173 detections
Filters
Last updated
All Time
Detection languages
93
25
23
19
11
Contributors
98
20
18
9
5
Categories
20,443
11,831
5,875
5,151
4,864
Platforms
134
60
56
24
6
Products / Services
94
57
57
24
12
MITRE Techniques
103
56
55
31
30
IDS Classtypes
1
1
IDS Protocols
3
This rule identifies potential account compromise through the detection of non-interactive Azure AD sign-ins originating from geographically distant locations within a short, travel-implausible timeframe. Such activity is highly indicative of the theft and export of a Primary Refresh Token (PRT) from a legitimate endpoint, which is subsequently replayed by an adversary from external infrastructure to gain unauthorized access to cloud resources.
Detects the suspicious sequence of adding a domain or changing federation settings followed rapidly by a configuration update to the federated domain. This pattern is indicative of an adversary establishing a covert federated backdoor for persistent, delegated authentication, allowing bypass of standard credential rotation mechanisms.
Detects modifications to Microsoft Entra ID (formerly Azure AD) cross-tenant access policies or B2B synchronization settings. Specifically, this rule monitors for the addition of new external partner tenants to trust lists or the relaxation of security controls such as MFA and compliant device requirements for external partner access.
Detects the addition of a new federated domain or a modification to an existing domain's authentication settings to Federated, where the domain was not previously verified within a standard verification window. This technique is often used by adversaries to establish persistence and perform self-issued token forgery (e.g., SAML/JWT) by trusting an attacker-controlled identity provider.
Detects changes to federation settings on an Entra ID domain, including modifications to IssuerUri, ActiveLogOnUri, MetadataExchangeUri, or SigningCertificate, as well as transitions between Managed and Federated authentication types. Such changes can facilitate 'Golden SAML' attacks by allowing an adversary to forge authentication tokens for the tenant.
Detects the addition of a new federated domain or a modification to an existing domain's authentication settings to Federated, where the domain was not previously verified within a standard verification window. This technique is often used by adversaries to establish persistence and perform self-issued token forgery (e.g., SAML/JWT) by trusting an attacker-controlled identity provider.
This rule detects unscheduled modifications to federation, application, or service principal credentials, including ADFS token-signing certificates, in both Azure AD (via O365 management activity logs) and local Windows environments (via Security Event Logs). It filters these events against a known rotation schedule to highlight suspicious, non-routine changes that may indicate persistence establishment or identity provider tampering.
This rule detects the addition of a new domain or the modification of federation settings within an Office 365/Azure Active Directory environment. It specifically monitors for operations such as 'Add domain to company', 'Add unverified domain', and 'Set federation settings on domain'. The rule filters against a known list of federated domains to identify new or unexpected federation configurations, which could indicate an adversary attempting to establish persistence or facilitate privilege escalation through trust modification.
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 modifications to Microsoft Entra ID applications or service principals involving the addition or configuration of 'externalauthprovider' redirect URIs or properties. This behavior is indicative of an attacker attempting to establish a malicious federated identity or persistence mechanism by manipulating application configuration to use an adversary-controlled authentication provider.
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 a suspected account compromise sequence where an account first authenticates to a Microsoft Teams application from infrastructure associated with TeamFiltration (e.g., specific AWS ranges), followed by a rapid (within 2 minutes) authentication to a VPN or SAML service provider from a different IP address, indicative of an account pivot.
Detects the addition or modification of federated identity credentials within Microsoft Entra ID (Azure AD). Adversaries may add these credentials to service principals or applications to achieve persistent access and potentially bypass traditional password-based authentication mechanisms.
Detects tenant-level enablement of Microsoft Teams external/federated access or addition of an unfamiliar external domain shortly before a spike in inbound Teams calls to helpdesk/IT-support-tagged users — models CrowdStrike's 2026 Financial Services Threat Landscape Report on 'Mutant Spider,' the most active threat to financial services, whose primary technique is voice phishing over Microsoft Teams impersonating internal IT.
Detects the creation, update, or activation of an external Identity Provider (IdP) or federated trust configuration within the Okta environment. This activity may indicate an attempt to establish a rogue federation trust, which allows an adversary to perform cross-tenant impersonation and authenticate as any user by minting assertions signed by attacker-controlled keys.
Detects changes to Entra ID (Azure AD) federation settings, specifically targeting updates to trust and authentication parameters such as IssuerUri, ActiveLogOnUri, and TokenSigningCertificate. These modifications are critical indicators of potential Golden SAML attacks, where adversaries forge SAML tokens to bypass MFA and impersonate users.
Detects modifications to Entra ID (Azure AD) cross-tenant access settings, including inbound/outbound trust settings and B2B collaboration configurations. This activity may indicate an adversary attempting to establish persistence or facilitate unauthorized access by creating a trust relationship with an external tenant they control.
Detects modifications to Entra ID (Azure AD) cross-tenant access settings, including inbound/outbound trust settings and B2B collaboration configurations. This activity may indicate an adversary attempting to establish persistence or facilitate unauthorized access by creating a trust relationship with an external tenant they control.
Detects unauthorized changes to the token-signing certificate for federated domains in Microsoft Entra ID (formerly Azure AD). This behavior is often associated with the Golden SAML attack technique, where an adversary modifies federation settings to forge authentication tokens. The rule filters for events occurring outside of standard business hours and alerts when the modification is not performed by known automation service accounts.
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 chained AWS STS AssumeRole/AssumeRoleWithSAML/AssumeRoleWithWebIdentity events where a principal assumes a role in a different account and then quickly performs another role assumption from that new context. This pattern, often referred to as 'role chaining' or 'role laundering', is frequently used to obfuscate identity tracking and facilitate lateral movement across AWS account boundaries.
Page 2 of 9