Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
18,128 detections
Filters
Last updated
All Time
Detection languages
6,549
6,208
1,473
1,005
661
Contributors
3,555
2,652
2,153
2,087
1,515
Categories
7,572
3,901
1,465
1,393
1,330
Platforms
13,733
1,392
1,319
824
738
Products / Services
3,828
3,137
2,448
912
908
MITRE Techniques
18,128
15,653
12,600
8,411
6,235
CVEs
19
18
17
16
14
IDS Classtypes
305
51
24
23
22
IDS Protocols
308
136
13
10
10
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.
Detects impossible travel activity for Azure AD accounts by calculating the speed between consecutive sign-in events using the Haversine formula. The rule correlates sign-ins sharing the same SessionId or DeviceId and identifies instances where the calculated travel speed exceeds 900 km/h over a distance greater than 300 km. It includes filtering to exclude known corporate VPN egress points to reduce noise.
Detects impossible travel activity for Azure AD accounts by calculating the speed between consecutive sign-in events using the Haversine formula. The rule correlates sign-ins sharing the same SessionId or DeviceId and identifies instances where the calculated travel speed exceeds 900 km/h over a distance greater than 300 km. It includes filtering to exclude known corporate VPN egress points to reduce noise.
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 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.
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.
Detects successful authentication attempts using legacy (basic) protocols that do not enforce modern Conditional Access policies (e.g., MFA, device compliance). The rule specifically flags these events if the originating IP address or geographic location is not observed in historical sign-in activity for the specific user, which may indicate account compromise via credential theft.
Detects successful authentication attempts using legacy (basic) protocols that do not enforce modern Conditional Access policies (e.g., MFA, device compliance). The rule specifically flags these events if the originating IP address or geographic location is not observed in historical sign-in activity for the specific user, which may indicate account compromise via credential theft.
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 potential abuse of Azure Cloud Shell backing storage (acsCloudShell) to stage or persist malicious scripts following an Azure AD session compromise. Adversaries may use this storage to blend in with legitimate engineering operations while maintaining persistent access to their tooling.
Page 49 of 864