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 monitors for the addition of new credentials (secrets) to service principals or applications in an Azure/Entra ID environment. It then correlates this event with subsequent mailbox activity (such as accessing mail items, sending mail, or message binding) performed by the application within 7 days of the credential creation. This detection pattern is indicative of potential OAuth application-based persistence and mailbox data exfiltration.
Detects activity associated with the MALFEX npm supply-chain campaign (also known as Overlord/movinlike). This rule performs a sweep for known malicious file hashes, suspicious process command lines, outbound network connections to malicious domains or IPs, and email communications from identified adversary-controlled accounts.
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 network communication with known malicious infrastructure (C2 IPs and URLs), presence of malicious files identified by SHA256 hashes on disk, and execution of known malicious files. It also correlates these activities with specific operator email addresses involved in the malicious campaign.
This rule detects potential adversarial reconnaissance activities targeting AI agents via multiple communication channels (e.g., email, collaboration tools). It identifies patterns where a sender transmits messages containing common 'jailbreak' or 'instruction-override' phrases (e.g., 'ignore previous instructions', 'bypass approval') across at least three distinct channels within a 24-hour window, indicating a concerted effort to manipulate or probe agent logic.
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.
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 detects the creation or modification of mailbox rules (forwarding, redirection, or deletion) that occurs within two hours of a sign-in event flagged as high-risk, specifically those indicative of AiTM or token-replay attacks. It further filters for rules involving sensitive keywords, suggesting an attempt to intercept or hide specific categories of emails post-compromise.
Detects mailbox items being accessed or bound by an OAuth-based application (app-only context) in Microsoft 365, filtering out expected interactive client signatures like Outlook or OWA. This behavior is indicative of potential post-compromise mailbox enumeration or data harvesting by malicious applications using stolen or illicitly granted OAuth access tokens.
Detects potential reconnaissance or data collection activity within Office 365 Exchange mailboxes. The rule monitors for mailbox access operations (MailItemsAccessed, SearchQueryInitiated, FolderBind, or MessageBind) originating from new or uncommon application IDs, IP addresses, or ASNs for a specific user, or indicates bulk folder enumeration behavior in a short timeframe, which may suggest session token reuse or unauthorized mailbox access.
This rule detects potentially malicious inbox rule creation or modification in Office 365 Exchange. It flags rules that contain keywords associated with financial fraud (e.g., invoice, wire, payment) and include actions that hide evidence (e.g., moving messages to junk or deleting them). It further correlates these actions with suspicious user login activity, such as logging in from a new IP address or country within an hour of the rule change, which is a common indicator of a Business Email Compromise (BEC) account takeover.
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.
Detects activity associated with the MALFEX npm supply-chain campaign (also known as Overlord/movinlike). This rule performs a sweep for known malicious file hashes, suspicious process command lines, outbound network connections to malicious domains or IPs, and email communications from identified adversary-controlled accounts.
Detects a sequence of activity where a user receives a high volume of inbound emails (potential vishing or social engineering lures) within a short window, followed by the user executing Windows Remote Assistance or Quick Assist tools within the next 6 hours, which is highly indicative of remote access social engineering pre-cursors.
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.
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 potential quishing (QR code phishing) attempts by identifying emails with one or more image attachments and minimal URL content, followed by a risky user authentication event within a 3-hour window. This behavior is indicative of an attacker attempting to harvest credentials via a malicious QR code that redirects the user to a phishing site.
Detects inbound email or ticketing messages containing extortion language (such as payment deadlines, leak-site references, and data-shredding threats) specifically directed at high-value internal targets like executives, security teams, and legal departments. This pattern is consistent with the ShinyHunters 'pay-or-leak' extortion model.
This rule detects potential adversarial reconnaissance activities targeting AI agents via multiple communication channels (e.g., email, collaboration tools). It identifies patterns where a sender transmits messages containing common 'jailbreak' or 'instruction-override' phrases (e.g., 'ignore previous instructions', 'bypass approval') across at least three distinct channels within a 24-hour window, indicating a concerted effort to manipulate or probe agent logic.
Page 4 of 40