Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,598 detections
Filters
Last updated
All Time
Detection languages
1,151
134
65
63
53
Contributors
368
274
239
197
70
Categories
983
375
271
227
140
Platforms
871
506
164
160
149
Products / Services
949
298
133
113
108
MITRE Techniques
18,116
15,638
12,587
8,397
6,227
1,598
CVEs
2
1
1
1
1
IDS Classtypes
18
5
4
1
1
IDS Protocols
15
8
4
3
This rule detects Salesforce Agentforce or similar AI-driven chat responses that contain external URLs with non-standard Top-Level Domains (TLDs). It identifies cases where the organization's redactor failed to strip a URL due to unexpected TLDs or unusual trailing termination characters (e.g., brackets) that are still rendered as clickable links in the interface. Such links may facilitate phishing, credential harvesting, or redirection to malicious sites.
This rule detects potential AI agent prompt injection by monitoring email subjects or attachment names for keywords often associated with system instruction overrides. It correlates these potentially malicious emails with subsequent execution of common administrative or script-interpreting binaries (e.g., PowerShell, cmd.exe) on the recipient's device within a one-hour window, suggesting a potential successful hijack of an automated process or AI agent.
Detects phishing attempts leveraging SendGrid infrastructure to send emails that impersonate well-known financial brands. The detection looks for emails with authentication checks passing (SPF/DKIM/DMARC) where the sender domain is suspicious (e.g., .asia or .com not matching the brand) and the volume of such messages suggests an automated campaign.
Detects incoming emails that use 'Apple' or 'Find My' related strings in the sender display name while originating from common consumer email relay domains like Gmail or iCloud, which is indicative of a social engineering or phishing attempt attempting to impersonate Apple support.
Detects phishing messages that deliberately mix writing systems/scripts/homoglyphs in the Subject line as ONE corroborating signal within a broader, multi-signal phishing pattern. Hardened against false positives: brand/product tokens (e.g. Microsoft, PayPal) are stripped before the Latin-script check so a lone brand mention in non-Latin correspondence doesn't count as mixed-script; the suspicious-URL signal requires a high-confidence credential/urgency term (not generic business vocabulary); sender risk requires the domain to be new to both the recipient and the organization; and at least three independent signal categories (not two) must corroborate the language-confusion signal before the rule fires.
Detects web traffic directed towards the AnonyMousKIT SMS relay API endpoint, commonly used by threat actors for dispatching SMS phishing lures. The rule monitors for requests to specific API paths related to SMS dispatching and analyzes the gateway status messages returned by the service.
Detects the specific C2/WebSocket instruction sequence utilized by the JWR/Outsider phishing kit operators. The rule monitors DeviceNetworkEvents for characteristic outbound URL query parameters that indicate progress through a phishing interaction, including initial info collection (to_info), card data submission (to_card), and subsequent verification or outcome steps.
This rule detects DNS lookups, email URL clicks, and network connections involving lookalike domains that mimic Singaporean government or infrastructure services (e.g., LTA, OneMotoring, ERP, Gov.sg). It employs a regex-based pattern match for common brand-keywords combined with high-risk top-level domains, identifying potential phishing activity associated with the JWR framework that utilizes algorithmically varied, single-suffix rotated lookalike domains.
This rule detects network connections to specific domains and domain patterns that mimic legitimate entities (e.g., NinjaVan, EmiratesPost). The detection logic identifies direct matches to known malicious infrastructure and uses regular expressions to catch permutation-based typosquatting, which are common indicators of phishing or credential harvesting campaigns.
Detects the specific fingerprinting sequence associated with Mirage2FA AiTM phishing campaigns. The detection triggers when a process downloads a specific JavaScript loader from an '/xls/' path, followed closely within two minutes by an IP/geolocation lookup request to common services (api.ipify.org, api.country.is, api.ipgeolocation.io), which is a characteristic precursor to credential interception.
This rule monitors for network DNS queries containing keywords commonly associated with credential harvesting and identity verification lures, such as 'sso', 'mfa', 'passkey', or 'helpdesk'. It detects attempts to reach suspicious domains that may be used in phishing campaigns targeting corporate identity portals.
Detects inbound email messages containing keywords and phrases consistent with extortion attempts, specifically referencing stolen data, unauthorized access, and demands for cryptocurrency payment.
This rule monitors for indicators of compromise (IOCs) associated with the ShinyHunters threat actor, including specific malicious domains, IP addresses, and artifacts found in command lines or event data. It aggregates telemetry from network events, Entra ID sign-in logs, cloud application activity, email logs, process execution, and general device events to detect interaction with known malicious infrastructure or execution of threat-actor specific artifacts.
This rule detects mass-distributed email phishing campaigns that impersonate Google branding. It identifies emails using Google-related sender display names or subjects that originate from non-Google domains and contain links to external, non-Google domains. The detection focuses on identifying suspicious patterns across multiple recipients rather than individual email signatures.
Detects the execution of piped curl-to-shell or curl-to-bash commands originating from a macOS Terminal process, a common pattern used in ClickFix-style social engineering attacks where users are tricked into copying and pasting malicious commands.
Detects instances where a user successfully authenticates via the OAuth Device Code flow using an unmanaged or non-compliant device, followed closely by high-privileged Azure/Graph API administrative actions within a short timeframe. This behavior is indicative of a device-code phishing attack aimed at bypassing MFA controls, including FIDO2/passkeys, by compromising an active session.
This rule detects potential Business Email Compromise (BEC) attempts where external senders impersonate corporate executives (e.g., CEO, CFO) by spoofing display names or using lookalike/cousin domains. It triggers when these impersonations are combined with urgent, financial-themed language in the email subject line (e.g., wire transfers, payroll changes, or gift card requests).
This rule monitors incoming email events for potential phishing attempts by identifying messages from unknown sender domains (not seen in the last 90 days) that contain known AI-generated response phrases in the subject line or personalized content matching the recipient's display name. This helps detect spearphishing lures that attempt to build trust through impersonation or leverage LLM-generated phrasing common in automated phishing campaigns.
Detects evidence of indirect prompt injection (IPI) attempts within email and document content processed by enterprise AI assistants. The rule flags instruction-hijack phrases, hidden obfuscation characters (e.g., zero-width, white-on-white text), and encoded blocks specifically targeting AI model behavior.
This rule monitors DeviceNetworkEvents and DnsEvents for connections to known malicious domains and IP addresses associated with phishing campaigns. It alerts on any network communication or DNS resolution attempt targeting these indicators, providing visibility into potential user interaction with phishing infrastructure.
This rule detects email activity containing keywords related to SSO or passkey updates combined with urgent terminology and support request language. This pattern is commonly indicative of phishing attempts aimed at stealing credentials or tricking users into providing sensitive information.
Page 13 of 77