Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
3,867 detections
Filters
Last updated
All Time
Detection languages
2,526
525
299
218
131
Contributors
999
706
554
263
188
Categories
1,449
1,199
1,091
793
576
Platforms
39,960
7,270
6,537
3,867
3,651
Products / Services
1,756
1,449
1,121
438
406
MITRE Techniques
1,889
1,392
913
814
727
CVEs
12
5
4
3
2
IDS Classtypes
10
7
6
6
5
IDS Protocols
37
2
1
This rule detects network connections to known dynamic DNS (DDNS) subdomains. Adversaries often use dynamic DNS services to maintain persistent command and control (C2) communication channels, as these services allow them to frequently change the IP address associated with a static hostname, making it harder for defenders to block or track their infrastructure. These providers also have established domain reputation, and provide legitimate services making blanket IOC rules impossible. The rule identifies connections to specific DDNS providers such as DuckDNS, No-IP, PublicVM, and others.
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 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.
Page 152 of 185