Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
4,916 detections
Filters
Last updated
All Time
Detection languages
2,236
1,064
466
410
326
Contributors
725
665
535
485
271
Categories
1,085
870
805
765
576
Platforms
1,843
1,022
856
814
656
Products / Services
988
596
477
456
383
MITRE Techniques
18,123
15,639
12,581
8,394
6,215
4,916
CVEs
37
17
17
15
12
IDS Classtypes
196
73
47
29
16
IDS Protocols
301
27
24
22
6
Detects a privileged session beginning with no preceding credential retrieval by the
same account. The expected sequence is checkout then session. A session without one
suggests the credential was obtained outside the vault — cached, shared, or stolen —
which defeats the control the vault exists to provide.
Correlate SESSION_STARTED in the audit stream against PASSWORD_RETRIEVED in the iam
stream for the same user within a preceding window.
Onboarding: PAM360 is ingested via Syslog (Bloo extractor 879).
Integration guide: https://bloo.io/docs/hypercloud/syslog-connector
BQL (Bloo Query Language):
stream=audit where sourcename='PAM360' and action='SESSION_STARTED'
| groupby user, targetuser, srcip, devicetype
same account. The expected sequence is checkout then session. A session without one
suggests the credential was obtained outside the vault — cached, shared, or stolen —
which defeats the control the vault exists to provide.
Correlate SESSION_STARTED in the audit stream against PASSWORD_RETRIEVED in the iam
stream for the same user within a preceding window.
Onboarding: PAM360 is ingested via Syslog (Bloo extractor 879).
Integration guide: https://bloo.io/docs/hypercloud/syslog-connector
BQL (Bloo Query Language):
stream=audit where sourcename='PAM360' and action='SESSION_STARTED'
| groupby user, targetuser, srcip, devicetype
Detects one endpoint authenticating under several distinct user identities in a short
period. A workstation normally carries one user at a time. Several identities from
one endpoint suggests credential testing, a shared or kiosk device being misused, or
an attacker working through harvested accounts from a single foothold.
Onboarding: CISCO-ISE is ingested via Syslog (KV) (Bloo extractor 196).
Integration guide: https://bloo.io/docs/hypercloud/syslog-connector
BQL (Bloo Query Language):
stream=authentication where sourcename='CISCO-ISE' and action='LOGIN'
| duration 1h
| groupby srcip
| select srcip, distinct_count(user)
| having distinct_count_col1 > 4
period. A workstation normally carries one user at a time. Several identities from
one endpoint suggests credential testing, a shared or kiosk device being misused, or
an attacker working through harvested accounts from a single foothold.
Onboarding: CISCO-ISE is ingested via Syslog (KV) (Bloo extractor 196).
Integration guide: https://bloo.io/docs/hypercloud/syslog-connector
BQL (Bloo Query Language):
stream=authentication where sourcename='CISCO-ISE' and action='LOGIN'
| duration 1h
| groupby srcip
| select srcip, distinct_count(user)
| having distinct_count_col1 > 4
Detects authentication succeeding via MAC address where certificate or credential
based 802.1X is expected. MAC addresses are trivially spoofed, so a port falling back
to MAC authentication is a weak point an attacker can walk through by cloning the
address of a permitted device such as a printer or IP phone.
Onboarding: ARUBA-CLEARPASS is ingested via Syslog (CEF) (Bloo extractor 261).
Integration guide: https://bloo.io/docs/integrations/aruba-clearpass
BQL (Bloo Query Language):
stream=authentication where sourcename='ARUBA-CLEARPASS' and action='LOGIN'
| groupby authproto, user, srcip, role
based 802.1X is expected. MAC addresses are trivially spoofed, so a port falling back
to MAC authentication is a weak point an attacker can walk through by cloning the
address of a permitted device such as a printer or IP phone.
Onboarding: ARUBA-CLEARPASS is ingested via Syslog (CEF) (Bloo extractor 261).
Integration guide: https://bloo.io/docs/integrations/aruba-clearpass
BQL (Bloo Query Language):
stream=authentication where sourcename='ARUBA-CLEARPASS' and action='LOGIN'
| groupby authproto, user, srcip, role
Detects network connections, process executions, file creations, and image loads associated with the UNC7017 AOMEI supply chain campaign IOC sweep, including specific malicious URLs, domains, IPs, file paths, and hashes.
Detects incoming xAI invitation emails from noreply@x.ai containing URLs that do not belong to the x.ai domain, which may indicate a phishing attempt or link injection.
Detects external inbound FortiGate Fabric Management Protocol (FGFM) traffic on TCP port 541 followed by a FortiGateCloud administrative configuration download, backup, or running-config event on the same FortiGate device within a one-hour window, potentially indicating unauthorized configuration access or device compromise.
Detects external inbound FortiGate Fabric Management Protocol (FGFM) traffic on TCP port 541 followed by a FortiGateCloud administrative configuration download, backup, or running-config event on the same FortiGate device within a one-hour window, potentially indicating unauthorized configuration access or device compromise.
Builds a per-account baseline of the devices that each enabled service account has made a successful network logon to over the previous 30 days, then alerts when one makes a successful network logon to a device outside that baseline within the latest window.
Service accounts are identified from IdentityInfo using each account’s most recent recorded type and enabled status, and are matched to logon events by their on-premises SID, so local accounts or accounts in other domains that share the same name are not mistaken for them. Accounts with no logon history in the baseline period are still evaluated, so a dormant service account that suddenly begins making network logons will alert on every device it reaches.
Service accounts tend to touch a small, fixed set of hosts, so a per-entity first-seen check is a strong lateral movement signal with less noise than the same logic applied to users.
Each result is enriched with the number of times the destination device’s sensor reporting restarted during the alert window, along with the times of those restarts in UTC, as restarts close to the new logons often indicate maintenance activity such as patching, although they should prompt a check to confirm rather than closure of the alert.
The rule runs every 24 hours, as this is the only Defender custom detection frequency with a 30-day lookback, and the alert window covers the last 25 hours so that a slightly delayed run does not leave a gap.
The baseline and alert windows are separated by ingestion time rather than event time, so events that arrive late are still evaluated.
Service accounts are identified from IdentityInfo using each account’s most recent recorded type and enabled status, and are matched to logon events by their on-premises SID, so local accounts or accounts in other domains that share the same name are not mistaken for them. Accounts with no logon history in the baseline period are still evaluated, so a dormant service account that suddenly begins making network logons will alert on every device it reaches.
Service accounts tend to touch a small, fixed set of hosts, so a per-entity first-seen check is a strong lateral movement signal with less noise than the same logic applied to users.
Each result is enriched with the number of times the destination device’s sensor reporting restarted during the alert window, along with the times of those restarts in UTC, as restarts close to the new logons often indicate maintenance activity such as patching, although they should prompt a check to confirm rather than closure of the alert.
The rule runs every 24 hours, as this is the only Defender custom detection frequency with a 30-day lookback, and the alert window covers the last 25 hours so that a slightly delayed run does not leave a gap.
The baseline and alert windows are separated by ingestion time rather than event time, so events that arrive late are still evaluated.
This rule tracks user and administrator submissions of potential phishing emails to Microsoft for analysis within the Security & Compliance Center. It extracts and logs details such as the submission verdict, rescan verdict, recipients, subject, content, submitter's display name, sender information (P1 and P2), email destination, final delivery verdict, and sender IP address. This provides visibility into an organization's proactive efforts to report and analyze suspected phishing attempts.
Detects when the IIS worker process (w3wp.exe) spawns command-line utilities or script interpreters such as cmd.exe, powershell.exe, mshta.exe, wscript.exe, or cscript.exe. This behavior often indicates web application exploitation or webshell activity.
Detects non-browser Python-based HTTP clients (such as python-requests, python-urllib, aiohttp, or httpx) targeting specific API endpoints (/user, /profile, /order, /upload) while exhibiting indicators of SQL injection or high-volume object ID enumeration.
Detects non-browser Python-based HTTP clients (such as python-requests, python-urllib, aiohttp, or httpx) targeting specific API endpoints (/user, /profile, /order, /upload) while exhibiting indicators of SQL injection or high-volume object ID enumeration.
Detects non-browser Python-based HTTP clients (such as python-requests, python-urllib, aiohttp, or httpx) targeting specific API endpoints (/user, /profile, /order, /upload) while exhibiting indicators of SQL injection or high-volume object ID enumeration.
Detects non-browser Python-based HTTP clients (such as python-requests, python-urllib, aiohttp, or httpx) targeting specific API endpoints (/user, /profile, /order, /upload) while exhibiting indicators of SQL injection or high-volume object ID enumeration.
Detects non-browser Python-based HTTP clients (such as python-requests, python-urllib, aiohttp, or httpx) targeting specific API endpoints (/user, /profile, /order, /upload) while exhibiting indicators of SQL injection or high-volume object ID enumeration.
Hunts for NetScaler Pitboss packet engine messages where the text after NSPPE carries shell syntax such as separators, command substitution or ${IFS}. Security vendors observed this pattern during exploitation of the NetScaler pre authentication command injection flaw patched in September 2026.
The query reads Syslog and CommonSecurityLog and decodes URL encoding. It checks only the text after NSPPE, so plain heartbeat lines without shell syntax do not match. The matching logic was checked on sample strings only, not on real appliance logs.
Triage: Check the source, the appliance version and whether it was patched at that time. A match on an unpatched appliance points to an exploitation attempt, not proof of success. Preserve logs and a snapshot before upgrading. Hunting query, not an alert.
Limitations: Needs NetScaler syslog forwarded to Sentinel. Empty results do not prove an appliance is clean. Attackers can remove traces and other techniques are not covered. Field names depend on the syslog format and connector. Bare separators and short words can match legitimate messages, so tune the regex after reviewing real results.
The query reads Syslog and CommonSecurityLog and decodes URL encoding. It checks only the text after NSPPE, so plain heartbeat lines without shell syntax do not match. The matching logic was checked on sample strings only, not on real appliance logs.
Triage: Check the source, the appliance version and whether it was patched at that time. A match on an unpatched appliance points to an exploitation attempt, not proof of success. Preserve logs and a snapshot before upgrading. Hunting query, not an alert.
Limitations: Needs NetScaler syslog forwarded to Sentinel. Empty results do not prove an appliance is clean. Attackers can remove traces and other techniques are not covered. Field names depend on the syslog format and connector. Bare separators and short words can match legitimate messages, so tune the regex after reviewing real results.
Detects successful Azure Active Directory (Entra ID) sign-ins using the device code flow where the originating device is neither registered nor trusted (managed or compliant), which may indicate suspicious authentication attempts or token abuse.
Sweeps Defender XDR telemetry for known NEBULA / KNTRAT indicators (SHA256 hashes, C2 IP, decoy domain and URLs, burner publisher emails). Hash matching is scoped per table (execution hash only in process events), noisy tooling is excluded from command-line matches, network hits are limited to connection events, and results are aggregated per device and IOC.
Detects unusual volumes of redirects through WebSEAL. Open or manipulable redirects
on an authentication gateway are valuable to an attacker: a link that genuinely
begins on the organisation's own trusted domain will survive scrutiny that an
external link would not.
Onboarding: ISAM-WEBSEAL is ingested via Syslog (Bloo extractor 85).
Integration guide: https://bloo.io/docs/hypercloud/syslog-connector
BQL (Bloo Query Language):
stream=webserver where sourcename='ISAM-WEBSEAL' and action='REQUEST_REDIRECTED'
| duration 1h
| groupby srcip, url, uriquery, returncode
on an authentication gateway are valuable to an attacker: a link that genuinely
begins on the organisation's own trusted domain will survive scrutiny that an
external link would not.
Onboarding: ISAM-WEBSEAL is ingested via Syslog (Bloo extractor 85).
Integration guide: https://bloo.io/docs/hypercloud/syslog-connector
BQL (Bloo Query Language):
stream=webserver where sourcename='ISAM-WEBSEAL' and action='REQUEST_REDIRECTED'
| duration 1h
| groupby srcip, url, uriquery, returncode
Detects requests through WebSEAL whose URI or query string carries exploitation
characteristics. As a reverse proxy, WebSEAL sees the full request before it reaches
the application, which makes it the right place to catch attempts against back-end
systems that log very little themselves.
Onboarding: ISAM-WEBSEAL is ingested via Syslog (Bloo extractor 85).
Integration guide: https://bloo.io/docs/hypercloud/syslog-connector
BQL (Bloo Query Language):
stream=webserver where sourcename='ISAM-WEBSEAL'
| groupby url, uriquery, method, returncode, srcip, useragent
characteristics. As a reverse proxy, WebSEAL sees the full request before it reaches
the application, which makes it the right place to catch attempts against back-end
systems that log very little themselves.
Onboarding: ISAM-WEBSEAL is ingested via Syslog (Bloo extractor 85).
Integration guide: https://bloo.io/docs/hypercloud/syslog-connector
BQL (Bloo Query Language):
stream=webserver where sourcename='ISAM-WEBSEAL'
| groupby url, uriquery, method, returncode, srcip, useragent
Detects a threat raised by Zscaler Private Access. Because ZPA mediates every
connection to an internal application, a threat on a session means hostile activity
reaching private applications from a device that already passed authentication —
which points at the endpoint rather than the perimeter.
Onboarding: ZSCALER-SPA is ingested via the Zscaler connector (Bloo extractor 176).
Integration guide: https://bloo.io/docs/integrations
BQL (Bloo Query Language):
stream=threat where sourcename='ZSCALER-SPA' and action='THREAT_DETECTED'
| groupby user, srcip, threat
connection to an internal application, a threat on a session means hostile activity
reaching private applications from a device that already passed authentication —
which points at the endpoint rather than the perimeter.
Onboarding: ZSCALER-SPA is ingested via the Zscaler connector (Bloo extractor 176).
Integration guide: https://bloo.io/docs/integrations
BQL (Bloo Query Language):
stream=threat where sourcename='ZSCALER-SPA' and action='THREAT_DETECTED'
| groupby user, srcip, threat
Page 7 of 235