Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
23 detections
Filters
Last updated
All Time
Detection languages
17
3
1
1
1
Contributors
6
6
1
1
1
Categories
12
10
8
7
4
Platforms
20
4
2
2
1
Products / Services
12
8
5
5
4
MITRE Techniques
18,108
15,613
12,573
8,384
6,203
Detects enumeration of Entra ID applications and permissions via AzureHound or ROADrecon, identified by distinct user-agent strings or abnormal Graph API request volume — the same signal Organization B's custom alerts used to catch CISA's red team.
Detects the execution of the roadtx command-line utility, which is a component of the ROADtools framework used for OAuth device code flow interaction and token acquisition within Entra ID (formerly Azure AD) environments.
Detects a benign executable loading a nearby DLL that reads and executes a data file containing an embedded .NET backdoor. This technique is often used by threat actors to evade detection by leveraging legitimate processes and file types.
Detects sign-in or Microsoft Graph API activity using user-agent strings characteristic of ROADtools and similar Python-based identity-attack tooling. The rule generalizes beyond ROADtools to catch AzureHound, MicroBurst, MFASweep, GraphRunner, and similar identity attack frameworks by looking for scripting user-agents (python, requests, urllib, curl) which signal non-browser, non-app authentication that is inherently suspicious for Entra ID admin operations.
Identifies potential use of ROADtools for Azure AD reconnaissance by monitoring for Azure CLI/PowerShell App IDs coupled with a Python user agent in sign-in logs. This rule specifically looks for sign-ins to 'Windows Azure Active Directory' resource where the user agent string contains 'python' or the device detail string contains 'Python', and the App ID or App Display Name matches known Azure AD PowerShell or Azure CLI applications.
This rule detects suspicious user-agent strings in Microsoft Graph activity logs that are commonly associated with reconnaissance and attack tools targeting Azure AD and Microsoft 365 environments. These tools include BloodHound, ROADtools, AADInternals, and various other utilities used for enumeration, credential spraying, and other malicious activities.
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 non-interactive sign-in using a refresh token for the Microsoft Authentication Broker client, targeting the Device Registration Service (DRS) with the 'adrs_access' scope. This specific combination of attributes is highly indicative of an adversary using tools like ROADtools to register a malicious device in the tenant following a successful OAuth phishing attack.
Detects a sequence of events indicative of a new device being registered using a refresh token, a TTP associated with the ROADtools framework following an OAuth phishing attack. This sequence involves the Device Registration Service adding a device with a specific hardcoded OS version, followed by user and owner assignments, all within a short timeframe and sharing the same correlation ID.
KQL Query from file: NEW Real-time Anomalous Token Detection
KQL Query from file: Detect Privilege Admin under AiTM attack
KQL Query
KQL Query from file: Entra Admin Roles Query
KQL Query from file: Mitigating security risks in MCP implementations
KQL Query
This detection leverages Azure Graph activity logs to identify when Graph APIs have been used to identify 10 or more service principals. This type of behavior is associated with tools such as Azure enumeration tools like AzureHound or ROADtools.
'Identifies accounts that have been added to a PIM managed privileged group'
'Looks for multiple users that had their admin role removed by a single user within a certain period.
The default threshold is 5 removals, this can be edited in the query.'
The default threshold is 5 removals, this can be edited in the query.'
'This query looks for accounts being created that do not have attributes populated that are commonly populated in the tenant.
Attackers may attempt to add accounts as a means of establishing persistant access to an environment, looking for anomalies in created accounts may help identify illegitimately created accounts.
Created accounts should be investigated to ensure they were legitimated created.
Ref: https://docs.microsoft.com/azure/active-directory/fundamentals/security-operations-user-accounts#accounts-not-following-naming-policies'
Attackers may attempt to add accounts as a means of establishing persistant access to an environment, looking for anomalies in created accounts may help identify illegitimately created accounts.
Created accounts should be investigated to ensure they were legitimated created.
Ref: https://docs.microsoft.com/azure/active-directory/fundamentals/security-operations-user-accounts#accounts-not-following-naming-policies'
'Detects a successful logon by a privileged account from an ASN not logged in from in the last 14 days.
Monitor these logons to ensure they are legitimate and identify if there are any similar sign ins.'
Monitor these logons to ensure they are legitimate and identify if there are any similar sign ins.'
'This query looks at the last 14 days for "Consent to application" operation by a user/app which could potentially mean unauthorized access. Additional context is added from AuditLogs based on CorrleationId from the same account that performed the action.'
Page 1 of 2