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 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
This detection rule flags events where conditional access policies are getting weaker, when modifications to CA inclusion or exclusion groups are happening, or when the effectiveness of a policy is disabled.
This rule identifies accounts that have been assigned administrative roles within the environment. It helps assess exposure risk by focusing on identities with elevated permissions, supports attack surface reduction by auditing role assignments, and enables proactive threat hunting for potential misuse of admin privileges.
This rule identifies inbound emails that have been delivered to the organization's email domain and are categorized as 'Phishing' by the email security system. It specifically looks for phishing indicators within the email's attachment or body. The query then summarizes the count of such emails by their URL domain, sorting them to highlight the most frequent phishing domains. The accompanying Python script demonstrates how to cross-reference these identified URL domains with VirusTotal for further analysis.
This rule identifies disabled service accounts within the environment. The goal is to help audit the state of service accounts, identify unused or stale accounts, ensure only necessary service accounts are active to reduce the attack surface, and support compliance and security posture assessments. While not directly indicative of an attack, monitoring disabled service accounts can help identify potential misconfigurations or accounts that could be re-enabled and abused.
This detection specifically flags credentials being added to the Connect Sync Application in Entra ID, a technique known to have persistance from On-premise AD DS to Entra ID. It tries to look at both certificate, client secret, and federated credentials being added, and tries to remove legitimate renewal processes. Since the legitimate renewal process first adds a new certificate only te remove the old one short after, we by default allow for a maximum of 1 minute between the certificate create and delete events.
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
This rule detects DNS queries to known malicious domains by joining IdentityQueryEvents with ThreatIntelligenceIndicator data. It specifically looks for matches between the queried domain (QueryTarget) and known malicious domains (DomainName) from threat intelligence feeds.
This rule identifies all enabled service accounts in the environment. The goal is to audit the state of service accounts to identify unused or stale accounts, ensure only necessary service accounts are active, reduce the attack surface, and support compliance and security posture assessments. While not directly detecting malicious activity, it provides crucial visibility for security hygiene and can help identify potential accounts that could be abused by adversaries for persistence or defense evasion.
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 identifies all logon events within the organization's domain by querying the IdentityLogonEvents table. It extracts distinct account display names, UPNs, device names, destination device names, action types, account domains, and applications involved in the logon.
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 detection flags any changes happening on the Connect Sync Application in Entra ID. Since this is a very interesting account for attackers to abuse when moving laterally between AD DS and Entra ID, any change to the account should be investigated. We try to exclude legitimate certificate renewal processes, and a new account onboarding in the detection rule.
This rule identifies all service accounts in the environment by querying IdentityInfo logs. The goal is to audit the state of these accounts, helping to identify unused or stale service accounts (especially if disabled), ensure only necessary service accounts are active to reduce the attack surface, and support compliance and security posture assessments. This rule does not detect malicious activity but rather provides an inventory for security auditing.
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.
This detection identifies repeated outbound email events where large files are sent multiple times within a specific time window. It helps uncover potential data exfiltration attempts or misuse of corporate email for transferring large files externally.
Thresholds for file size, frequency, and time window can be adjusted to fit organizational context.
Thresholds for file size, frequency, and time window can be adjusted to fit organizational context.
Detects indicators of compromise (IOCs) and suspicious OAuth consent activity
linked to the Tycoon/ODx phishing kits. These campaigns impersonate Microsoft
OAuth apps to bypass MFA and harvest Microsoft 365 credentials.
linked to the Tycoon/ODx phishing kits. These campaigns impersonate Microsoft
OAuth apps to bypass MFA and harvest Microsoft 365 credentials.
Detects potential data exfiltration from cloud storage or SaaS platforms based on a large volume of data transferred or a high number of distinct files accessed by a single user or application within a one-hour window. This is a common TTP for threat actors like ShinyHunters who aim to steal large datasets.
Suspicious Email Impersonating DocuSign Service Sent to {{RecipientEmailAddress}}
Flags an inbound phishing email impersonating the DocuSign service using lookalike domains, URLs, or attachments.
Flags an inbound phishing email impersonating the DocuSign service using lookalike domains, URLs, or attachments.
Page 153 of 185