Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,632 detections
Filters
Last updated
All Time
Detection languages
1,056
161
128
83
72
Contributors
427
386
258
93
93
Categories
923
331
312
289
237
Platforms
768
404
356
303
295
Products / Services
820
308
216
159
157
MITRE Techniques
18,113
15,640
12,591
8,389
6,208
1,632
CVEs
3
2
1
1
1
IDS Classtypes
108
26
18
5
3
IDS Protocols
100
33
20
3
This rule detects a specific typosquatting pattern used by the EvilTokens phishing kit. It looks for HTTP traffic where the host contains 'workers.dev' and matches a regular expression for 'viewdoc[a-z0-9\-]+\.workers\.dev'. This indicates an attempt to mimic legitimate Cloudflare Workers domains for phishing purposes, specifically targeting the 'viewdoc' pattern often seen in document-sharing lures.
Detects inbound emails relayed through GoDaddy secureserver.net infrastructure where SPF and DMARC authentication pass but DKIM is absent, and the X-SECURESERVER-ACCT header is present. This pattern is consistent with the Scotiabank TOAD callback phishing campaign leveraging compromised legitimate domains to bypass email authentication controls.
Detects a browser session that contacts an EvilTokens Device Code phishing endpoint (/api/device/status/) and then immediately navigates to onedrive.live.com, indicating the attacker backend returned status:completed and the kit executed window.location.replace to redirect the victim to OneDrive after token capture. This sequence suggests a successful device code phishing attack where the victim's credentials or tokens have been captured, and they are then redirected to a legitimate service to avoid suspicion.
This rule detects successful OAuth logins originating from IP addresses identified as residential proxies. This behavior can indicate an adversary attempting to bypass geo-blocking or other IP-based restrictions, potentially using stolen credentials (Valid Accounts) or after a successful phishing campaign (Spearphishing Link) to gain initial access or maintain persistence.
Detects web traffic where a user initiates a request for content related to 'policy', 'conduct', 'compliance', or 'handbook', experiences at least three redirects across different hosts, and ultimately lands on a page containing keywords indicative of a login, sign-in, OAuth, or authorization prompt. This pattern is often used in multi-stage phishing campaigns to obscure the malicious infrastructure.
Detects a two-stage credential page that receives an email address and then requests tenant branding or a password form during the same browser session. This behavior is indicative of advanced phishing attacks that attempt to mimic legitimate login flows.
Detects network activity and DNS lookups associated with the domain 'loopedin.io', which has been identified as a second-hop open-redirect service used in forged healthcare-themed phishing campaigns. The rule specifically monitors connections from common web browsers to facilitate the identification of redirected user traffic.
This rule detects potential engagement with known phishing infrastructure by monitoring common email clients and browsers for DNS resolutions to specific malicious domains (holabrief.com, loopedin.io) or network connections to suspicious IP addresses associated with a healthcare-themed phishing campaign.
Detects inbound invoice-themed phishing emails where the sender domain authentication (SPF/DKIM) fails, combined with healthcare-related display name impersonation. The rule specifically targets the abuse of aged, high-reputation domains used as a vector to bypass standard reputation-based email filtering while masquerading as healthcare organizations.
Detects HTTP requests directed at known MexicanMafia Operation Escaneo phishing infrastructure, specifically targeting tax authority and SeedDMS document management users. The rule alerts on access to identified artifact filenames used in the campaign, such as phishing poc and spoofed document management pages.
Detects successful device code authentication via the Microsoft Office App (FOCI), which could indicate potential Adversary-in-the-Middle (AiTM) phishing attacks. The rule specifically looks for successful sign-ins using the 'deviceCode' authentication protocol and the AppId associated with Microsoft Office.
This rule identifies a suspicious sequence of events: a successful device code authentication immediately followed (within one hour) by a device registration event (PRT upgrade) for the same user. This pattern is indicative of a device code phishing attack where an attacker tricks a user into authenticating a device code, then registers their own device to gain persistent access.
Detects successful sign-ins utilizing the device code flow, which is frequently abused in Adversary-in-the-Middle (AiTM) phishing attacks. This rule specifically looks for successful authentication events where the 'AuthenticationProtocol' is 'deviceCode'.
Identifies emails where SenderFromDomain matches an internal legitimate domain, but the SenderIPv4 originates from an unassociated external network exploiting permissive SPF records or dangling DNS. This rule specifically looks for emails with a sender domain matching 'yourcompany.com' (which should be replaced with the actual tenant domain), where the sender's IPv4 address is not from internal networks (excluding 10.0.0.0/8 and 192.168.0.0/16), and the SPF authentication passed. It further ensures that the originating IP address is not known to internal devices via network connection events, helping to filter out legitimate internal mail relays or services.
Detects browser network events accessing Cloudflare Turnstile endpoints followed immediately by a connection to an anomalous, newly registered AiTM subdomain. This sequence of events is indicative of a CAPTCHA bypass technique used by the Tycoon2FA phishing kit.
Tracks AAD/Exchange logs showing mail routed through an external tenant specifically to bypass internal domain spoofing filters via trusted connectors. This rule identifies emails where the sender's domain matches the internal company domain, but the email was routed through an external Office 365 connector and did not originate from a trusted internal IP address, indicating a potential cross-tenant spoofing attempt.
Identifies emails where the From header spoofing a government entity mismatches the envelope sender in MailEvents. This indicates a potential email spoofing attempt, often used in phishing campaigns.
Detects the initial phishing delivery vector: Microsoft Teams spawning a process which downloads from AWS S3 buckets.
Detects a successful multifactor authentication followed within minutes by another successful sign-in for the same account from a different IP address and user agent. This pattern can indicate an adversary has bypassed MFA, potentially through techniques like AiTM phishing, and is attempting to use the compromised session.
This rule detects network communication with infrastructure associated with the 'EvilTokens' phishing kit, specifically targeting Microsoft OAuth device code API endpoints (/api/device/*) hosted on workers.dev. This behavior is indicative of an adversary conducting device code phishing (a form of AitM attack) to obtain unauthorized access tokens.
Detects reverse proxy phishing pages designed to intercept MFA OTP codes
Page 57 of 78