Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
461 detections
Filters
Last updated
All Time
Detection languages
276
67
44
26
23
Contributors
167
111
62
17
9
Categories
238
219
140
83
78
Platforms
338
217
143
29
23
Products / Services
286
157
50
38
27
MITRE Techniques
18,123
15,639
12,581
8,394
6,215
CVEs
13
5
3
2
1
IDS Classtypes
5
3
2
IDS Protocols
9
This analytic query detects potential phishing compromise activity by correlating URL click events from Defender for Office 365 with Sign-in device code authentication logs.
This detection identifies instances where a user grants consent to an OAuth application that has very low prevalence within the tenant and requests high-risk permissions. This pattern is a strong indicator of a targeted consent phishing attack, as malicious apps often target a small number of users to gain initial access.
With OAuth 2.0 Device Code Flow phishing campaigns actively targeting M365 environments in financial services and beyond, I built a cross-phase KQL detection rule that moves beyond the obvious deviceCode protocol filter — because the real damage happens in tables most hunts never look at.
The rule correlates three phases across both SigninLogs and AADNonInteractiveUserSignInLogs:
Phase 1 catches victim-side device code authentications, filtering out primaryRefreshToken (enrolled devices) and known low-risk resources to cut noise at the source.
Phase 2 surfaces non-interactive single-factor token replay activity — this is where the attacker's stolen OAuth token actually appears, silently blending into background API traffic.
Phase 3 identifies post-compromise Graph/mail resource access across anomalous IP counts — the data exfiltration and BEC staging layer.
The key design decisions that make it production-ready: a cross-phase inner join so only users appearing in Phase 1 and Phase 2 surface at all, a MinutesToReplay temporal constraint (>= 0 and <= 2880) to eliminate false correlations where phases are coincidental rather than causal, and a composite risk score with banded severity output.
Tested against 90 days of real tenant data. Came back clean after tuning — which is the outcome you want before deploying as a scheduled analytics rule.
The rule correlates three phases across both SigninLogs and AADNonInteractiveUserSignInLogs:
Phase 1 catches victim-side device code authentications, filtering out primaryRefreshToken (enrolled devices) and known low-risk resources to cut noise at the source.
Phase 2 surfaces non-interactive single-factor token replay activity — this is where the attacker's stolen OAuth token actually appears, silently blending into background API traffic.
Phase 3 identifies post-compromise Graph/mail resource access across anomalous IP counts — the data exfiltration and BEC staging layer.
The key design decisions that make it production-ready: a cross-phase inner join so only users appearing in Phase 1 and Phase 2 surface at all, a MinutesToReplay temporal constraint (>= 0 and <= 2880) to eliminate false correlations where phases are coincidental rather than causal, and a composite risk score with banded severity output.
Tested against 90 days of real tenant data. Came back clean after tuning — which is the outcome you want before deploying as a scheduled analytics rule.
This rule detects attempts to grant consent to OAuth applications, which could indicate an illicit consent grant attack. It specifically looks for successful operations related to consenting to applications, adding app role assignments to service principals, adding delegated permission grants, or adding OAuth2PermissionGrants within audit logs. The rule extracts details such as the target application, the user who consented, their initiating IP address, and the permissions granted.
This rule detects sign-ins by Azure Managed Identities where the token was likely obtained via the Instance Metadata Service (IMDS). It identifies these sign-ins by looking for 'ImdsIdentityProvider' in the UserAgent or 'Imds' in the ClientCredentialType within AADManagedIdentitySignInLogs. This activity could indicate lateral movement through abuse of managed identities attached to virtual machines.
Detects successful POST requests to better-auth API key creation or update endpoints that appear to be unauthenticated. This pattern is indicative of exploitation of CVE-2025-61928, where an attacker can create or modify API keys for any user without a valid session.
Detects when a Managed Identity successfully authenticates via the Azure Instance Metadata Service (IMDS) and subsequently performs administrative or enumeration actions within a short timeframe. This pattern can indicate an attacker has compromised a resource (e.g., a Virtual Machine) and is using its Managed Identity to move laterally or access other resources within the Azure environment. The rule correlates successful IMDS-based sign-ins with subsequent activities such as running commands on virtual machines, or listing/getting secrets and keys from Key Vaults, or other general administrative/alert-generating activities.
Detects when a VM Run Command is executed successfully, followed by the VM's Managed Identity authenticating to Azure Resource Manager. This pattern may indicate an attacker using Run Command to steal MI tokens for lateral movement.
Detects potential exploitation of CVE-2026-25253, a 1-click RCE in OpenClaw, by identifying the 'gatewayUrl' query parameter in HTTP traffic. This parameter is used to hijack authentication tokens.
Detects a sequence of events where an AWS IAM Role Trust Policy or a Role's managed policy is modified (UpdateAssumeRolePolicy, PutRolePolicy) and is immediately followed by a successful assumption of that role (AssumeRole, AssumeRoleWithSAML, etc.) within a 10-minute window. This behavior is characteristic of an attacker setting up a backdoor or escalating privileges by granting a new, unauthorized principal (user, service, or account) permission to assume a critical role.
Multiple threat actors are compromising Microsoft 365 accounts in phishing attacks that leverage the OAuth device code authorization mechanism.
Attackers trick victims into entering a device code on Microsoft’s legitimate device login page, unknowingly authorizing an attacker-controlled application and granting them access to the target account without stealing credentials or bypassing multi-factor authentication (MFA).
Attackers trick victims into entering a device code on Microsoft’s legitimate device login page, unknowingly authorizing an attacker-controlled application and granting them access to the target account without stealing credentials or bypassing multi-factor authentication (MFA).
Detects when an AWS IAM role is assumed by an identity that has not used that specific role within a historical 7-day window. This behavior can indicate lateral movement, privilege escalation, compromised credentials, or a deviation from normal workload patterns. The rule excludes AWS internal service identities to focus on human and workload actors.
Detects potentially suspicious events involving "GetSigninToken" in AWS. An adversary using the "aws_consoler" tool can leverage this console API to create temporary federated credentials, which can help obfuscate the compromised AWS credential (the original access key) and enable pivoting from the AWS CLI to console sessions without requiring MFA, using the newly issued access key.
This rule identifies suspicious usage of the AWS Security Token Service (STS) `AssumeRole` API call. Specifically, it looks for instances where the `userIdentity.type` is `AssumedRole` and the `userIdentity.sessionContext.sessionIssuer.type` is `Role`. This pattern indicates that an AWS role is being assumed by another role, which could be a legitimate administrative action but also a technique used by attackers for lateral movement and privilege escalation within an AWS environment. Attackers might use `AssumeRole` to switch to roles with higher privileges or to move between different accounts or services after gaining initial access.
This rule identifies the suspicious use of the AWS Security Token Service (STS) API call `GetSessionToken`. This API call is used to request temporary, limited-privilege credentials for an IAM user or role. Attackers may use `GetSessionToken` to generate temporary tokens to move laterally within an AWS environment or escalate privileges by assuming roles with broader permissions. The rule specifically looks for `GetSessionToken` calls made by an `IAMUser`.
Detects multiple Event ID 4648 logon attempts using the same target account but from different source accounts within a short time window. This behavior may indicate lateral movement, credential stuffing, or misuse of shared credentials. By correlating explicit credential use across users, it helps identify possible compromise or abuse of privileged accounts.
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 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.
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.
Detects when an application or service principal performs sensitive configuration changes, likely via the Microsoft Graph API. This can indicate an attacker using a compromised or malicious application for persistence (adding credentials), privilege escalation (adding owners), or defense evasion (modifying Conditional Access policies). This aligns with the "Consent & Compromise" research where attackers abuse application permissions.
Purpose: Hunts for risky OAuth applications in Microsoft 365 with overly permissive Microsoft Graph permissions.
Key Actions:
Finds enabled OAuth apps and retrieves their latest state (arg_max).
Expands permissions and flags sensitive ones (e.g., Mail.Send, Files.ReadWrite.All, User.ReadWrite.All, Sites.ReadWrite.All).
Notes publisher verification, origin, and last modification date.
Marks risky apps via HasRiskyPermissions flag.
Use Cases: Detects malicious consent grant phishing, overprivileged third-party apps, and integrations that could enable data theft or long-term access.
Key Actions:
Finds enabled OAuth apps and retrieves their latest state (arg_max).
Expands permissions and flags sensitive ones (e.g., Mail.Send, Files.ReadWrite.All, User.ReadWrite.All, Sites.ReadWrite.All).
Notes publisher verification, origin, and last modification date.
Marks risky apps via HasRiskyPermissions flag.
Use Cases: Detects malicious consent grant phishing, overprivileged third-party apps, and integrations that could enable data theft or long-term access.
Page 21 of 22