Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
771 detections
Filters
Last updated
All Time
Detection languages
392
128
66
49
47
Contributors
296
150
91
39
27
Categories
388
258
255
124
110
Platforms
523
344
285
121
72
Products / Services
370
328
112
51
43
MITRE Techniques
18,115
15,635
12,576
8,388
6,215
771
CVEs
2
1
IDS Classtypes
15
11
3
1
1
IDS Protocols
29
Detects Microsoft 365 token replay from the Huntress token spray and replay campaign. Alerts on sign-ins from an IP new to the account (not seen on 3 or more distinct days in the 14d baseline) that match one of three behaviors: a scripted client (node or bare Mozilla/5.0 user agent with Office or Authentication Broker client IDs), Device Registration Service access (Medium-High only when corroborated by a campaign IP, scripted user agent or session IP hop, otherwise Low), or one session moving across IPs within 60 minutes. Rows are raised to High when the same new IP hits 3 or more baseline accounts in the window (token spray pattern) or matches a campaign IOC. Low Signal rows are dropped when AlertOnly = true. Does not cover MFA changes, device registration events or inbox rules.
Audit query that finds enabled OAuth apps in Microsoft Entra ID holding permissions an attacker would want: reading or sending mail, accessing files and sites, planting credentials on other apps, assigning roles, or changing Conditional Access. App-only permissions (the app signs in as itself, with no user and no MFA) are split from delegated ones. High-privilege delegated grants are flagged only for external apps with no verified publisher, the typical consent-phishing shape. Output is one row per app with a plain-language ReviewReason, publisher, origin, admin consent, activity (Inactive 90d+ is the easiest to disable) and “(in use)” markers on permissions the app actually exercises, so a review team can decide to keep, reduce or disable.
This is an inventory of what apps can do, not a change detector. A verified publisher does not mean safe, as the ConnectWise/SkyKick credential abuse showed. Pair it with audit-log hunting for new secrets and role assignments. Requires OAuthAppInfo (app governance in Defender for Cloud Apps).
This is an inventory of what apps can do, not a change detector. A verified publisher does not mean safe, as the ConnectWise/SkyKick credential abuse showed. Pair it with audit-log hunting for new secrets and role assignments. Requires OAuthAppInfo (app governance in Defender for Cloud Apps).
Audit query that finds enabled OAuth apps in Microsoft Entra ID holding permissions an attacker would want: reading or sending mail, accessing files and sites, planting credentials on other apps, assigning roles, or changing Conditional Access. App-only permissions (the app signs in as itself, with no user and no MFA) are split from delegated ones. High-privilege delegated grants are flagged only for external apps with no verified publisher, the typical consent-phishing shape. Output is one row per app with a plain-language ReviewReason, publisher, origin, admin consent, activity (Inactive 90d+ is the easiest to disable) and “(in use)” markers on permissions the app actually exercises, so a review team can decide to keep, reduce or disable.
This is an inventory of what apps can do, not a change detector. A verified publisher does not mean safe, as the ConnectWise/SkyKick credential abuse showed. Pair it with audit-log hunting for new secrets and role assignments. Requires OAuthAppInfo (app governance in Defender for Cloud Apps).
This is an inventory of what apps can do, not a change detector. A verified publisher does not mean safe, as the ConnectWise/SkyKick credential abuse showed. Pair it with audit-log hunting for new secrets and role assignments. Requires OAuthAppInfo (app governance in Defender for Cloud Apps).
Correlates a device code flow sign-in event with bulk file downloads from SharePoint or OneDrive by the same user account within a 1-hour window. This behavior can indicate potential account compromise or misuse where an adversary uses device code phishing to authenticate and subsequently exfiltrate sensitive files.
Detects successful Azure Active Directory (Entra ID) sign-ins using the device code flow where the originating device is neither registered nor trusted (managed or compliant), which may indicate suspicious authentication attempts or token abuse.
Detects a successful device-code sign-in followed within 60 minutes by non-interactive replay from a different IP AND a persistence action (inbox rule, app consent, device add) from a non-original IP. Persistence is now mandatory (inner join) instead of optional, and the retired AADSignInEventsBeta table is replaced by EntraIdSignInEvents.
Detects instances where an OAuth token is used from a new IP address and a new country within 24 hours of a successful device-code sign-in for the same user, potentially indicating token theft or abuse.
Detects successful OAuth device-code flow sign-ins where the user completed multi-factor authentication (MFA) from a non-compliant/unmanaged device using an IP address never seen in their 30-day baseline history. This behavior can indicate device-code phishing or token abuse.
Detects a successful device-code sign-in followed within 60 minutes by non-interactive replay from a different IP AND a persistence action (inbox rule, app consent, device add) from a non-original IP. Persistence is now mandatory (inner join) instead of optional, and the retired AADSignInEventsBeta table is replaced by EntraIdSignInEvents.
Detects the Mir0Auth phishing kit sequence within a single HTTP flow: POST /task_queue.cs beacon followed by POST /context.go device-code request, both with application/octet-stream bodies. Requires both requests (flowbits) and exact path endings to limit false positives. SIDs made unique.
Azure AD Device Code Flow Token Phishing
Cortex XDR
Detects potential device code phishing attacks by identifying OAuth token requests associated with the device code flow that originate from unmanaged or non-compliant devices. The rule specifically monitors for suspicious Cmsi (Client Managed Service Identity) activity or the use of unbound sign-in tokens within the device code flow for targeted Microsoft productivity and management applications.
Detects a successful device-code sign-in followed within 60 minutes by non-interactive replay from a different IP AND a persistence action (inbox rule, app consent, device add) from a non-original IP. Persistence is now mandatory (inner join) instead of optional, and the retired AADSignInEventsBeta table is replaced by EntraIdSignInEvents.
Detects a successful device-code sign-in followed within 60 minutes by non-interactive replay from a different IP AND a persistence action (inbox rule, app consent, device add) from a non-original IP. Persistence is now mandatory (inner join) instead of optional, and the retired AADSignInEventsBeta table is replaced by EntraIdSignInEvents.
Detects repeated OAuth device authorization ('device code') grant flow authentication events targeting the same user within a short window, which is indicative of an active device code phishing attempt.
Detects the Mir0Auth phishing kit sequence within a single HTTP flow: POST /task_queue.cs beacon followed by POST /context.go device-code request, both with application/octet-stream bodies. Requires both requests (flowbits) and exact path endings to limit false positives. SIDs made unique.
Detects repeated octet-stream POST polling of /window.rs (5+ in 20s, alerting once per window), matching the ~3s Mir0Auth session polling while the victim completes device login. SID de-duplicated from another rule.
Detects a successful device-code sign-in followed within 60 minutes by non-interactive replay from a different IP AND a persistence action (inbox rule, app consent, device add) from a non-original IP. Persistence is now mandatory (inner join) instead of optional, and the retired AADSignInEventsBeta table is replaced by EntraIdSignInEvents.
Detects repeated octet-stream POST polling of /window.rs (5+ in 20s, alerting once per window), matching the ~3s Mir0Auth session polling while the victim completes device login. SID de-duplicated from another rule.
The following analytic detects instances where Azure AD has blocked a user's attempt to grant consent to a risky or potentially malicious application.
This detection leverages Azure AD audit logs, focusing on user consent actions and system-driven blocks.
Monitoring these blocked consent attempts is crucial as it highlights potential threats early on, indicating that a user might be targeted or that malicious applications are attempting to infiltrate the organization.
If confirmed malicious, this activity suggests that Azure's security measures successfully prevented a harmful application from accessing organizational data, warranting immediate investigation to understand the context and take preventive measures.
This detection leverages Azure AD audit logs, focusing on user consent actions and system-driven blocks.
Monitoring these blocked consent attempts is crucial as it highlights potential threats early on, indicating that a user might be targeted or that malicious applications are attempting to infiltrate the organization.
If confirmed malicious, this activity suggests that Azure's security measures successfully prevented a harmful application from accessing organizational data, warranting immediate investigation to understand the context and take preventive measures.
This rule monitors for the addition of new credentials (secrets) to service principals or applications in an Azure/Entra ID environment. It then correlates this event with subsequent mailbox activity (such as accessing mail items, sending mail, or message binding) performed by the application within 7 days of the credential creation. This detection pattern is indicative of potential OAuth application-based persistence and mailbox data exfiltration.
Detects the Mir0Auth phishing kit sequence within a single HTTP flow: POST /task_queue.cs beacon followed by POST /context.go device-code request, both with application/octet-stream bodies. Requires both requests (flowbits) and exact path endings to limit false positives. SIDs made unique.
Page 1 of 37