Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
3,141 detections
Filters
Last updated
All Time
Detection languages
2,292
246
196
179
104
Contributors
738
670
569
284
148
Categories
1,163
747
693
623
440
Platforms
39,921
7,246
6,535
3,864
3,627
3,141
Products / Services
2,849
742
268
187
182
MITRE Techniques
871
856
778
768
738
CVEs
13
5
2
1
1
IDS Classtypes
3
2
2
2
1
IDS Protocols
9
1
1
Detects potential help-desk impersonation or social engineering activity involving account credential or MFA method resets, followed shortly by a sign-in from an unknown device or geography. The rule excludes activity tied to established ticketing systems or standard automated password expiration processes.
Detects an authentication pattern characteristic of credential compromise, consisting of a burst of failed authentication attempts against an account within a short window, followed immediately by a successful sign-in from an anomalous or new device/location. This pattern is indicative of brute-force or credential spraying followed by successful validation and potential lateral movement.
This rule detects various malicious indicators of compromise (IOCs) across multiple telemetry sources, including DNS queries, web network traffic, file executions, process creation, and email activity. It monitors for interactions with known malicious domains, URLs, file hashes, and specific sender email addresses to identify potential malware distribution or C2 activity.
This rule detects various malicious indicators of compromise (IOCs) across multiple telemetry sources, including DNS queries, web network traffic, file executions, process creation, and email activity. It monitors for interactions with known malicious domains, URLs, file hashes, and specific sender email addresses to identify potential malware distribution or C2 activity.
This rule detects various malicious indicators of compromise (IOCs) across multiple telemetry sources, including DNS queries, web network traffic, file executions, process creation, and email activity. It monitors for interactions with known malicious domains, URLs, file hashes, and specific sender email addresses to identify potential malware distribution or C2 activity.
This rule detects various malicious indicators of compromise (IOCs) across multiple telemetry sources, including DNS queries, web network traffic, file executions, process creation, and email activity. It monitors for interactions with known malicious domains, URLs, file hashes, and specific sender email addresses to identify potential malware distribution or C2 activity.
This rule performs an indicator of compromise (IOC) sweep for activities associated with the TOPHIT / VHX Harvester / @prime0 NPM typosquatting campaign. It detects known malicious C2 network connections (IPs and URLs), file artifacts (hashes) on endpoints, and suspicious email activity involving specific operator email addresses.
This rule performs an indicator of compromise (IOC) sweep for activities associated with the TOPHIT / VHX Harvester / @prime0 NPM typosquatting campaign. It detects known malicious C2 network connections (IPs and URLs), file artifacts (hashes) on endpoints, and suspicious email activity involving specific operator email addresses.
This rule detects activity involving known malicious indicators of compromise (IOCs), including specific IP addresses, domains, and file hashes. It monitors network connections, file system activity, process execution, and email attachments, filtering out common security tools to reduce noise.
Detects phishing messages that deliberately mix writing systems/scripts/homoglyphs in the Subject line as ONE corroborating signal within a broader, multi-signal phishing pattern. Hardened against false positives: brand/product tokens (e.g. Microsoft, PayPal) are stripped before the Latin-script check so a lone brand mention in non-Latin correspondence doesn't count as mixed-script; a weighted score (script-mixing=2, homoglyph=3, high-confidence phishing vocabulary=2, threshold=6) means no two of the three signal categories can reach the threshold alone — all three must co-occur before the rule fires.
Detects phishing messages that mix writing systems/scripts/homoglyphs in the Subject line as one corroborating signal within a broader, multi-signal phishing pattern.
This rule detects potential phishing attempts where the sender's display name is formatted as an email address and the sender's domain uses a capital 'I' character to mimic a well-known service provider (typosquatting/homoglyph attack), such as 'gmaiI.com'. It identifies discrepancies between the actual sender domain and the normalized domain name after character replacement.
Detects patterns associated with the TeamFiltration backdoor module, specifically unauthorized OneDrive/SharePoint file modifications occurring shortly after an authentication from a previously unseen device/IP. The rule flags file changes (modifications, deletions, or renames) involving potential executable or script extensions, or those performed by the OneDrive SyncEngine app from a new source.
This rule monitors for indicators of compromise (IOCs) associated with the TrustSink rogue MFA provider, specifically tracking the domain 'trident-sip-filter.ngrok-free.dev' and its associated OIDC discovery path. It aggregates signals from sign-in logs, audit logs, DNS queries, and network proxy traffic to identify attempts to interact with this malicious infrastructure.
Detects modifications to Microsoft Entra ID applications or service principals involving the addition or configuration of 'externalauthprovider' redirect URIs or properties. This behavior is indicative of an attacker attempting to establish a malicious federated identity or persistence mechanism by manipulating application configuration to use an adversary-controlled authentication provider.
Detects the multi-stage Microsoft cloud identity compromise chain reported by Microsoft Security Research (September 2026): a victim completes a successful Entra ID device-code sign-in (often induced by passkey-themed device-code phishing), the same identity's authentication/security info is registered or changed (MFA/passkey persistence) within 60 minutes (deduplicated to the earliest such event per sign-in), followed within 120 minutes by a burst of at least 25 successful, delegated-context Microsoft Graph API calls (Scopes claim populated, i.e. user-delegated permissions rather than pure application/client-credential access) spanning at least 3 distinct resource paths, exhibiting reconnaissance (>=5 requests against /users, /groups, /directoryRoles, /roleManagement, /applications, /servicePrincipals, /organization) and/or collection (>=10 requests against /messages, /mailFolders, /attachments, /drive, /drives, /sites, /lists, /search) patterns. Restricting to delegated (Scopes-bearing) Graph calls and requiring resource-path breadth removes the two largest false-positive sources: service-principal/application-only automation jobs (Roles-only tokens) and single-endpoint polling tools. Pure behavioral correlation across SigninLogs, AuditLogs, and MicrosoftGraphActivityLogs - no static IOCs. Flags whether Graph activity originated from an IP different from the original device-code sign-in IP as a strong pivot/session-reuse indicator.
Hunts network, HTTP, and email-URL telemetry for known ARToken infrastructure (operator backend IPs and phishing/panel domains). Bounded to a 30-day lookback and tiers matches by confidence: domain hits are high-confidence (attacker-registered infrastructure), while IP hits are medium-confidence since the IPs sit on shared DigitalOcean hosting that can be reassigned to unrelated tenants once ARToken's infrastructure is taken down. Empty/unparsed indicator fields are excluded to avoid spurious matches in the HTTP event parsing branch. No known file hashes are associated with this intel.
Detects potential insider threats or departing employees by correlating abnormal bulk data downloads from cloud repositories (SharePoint/OneDrive/Box/etc.) with subsequent sensitive data access and exfiltration signals. It uses baseline behavioral profiling, requires a threshold of sensitive file interactions, and mandates high-confidence exfiltration indicators (removable media usage, suspicious external domains, or multiple combined destination events) to reduce noise. Archive/staging activity is used as an optional confidence booster.
This rule correlates multiple telemetry sources to detect a sophisticated cloud identity compromise chain. It identifies suspicious MFA-satisfied logins (potentially via Adversary-in-the-Middle) followed by the granting of high-risk OAuth application consents, the creation of persistent mailbox rules for hiding or forwarding communications, and finally mass data access or exfiltration from the user's account.
Detects potential insider threats or departing employees by correlating abnormal bulk data downloads from cloud repositories (SharePoint/OneDrive/Box/etc.) with subsequent sensitive data access and exfiltration signals. It uses baseline behavioral profiling, requires a threshold of sensitive file interactions, and mandates high-confidence exfiltration indicators (removable media usage, suspicious external domains, or multiple combined destination events) to reduce noise. Archive/staging activity is used as an optional confidence booster.
For years, when hunting phishing emails, I have mainly focused on what the user sees inside of it. But I think AI agents are going to change this.
An email may soon have two audiences: Human + AI Agent. And they may not always see exactly the same thing.
In this new KQL, I explore a simple example: invisible Unicode characters. Microsoft and Micro<U+200B>soft may look the same to us, but not necessarily to a detection, filter, parser or AI agent. For attackers, this difference can be interesting as a way to obfuscate content and potentially evade keyword-based detections or other systems processing the text.
I hunt these patterns in email and add context around them. Because attackers will not only write emails for us. They will(are) start writing emails for our agents too.
An email may soon have two audiences: Human + AI Agent. And they may not always see exactly the same thing.
In this new KQL, I explore a simple example: invisible Unicode characters. Microsoft and Micro<U+200B>soft may look the same to us, but not necessarily to a detection, filter, parser or AI agent. For attackers, this difference can be interesting as a way to obfuscate content and potentially evade keyword-based detections or other systems processing the text.
I hunt these patterns in email and add context around them. Because attackers will not only write emails for us. They will(are) start writing emails for our agents too.
Page 11 of 150