Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
170 detections
Filters
Last updated
All Time
Detection languages
64
46
20
18
12
Contributors
36
23
19
13
12
Categories
59
42
39
38
36
Platforms
74
43
24
22
18
Products / Services
42
36
33
13
10
MITRE Techniques
18,123
15,639
12,580
8,394
6,215
CVEs
7
2
2
2
1
IDS Classtypes
4
4
3
3
1
IDS Protocols
7
5
KQL Query
KQL Query from file: DISCOVERY: Obsolete device connecting to Entra
Detects possible addition of shadow credentials to an active directory object.
This query shows authentication methods being added and devices registered around the time of a high risk sign in which could indicate an attempt to establish persistence on a compromised account. The threshold can be changed to a wider timeframe if needed.
This rule identifies a source that repeatedly fails to authenticate to a web service (HTTP response code 403). This may indicate a [brute force](https://en.wikipedia.org/wiki/Brute-force_attack) or [credential stuffing](https://en.wikipedia.org/wiki/Credential_stuffing) attack.
This rule uses the [Advanced Security Information Model (ASIM)](https://aka.ms/AboutSIM) and supports any web session source that complies with ASIM.
This rule uses the [Advanced Security Information Model (ASIM)](https://aka.ms/AboutSIM) and supports any web session source that complies with ASIM.
This query shows details about all approved Entra ID Governance Access Packages assignments. The results include the time the request was created and approved along with the justification text provided by the requestor and the approver.
Detects changes to "DsrmAdminLogonBehavior" registry value.
During a Domain Controller (DC) promotion, administrators create a Directory Services Restore Mode (DSRM) local administrator account with a password that rarely changes. The DSRM account is an “Administrator” account that logs in with the DSRM mode when the server is booting up to restore AD backups or recover the server from a failure.
Attackers could abuse DSRM account to maintain their persistence and access to the organization's Active Directory.
If the "DsrmAdminLogonBehavior" value is set to "0", the administrator account can only be used if the DC starts in DSRM.
If the "DsrmAdminLogonBehavior" value is set to "1", the administrator account can only be used if the local AD DS service is stopped.
If the "DsrmAdminLogonBehavior" value is set to "2", the administrator account can always be used.
During a Domain Controller (DC) promotion, administrators create a Directory Services Restore Mode (DSRM) local administrator account with a password that rarely changes. The DSRM account is an “Administrator” account that logs in with the DSRM mode when the server is booting up to restore AD backups or recover the server from a failure.
Attackers could abuse DSRM account to maintain their persistence and access to the organization's Active Directory.
If the "DsrmAdminLogonBehavior" value is set to "0", the administrator account can only be used if the DC starts in DSRM.
If the "DsrmAdminLogonBehavior" value is set to "1", the administrator account can only be used if the local AD DS service is stopped.
If the "DsrmAdminLogonBehavior" value is set to "2", the administrator account can always be used.
Detects changes to "DsrmAdminLogonBehavior" registry value.
During a Domain Controller (DC) promotion, administrators create a Directory Services Restore Mode (DSRM) local administrator account with a password that rarely changes. The DSRM account is an “Administrator” account that logs in with the DSRM mode when the server is booting up to restore AD backups or recover the server from a failure.
Attackers could abuse DSRM account to maintain their persistence and access to the organization's Active Directory.
If the "DsrmAdminLogonBehavior" value is set to "0", the administrator account can only be used if the DC starts in DSRM.
If the "DsrmAdminLogonBehavior" value is set to "1", the administrator account can only be used if the local AD DS service is stopped.
If the "DsrmAdminLogonBehavior" value is set to "2", the administrator account can always be used.
During a Domain Controller (DC) promotion, administrators create a Directory Services Restore Mode (DSRM) local administrator account with a password that rarely changes. The DSRM account is an “Administrator” account that logs in with the DSRM mode when the server is booting up to restore AD backups or recover the server from a failure.
Attackers could abuse DSRM account to maintain their persistence and access to the organization's Active Directory.
If the "DsrmAdminLogonBehavior" value is set to "0", the administrator account can only be used if the DC starts in DSRM.
If the "DsrmAdminLogonBehavior" value is set to "1", the administrator account can only be used if the local AD DS service is stopped.
If the "DsrmAdminLogonBehavior" value is set to "2", the administrator account can always be used.
'This alerts when the account setting is changed to allow either external domain access or anonymous access to meetings.'
The following analytic identifies the registration of a new Multi-Factor Authentication (MFA) method for an AWS account, as logged through Amazon Security Lake (ASL). It detects this activity by monitoring the `CreateVirtualMFADevice` API operation within ASL logs. This behavior is significant because adversaries who gain unauthorized access to an AWS account may register a new MFA method to maintain persistence. If confirmed malicious, this activity could allow attackers to secure their access, making it harder to detect and remove their presence from the compromised environment.
The following analytic identifies modifications to Okta Identity Provider (IDP) lifecycle events, including creation, activation, deactivation, and deletion of IDP configurations. It uses OktaIm2 logs ingested via the Splunk Add-on for Okta Identity Cloud. Monitoring these events is crucial for maintaining the integrity and security of authentication mechanisms. Unauthorized or anomalous changes could indicate potential security breaches or misconfigurations. If confirmed malicious, attackers could manipulate authentication processes, potentially gaining unauthorized access or disrupting identity management systems.
The analytic detects the registration of a new Multi-Factor Authentication (MFA) method for an Azure AD account. It leverages Azure AD AuditLogs to identify when a user registers new security information. This activity is significant because adversaries who gain unauthorized access to an account may add their own MFA method to maintain persistence. If confirmed malicious, this could allow attackers to bypass existing security controls, maintain long-term access, and potentially escalate their privileges within the environment.
The following analytic identifies instances where Multi-Factor Authentication (MFA) is disabled for a user within the Office 365 environment. It leverages O365 audit logs, specifically focusing on events related to MFA settings. Disabling MFA removes a critical security layer, making accounts more vulnerable to unauthorized access. If confirmed malicious, this activity could indicate an attacker attempting to maintain persistence or an insider threat, significantly increasing the risk of unauthorized access. Immediate investigation is required to validate the reason for disabling MFA, potentially re-enable it, and assess any other suspicious activities related to the affected account.
The following analytic detects an attempt to disable multi-factor authentication (MFA) for a Google Cloud Platform (GCP) user. It leverages Google Workspace Admin log events, specifically the UNENROLL_USER_FROM_STRONG_AUTH command. This activity is significant because disabling MFA can allow an adversary to maintain persistence within the environment using a compromised account without raising suspicion. If confirmed malicious, this action could enable attackers to bypass additional security layers, potentially leading to unauthorized access, data exfiltration, or further exploitation of the compromised account.
The analytic identifies failed user authentication attempts in Okta where FastPass explicitly declined a phishing attempt. This indicates that users are being targeted by real-time phishing proxies attempting to capture credentials. Successful exploitation could lead to unauthorized account access and further compromise.
The analytic detects accounts experiencing a high number of Single Sign-On (SSO) logon errors within Office 365. It specifically looks for `UserLoginFailed` operations with `LogonError` containing "Sso" in the `o365_management_activity` data. A count of 5 or more such errors from the same source, vendor account, vendor product, destination, signature, and user agent within a given timeframe is considered anomalous. This activity can indicate brute-force attempts against SSO, credential stuffing, or attempts to reuse hijacked SSO tokens, potentially leading to unauthorized account access, data breaches, or further compromise.
The following analytic identifies an attempt to disable multi-factor authentication (MFA) for an Okta user. It leverages OktaIM2 logs to detect when the 'user.mfa.factor.deactivate' command is executed. This activity is significant because disabling MFA can allow an adversary to maintain persistence within the environment using a compromised valid account. If confirmed malicious, this action could enable attackers to bypass additional security layers, potentially leading to unauthorized access to sensitive information and prolonged undetected presence in the network.
Detects when an Okta user's password is reset and MFA factor(s) are deactivated or reset within a 30 minute time window. This activity may indicate that the user account has been compromised.
This rule identifies when multi-factor authentication (MFA) is disabled for a Google Workspace organization. This change can weaken the organization's security posture by removing an important layer of defense against unauthorized access. Security teams should monitor for such changes to prevent potential account compromise.
Detects when a user removes an authentication factor or otp device.
Detects attempts to disable multi-factor authentication for an AWS IAM user.
Page 8 of 9