Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,061 detections
Filters
Last updated
All Time
Detection languages
594
173
103
71
51
Contributors
184
155
139
90
73
Categories
20,443
11,831
5,872
5,155
4,866
1,061
Platforms
576
267
228
221
116
Products / Services
499
220
129
118
86
MITRE Techniques
487
451
362
349
339
CVEs
10
5
4
3
2
IDS Classtypes
34
3
2
2
1
IDS Protocols
29
9
1
This analytic detects an unusual number of NTLM authentications targeting a single destination using a null domain. This activity is indicative of an attacker attempting to brute force or password spray a domain-joined Windows device from a non-domain device. Such activity may also generate a high volume of EventID 4776 events, though these events might not specify the attacker or target device.
This analytic identifies when a single user account attempts to authenticate to Azure/EntraID/Office 365 from multiple distinct operating systems within a short timeframe. This behavior can indicate an attacker's attempt to enumerate various logon capabilities, potentially to discover weaknesses in an organization's MFA or conditional access configurations. Tools like "MFASweep" are known to trigger this detection.
The analytic detects when an unusual number of NTLM authentications is attempted by the same source against multiple destinations. This activity generally results when an attacker attempts to brute force, password spray, or otherwise authenticate to multiple domain-joined Windows devices using an NTLM-based process/attack. This same activity may also generate a large number of EventID 4776 events as well.
This analytic detects CrowdStrike alerts indicating privilege escalation attempts by non-admin users. These alerts signify unauthorized efforts by regular users to gain elevated permissions, which poses a significant security risk. Detecting and addressing these attempts promptly helps prevent potential breaches and ensures that user privileges remain properly managed, maintaining the integrity of the organization's security protocols. The rule specifically filters for alerts containing "Privilege escalation" in the incident type and excludes users identified as administrators or service accounts.
This analytic detects suspicious Kerberos Ticket Granting Ticket (TGT) requests that may indicate exploitation of CVE-2021-42278 and CVE-2021-42287. It identifies sequences where a computer account is renamed (Event ID 4781) and immediately followed by a TGT request (Event ID 4768) for that same account. This behavior is significant as it could represent an attempt to escalate privileges by impersonating a Domain Controller, potentially leading to elevated access and control over the domain environment.
This analytic detects and analyzes PowerShell Web Access (PSWA) usage in Windows environments. It tracks both connection attempts (EventID 4648) and successful logons (EventID 4624) associated with PSWA, providing a comprehensive view of access patterns. The analytic identifies PSWA's operational status, host servers, processes, and connection metrics. It highlights unique target accounts, domains accessed, and verifies logon types. This information is crucial for detecting potential misuse, such as lateral movement, brute force attempts, or unusual access patterns. By offering insights into PSWA activity, it enables security teams to quickly assess and investigate potential security incidents involving this powerful administrative tool.
The following analytic identifies discrepancies between the IP address of an authentication event and the IP address of the verification response event, focusing on differences in the originating countries. It leverages JSON logs from PingID, comparing the 'auth_Country' and 'verify_Country' fields. This activity is significant as it may indicate suspicious sign-in behavior, such as account compromise or unauthorized access attempts. If confirmed malicious, this could allow attackers to bypass authentication mechanisms, potentially leading to unauthorized access to sensitive systems and data.
The following analytic detects changes to the sIDHistory attribute of user or computer objects across different domains. It leverages Windows Security Event Codes 4738 and 4742 to identify when the sIDHistory attribute is modified. This activity is significant because the sIDHistory attribute allows users to inherit permissions from other AD accounts, which can be exploited by adversaries for inter-domain privilege escalation and persistence. If confirmed malicious, this could enable attackers to gain unauthorized access to resources, maintain persistence, and escalate privileges across domain boundaries.
The analytic identifies the creation of a login profile for one AWS user by another, followed by a console login from the same source IP. It uses AWS CloudTrail logs to correlate the `CreateLoginProfile` and `ConsoleLogin` events based on the source IP and user identity. This activity is significant as it may indicate privilege escalation, where an attacker creates a new login profile to gain unauthorized access. If confirmed malicious, this could allow the attacker to escalate privileges and maintain persistent access to the AWS environment.
The analytic identifies threats detected by Okta ThreatInsight, such as password spraying, login failures, and high counts of unknown user login attempts. It leverages Okta Identity Management logs, specifically focusing on `security.threat.detected` events. This activity is significant for a SOC as it highlights potential unauthorized access attempts and credential-based attacks. If confirmed malicious, these activities could lead to unauthorized access, data breaches, and further exploitation of compromised accounts, posing a significant risk to the organization's security posture.
The analytic identifies authentication events of service principals in Azure Active Directory. It leverages the `azure_monitor_aad` data source, specifically targeting "Sign-in activity" within ServicePrincipalSignInLogs. This detection gathers details such as sign-in frequency, timing, source IPs, and accessed resources. Monitoring these events is significant for SOC teams to distinguish between normal application authentication and potential anomalies, which could indicate compromised credentials or malicious activities. If confirmed malicious, attackers could gain unauthorized access to resources, leading to data breaches or further exploitation within the environment.
The analytic detects an Azure AD user enabling a previously disabled account and resetting its password within 2 minutes. This activity is significant because it may indicate an adversary with administrative access attempting to establish a backdoor identity within the Azure AD tenant. If confirmed malicious, this could allow the attacker to maintain persistent access, escalate privileges, and potentially exfiltrate sensitive information from the environment.
The analytic identifies potential Kerberos ticket forging attacks, specifically the Diamond Ticket attack. This is detected when a user logs into a host and the GroupMembership field in event 4627 indicates a privileged group (e.g., Domain Admins), but the user does not actually belong to that group in the directory service. The detection leverages Windows Security Event Log 4627, which logs account logon events. The analytic cross-references the GroupMembership field from the event against a pre-populated lookup of actual group memberships. Any discrepancies between the events GroupMembership and the lookup indicate potential ticket forging. Kerberos ticket forging, especially the Diamond Ticket attack, allows attackers to impersonate any user and potentially gain unauthorized access to resources. By forging a ticket that indicates membership in a privileged group, an attacker can bypass security controls and gain elevated privileges. Detecting such discrepancies in group memberships during logon events can be a strong indicator of this attack in progress.
The following analytic identifies instances where the same Okta user logs in from different cities within a 24-hour period. This detection leverages Okta Identity Management logs, analyzing login events and their geographic locations. Such behavior is significant as it may indicate a compromised account, with an attacker attempting unauthorized access from multiple locations. If confirmed malicious, this activity could lead to account takeovers and data breaches, allowing attackers to access sensitive information and potentially escalate their privileges within the environment.
The following analytic identifies when an associate reports a login attempt as suspicious via an email from Okta. It leverages Okta Identity Management logs, specifically the `user.account.report_suspicious_activity_by_enduser` event type. This activity is significant as it indicates potential unauthorized access attempts, warranting immediate investigation to prevent possible security breaches. If confirmed malicious, the attacker could gain unauthorized access to sensitive systems and data, leading to data theft, privilege escalation, or further compromise of the environment.
The analytic detects the addition of Service Principal Names (SPNs) HOST and RestrictedKrbHost to a computer account, indicative of KrbRelayUp behavior. This detection leverages Windows Security Event Logs, specifically EventCode 4741, to identify changes in SPNs. This activity is significant as it is commonly associated with Kerberos-based attacks, which can be used to escalate privileges or perform lateral movement within a network. If confirmed malicious, this behavior could allow an attacker to impersonate services, potentially leading to unauthorized access to sensitive resources.
The analytic detects a high volume of Kerberos service ticket requests (more than 30) from a single source within a 5-minute window, specifically focusing on requests with computer names as the Service Name (Event ID 4769). This behavior may indicate malicious activities such as lateral movement, malware staging, or reconnaissance, potentially leading to unauthorized access and network compromise.
The following analytic detects a suspicious registry modification that hides a user account from the Windows Login screen. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "*\\Windows NT\\CurrentVersion\\Winlogon\\SpecialAccounts\\Userlist*" with a value of "0x00000000". This activity is significant as it may indicate an adversary attempting to create a hidden admin account to avoid detection and maintain persistence on the compromised machine. If confirmed malicious, this could allow the attacker to maintain undetected access and control over the system, posing a severe security risk.
This rule detects login activity by Azure AD administrators to Microsoft cloud applications that are not part of a predefined list of common first-party applications. The rule specifically looks for successful logins where the application ID is not in the 'first_party_ms_cloud_apps' list and the user ID is present in the 'entra_id_admin_watchlist'. This helps identify potentially unusual or unauthorized access by administrators to less common or custom applications, which could indicate compromise or policy violation.
This rule detects Azure AD login activity to applications that are not part of a predefined list of first-party Microsoft Cloud Apps. This could indicate an attempt to access an unauthorized or unusual application within the Azure AD environment, potentially by a compromised account or an insider threat. The rule specifically excludes the 'On-Premises Directory Synchronization Service Account' to reduce false positives related to ADFS synchronization.
This rule detects persistent login activity to the Azure AD PowerShell application. Specifically, it looks for successful user logins to the application identified by the product object ID '1b730954-1685-4b74-9bfd-dac224a7b894' (which corresponds to Azure AD PowerShell) by the same user ID over a 24-hour period. The rule is designed to flag continuous access to this administrative tool, which is not considered a security best practice and warrants further investigation.
Page 48 of 51