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,936
7,266
6,535
3,866
3,647
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
Suspicious Inbox Rule Creation
Cortex XDR
Detects creation of malicious Exchange Online inbox rules used for BEC and account-takeover persistence. Normalizes both client logging paths, OWA (New-InboxRule) and Outlook desktop (UpdateInboxRules + AddMailboxRule), and flags rules with hidden names (., ,, blank, 1 to 2 chars), external forwarding, or move/delete actions paired with payment (ach, wire, invoice) or security-notification (password, MFA, Microsoft) keywords, especially with stop-processing/exit-after-execution set.
This rule detects potential phishing emails that successfully pass through to the mailbox despite failing SPF, DKIM, or DMARC authentication checks. It specifically flags emails that claim to originate from high-value vendor domains (e.g., DocuSign, Zoom, Adobe, RingCentral) but contain links to external domains that do not match the alleged sender's domain, which is a common indicator of brand impersonation or credential harvesting campaigns.
During my vacation, I've been enjoying conversations with people from different countries about their national teams and the World Cup. What I don't expect (although it certainly can happen) is a Mexican speaking Japanese, a Spaniard speaking Russian, or an Egyptian speaking Spanish. Yet, this is becoming more and more common, and I love it. Our world is becoming increasingly connected and multicultural.
However, the same logic doesn't always apply to emails.
That thought inspired me to build a KQL query that I'll explore further after my break, but I wanted to share it now. The idea is detect emails where the language doesn't match the expected language(s) of the sender's country. While this isn't a detection by itself, it can be a valuable hunting signal when combined with other indicators.
KQL Query Filter options:
EmailCount < X → Filter based on the number of emails observed.
Country !in ("Spain") → Exclude countries with a higher false-positive ratio.
SenderDomains !in ("Domain1","Domain2") → Exclude trusted sender domains.
However, the same logic doesn't always apply to emails.
That thought inspired me to build a KQL query that I'll explore further after my break, but I wanted to share it now. The idea is detect emails where the language doesn't match the expected language(s) of the sender's country. While this isn't a detection by itself, it can be a valuable hunting signal when combined with other indicators.
KQL Query Filter options:
EmailCount < X → Filter based on the number of emails observed.
Country !in ("Spain") → Exclude countries with a higher false-positive ratio.
SenderDomains !in ("Domain1","Domain2") → Exclude trusted sender domains.
Detects successful Azure AD sign-in events authenticated via the device code flow that subsequently access Microsoft 365 resources such as Outlook, SharePoint, OneDrive, or Teams. This pattern is consistent with post-compromise use of OAuth tokens obtained through device-code phishing.
Detects HTTP POST requests to the Microsoft login endpoint for OAuth2 tokens using the client_credentials grant type, where the request body contains evidence of hardcoded client_secret parameters and specific scopes. This behavior often indicates an application or script with embedded, potentially leaked or insecurely stored, credentials being used to authenticate against Microsoft cloud services.
This rule aggregates SharePoint activity logs for a specific user within a defined timeframe. It groups activities by operation and file, intended to support investigation into potential mass file access or data staging behavior by a specific user in SharePoint.
Detects successful Azure AD sign-in events authenticated via the device code flow that subsequently access Microsoft 365 resources such as Outlook, SharePoint, OneDrive, or Teams. This pattern is consistent with post-compromise use of OAuth tokens obtained through device-code phishing.
Detects successful Azure AD sign-in events authenticated via the device code flow that subsequently access Microsoft 365 resources such as Outlook, SharePoint, OneDrive, or Teams. This pattern is consistent with post-compromise use of OAuth tokens obtained through device-code phishing.
This rule analyzes Microsoft Entra (Azure AD) sign-in logs over a 30-day period for access to sensitive administrative applications (e.g., Azure Portal, Microsoft Intune, Defender). It flags user-application-IP sessions that exhibit unusual characteristics, such as login successes following failures, access from multiple geographic locations, or the use of multiple client types, which may indicate account compromise or unauthorized access.
Detects GET requests to the Microsoft Graph API 'organization' endpoint, often used by malicious tools to validate a tenant environment or gather metadata before initiating C2 communication or secondary stages of an attack.
Detects Microsoft Graph API requests targeting user mailboxes within a tenant or organization structure likely associated with Israeli legal entities, identified by .co.il domain patterns in the Request URI.
This rule detects potential Adversary-in-the-Middle (AiTM) phishing attacks targeting Microsoft 365. It monitors for suspicious network connections to known Evilginx-style subdomains (e.g., owa, sso, secure, billing) that proxy traffic to login.microsoftonline.com, followed immediately by a successful user login event on the same host. This pattern indicates an active session hijacking attempt designed to capture session cookies like ESTSAUTH and ESTSAUTHPERSISTENT.
Detects Microsoft 365 Outlook calendar events with highly anomalous future dates (specifically the year 2050) or specific subject patterns, which are indicative of a command-and-control (C2) communication channel established via calendar item properties.
Detects suspicious modifications or deletions of Outlook calendar events using the Microsoft Graph API, potentially indicating the use of calendar infrastructure as a command-and-control (C2) heartbeat or exfiltration channel. The rule monitors for specific pattern-based event updates or deletions following calendar enumeration, which is a technique used to maintain persistent communication or exfiltrate small amounts of data.
Detects anomalous sign-in behavior where a single unique token identifier is used from multiple IP addresses, countries, or devices within a short timeframe (less than one hour). This pattern is often indicative of session token theft, where an adversary uses an exfiltrated token to authenticate from a different location or device, bypassing standard credential-based authentication.
Detects GET requests to the Microsoft Graph API 'organization' endpoint, often used by malicious tools to validate a tenant environment or gather metadata before initiating C2 communication or secondary stages of an attack.
Detects Microsoft Graph API requests targeting user mailboxes within a tenant or organization structure likely associated with Israeli legal entities, identified by .co.il domain patterns in the Request URI.
Detects anomalous activity in Microsoft 365 calendar events where potential C2 data is exfiltrated or synchronized. This is identified by the creation or modification of calendar events containing suspicious file names (e.g., File0.txt, File1.txt) or specific command-and-control markers within the event subject.
Detects Microsoft 365 Outlook calendar events with highly anomalous future dates (specifically the year 2050) or specific subject patterns, which are indicative of a command-and-control (C2) communication channel established via calendar item properties.
Detects Microsoft 365 Outlook calendar events being updated via Graph API where the subject is changed to a suspicious C2-like string (e.g., 'Boss Report ID:' or 'Boss update ID:'). This behavior is consistent with attackers using Outlook calendar events as a covert communication channel or for command and control signaling.
This rule detects incoming emails with subject lines containing keywords associated with invoice, payment, or banking detail changes. These patterns are highly characteristic of Business Email Compromise (BEC) and social engineering campaigns designed to redirect financial transactions to fraudulent accounts.
Page 83 of 150