Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
3,864 detections
Filters
Last updated
All Time
Detection languages
2,523
525
299
218
131
Contributors
999
706
554
263
188
Categories
1,448
1,199
1,091
792
575
Platforms
39,932
7,263
6,535
3,864
3,643
Products / Services
1,755
1,449
1,120
438
406
MITRE Techniques
1,888
1,391
913
814
726
CVEs
12
5
4
3
2
IDS Classtypes
10
7
6
6
5
IDS Protocols
37
2
1
Detects scenarios where an attacker creates a forwarding rules to a non company email in order to collect information.
This rule identifies and monitors deletion operations in Azure Active Directory (AAD) that could indicate unauthorized activity. It excludes routine deletions, such as security information or device removals, and captures details about the initiating user, target user/group, and their IP address. The rule helps detect potentially anomalous or suspicious deletion actions, enhancing AAD security monitoring.
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 activity related to the PromptLock ransomware, which leverages the Ollama AI API and is written in Go. This rule looks for network connections to the Ollama service (port 11434) and related process executions, specifically identifying processes like go.exe, curl.exe, wget.exe, python.exe, powershell.exe making connections or processes with 'ollama' in their command line.
The analytic detects the creation or update of a new Azure Automation Runbook within an Azure tenant. It leverages Azure Audit events, specifically the Azure Activity log category, to identify when this operation occurs. This activity is significant because adversaries with privileged access can use Runbooks to maintain persistence, escalate privileges, or execute malicious code. If confirmed malicious, this could lead to unauthorized actions such as creating Global Administrators, executing code on VMs, and compromising the entire Azure environment.
Detects scenarios where an federated trust is added by an attacker.
The analytic detects the creation of a new Azure Automation account within an Azure tenant. It leverages Azure Audit events, specifically the Azure Activity log category, to identify when an account is created or updated. This activity is significant because Azure Automation accounts can be used to automate tasks and orchestrate actions across Azure and on-premise environments. If an attacker creates an Automation account with elevated privileges, they could maintain persistence, execute malicious runbooks, and potentially escalate privileges or execute code on virtual machines, posing a significant security risk.
The analytic detects the creation of a new Automation Runbook Webhook within an Azure tenant. It leverages Azure Audit events, specifically the "Create or Update an Azure Automation webhook" operation, to identify this activity. This behavior is significant because Webhooks can trigger Automation Runbooks via unauthenticated URLs exposed to the Internet, posing a security risk. If confirmed malicious, an attacker could use this to execute code, create users, or maintain persistence within the environment, potentially leading to unauthorized access and control over Azure resources.
Detects scenarios where an attacker attempt to hide emails in order to perform phishing attacks by replacing, for example, financial information from the original email with another email containing attacker's financial information. This technique may also be used to avoid specific email notification to be received by end users in case, for example, of an ongoing breach.
Detects a user accessing the keys for multiple distinct Azure Storage Accounts in a short period. This behavior is associated with the threat actor Storm-0501, who performs this action for credential access prior to data exfiltration.
This detection identifies suspicious use of wreply or redirect_uri parameters in ADFS or Microsoft login URLs. Attackers can abuse these parameters to redirect users to non-Microsoft domains after authentication, a technique commonly referred to as ADFSjacking.
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.
In May 2025, a campaign started using the Microsoft Exchange Direct Send feature to send phishing mails to organizations. This feature is designed for use by printers, scanners, cloud services and other devices that need to send messages on behalf of the company. This detection rule tries to detect the malicious mails being send via Direct Send using a couple of indicators:
- Sender email is the same as Recipient email
- SPF and DMARC both failed
- Mail is not comming in via an Exchange connector
- The sender IP address country is not a country that the user is known to login from
FYI, if you remove the country check (last line of the query), you can use the query to identify if there are legitimate mails as well. If not, you can disable the Direct Send feature in Exchange Online.
- Sender email is the same as Recipient email
- SPF and DMARC both failed
- Mail is not comming in via an Exchange connector
- The sender IP address country is not a country that the user is known to login from
FYI, if you remove the country check (last line of the query), you can use the query to identify if there are legitimate mails as well. If not, you can disable the Direct Send feature in Exchange Online.
This KQL query searches the ExposureGraphNodes table in Microsoft Defender XDR or Sentinel to identify user accounts whose credentials have been leaked. It focuses on nodes categorized as "identity" and labeled as "user", then extracts detailed identity-related properties such as: Display name, UPN, email address, Account status (enabled/disabled), Job title, department, phone, address, Source provider (e.g., Azure AD, on-prem AD), Account creation time, and whether the account's credentials have been leaked. The query filters and enriches this data, and presents it in a clean, readable format for hunting or triage.
This rule detects changes to user multi-factor authentication (MFA) methods within an organization. It identifies when MFA methods are added, removed, or when the default MFA method is changed. This helps audit MFA configuration changes, detect unauthorized or suspicious modifications to authentication methods, support incident response by identifying the actor and timestamp of the change, and ensure compliance with security policies requiring strong authentication.
This rule detects changes to privileged roles and group memberships within Azure Active Directory. It helps identify potential unauthorized privilege escalation, supports compliance and audit requirements, and allows correlation of identity changes with suspicious activity or alerts. The rule specifically looks for operations such as adding/removing members from roles or groups, and updating role memberships or user details, ensuring the operation was successful.
This rule monitors changes to users' Authenticator app registrations within Azure Active Directory. It detects unauthorized device additions or removals, which can be used by adversaries to bypass multi-factor authentication or maintain persistent access to compromised accounts. The rule parses audit logs for 'Update user' operations specifically targeting 'StrongAuthenticationPhoneAppDetail' to identify both added and removed Authenticator app devices.
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.
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
Page 152 of 184