Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,666 detections
Filters
Last updated
All Time
Detection languages
1,077
189
170
102
53
Contributors
520
361
306
67
52
Categories
20,443
11,831
5,872
5,155
4,866
1,666
Platforms
1,091
591
441
252
122
Products / Services
1,130
476
189
125
117
MITRE Techniques
945
843
438
416
413
CVEs
12
12
9
6
5
IDS Classtypes
1
1
This rule detects successful user authentications from your Azure AD tenant to other Azure AD tenants. This activity can indicate an attacker attempting to maintain access or escalate privileges by leveraging existing user accounts to access resources in external tenants, or it could be a legitimate business-to-business (B2B) collaboration that needs to be approved.
This rule detects successful user authentications originating from geographic locations (countries) that are not designated as operational areas for the organization. This helps identify potential unauthorized access attempts or compromised accounts being used from unexpected locations.
This rule detects the successful creation of a new administrative account within an Azure environment. It specifically looks for audit log entries indicating both 'Add user' and 'Add member to role' actions occurring successfully, which signifies a user being created and then assigned a privileged role.
This detection identifies when a user successfully authenticates from a country for the first time within a given period. It establishes a baseline of known countries for each user and alerts on any successful login originating from a country not present in that baseline. This behavior can indicate compromised credentials being used from an unusual location, or a legitimate user traveling to a new country.
This rule identifies successful user sign-ins originating from IP addresses known to belong to VPN services. It leverages an external list of VPN IP ranges to correlate with Azure AD SigninLogs. This can indicate an attempt to bypass geo-restrictions, hide true origin, or could be legitimate use of a VPN by an employee.
The following analytic identifies instances where users may have mistakenly entered their passwords in the username field during authentication attempts. It detects this by analyzing failed authentication events with usernames longer than 7 characters and high Shannon entropy, followed by a successful authentication from the same source to the same destination. This activity is significant as it can indicate potential security risks, such as password exposure. If confirmed malicious, attackers could exploit this to gain unauthorized access, leading to potential data breaches or further compromise of the system.
This rule detects successful or failed logon attempts originating from IP addresses identified by threat intelligence as associated with botnets, command and control (C2) infrastructure, or proxies. The rule specifically looks for 'LogOn' or 'FailedLogOn' activity types where the source IP's threat intelligence indicator type is 'Botnet', 'C2', or 'Proxy', and where activity insights are available.
Detects a user password change synced from on-premises Active Directory, immediately followed by the same user registering a new MFA method. This sequence is highly suspicious for existing privileged accounts and was used by the threat actor Storm-0501 to compromise a Global Administrator account that previously lacked MFA.
This query is designed to detect a series of anomalous user behaviors that, when combined, may indicate a compromised account. It flags activity that is uncharacteristic for a specific user, such as performing an unusual action, using an unfamiliar application, connecting from an unexpected ISP or country, or logging in from a new device for the first time. The final filter | where InvestigationPriority > 5 focuses the results on high-priority alerts, which are more likely to be legitimate threats. This approach uses behavioral analytics to identify deviations from a user's normal baseline, making it effective for detecting both insider threats and external attacks that have breached credentials.
Detects logon events (successful or failed) originating from workstations with suspicious or generic names, which can be an indicator of threat actor activity. This pattern has been associated with Akira ransomware campaigns.
Detects multiple failed Multi-Factor Authentication (MFA) push attempts for a user from a single IP address, followed by a successful attempt within a short time window. This pattern can indicate an MFA push bombing or fatigue attack where an adversary spams a user with MFA requests until they approve one.
Detects a transition from a Refresh Token (RT) to a Primary Refresh Token (PRT) for the same user and device within a 24-hour window. This sequence is a strong indicator of an adversary completing a device registration flow (e.g., using ROADtx) and escalating to persistent access with a PRT, which can bypass MFA and conditional access policies. The rule specifically looks for an initial RT authentication via the Microsoft Authentication Broker, followed by PRT usage for resources other than the Device Registration Service.
Detects successful non-interactive sign-ins to Microsoft Graph using the Visual Studio Code (VSCode) application identity. This behavior was observed in a phishing campaign where threat actors tricked users into an OAuth flow to harvest tokens. These tokens were then used to access user data, such as emails, via the Graph API.
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.
Detects when new credentials are added to an Entra ID Service Principal, followed by a successful login from that principal within a short time frame. This pattern is consistent with MURKY PANDA TTPs for lateral movement and persistence in cloud environments.
Detects a user self-assigning access to a large number of applications in Okta within a short time frame. This behavior is associated with the threat group UNC3944 (Scattered Spider) for privilege escalation and lateral movement across SaaS applications.
This detection rule identifies suspicious logins by service accounts on devices they haven't accessed in the last 14 days. This behavior could indicate a compromised service account being used for lateral movement within the environment. Service accounts typically have a static set of devices they authenticate to, making deviations easier to spot compared to user accounts. However, some service accounts (e.g., MDI service accounts) are known to dynamically log into devices, which may require environment-specific fine-tuning to reduce false positives.
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.
This version is the V2 version for this query in this repo, which also flags when an adversary is using the same application to get new access tokens but with another scope (compared to V1 which does not do this). The v2 version focusses more on RoadTool detection tho, while the v1 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.
This version is the V2 version for this query in this repo, which also flags when an adversary is using the same application to get new access tokens but with another scope (compared to V1 which does not do this). The v2 version focusses more on RoadTool detection tho, while the v1 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
Detects a successful NTLM network logon from a NULL SID (S-1-0-0). This pattern is a strong indicator of an NTLM relay attack, where an attacker intercepts an authentication attempt and relays it to a target service, such as LDAP on a Domain Controller, to perform actions on behalf of the relayed user. This is often used to modify Group Policy Objects (GPOs).
This rule detects successful device registrations to the 'Device Registration Service' in Azure Entra. It specifically looks for sign-in events where the ResourceDisplayName is 'Device Registration Service', the ErrorCode is '0' (indicating success), and the ConditionalAccessStatus is not '1' (which typically means that conditional access did not block the authentication flow for device registration).
The rule is pivotal for hunting devices registered for persistence, post-successful phishing campaign execution, where >= 1 accounts were compromised.
The rule is pivotal for hunting devices registered for persistence, post-successful phishing campaign execution, where >= 1 accounts were compromised.
The following analytic detects successful Remote Desktop Protocol (RDP) connections by monitoring EventCode 1149 from the Windows TerminalServices RemoteConnectionManager Operational log. This detection is significant as successful RDP connections can indicate remote access to a system, which may be leveraged by attackers to control or exfiltrate data. If confirmed malicious, this activity could lead to unauthorized access, data theft, or further lateral movement within the network. Monitoring successful RDP connections is crucial for identifying potential security breaches and mitigating risks promptly.
Page 71 of 80