Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
837 detections
Filters
Last updated
All Time
Detection languages
672
42
37
25
22
Contributors
227
154
141
123
42
Categories
20,440
11,814
5,871
5,145
4,864
837
Platforms
747
156
83
82
41
Products / Services
773
85
73
71
50
MITRE Techniques
375
287
237
187
184
CVEs
5
1
1
1
1
IDS Classtypes
3
3
2
IDS Protocols
5
3
This rule detects potential spearphishing attempts targeting high-value individuals (CEO, CFO, IT Admin) within an organization. It looks for emails sent to these individuals with subjects commonly associated with financial phishing or social engineering lures, such as "Invoice," "Wire Transfer," "Payment," "Urgent," or "Purchase Order." The rule also checks if these emails contain attachments, which is a common vector for delivering malware or credential harvesting documents in phishing campaigns. It summarizes the attempts by sender, recipient, and day, counting the number of attempts and listing the attachments.
This rule detects the creation of new transport rules within Exchange Online. Adversaries may create malicious transport rules to forward emails, bypass security controls, or exfiltrate data. Monitoring the creation of new transport rules can help identify suspicious activity.
Identifies a risky sign-in to a known O365 landing page followed shortly by the creation of an inbox rule that deletes messages or moves them to junk/trash. This pattern frequently indicates account compromise (e.g., BEC or AiTM) attempting to hide malicious activity.
This rule detects a high volume (5 or more within an hour) of emails from the same sender containing compressed attachments (.zip, .rar, .7z) and subjects indicating documents, invoices, or reports. This pattern can be indicative of phishing campaigns attempting to deliver malware or gather information.
This rule detects an 'Email Subscription Bomb' attack, where an attacker automates sign-ups to various services using a victim's email address. The goal is to flood the victim's inbox with confirmation emails, potentially causing a denial of service or distracting them from other malicious activities. The rule specifically looks for SMTP traffic to port 25 containing the phrase 'confirm your subscription' (case-insensitive) and triggers an alert if this content is seen 50 times within 60 seconds from the same destination IP address.
This rule detects when a single user removes permissions from 5 or more mailboxes within a one-hour window in an Exchange environment. This activity could indicate an attempt to cover tracks or disrupt access to mailboxes by an attacker.
This rule detects spearphishing emails sent over SMTP that contain an Office document attachment. It specifically looks for emails with a 'Content-Type: application/' header, a 'filename=' attribute, and the '.docx' extension in the content, indicating a Microsoft Word document.
This rule detects a high volume (5 or more within an hour) of emails from the same sender containing compressed attachments (.zip, .rar, .7z) and subjects indicating documents, invoices, or reports. This pattern can be indicative of phishing campaigns attempting to deliver malware or gather information.
Detects the creation or modification of Exchange inbox rules used by Kali365 designed to suppress security alerts by moving, deleting, or marking as read emails containing specific keywords. This technique is often used by adversaries to hide their activities or prevent detection.
Detects inbound emails originating from 'azure-noreply@microsoft.com' with subjects that typically indicate financial transactions (e.g., 'Invoice Paid', 'Payment Reference') or system alerts (e.g., 'MemorySpike', 'DiskFull'). This pattern could be indicative of phishing attempts leveraging a seemingly legitimate sender to trick recipients.
This rule detects potential spearphishing attempts targeting high-value individuals (CEO, CFO, IT Admin) within an organization. It looks for emails sent to these individuals with subjects commonly associated with financial phishing or social engineering lures, such as "Invoice," "Wire Transfer," "Payment," "Urgent," or "Purchase Order." The rule also checks if these emails contain attachments, which is a common vector for delivering malware or credential harvesting documents in phishing campaigns. It summarizes the attempts by sender, recipient, and day, counting the number of attempts and listing the attachments.
This rule detects emails containing archive file attachments (zip, rar, 7z). It summarizes the count of such archives per sender, recipient, and file name over a daily period. The rule specifically looks for instances where at least one archive is present in an email.
Detects a temporal pattern characteristic of CVE-2026-42897 XSS exploitation: an OWA user reads a message (via Bind, OpenMessage, or similar EWS/OWA endpoints), and within 60 seconds, the same session issues a POST request to create or modify an inbox rule. This rapid succession from the same session cookie indicates programmatic action (XSS-driven JavaScript) rather than human-driven workflow. The rule correlates events by client IP and username within a 60-second window.
This rule detects potential thread hijacking phishing attempts where an email with a subject starting with 'RE:' or 'FW:' (indicating a reply or forward) contains an attachment with a suspicious file extension (.js, .hta, or .lnk). The rule specifically looks for these emails originating from domains outside of a predefined list of trusted domains and flags instances where more than one such suspicious reply/forward is sent from the same sender with the same subject and filename within a day, suggesting a coordinated attack.
This rule detects the creation or modification of Exchange inbox rules with highly suspicious or obfuscated names. Adversaries often create inbox rules with short, non-descriptive, or special character names (e.g., '.', '...', ';') to forward, redirect, or delete emails, facilitating data exfiltration or maintaining persistence. The rule specifically looks for rule names that are very short (less than 3 characters), empty, or match a predefined list of suspicious names.
If you are in a country where there is more than one local language, like me in Switzerland, it is challenging to create detections based on subjects because you can have them in multiple languages. Therefore, focusing on the value odspnotify inside of InternetMessageId - which does not change based on the language - helps to detect cases.
This one is related to OneTimePassCode and is useful to identify if the code is sent to other domains, which could mean that a forwarding rule has been configured or some other suspicious activity.
This one is related to OneTimePassCode and is useful to identify if the code is sent to other domains, which could mean that a forwarding rule has been configured or some other suspicious activity.
The are some cases where InternetMessageIds contain a date integrated, sometimes encoded, sometimes not. Therefore, we have two timestamps to compare:
- InternetMessageId date → usually when the sending system generated the message.
- Timestamp (EmailEvents) → when Microsoft received/processed the email.
So if we compare “when it was created” vs “when it arrived”, we can detect cases such as emails created by the system but, due to local configuration, email campaigns that deliver slowly, or messages that were postponed compared to when they were received by Microsoft.
The ratio of true positive was really high and multiple emails were not detected as a Threat so good case to add as a detection.
- InternetMessageId date → usually when the sending system generated the message.
- Timestamp (EmailEvents) → when Microsoft received/processed the email.
So if we compare “when it was created” vs “when it arrived”, we can detect cases such as emails created by the system but, due to local configuration, email campaigns that deliver slowly, or messages that were postponed compared to when they were received by Microsoft.
The ratio of true positive was really high and multiple emails were not detected as a Threat so good case to add as a detection.
Detects the creation or modification of inbox rules that move messages to rarely checked folders like Archive, RSS Subscriptions, Conversation History, Junk Email, or Deleted Items. This is a common post-exploitation technique used to hide fraudulent communications (BEC, payroll fraud) or suppress security alerts, MFA notifications, and password reset emails from the victim. Approximately 10% of compromised accounts have malicious mailbox rules created shortly after initial access.
Detects automatic email forwarding to external domains in Google Workspace, which may indicate data leakage or misuse.
Detects instances where an email, identified as malicious or suspicious by the Microsoft Defender for Office 365 (formerly ATP) engine, was delivered to a user's Inbox or Junk folder.
It might indicate that a potential threat, such as a spearphishing attachment or links, has bypassed initial blocking mechanisms and reached an end-user, requiring further investigation and potential remediation.
It might indicate that a potential threat, such as a spearphishing attachment or links, has bypassed initial blocking mechanisms and reached an end-user, requiring further investigation and potential remediation.
Detects early-stage collection and reconnaissance activities targeting sensitive email data prior to exfiltration via Exchange cmdlets. This rule identifies the use of 'New-MailboxSearch' and 'Get-Recipient' cmdlets, which can be leveraged by adversaries to discover and collect email-related information. Detection covers both endpoint PowerShell execution and cloud audit logs for Microsoft Exchange Online.
Page 30 of 40