Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
18,132 detections
Filters
Last updated
All Time
Detection languages
6,549
6,212
1,473
1,005
661
Contributors
3,555
2,652
2,153
2,087
1,515
Categories
7,573
3,902
1,466
1,393
1,330
Platforms
13,736
1,393
1,320
824
738
Products / Services
3,828
3,138
2,448
912
908
MITRE Techniques
18,132
15,662
12,606
8,417
6,238
CVEs
19
18
17
16
14
IDS Classtypes
305
51
24
23
22
IDS Protocols
308
136
13
10
10
Detects a suspicious sequence of interactive sign-ins to Microsoft management and profile-related applications from unmanaged devices occurring within a tight 15-minute window. This behavior is indicative of post-compromise activity, potentially associated with activity clusters such as UNC6671, where an attacker interacts with account settings shortly after compromising a session.
Detects a suspicious sequence of events where a user's password is changed or reset by an administrator (or help-desk role) followed within a short time window by that same user registering a new MFA device, potentially indicating a vishing-based account takeover attack (e.g., PREY-0058/UNC6671).
This rule detects user authentication events that deviate significantly from a 14-day historical baseline of known devices, operating systems, browsers, and network locations (ASN). It flags logins where at least two out of four key metadata signals (DeviceId, OS, Browser, ASN) have changed compared to the user's historical pattern, specifically targeting successful authentications that did not trigger a fresh multi-factor authentication (MFA) challenge, potentially indicating token theft or unauthorized session reuse.
Detects successful Azure AD sign-ins where the user agent identifies as a Python requests library version (2.33.1 or 2.34.2) that has not been observed for that specific user account in the preceding 14 days. This behavior is indicative of anomalous automated or scripted access.
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.
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.
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.
Detects the RejectDirectSend bypass (null SMTP envelope sender + internal-domain spoof). Tightened to require Microsoft's composite auth verdict OR all of SPF/DKIM/DMARC failing (vs. any one), excludes known-approved Direct Send relay IPs, and excludes likely-legitimate bulk/newsletter traffic via BulkComplaintLevel.
Detects execution of PowerShell commands that use obfuscated [char[]] hex arrays in conjunction with 'iex' (Invoke-Expression) to run code in memory. This pattern is commonly used by loaders like SynkLoader (cleaner.ps1) to execute scripts while avoiding disk artifacts.
Detects the execution of a Faronics Deploy installer that has been renamed to mimic Adobe-related software. This technique is often used in phishing campaigns to trick users into executing binaries that lead to the silent installation of remote monitoring tools like ScreenConnect.
Detects the execution of BrowserCore.exe, a native messaging component for web browsers, when combined with command-line redirection (< or >) or specific output file creation (e.g., prt_cookie.txt, formatted_nonce.txt). This behavior is characteristic of an attack designed to extract Primary Refresh Tokens (PRTs) or browser cookies, which can be used to bypass authentication mechanisms.
Detects the creation or modification of files within the /tmp directory that follow a specific naming convention (t[number]_w.pipe) by an HAProxy process. This pattern is often associated with inter-process communication or potential post-exploitation activity where HAProxy is leveraged to handle named pipes for malicious command execution or data redirection.
Detects the use of common Linux command-line utilities (sed, grep, awk, bash, sh) to perform operations on sensitive system logs or shell history files. The rule targets command strings indicative of log modification, filtering, or removal of audit trails, often associated with an attacker attempting to conceal malicious activity.
Detects the use of common Linux command-line utilities (sed, grep, awk, bash, sh) to perform operations on sensitive system logs or shell history files. The rule targets command strings indicative of log modification, filtering, or removal of audit trails, often associated with an attacker attempting to conceal malicious activity.
Detects the 'ted' backdoor or similar malicious activity attempting to manipulate HAProxy's internal connection counters by accessing or writing to the HAProxy process memory (/proc/[pid]/mem or /proc/self/mem). This behavior is characteristic of an attempt to evade backend logging and statistics tracking by directly modifying process memory structures.
Detects the creation or modification of files within the /tmp directory that follow a specific naming convention (t[number]_w.pipe) by an HAProxy process. This pattern is often associated with inter-process communication or potential post-exploitation activity where HAProxy is leveraged to handle named pipes for malicious command execution or data redirection.
Detects when the PostgreSQL service process (postgres.exe/postgres/postmaster) loads a shared library (.dll or .so) from a non-standard, user-writable directory (e.g., Temp, AppData, /tmp). This behavior is indicative of potential exploitation of vulnerabilities like CVE-2026-6471, where attackers attempt to load malicious plugins via unvalidated logical decoding plugin paths.
Detects potential exploitation of PostgreSQL via logical decoding plugins, specifically targeting CVE-2026-6471. The rule monitors for the PostgreSQL server process spawning suspicious shell utilities or loading modules from locations outside of the expected PostgreSQL library or plugin directories, which is a common indicator of unauthorized code execution.
Detects potential exploitation of PostgreSQL via logical decoding plugins, specifically targeting CVE-2026-6471. The rule monitors for the PostgreSQL server process spawning suspicious shell utilities or loading modules from locations outside of the expected PostgreSQL library or plugin directories, which is a common indicator of unauthorized code execution.
Detects when the PostgreSQL service process (postgres.exe/postgres/postmaster) loads a shared library (.dll or .so) from a non-standard, user-writable directory (e.g., Temp, AppData, /tmp). This behavior is indicative of potential exploitation of vulnerabilities like CVE-2026-6471, where attackers attempt to load malicious plugins via unvalidated logical decoding plugin paths.
This rule detects potentially malicious modifications to PostgreSQL configuration files or the creation of new library files (.so or .dll) by the PostgreSQL service process. It also flags when the PostgreSQL service process is initiated with command-line arguments referencing 'shared_preload_libraries', which can be abused to load arbitrary code or malicious extensions into the database engine.
Page 181 of 864