Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
3,750 detections
Filters
Last updated
All Time
Detection languages
2,544
328
307
253
149
Contributors
953
720
641
297
173
Categories
1,245
994
880
773
476
Platforms
2,850
1,449
1,229
356
73
Products / Services
10,683
9,759
6,695
4,421
3,750
MITRE Techniques
1,096
989
950
912
820
CVEs
17
6
2
1
1
IDS Classtypes
9
4
3
2
2
IDS Protocols
21
1
Detects suspicious Entra ID device registration and Primary Refresh Token (PRT) issuance occurring shortly after an OAuth Device Code sign-in. This pattern is indicative of ARToken-style post-compromise persistence, where an attacker leverages a stolen device code to register a rogue device and establish a persistent session.
Detects outbound email replies concerning invoices or payments sent by a user shortly after performing a device-code authentication flow, indicative of an ARTSender proxy attack where the attacker hijacks an existing email conversation to conduct Business Email Compromise (BEC).
Detects anomalous device-code authentication attempts from multiple distinct users originating from known ARToken PhaaS platform egress IP addresses within a 3-day window. This behavior is indicative of a bulk token-capture operation, where an attacker leverages an Adversary-in-the-Middle (AiTM) phishing framework to harvest credentials and session tokens from multiple users.
Detects Microsoft 365 MailItemsAccessed events where the email subject or body contains finance-related keywords such as 'invoice', 'payment', 'bank details', or 'wire'. This activity may indicate malicious mailbox scanning or data collection, often associated with unauthorized access or automated enumeration tools like the ARToken Inbox Monitor.
Detects phishing emails leveraging finance or accounts-payable themes (e.g., invoices, payment confirmations, bank detail updates) that contain known ARToken phishing template strings. This activity is indicative of credential harvesting via device code authorization flow abuse.
Detects automated mailbox access operations such as 'MailItemsAccessed' or 'Search-Mailbox' that are filtered by specific, high-risk financial or Business Email Compromise (BEC) keywords in the email subject line. This behavior is indicative of an automated 'inbox-monitor' style attack, where a compromised OAuth token is used to systematically scrape mailboxes for sensitive financial data.
Detects inbound emails containing an '.r01' attachment (often associated with multi-part RAR archives) where both SPF and DMARC authentication checks have failed, and the email subject implies business-related themes like purchase orders or supply chain communication. This pattern is indicative of a spearphishing attempt.
Detects inbound emails containing an '.r01' attachment (often associated with multi-part RAR archives) where both SPF and DMARC authentication checks have failed, and the email subject implies business-related themes like purchase orders or supply chain communication. This pattern is indicative of a spearphishing attempt.
Detects inbound emails containing an '.r01' attachment (often associated with multi-part RAR archives) where both SPF and DMARC authentication checks have failed, and the email subject implies business-related themes like purchase orders or supply chain communication. This pattern is indicative of a spearphishing attempt.
Detects anomalous reuse of an authenticated Microsoft 365 session cookie shortly after a successful MFA-satisfied sign-in. The detection identifies scenarios where the subsequent access originates from a different IP address, device, or user agent without an intervening MFA challenge, which is a pattern indicative of session hijacking techniques like Adversary-in-the-Middle (AiTM) or session token replay.
Audits Direct Send traffic against an approved-IP watchlist, flagging unauthenticated inbound mail spoofing an internal domain from an unrecognized source IP. Fixed: RecipientDomain/SenderFromDomain were referenced but never defined (would have errored at runtime); replaced with derived SenderDomain/RecipientDomain consistent with the sibling rules. Removed a noisy display-name-contains-domain OR-branch. Replaced an always-true-in-practice auth check (required every one of SPF/DKIM/DMARC to show literal "Pass", which fails for many legitimate senders that pass via alignment on only one protocol) with the same CompAuth/all-three-fail logic used elsewhere in this set.
This rule monitors Office 365 activity for anomalous search behavior, specifically targeting high volumes of distinct search queries involving site collections, web structures, or index ID patterns. Such patterns are indicative of automated data discovery or enumeration activities performed against SharePoint or OneDrive environments.
This rule detects modifications to Group Policy Objects (GPO) or Microsoft Entra (formerly Azure AD) policies that weaken established security controls. For GPO, it monitors Event ID 5136 for changes to security-relevant attributes (e.g., disabling firewall or real-time monitoring) in Active Directory. For Entra, it monitors audit logs for administrative operations that reduce security posture, such as disabling MFA, lowering authentication trust, or deleting Conditional Access policies. It includes filters to exclude legitimate, documented change management activities.
Detects potential Business Email Compromise (BEC) related to 'Phantom Deal' fraud. The rule identifies email threads where a user receives an urgent request for proof of payment (MT103/UETR) within 72 hours of an email discussion involving both wire transfer/payment keywords and M&A/deal context.
Detects high-volume, potentially malicious email campaigns characterized by discount-themed subject lines containing keywords like '65% off' and links pointing to '.shop' domains. The rule identifies suspicious patterns by aggregating events and flagging instances where multiple users are targeted with similar subjects and domains, excluding those specifically allowlisted.
Detects instances where a user grants OAuth application permissions to GitHub or Slack shortly (within 30 minutes) after signing into a low-trust application (Discourse or OpenAI Community), suggesting a potential session hijacking or trusted-relationship abuse scenario where an attacker leverages an existing SSO session to authorize malicious applications.
Detects instances where a user grants OAuth application permissions to GitHub or Slack shortly (within 30 minutes) after signing into a low-trust application (Discourse or OpenAI Community), suggesting a potential session hijacking or trusted-relationship abuse scenario where an attacker leverages an existing SSO session to authorize malicious applications.
Detects instances where a user grants OAuth application permissions to GitHub or Slack shortly (within 30 minutes) after signing into a low-trust application (Discourse or OpenAI Community), suggesting a potential session hijacking or trusted-relationship abuse scenario where an attacker leverages an existing SSO session to authorize malicious applications.
This rule detects network communication, email interaction, or identity logon events related to known spoofed IC3 (Internet Crime Complaint Center) domains used in business email compromise (BEC) campaigns. The detection covers multiple telemetry sources including email URL information, device network events, and identity logon logs to identify attempts to interact with fraudulent portals.
This rule detects email-based business fraud (BEC) targeting the organization, specifically looking for executive impersonation paired with financial lure terminology and sender domain mismatches. It utilizes both a blocklist of known fraudulent sender indicators (domains and addresses) and a heuristic approach analyzing discrepancies between the envelope sender domain and the header sender domain combined with executive titles in display names and invoice-related keywords.
Detects active phishing threat-intelligence indicators whose domain name uses one of the disposable TLDs observed across IronToll's 73+ rotating lookalike domains (.cfd, .sbs, .icu, .buzz, etc.). Scoped to the structured ThreatType classification only — dropped the free-text 'Description has phishing' fallback, since KQL's 'has' is a substring/token match with no negation awareness (e.g. a description stating an indicator is 'not related to phishing' would still match), which could pull in indicators unrelated to actual phishing activity.
Page 65 of 179