Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
839 detections
Filters
Last updated
All Time
Detection languages
438
190
77
62
40
Contributors
120
114
72
71
68
Categories
464
233
193
152
122
Platforms
288
274
154
88
56
Products / Services
220
169
162
90
76
MITRE Techniques
18,127
15,648
12,596
8,407
6,231
839
CVEs
6
5
5
5
5
IDS Classtypes
4
2
IDS Protocols
1
This rule detects suspicious activity on high blast radius accounts, specifically correlating failed authentication attempts, password resets, and successful logons outside business hours.
The rule prioritizes detection based on a password reset event to produce an informational severity alert, then looks for preceding failed authentications and subsequent out-of-hours logons to indicate a potential compromise by raising severity accordingly.
You will need to utilise the AlertSeverityOverride configuration, pointed at the AlertSeverity field, in your Sentinel rule metaconfig to use this detection effectively.
Hard requirement: Need UEBA enabled in your tenant to populate the BlastRadius field in your IdentityInfo table.
Change each stage to suit your log source for the behaviour mapped to this stage.
Add in other stages if needed to add more dynamic severity (e.g., Account has high blast radius AND is a GA AND was logged in to from outside of expected geolocation > Critical severity)
The rule prioritizes detection based on a password reset event to produce an informational severity alert, then looks for preceding failed authentications and subsequent out-of-hours logons to indicate a potential compromise by raising severity accordingly.
You will need to utilise the AlertSeverityOverride configuration, pointed at the AlertSeverity field, in your Sentinel rule metaconfig to use this detection effectively.
Hard requirement: Need UEBA enabled in your tenant to populate the BlastRadius field in your IdentityInfo table.
Change each stage to suit your log source for the behaviour mapped to this stage.
Add in other stages if needed to add more dynamic severity (e.g., Account has high blast radius AND is a GA AND was logged in to from outside of expected geolocation > Critical severity)
Detects a potential logging sink hijack in Google Cloud Platform (GCP) by identifying the deletion of a logging sink's destination bucket followed by the creation of a new bucket with the same name in a different project. This technique could allow an attacker to redirect logs to an attacker-controlled bucket, impairing defenses and potentially exfiltrating sensitive log data.
Detects the use of net.exe or net1.exe to add a local user account to the 'Administrators' or 'Remote Desktop Users' groups. This is a common technique used by attackers to gain persistent, elevated access or enable remote access to a compromised machine.
Detects the use of the `sysadminctl` utility with the `addUser` or `-addUser` command-line arguments, which can be used to create new user accounts on macOS systems. This activity could indicate an adversary attempting to establish persistences by creating new accounts.
Detects a successful self-service password reset for a privileged or high-value account when the initiating context does not match an approved helpdesk workflow.
Detects instances where an interactive user initiates a password change attempt as captured by Windows Security Event ID 4723. The rule filters out non-interactive accounts (ending with '$') and common service account naming patterns to focus on human-driven account modifications.
Detects the deletion of a storage bucket immediately followed by the creation of a new bucket with the same name across different cloud providers (GCP, AWS S3, Azure). This rule specifically flags scenarios where the deleting actor or project differs from the creating actor or project, indicating a potential cross-account hijack or data exfiltration attempt.
This rule detects a potential Azure storage account name hijacking scenario. It identifies instances where a storage account is deleted and then recreated with the exact same name in a different subscription within the same Azure tenant, all within a 60-minute window. This activity could indicate an attempt to exfiltrate data via Azure Monitor diagnostic settings by taking over a previously used storage account name.
This rule detects attempts to manipulate user or service principal names (SPN/UPN) in Active Directory by adding non-ASCII or zero-width characters. Such modifications can be used by adversaries for obfuscation, to bypass detection mechanisms, or to create stealthy persistence. The rule specifically looks for Event IDs 4738 (User Account Changed) and 5136 (Directory Service Object Modified) where the 'servicePrincipalName' or 'userPrincipalName' attributes contain characters outside the standard ASCII range or zero-width characters like U+200B, U+200C, U+200D.
This rule detects suspicious activities related to AWS S3 buckets that could indicate a bucket hijacking attempt or unauthorized replication to an external account. Specifically, it looks for two scenarios: 1) an S3 bucket being deleted and then recreated by a different AWS account within a one-hour window, suggesting a namespace hijacking, or 2) an S3 bucket being deleted while a PutBucketReplication event references an external AWS account, indicating an attempt to exfiltrate data or maintain access through replication.
Correlates the creation of a local user with the immediate addition of that user to the "Remote Desktop Users" or "Administrators" group.
Detects cross-tenant service principal authentications that leverage blueprint-derived identities. This rule specifically looks for client_credentials grant types using client_assertion (JWT bearer) or client_secret targeting sensitive scopes like 'api://AzureADTokenExchange/.default' or 'AgentIdentity.CreateAsManager' from a foreign tenant service principal. This activity could indicate an attempt to establish persistence or gain unauthorized access across Azure AD tenants.
Detects successful retrieval of storage account access keys by a user identity rather than an established deployment or backup service.
This rule detects the creation (EventID 4720) or deletion (EventID 4726) of user accounts within the Security Event logs. It summarizes these activities by the subject user name and time generated, providing an hourly count of account management actions.
This rule detects a high volume of group membership changes (additions or removals) by a single user within a one-hour window. Event IDs 4728 (A member was added to a security-enabled global group), 4729 (A member was removed from a security-enabled global group), and 4730 (A member was removed from a security-enabled universal group) are monitored. A count of 5 or more such events by the same user within an hour is flagged as suspicious, potentially indicating malicious account manipulation or privilege escalation attempts.
This rule detects when a single user makes multiple changes to security groups within a short timeframe (binned hourly). Specifically, it looks for Event IDs 4752 (A security-enabled global group was changed), 4753 (A security-enabled local group was changed), or 4754 (A security-enabled universal group was changed). This could indicate an attempt to manipulate group memberships for privilege escalation or lateral movement.
Detects when a user account's 'UserAccountControl' attribute is modified to include the 'Not Delegated' flag (EventID 4738). This change can be an indicator of an attacker attempting to alter account behavior for persistence or to evade detection, or it could be a legitimate administrative action.
Detects a successful self-service password reset for a privileged or high-value account when the initiating context does not match an approved helpdesk workflow. This could indicate an attacker attempting to gain access to an account by resetting its password without proper authorization.
This rule detects the creation, modification, or renaming of the `authorized_keys` file within the `.ssh` directory by processes other than common SSH key management or shell utilities. This activity could indicate an adversary attempting to establish persistence or elevate privileges by adding their own public key for SSH access.
Detects successful Device Code authentication followed immediately by a new device registration, a tactic used to extend access via PRT generation. This behavior is indicative of an attacker using a stolen device code to register a new device, thereby gaining persistent access to the user's account.
Detects attempts to modify or delete Conditional Access Policies in Microsoft Graph. This could indicate an adversary attempting to weaken security controls to facilitate unauthorized access or persistence.
Page 18 of 40