Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
4,311 detections
Filters
Last updated
All Time
Detection languages
2,035
733
398
299
243
Contributors
1,048
740
503
372
239
Categories
20,456
11,839
5,876
5,155
4,865
4,311
Platforms
2,572
793
615
382
319
Products / Services
767
740
659
513
348
MITRE Techniques
2,350
917
848
814
635
CVEs
9
6
6
6
5
IDS Classtypes
81
66
44
14
14
IDS Protocols
136
79
11
7
4
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 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 PRT token stealing on a device when exploiting the MicrosoftAccountTokenProvider.dll, leveraging a WDAC audit policy to ingest missing Microsoft Defender for Endpoint events. This addresses a blind spot in default Defender for Endpoint detection.
Detects suspicious downloads or fetches of common privilege-escalation tools such as winPEAS, linPEAS, PowerUp, Seatbelt, SharpUp, WinPwn, PrivescCheck, Sherlock, Watson, BeRoot, LinEnum, LSE/LES, Linux Exploit Suggester, pspy, or GTFObins. These tools are often used by adversaries after initial access to enumerate the environment and attempt local privilege escalation.
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 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 detection rule uses a WDAC audit policy to ingest missing DeviceImageLoad events in MDE, and check for suspicious processes using the ncrypt.dll and requesting an Entra ID Nonce. More information on the attack scenario this is detection is applicable for can be found in the references.
The analytic identifies the deletion or modification of registry keys that disable Local Security Authority (LSA) protection and Microsoft Defender Device Guard. This activity is significant because disabling these defenses can leave a system vulnerable to various attacks, including credential theft and unauthorized code execution. If confirmed malicious, this action could allow attackers to bypass critical security mechanisms, leading to potential system compromise and persistent access.
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 rule uses a WDAC audit policy to ingest missing DeviceImageLoad events in MDE, and check for suspicious processes using the ncrypt.dll. More information on the attack scenario this is detection is applicable for can be found in the references.
The following analytic detects a process attempting to duplicate the handle of winlogon.exe from an uncommon or public source path. This is identified using Sysmon EventCode 10, focusing on processes targeting winlogon.exe with specific access rights and excluding common system paths. This activity is significant because it may indicate an adversary trying to escalate privileges by leveraging the high-privilege tokens associated with winlogon.exe. If confirmed malicious, this could allow the attacker to gain elevated access, potentially leading to full system compromise and persistent control over the affected host.
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 suspicious activities in Salesforce environments consistent with the TTPs of the ShinyHunters threat group (also tracked as UNC6040/UNC6240). The attack involves social engineering (vishing) to trick users into authorizing malicious OAuth applications that impersonate legitimate tools like 'Salesforce Data Loader'. This rule looks for key indicators such as the installation of unreviewed packages, creation of impersonating connected apps, elevation of permissions to 'full' API access, and large data exports.
Detects a variety of post-exploitation techniques observed in attacks leveraging SonicWall vulnerabilities (CVE-2024-40766). These techniques are associated with the Akira ransomware group and include defense evasion, credential access, and data staging.
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).
Detects the execution of an AppleScript, characteristic of the Odyssey Stealer, that displays a dialog box prompting the user for their password.
This rule detects attempts to disable Multi-Factor Authentication (MFA) within Microsoft 365 services. Specifically, it looks for audit log entries containing the operation 'Disable Strong Authentication.' This action could be performed by an attacker to maintain persistent access to compromised accounts by removing an important security layer.
Detects suspicious SMB/NTLM activity triggered by explorer.exe following recent .lnk file creation by script engines. This behavior aligns with the CVE-2025-50154 bypass of Microsoft’s NTLM credential leak patch (CVE-2025-24054), allowing zero-click NTLM hash disclosure and remote binary staging without execution.
Detects the simultaneous modification of 'msDS-ManagedAccountPrecededByLink' and 'msDS-DelegatedMSAState' attributes on a delegated Managed Service Account (dMSA) object. This activity is a strong indicator of the BadSuccessor privilege escalation technique, where an attacker simulates a dMSA migration to impersonate a target account.
This analytic detects a user account initiating an Active Directory replication request, indicative of a DCSync attack. It leverages EventCode 4662 from the Windows Security Event Log, focusing on specific object types and replication permissions. This activity is significant because it can allow an attacker with sufficient privileges to request password hashes for any or all users within the domain. If confirmed malicious, this could lead to unauthorized access, privilege escalation, and potential compromise of the entire domain.
Page 170 of 206