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 instances where a user grants consent to an unverified OAuth application requesting high-privilege scopes (e.g., Mail.Read, Files.ReadWrite.All). This behavior is characteristic of consent phishing attacks aimed at obtaining persistent access to sensitive data and mailbox contents.
Detects a multi-stage Telephone-Oriented Attack Delivery (TOAD) campaign. The first stage identifies phishing emails containing billing or security-themed subjects and phone numbers without links or attachments to evade automated analysis. The second stage monitors for the subsequent installation or execution of common remote-support tools (e.g., AnyDesk, TeamViewer, ScreenConnect). A final correlative rule detects these events occurring sequentially on the same host, indicating a high-confidence indicator of a successful callback phishing social-engineering attempt.
Detects high-volume, individually-tailored spear-phishing campaigns likely assisted by Generative AI. The rule monitors for a single sender targeting a high number of unique recipients with distinct, non-identical email subjects within a short timeframe. It specifically flags activity involving newly registered look-alike domains and interactions with credential-harvesting patterns in URLs.
Detects a suspicious sequence of events where a user engagement (voice/video call) involving themes of urgency or helpdesk interaction is closely followed by a high-risk administrative action (e.g., password reset, MFA device enrollment, or financial transfer) by the same user, where the communication session context differs from standard activity, indicative of a deepfake-enabled vishing attack.
Detects anomalous account recovery or MFA reset activity performed by a single help-desk user account. A high volume of reset actions across numerous distinct users within a short duration is a key behavioral indicator of potential help-desk account compromise or insider abuse involving unauthorized account takeovers.
Detects the registration of a new MFA device or authenticator by a user shortly after a password reset event, where the registration originates from an IP address classified as a hosting provider, datacenter, or VPN. This pattern is indicative of a help-desk or vishing-based account takeover attack where an adversary registers their own MFA device to gain persistent access.
Single-source Sigma proxy for the authentication-persistence stage of the multi-stage device-code-phishing-to-Graph-collection chain (see the companion KQL correlation rule "Passkey Persistence: Device-Code Phishing to MFA Takeover and Graph Collection" for the full, threshold-gated, cross-table detection). Sigma has no join, temporal-windowing, or aggregation support, so this rule fires on the authentication-persistence event alone and does NOT enforce the device-code sign-in precursor or the subsequent Graph-activity burst - both required by the full correlation. Scoped to the two highest-signal operations only (new security-info registration, and any admin-initiated registration on another user's account) to cut noise from routine self-service profile edits.
Hunts network, HTTP, and email-URL telemetry for known ARToken infrastructure (operator backend IPs and phishing/panel domains). Bounded to a 30-day lookback and tiers matches by confidence: domain hits are high-confidence (attacker-registered infrastructure), while IP hits are medium-confidence since the IPs sit on shared DigitalOcean hosting that can be reassigned to unrelated tenants once ARToken's infrastructure is taken down. Empty/unparsed indicator fields are excluded to avoid spurious matches in the HTTP event parsing branch. No known file hashes are associated with this intel.
This rule identifies potential phishing attempts by correlating email delivery events with known suspicious sender addresses and URLs containing typosquatting domains impersonating legitimate organizations.
Detects the Sauron Loader vishing chain: a mailbox hit by a high-volume, high-distinct-sender email bombing burst (raised from 20 to 50 emails/hour and now requiring 15+ distinct senders, to exclude single-sender retry loops or broken automation), followed within 2 hours by the same user launching Quick Assist or AnyDesk — consistent with an attacker posing as IT support after the flood. Also fixes a schema bug where EmailEvents was queried with TimeGenerated instead of Timestamp, and a post-join column reference bug.
Detects the Sauron Loader vishing chain: a mailbox hit by a high-volume, high-distinct-sender email bombing burst (raised from 20 to 50 emails/hour and now requiring 15+ distinct senders, to exclude single-sender retry loops or broken automation), followed within 2 hours by the same user launching Quick Assist or AnyDesk — consistent with an attacker posing as IT support after the flood. Also fixes a schema bug where EmailEvents was queried with TimeGenerated instead of Timestamp, and a post-join column reference bug.
Detects the Sauron Loader vishing chain: a mailbox hit by a high-volume, high-distinct-sender email bombing burst (raised from 20 to 50 emails/hour and now requiring 15+ distinct senders, to exclude single-sender retry loops or broken automation), followed within 2 hours by the same user launching Quick Assist or AnyDesk — consistent with an attacker posing as IT support after the flood. Also fixes a schema bug where EmailEvents was queried with TimeGenerated instead of Timestamp, and a post-join column reference bug.
Detects known file hashes associated with SideCopy/ReverseRAT.
This rule detects a suspicious monetization pattern where a user account experiences a high-risk sign-in event, followed shortly (within 2 hours) by the creation or modification of inbox rules. This pattern is often indicative of account compromise, where an adversary configures mailbox rules (e.g., forwarding or redirection) to facilitate data exfiltration or financial fraud.
This rule detects a suspicious monetization pattern where a user account experiences a high-risk sign-in event, followed shortly (within 2 hours) by the creation or modification of inbox rules. This pattern is often indicative of account compromise, where an adversary configures mailbox rules (e.g., forwarding or redirection) to facilitate data exfiltration or financial fraud.
This rule detects the presence of files matching known SHA256 hashes associated with the GhostCode phishing kit. It monitors for these files both in email attachments and on local device filesystems to identify potential delivery and execution of malicious phishing payloads.
Detects a suspicious sequence of events where a user's registered phone number or recovery contact method is updated, followed shortly by an MFA factor reset or new factor enrollment. This pattern is a common indicator of a SIM-swap attack, where an attacker intercepts SMS-based MFA codes after hijacking the victim's phone number.
Detects multiple MFA push notifications generated within a short timeframe for a single user during a Self-Service Password Reset (SSPR) flow. This behavior is indicative of an attacker attempting to perform MFA fatigue/push harassment to gain unauthorized access via SSPR or to bypass account security controls.
Detects anomalous account recovery or MFA reset activity performed by a single help-desk user account. A high volume of reset actions across numerous distinct users within a short duration is a key behavioral indicator of potential help-desk account compromise or insider abuse involving unauthorized account takeovers.
Detects multiple MFA push notifications generated within a short timeframe for a single user during a Self-Service Password Reset (SSPR) flow. This behavior is indicative of an attacker attempting to perform MFA fatigue/push harassment to gain unauthorized access via SSPR or to bypass account security controls.
Detects anomalous authentication behavior where the same session token or identifier is utilized by multiple distinct IP addresses or User-Agent strings within a short timeframe. This behavior is indicative of Adversary-in-the-Middle (AiTM) attacks, such as those employing Evilginx, where an attacker intercepts and replays stolen session cookies to bypass standard authentication and MFA controls.
Page 38 of 179