Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,735 detections
Filters
Last updated
All Time
Detection languages
1,216
144
98
80
59
Contributors
496
324
298
171
55
Categories
20,438
11,829
5,872
5,150
4,864
1,735
Platforms
1,163
328
260
244
163
Products / Services
1,244
200
166
146
138
MITRE Techniques
983
923
765
247
245
CVEs
2
1
IDS Classtypes
68
33
19
10
8
IDS Protocols
90
24
15
15
Detects outbound HTTPS traffic to domains using file-sharing or cloud-sync themed keywords in combination with specific top-level domains (TLD) often associated with suspicious infrastructure. The rule specifically excludes well-known legitimate services such as OneDrive, SharePoint, Dropbox, Box, iCloud, and Google, and includes a detection threshold to minimize alerts for incidental traffic.
Detects outbound HTTPS traffic to domains using file-sharing or cloud-sync themed keywords in combination with specific top-level domains (TLD) often associated with suspicious infrastructure. The rule specifically excludes well-known legitimate services such as OneDrive, SharePoint, Dropbox, Box, iCloud, and Google, and includes a detection threshold to minimize alerts for incidental traffic.
Detects clicks on sponsored search engine ads that redirect users to Google Cloud Storage (GCS) buckets with names or paths designed to impersonate the 'Ledger' brand. These artifacts are indicative of a malvertising campaign using typosquatted storage paths to deliver malicious payloads or credential harvesting pages.
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.
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.
This rule identifies potential phishing attempts by correlating email delivery events with known suspicious sender addresses and URLs containing typosquatting domains impersonating legitimate organizations.
This rule detects when a user or admin grants consent to an unverified OAuth application that simultaneously requests sensitive delegated permissions across multiple categories (Mail, Files, Directory, and Contacts). This pattern is a strong indicator of consent phishing attacks, where adversaries trick users into granting broad permissions to a malicious application to harvest sensitive data or gain persistent access to a Microsoft 365 environment.
Detects potential Adversary-in-the-Middle (AiTM) phishing attacks by identifying a correlation between URL clicks (Safe Links) and subsequent rapid successful sign-ins by the same user. Additionally, the rule flags instances where multiple distinct users authenticate via the same IP address within a one-hour window, identifying potential infrastructure fan-out typical of proxy-based phishing kits.
Detects phishing emails that impersonate Adobe Acrobat Sign or DocuSign using invoice or RFP-themed lures. The rule identifies suspicious emails by checking for brand-related keywords in the subject and display name, identifying links that do not lead to legitimate signing domains, and identifying senders that are impersonating a brand or are newly seen in the environment.
Detects inbound phishing emails containing brand mentions for Signal, WhatsApp, or Telegram alongside lure phrases related to verification, 2FA, or device linking. The rule specifically filters for emails containing URLs while excluding messages originating from official domains associated with these services.
Detects HTTP response bodies containing indicators of 'ClickFix' social engineering lures. The rule monitors for JavaScript code designed to manipulate the user's clipboard (execCommand('copy') or clipboard.writeText) in conjunction with instructions for the user to execute the Windows Run dialog (Win+R), a common technique to trick users into executing malicious commands under the guise of solving a fake CAPTCHA or error.
This rule detects a multi-stage phishing redirection chain where a user visits a known survey platform (t.maze.co) followed immediately by a request to a Cloudflare Workers landing page (.workers.dev), a common pattern used by adversaries to obfuscate malicious delivery endpoints.
This rule detects established TLS connections to external domains that exhibit characteristics often associated with phishing campaigns. Specifically, it looks for domain names in the SNI field that contain common brand names (e.g., microsoft, google, paypal) combined with typical login-related keywords (e.g., login, verify, auth) on high-churn or suspicious Top-Level Domains (TLDs) such as .top, .xyz, or .icu.
Detects a sequence of potentially malicious local command execution (via PowerShell, cmd, or mshta) that mirrors the 'ClickFix' social engineering pattern, followed by an OAuth application consent grant or device-code authorization by the same user within a short timeframe. This behavior is indicative of an adversary attempting to bypass MFA by tricking a user into authorizing a malicious application after establishing local execution on their endpoint.
Detects network traffic associated with Adversary-in-the-Middle (AiTM) phishing kits that impersonate Microsoft and Google login pages. The rules identify the presence of specific HTML elements (like Cloudflare Turnstile anti-bot gates) and authentication session cookie headers served from non-authorized/non-official domains, indicating a reverse-proxy phishing attack.
Detects a suspected device-code phishing attack where a user visits a known malicious lure domain and shortly thereafter completes a successful Microsoft 365 device-code authentication. This rule correlates network events with sign-in logs within a 10-minute window to identify session hijacking attempts that bypass traditional MFA.
Detects a suspected device-code phishing attack where a user visits a known malicious lure domain and shortly thereafter completes a successful Microsoft 365 device-code authentication. This rule correlates network events with sign-in logs within a 10-minute window to identify session hijacking attempts that bypass traditional MFA.
This rule performs a retrospective sweep across Microsoft Defender XDR data sources (DeviceFileEvents, DeviceProcessEvents, DeviceNetworkEvents, and EmailEvents) to identify activity associated with the Star Blizzard (COLDRIVER) campaign. It monitors for specific file hashes, file names, known C2 IP addresses and domains, malicious URL patterns, and known phishing email sender addresses identified in threat intelligence reporting.
This rule performs a retrospective sweep across Microsoft Defender XDR data sources (DeviceFileEvents, DeviceProcessEvents, DeviceNetworkEvents, and EmailEvents) to identify activity associated with the Star Blizzard (COLDRIVER) campaign. It monitors for specific file hashes, file names, known C2 IP addresses and domains, malicious URL patterns, and known phishing email sender addresses identified in threat intelligence reporting.
Detects incoming email messages where the Reply-To header address domain differs from the Sender From address domain. This technique is commonly used in phishing attacks to redirect victim replies to an attacker-controlled mailbox while maintaining a spoofed appearance in the original sender field.
This rule detects inbound email messages where the SPF check passes for a specific domain (osc-cdn.com) or uses specific infrastructure (Migadu), but the DMARC check fails due to misalignment between the envelope domain and the From header. This pattern is indicative of email spoofing or domain impersonation attempts where the attacker abuses misconfigured SPF/DMARC policies (p=none) to facilitate spearphishing.
Page 7 of 83