Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,088 detections
Filters
Last updated
All Time
Detection languages
619
191
113
86
47
Contributors
302
211
112
88
54
Categories
481
416
353
192
164
Platforms
726
348
216
136
57
Products / Services
518
292
197
124
88
MITRE Techniques
18,123
15,639
12,581
8,394
6,215
1,088
CVEs
5
5
5
5
4
IDS Classtypes
3
2
1
1
IDS Protocols
3
This rule detects the launch of an AWS EC2 instance that is configured with an IAM instance profile containing administrative keywords (e.g., AdministratorAccess, FullAccess) or a wildcard (*). Attackers can abuse this configuration after gaining initial access to the console or API to attach an over-privileged profile to a new instance, then pivot to the instance metadata service (IMDS) to extract these administrative credentials for persistent, broadly-scoped access.
Detects the creation of an AWS IAM access key followed immediately by the use of that key from a new or anomalous geolocation, which is a strong indicator of credential theft or unauthorized key generation for persistence.
Detects successful AWS STS AssumeRole, AssumeRoleWithSAML, or AssumeRoleWithWebIdentity calls originating from an AWS account ID not included in the 'trusted_aws_accounts' lookup. The rule further enriches events with geolocation and ASN data to flag potential cross-account activity from high-risk or unexpected regions.
Detects the attachment or creation of IAM policies that grant administrative access (via 'AdministratorAccess' policy name) or full wildcard permissions ('Action': '*', 'Resource': '*') to users, roles, or groups. This activity is a common indicator of privilege escalation following a cloud identity compromise, frequently observed in campaigns by threat actors such as Scattered Spider (UNC3944).
Detects instances where a long-dormant Entra ID (Azure AD) service principal is reactivated shortly after having a new credential added or a new app role assigned. This activity is a potential persistence technique where an attacker repurposes a legitimate, high-privileged, but unused service principal to blend in as legacy automation.
Detects the addition of secrets or certificates to service principals by identities that are not currently registered as owners of those applications, or modifications occurring outside of standard business hours. This behavior is often indicative of an adversary with compromised administrative privileges (e.g., Application Administrator) attempting to establish persistent, lateral access without alerting legitimate application owners.
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.
Detects anomalous sign-in activity for Azure Service Principals by comparing the current source IP/ASN and country against a 30-day historical baseline. This alert identifies potentially compromised service principals, where attackers exfiltrate secrets or certificates and attempt to authenticate from their own infrastructure.
This rule detects modifications to multi-factor authentication (MFA) settings performed by privileged users (e.g., Global Admins) from IP addresses not previously associated with their account. The rule tracks actions such as registering new security information, changing default MFA methods, or deleting authentication methods. High-risk indicators like an unknown IP address for a privileged account are flagged for further investigation.
This rule detects modifications to multi-factor authentication (MFA) settings performed by privileged users (e.g., Global Admins) from IP addresses not previously associated with their account. The rule tracks actions such as registering new security information, changing default MFA methods, or deleting authentication methods. High-risk indicators like an unknown IP address for a privileged account are flagged for further investigation.
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 the reactivation of a Microsoft Entra ID (Azure AD) service principal that has been inactive for 90 or more days, specifically flagging those that perform privileged Graph API operations after their return. This rule helps identify potentially compromised or stale service principals being leveraged by adversaries for persistent access.
Detects the reactivation of a Microsoft Entra ID (Azure AD) service principal that has been inactive for 90 or more days, specifically flagging those that perform privileged Graph API operations after their return. This rule helps identify potentially compromised or stale service principals being leveraged by adversaries for persistent access.
Detects the assignment of highly privileged Azure AD/Entra ID directory roles (e.g., Global Administrator, Application Administrator) to a service principal. Assigning such roles to service principals is a common persistence technique, as these identities can be used to bypass conditional access policies and MFA through non-interactive authentication methods like client credentials.
Detects the assignment of highly privileged Azure AD/Entra ID directory roles (e.g., Global Administrator, Application Administrator) to a service principal. Assigning such roles to service principals is a common persistence technique, as these identities can be used to bypass conditional access policies and MFA through non-interactive authentication methods like client credentials.
Detects the assignment of highly privileged Azure AD/Entra ID directory roles (e.g., Global Administrator, Application Administrator) to a service principal. Assigning such roles to service principals is a common persistence technique, as these identities can be used to bypass conditional access policies and MFA through non-interactive authentication methods like client credentials.
Detects anomalous sign-in activity for service principals (non-interactive accounts) where the same application authenticates from multiple distinct countries within a 24-hour window. This behavior often indicates the unauthorized use of compromised service principal credentials, such as client secrets or certificates, from distributed attacker-controlled infrastructure.
Detects anomalous sign-in activity for service principals (non-interactive accounts) where the same application authenticates from multiple distinct countries within a 24-hour window. This behavior often indicates the unauthorized use of compromised service principal credentials, such as client secrets or certificates, from distributed attacker-controlled infrastructure.
This rule detects instances where a user successfully activates a privileged role via Privileged Identity Management (PIM) in a cloud environment, despite the activation policy requiring approval. It flags cases where the 'Add member to role completed' event indicates that approval is required, but the 'approvalStatus' is absent, suggesting an attempt to bypass the formal approval workflow.
Detects the reactivation of a service principal by correlating the addition of new credentials followed by a successful login event for the same principal within a 7-day window. This behavior is indicative of potential persistence maintenance or account hijacking, especially when legacy or deprecated accounts are targeted.
Detects a privilege escalation sequence where a principal uses 'PassRole' to attach an IAM role to a newly created compute resource (Lambda, EC2, or CloudFormation stack), followed shortly by that compute resource performing privileged API calls. This behavior indicates a potential attempt to gain unauthorized elevated permissions by executing actions from an over-privileged service identity.
Page 8 of 52