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 command-line execution that attempts to access GitHub authentication tokens outside of expected CI/CD or development environments. This could indicate an attempt to steal or misuse credentials.
Detects unauthorized processes attempting to access or interact with the dynamically generated Azure Arc identity token .key files. These files reside in a protected directory and are limited to SYSTEM-level ARC agent processes
(CVE-2026-26117)
(CVE-2026-26117)
Detects the creation of 'format-results.txt' on a system, which is used by the malicious GitHub Actions workflow injected by the Checkmarx worm to store serialized GitHub repository secrets.
Detects process creation with a renamed BrowserCore.exe (used to extract Azure tokens)
Multi-layered detection for two linked March 2026 threat campaigns identified by ANY.RUN and Objective-See:
**Campaign 1 — EvilTokens (OAuth Device Code Phishing)**
Abuses Microsoft's OAuth 2.0 Device Code authentication flow to silently hijack enterprise accounts. Attackers trick users into entering a device code on Microsoft's legitimate login page, granting the attacker a valid OAuth token — no credentials stolen, no MFA bypass needed. Over 180 phishing URLs detected in a single week. Targets: Technology, Education, Manufacturing, and Government sectors (US & India focus).
**Campaign 2 — AMOS Stealer (macOS ClickFix)**
Distributed via a trojanized disk image (Clearl_AI.dmg) posing as an AI tool installer. Harvests browser credentials, macOS Keychain, cryptocurrency wallets (256 extensions), Apple Notes, and sensitive files. Deploys a persistent backdoor via ~/.mainhelper (WebSocket reverse shell) and LaunchAgent persistence (com.apple.mdworker.plist / com.apple.systemupdate). Kills security tools (Little Snitch, BlockBlock, Lulu) and validates stolen passwords against the keychain.
1. EvilTokens — Detects Device Code OAuth sign-ins from suspicious infrastructure (workers[.]dev phishing domains)
2. AMOS IOC Network Sweep — Identifies connections to known C2/payload domains (laislivon.com, rvdownloads.com)
3. AMOS Behavioral — Detects ClickFix-style base64 curl-to-shell execution, /tmp/helper payloads, and LaunchAgent persistence artifacts
4. Cross-platform IOC file hash matching across endpoints
**Campaign 1 — EvilTokens (OAuth Device Code Phishing)**
Abuses Microsoft's OAuth 2.0 Device Code authentication flow to silently hijack enterprise accounts. Attackers trick users into entering a device code on Microsoft's legitimate login page, granting the attacker a valid OAuth token — no credentials stolen, no MFA bypass needed. Over 180 phishing URLs detected in a single week. Targets: Technology, Education, Manufacturing, and Government sectors (US & India focus).
**Campaign 2 — AMOS Stealer (macOS ClickFix)**
Distributed via a trojanized disk image (Clearl_AI.dmg) posing as an AI tool installer. Harvests browser credentials, macOS Keychain, cryptocurrency wallets (256 extensions), Apple Notes, and sensitive files. Deploys a persistent backdoor via ~/.mainhelper (WebSocket reverse shell) and LaunchAgent persistence (com.apple.mdworker.plist / com.apple.systemupdate). Kills security tools (Little Snitch, BlockBlock, Lulu) and validates stolen passwords against the keychain.
1. EvilTokens — Detects Device Code OAuth sign-ins from suspicious infrastructure (workers[.]dev phishing domains)
2. AMOS IOC Network Sweep — Identifies connections to known C2/payload domains (laislivon.com, rvdownloads.com)
3. AMOS Behavioral — Detects ClickFix-style base64 curl-to-shell execution, /tmp/helper payloads, and LaunchAgent persistence artifacts
4. Cross-platform IOC file hash matching across endpoints
Detects when a configuration change is made to an applications URI.
URIs for domain names that no longer exist (dangling URIs), not using HTTPS, wildcards at the end of the domain, URIs that are no unique to that app, or URIs that point to domains you do not control should be investigated.
URIs for domain names that no longer exist (dangling URIs), not using HTTPS, wildcards at the end of the domain, URIs that are no unique to that app, or URIs that point to domains you do not control should be investigated.
Detects creation of default named pipes used by the Koh tool
Detects curl or wget accessing the default Kubernetes service account token path. Adapted from Unit 42 reporting on Slow Pisces and React2Shell (CVE-2025-55182) campaigns.
Detects attempts to access or exfiltrate the default Kubernetes service account token file using web utilities like curl or wget. This activity is commonly observed in attacks by threat actors such as Slow Pisces to escalate privileges or move laterally from a compromised pod into backend cloud infrastructure.
Detects unauthorized processes attempting to access or interact with the dynamically generated Azure Arc identity token .key files. These files reside in a protected directory and are limited to SYSTEM-level ARC agent processes
This rule detects suspicious device registration activity in Microsoft 365. It correlates users who have recently visited Microsoft device login or OAuth2 device authentication URLs with subsequent device registration events in Azure AD. This could indicate an adversary attempting to register a new device to bypass MFA or gain persistent access, potentially through device code phishing.
This rule detects emails containing URLs that initiate OAuth 2.0 authorization flows for Microsoft or Google, and where the URL contains a known malicious OAuth ID. This is indicative of an OAuth phishing attempt, where attackers try to trick users into granting access to malicious applications.
This detection identifies the consent or addition of an OAuth application that may be impersonating a legitimate, well-known brand. The logic flags applications whose names mimic major brands (e.g., Adobe, Microsoft, DocuSign) and use a reply URL hosted on a shared or free platform, a common tactic in consent phishing campaigns.
This rule is meant to help analysts quickly spot a high-confidence indicator related to Google AuraInspector Salesforce Aura Audit. It is written to be easy to understand and to keep false alarms low by focusing on a very specific match: an HTTP POST to a Salesforce /aura endpoint that includes specific Aura method strings. A match does not automatically prove an attacker is currently active, and it does not prove a file was executed, but it does mean the event is important because it lines up with a public threat intelligence source. When this triggers, start by identifying the host, user, and timeframe involved, then decide whether the activity is expected for that system. If it is unexpected, preserve the related logs and any files, and look for nearby events that could explain how the indicator appeared, such as a download, a new process, or a new connection. If the same indicator appears on multiple systems, treat it as a scoping signal and expand the investigation window. Use the reference link (https://cloud.google.com/blog/topics/threat- intelligence/auditing-salesforce-aura-data-exposure) to document where the indicator came from and to support incident notes and reporting.
Identifies consent grants to OAuth applications with Application IDs matching known malicious campaigns. The IOCs are sourced from Wiz Research on campaigns from 2019-2025 involving brand impersonation and consent phishing.
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.
Detects when a user grants consent to an application that has not been seen in the environment before. This rule baselines known applications over a 30-day period and alerts on any new application consent grants or service principal additions within the last day that are not part of the baseline or an explicit allow list.
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 processes other than known Microsoft identity components accessing sensitive authentication token directories (IdentityCache or OneAuth). Threat actors use this technique to steal session tokens to bypass MFA and maintain persistent access to cloud environments.
This detection monitors for the creation or deletion of files within the TokenBroker and AAD Broker Plugin cache folders. These folders store authentication tokens that, if accessed or manipulated by an unauthorized process, could indicate credential theft activity.
Page 33 of 37