Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,064 detections
Filters
Last updated
All Time
Detection languages
597
173
103
71
51
Contributors
184
155
139
90
73
Categories
20,443
11,831
5,875
5,151
4,864
1,064
Platforms
575
266
228
223
118
Products / Services
498
220
130
118
86
MITRE Techniques
488
451
363
349
341
CVEs
10
5
4
3
2
IDS Classtypes
34
3
2
2
1
IDS Protocols
29
9
1
Detects a user initiating an OAuth flow with the Microsoft Authentication Broker (MAB) client to the Device Registration Service (DRS) from multiple IP addresses within a short time window. This pattern is indicative of an adversary using a phished authorization code to begin the process of registering a malicious device in the target tenant, a key step for establishing persistence. The rule specifically looks for sessions that involve at least one browser-based request, which is common in the initial phishing stage.
Identifies Entra ID sign-in events where a user authenticates using a refresh token issued to the Microsoft Authentication Broker (MAB) client, targeting the Device Registration Service (DRS) with the "adrs_access" OAuth scope. This pattern is a strong indicator of an adversary using a stolen refresh token to initiate a malicious device registration flow, often with tools like ROADtx, as a step towards establishing persistence.
Detects attempts to read the Key Distribution Service (KDS) Root Key from Active Directory. This is often a preliminary step in the Golden dMSA attack, where an attacker with high privileges attempts to retrieve the key material needed to forge tickets for Delegated Managed Service Accounts (dMSA) to establish domain persistence. The rule looks for access to the 'msKds-ProvRootKey' object, identified either by its name or its schema ID GUID 'aa02fd41-17e0-4f18-8687-b2239649736b'.
This rule detects GlobalProtect VPN login attempts originating from outside of Canada. This can help identify potential unauthorized access or policy violations where users are expected to connect from specific geographic regions.
This rule detects changes to user multi-factor authentication (MFA) configurations within Azure Active Directory. It identifies when MFA methods are added, removed, or changed for a user, providing details on the actor, target, and the specific changes made. This helps in auditing MFA configuration changes, detecting unauthorized modifications, supporting incident response, and ensuring compliance with security policies.
This rule audits the state of service accounts in the environment by counting total, enabled, and disabled service accounts. This helps in identifying unused or stale service accounts, ensuring only necessary service accounts are active to reduce the attack surface, and supporting compliance and security posture assessments.
FOCI tokens (Family of Client IDs tokens) are special refresh tokens that allow multiple applications within the same "family" to share authentication tokens. This means that once a user authenticates with one application, they can access other applications in the same family without needing to re-authenticate. For adversaries, these are very interesting tokens to abuse since they can access a normal application (Microsoft Teams for example), and reuse that refresh token to access another application (like Azure CLI).
To detect a suspicious foci token combination, we look for all the logins using foci tokens and group them by Session ID (since these belong to the same session). Then we take the first login where no refresh token was provided, and look at the logins that used refresh tokens as incomming token types within that same session. If the second login application is one that is typically abused by adversaries and the application for the first login is a 'normal' application, we flag the event.
We added a second version for this query in this repo, to also flag when an adversary is using the same application to get new access tokens but with another scope. The v2 version focusses more on RoadTool detection tho, while this detection is more broad.
Some organizations have a high BP hit count on Microsoft Azure CLI. To limit those hits, you have three finetune options to enable in the query:
- Only alert when first and second login has X time between each other (default 90 minutes if enabled)
- Only alert on Microsoft Azure CLI when Global Administrator scope is used in token
- Only alert on Microsoft Azure CLI when Global Administrator scope is used in token and request came from a non-compliant device
To detect a suspicious foci token combination, we look for all the logins using foci tokens and group them by Session ID (since these belong to the same session). Then we take the first login where no refresh token was provided, and look at the logins that used refresh tokens as incomming token types within that same session. If the second login application is one that is typically abused by adversaries and the application for the first login is a 'normal' application, we flag the event.
We added a second version for this query in this repo, to also flag when an adversary is using the same application to get new access tokens but with another scope. The v2 version focusses more on RoadTool detection tho, while this detection is more broad.
Some organizations have a high BP hit count on Microsoft Azure CLI. To limit those hits, you have three finetune options to enable in the query:
- Only alert when first and second login has X time between each other (default 90 minutes if enabled)
- Only alert on Microsoft Azure CLI when Global Administrator scope is used in token
- Only alert on Microsoft Azure CLI when Global Administrator scope is used in token and request came from a non-compliant device
Hackers steal Microsoft logins using legitimate ADFS redirects
This might be one of the silliest detections I have created. But since there is a Beacon Object File out there which can be used to directly request Entra ID access tokens from an active beacon on a device using a specific User Agent, we can easily detect this beacon file by flagging the funny user agent and / or scope identifier that is used.
This rule detects Tycoon and ODx AiTM phishing activity that bypasses MFA. It matches:
🔹 Network connections to known malicious domains, IP addresses, and URLs.
🔹 Email-URL clicks and Azure AD sign-in events involving those domains or specific malicious application IDs.
🔹 Sign-ins originating from suspect IP addresses or user-agent strings.
🔹 Network connections to known malicious domains, IP addresses, and URLs.
🔹 Email-URL clicks and Azure AD sign-in events involving those domains or specific malicious application IDs.
🔹 Sign-ins originating from suspect IP addresses or user-agent strings.
This hunting rule searches for incoming ADWS connections on Domain Controllers from IP Addresses that cannot be linked to Microsoft Defender for Endpoint (MDE) onboarded devices. It aims to detect enumeration activities using ADWS from unmanaged or unknown devices, which might bypass typical monitoring tools.
This detection rule tries to find multiple PRT tokens being used simultaneously for one device. This might indicate that an attacker was able to request a new PRT on a second device using exxported Windows Hello for Business keys. More information about the attack scenario can be found in the references.
Detects potential DCSync attacks by identifying Event ID 4662 where specific DS-Replication access rights are used by a non-domain controller. This rule specifically looks for attempts to replicate directory changes (DS-Replication-Get-Changes, DS-Replication-Get-Changes-All, DS-Replication-Get-Changes-In-Filtered-Set) from an IP address that is not a known domain controller, while also excluding common system accounts.
MFA Fatigue Attack
Sigma
Detects a high number of failed or denied Multi-Factor Authentication (MFA) attempts followed by a success for the same user account within a short time frame. This pattern, known as MFA fatigue or push bombing, is a technique actively used by threat actors like Scattered Spider to overwhelm a user with push notifications until they approve one, granting the attacker access.
This analytic detects the addition of a Service Principal Name (SPN) to a domain account. It leverages Windows Event Code 5136 and monitors changes to the servicePrincipalName attribute. This activity is significant because it may indicate an attempt to perform Kerberoasting, a technique where attackers extract and crack service account passwords offline. If confirmed malicious, this could allow an attacker to obtain cleartext passwords, leading to unauthorized access and potential lateral movement within the domain environment.
The following analytic detects instances where a Duo admin login originates from a country outside of the United States, which may indicate suspicious or unauthorized access attempts. It works by analyzing Duo activity logs for admin login actions and filtering out events where the access device's country is not within the expected region. By correlating user, device, browser, and location details, the analytic highlights anomalies in geographic login patterns. This behavior is critical for a SOC to identify because admin accounts have elevated privileges, and access from unusual countries can be a strong indicator of credential compromise, account takeover, or targeted attacks. Early detection of such activity enables rapid investigation and response, reducing the risk of unauthorized changes, data breaches, or further lateral movement within the environment. The impact of this attack can be severe, potentially allowing attackers to bypass security controls, alter configurations, or exfiltrate sensitive information.
This rule detects suspicious device registration activity in Azure Active Directory (now Entra ID). Specifically, it looks for a sequence of two events: first, a 'Device Registration Service' adding a device with 'CloudAccountEnabled' set to true and a specific Windows build number (10.0.19041.928) in the user agent, followed by an attempt to add registered users to the device, referencing 'urn:ms-drs:enterpriseregistration.windows.net'. This sequence could indicate an adversary attempting to register a new device to bypass conditional access policies or gain persistent access.
The analytic identifies Cisco Duo admin login attempts originating from operating systems that are unusual for the environment, specifically excluding commonly used OS like Mac OS X. It analyzes Duo activity logs for 'admin_login' actions and filters out expected operating systems. The rule then aggregates events by browser, version, source IP, location, and OS details to highlight anomalies. Detecting admin logins from unexpected operating systems is crucial for a Security Operations Center (SOC) as it may indicate credential compromise, unauthorized access, or attacker activity using unfamiliar devices. Such behavior can precede privilege escalation, policy changes, or other malicious actions within the Duo environment. Early detection enables rapid investigation and response, reducing the risk of account takeover and minimizing potential damage to organizational security controls.
The analytic identifies instances where a Duo admin logs in using a browser other than Chrome, which is considered unusual based on typical access patterns. This behavior is significant for a SOC because the use of an unexpected browser may indicate credential compromise, session hijacking, or the use of unauthorized devices by attackers attempting to evade detection. Detecting such anomalies enables early investigation and response, helping to prevent privilege escalation, policy manipulation, or further compromise of sensitive administrative accounts. The impact of this attack could include unauthorized changes to security policies, user access, or the disabling of critical security controls, posing a substantial risk to the organizations security posture.
Detects a non-interactive sign-in using a refresh token for the Microsoft Authentication Broker client, targeting the Device Registration Service (DRS) with the 'adrs_access' scope. This specific combination of attributes is highly indicative of an adversary using tools like ROADtools to register a malicious device in the tenant following a successful OAuth phishing attack.
This detection identifies instances where the ESXi UI is accessed using the root account from an external IP address. Direct root access to the UI bypasses role-based access controls and auditing practices, and may indicate risky behavior, misconfiguration, or unauthorized activity by a malicious actor using compromised credentials.
Page 39 of 51