Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
82 detections
Filters
Last updated
All Time
Detection languages
47
11
8
6
6
Contributors
26
15
8
6
4
Categories
42
31
28
19
16
Platforms
46
28
15
13
8
Products / Services
47
20
11
11
9
MITRE Techniques
18,115
15,635
12,576
8,388
6,215
IDS Classtypes
5
3
2
1
IDS Protocols
11
Detects potential N0va-style phishing or token-exchange abuse where a user completes a device-code authentication flow, followed immediately by an access token usage from a different IP address or device. This sequence indicates an adversary has captured the resulting token/session and is attempting to bypass multi-factor authentication (MFA) to gain unauthorized access to cloud resources.
This rule identifies potentially malicious Azure AD/Entra authentication flows by flagging interruptions during MFA (e.g., failure codes 50074, 50140 indicating MFA requirements or time-outs during suspected AiTM phishing attempts) and the usage of Device Code Grant flows, which are frequently abused by adversaries to bypass MFA and capture session tokens.
This rule detects potential adversary-in-the-middle (AiTM) or device-code authentication attacks where a user reports suspicious vishing (voice phishing) or SMS lures involving passkeys or SSO updates. The rule correlates user-reported social engineering pretexts with evidence of risky authentication flows, such as device code usage or specific authentication error codes associated with interception.
Detects outbound WebSocket upgrade requests from internal network assets to known IronToll C2 IP addresses, restricted to requests whose Host header ends in one of the disposable TLDs observed across the campaign's 73+ rotating lookalike domains (.cfd, .sbs, .shop, .icu, .buzz, etc). This narrows the alert to the campaign's actual phishing-domain pattern rather than any WebSocket traffic that happens to reach the same shared Tencent/Alibaba cloud IPs, and a per-source threshold caps repeat alerts from the same host to one per hour.
Detects potential N0va-style phishing or token-exchange abuse where a user completes a device-code authentication flow, followed immediately by an access token usage from a different IP address or device. This sequence indicates an adversary has captured the resulting token/session and is attempting to bypass multi-factor authentication (MFA) to gain unauthorized access to cloud resources.
Detects potential N0va-style phishing or token-exchange abuse where a user completes a device-code authentication flow, followed immediately by an access token usage from a different IP address or device. This sequence indicates an adversary has captured the resulting token/session and is attempting to bypass multi-factor authentication (MFA) to gain unauthorized access to cloud resources.
Detects anomalous usage of the OAuth 2.0 Device Authorization Grant flow (Device Code Flow). This flow is frequently abused by attackers to bypass MFA by tricking users into authenticating an attacker-controlled device or session, potentially leading to token theft or unauthorized access to sensitive enterprise applications.
Detects outbound WebSocket upgrade requests from internal network assets to known IronToll C2 IP addresses, restricted to requests whose Host header ends in one of the disposable TLDs observed across the campaign's 73+ rotating lookalike domains (.cfd, .sbs, .shop, .icu, .buzz, etc). This narrows the alert to the campaign's actual phishing-domain pattern rather than any WebSocket traffic that happens to reach the same shared Tencent/Alibaba cloud IPs, and a per-source threshold caps repeat alerts from the same host to one per hour.
Detects potential N0va-style phishing or token-exchange abuse where a user completes a device-code authentication flow, followed immediately by an access token usage from a different IP address or device. This sequence indicates an adversary has captured the resulting token/session and is attempting to bypass multi-factor authentication (MFA) to gain unauthorized access to cloud resources.
Detects outbound WebSocket upgrade requests from internal network assets to known IronToll C2 IP addresses, restricted to requests whose Host header ends in one of the disposable TLDs observed across the campaign's 73+ rotating lookalike domains (.cfd, .sbs, .shop, .icu, .buzz, etc). This narrows the alert to the campaign's actual phishing-domain pattern rather than any WebSocket traffic that happens to reach the same shared Tencent/Alibaba cloud IPs, and a per-source threshold caps repeat alerts from the same host to one per hour.
Detects successful authentication to Microsoft Teams or Slack where MFA was successfully completed, but the device is reported as unmanaged or non-compliant and is accompanied by sign-in risk signals. This behavior is consistent with Adversary-in-the-Middle (AitM) proxy attacks where an attacker captures credentials and session tokens, bypassing MFA, and using the hijacked session from an unrecognized device or location.
Detects Microsoft-branded phishing pages served from non-Microsoft domains, the subsequent credential submission, and the establishment of a WebSocket relay connection characteristic of the Mirage2FA Adversary-in-the-Middle (AiTM) toolkit. This rule correlates multiple stages of the phishing flow to identify active proxy-based credential and MFA bypass attempts.
Detects HTTP requests to known UNC6671 AiTM reverse-proxy phishing kit IPs on MFA/OTP interception URI paths (push-tap, duo-push, oauth2 2fa, community verify), indicating live MFA bypass.
Detects AiTM reverse-proxy pages injecting the ServerData=$Config script alongside a redirUrl/api.country.is capture script and a rewritten login.microsoftonline.com authorize path hosted on a non-Microsoft domain, used to steal OAuth2 session tokens and bypass MFA.
Detects anomalous SOAP requests to 'GetScratchCodesRequest' within the 'zimbraSync' or 'zimbraAccount' namespaces in Zimbra logs. This activity is indicative of credential harvesting attempts, specifically the exfiltration of 2FA recovery scratch codes, often associated with the ZimReaper/Ulej payload used by threat actors.
Detects browser-based network connections to URLs containing Google or Gmail branding where the resolved IP address does not match the expected Google IP address prefixes. This behavior is indicative of an Adversary-in-the-Middle (AiTM) phishing attack, where a user is being redirected to a malicious proxy server that mimics the legitimate Google login service to intercept credentials and MFA tokens.
This rule detects potential Adversary-in-the-Middle (AiTM) session hijacking by monitoring for successful multi-factor authentication (MFA) events on unmanaged or non-compliant devices, followed within 30 minutes by an API request from a geographically distant location. It includes logic to flag suspicious User-Agent strings often associated with automated AiTM tools.
This rule monitors DeviceNetworkEvents for connections to domains that match naming patterns and TLDs frequently associated with the Ghostwriter/UNC1151 threat group. The rule specifically looks for URLs containing common credential-harvesting keywords (e.g., login, verify, account) combined with specific TLDs (e.g., .digital, .icu, .cc.cd). Connections to known common public DNS providers are excluded.
Detects browser-based network connections to URLs containing Google or Gmail branding where the resolved IP address does not match the expected Google IP address prefixes. This behavior is indicative of an Adversary-in-the-Middle (AiTM) phishing attack, where a user is being redirected to a malicious proxy server that mimics the legitimate Google login service to intercept credentials and MFA tokens.
This rule monitors DeviceNetworkEvents for connections to domains that match naming patterns and TLDs frequently associated with the Ghostwriter/UNC1151 threat group. The rule specifically looks for URLs containing common credential-harvesting keywords (e.g., login, verify, account) combined with specific TLDs (e.g., .digital, .icu, .cc.cd). Connections to known common public DNS providers are excluded.
Detects successful sign-ins to Microsoft Graph where Multi-Factor Authentication (MFA) was expected but not applied or not enabled, and the authentication method used was not MFA or passwordlessMFA. This could indicate an MFA bypass or misconfiguration, allowing access to sensitive resources without the required second factor.
Page 2 of 4