Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
40,045 detections
Filters
Last updated
All Time
Detection languages
15,346
13,598
2,797
1,803
1,721
Contributors
7,678
5,999
5,315
4,504
4,191
Categories
18,106
9,754
3,848
3,756
3,712
Platforms
40,045
7,313
6,542
3,903
3,660
Products / Services
10,431
9,678
6,722
1,887
1,878
MITRE Techniques
13,736
13,114
8,062
5,947
4,414
CVEs
49
45
30
30
29
IDS Classtypes
214
56
43
23
19
IDS Protocols
183
172
20
16
8
Detects endpoint, network, and security log activity matching known indicators of compromise (IOCs) associated with PEERSTITCH / CL-STA-0954, including specific file hashes, IP addresses, and URLs.
Detects endpoint, network, and security log activity matching known indicators of compromise (IOCs) associated with PEERSTITCH / CL-STA-0954, including specific file hashes, IP addresses, and URLs.
Sweeps file, process and image-load telemetry for known Kimsuky (APT-C-55) malware MD5 hashes. Exact hash matches carry very low false-positive risk.
Detects modification of HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Local AppData to a Windows kernel object namespace path such as \\.\globalroot\BaseNamedObjects\Restricted. The LegacyHive 0-day exploits this registry pivot to redirect UsrClass.dat loading via the Windows User Profile Service, achieving privilege escalation on all supported desktop and server versions with the July 2026 patch applied. No legitimate application redirects a user shell folder to a kernel namespace path.
Detects network connections, process command-line executions, and email URL info matching known APT28 (Swallowtail, HOOKEDGE, LegionRelay) indicators of compromise, including specific IP addresses and GUIDs.
Detects the execution of reverse engineering and decompilation tools such as JADX or Blutter against Android APK files or Flutter application binaries (libapp.so), as well as the creation of their typical output artifacts and staging folders.
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.
The following analytic detects the execution of processes with file or code signing attributes from known remote access software within the environment. It leverages Sysmon EventCode 1 data and cross-references a lookup table of remote access utilities such as AnyDesk, GoToMyPC, LogMeIn, and TeamViewer. This activity is significant as adversaries often use these tools to maintain unauthorized remote access. If confirmed malicious, this could allow attackers to persist in the environment, potentially leading to data exfiltration or further compromise of the network.
Detects the execution of rundll32.exe loading a DLL directly from common browser cache directories (Firefox, Chrome, or Edge), which is indicative of the SensePost cache-smuggling proof-of-concept technique.
Detects administrative login to the ePO console. An ePO administrator can change
protection policy, create exclusions and push software to every managed endpoint —
which makes this account one of the highest-value targets in any estate running it.
Onboarding: TRELLIX-EPO is ingested via RDBMS Log Shipper (Bloo extractor 857).
Integration guide: https://bloo.io/docs/integrations
BQL (Bloo Query Language):
stream=authentication where sourcename='TRELLIX-EPO' and action='LOGIN'
| groupby user, srcip, authproto
protection policy, create exclusions and push software to every managed endpoint —
which makes this account one of the highest-value targets in any estate running it.
Onboarding: TRELLIX-EPO is ingested via RDBMS Log Shipper (Bloo extractor 857).
Integration guide: https://bloo.io/docs/integrations
BQL (Bloo Query Language):
stream=authentication where sourcename='TRELLIX-EPO' and action='LOGIN'
| groupby user, srcip, authproto
Detects policy changes in Trellix ePolicy Orchestrator. ePO governs endpoint
protection across the estate, so weakening a policy there disables defences on many
machines at once — far more efficient for an attacker than tampering with hosts
individually, and visible only in ePO's own audit trail.
Onboarding: TRELLIX-EPO is ingested via RDBMS Log Shipper (Bloo extractor 857).
Integration guide: https://bloo.io/docs/integrations
BQL (Bloo Query Language):
stream=iam where sourcename='TRELLIX-EPO' and action='POLICY_UPDATED'
| groupby user, targetuser, role
protection across the estate, so weakening a policy there disables defences on many
machines at once — far more efficient for an attacker than tampering with hosts
individually, and visible only in ePO's own audit trail.
Onboarding: TRELLIX-EPO is ingested via RDBMS Log Shipper (Bloo extractor 857).
Integration guide: https://bloo.io/docs/integrations
BQL (Bloo Query Language):
stream=iam where sourcename='TRELLIX-EPO' and action='POLICY_UPDATED'
| groupby user, targetuser, role
Detects configuration changes to DLP policy. Weakening the policy — excluding a
channel, removing a classification, allowing a destination — opens an exfiltration
route for everyone it covers, and unlike most controls, DLP changes rarely trigger
any operational complaint to reveal them.
Onboarding: TRELLIX-DLP is ingested via Syslog (XML) (Bloo extractor 805).
Integration guide: https://bloo.io/docs/hypercloud/syslog-connector
BQL (Bloo Query Language):
stream=configuration where sourcename='TRELLIX-DLP'
and action='CONFIGURATION_CHANGED'
| groupby user
channel, removing a classification, allowing a destination — opens an exfiltration
route for everyone it covers, and unlike most controls, DLP changes rarely trigger
any operational complaint to reveal them.
Onboarding: TRELLIX-DLP is ingested via Syslog (XML) (Bloo extractor 805).
Integration guide: https://bloo.io/docs/hypercloud/syslog-connector
BQL (Bloo Query Language):
stream=configuration where sourcename='TRELLIX-DLP'
and action='CONFIGURATION_CHANGED'
| groupby user
Detects anomalous Kerberos ticket requests observed by ADAudit Plus. Service ticket
harvesting — one account requesting tickets for many services in quick succession —
is the precursor to offline cracking of service account credentials, and it is quiet
at the domain controller unless something is watching for the pattern.
Onboarding: MANAGE-ENGINE-ADAUDIT-PLUS is ingested via Syslog (KV) (Bloo extractor 830).
Integration guide: https://bloo.io/docs/hypercloud/syslog-connector
BQL (Bloo Query Language):
stream=win-audit where sourcename='MANAGE-ENGINE-ADAUDIT-PLUS'
and action='KERBEROS_AUTHENTICATION_TICKET_REQUESTED'
| duration 1h
| groupby user, domain
| select user, domain, count(*) as cnt
| having cnt > 20
harvesting — one account requesting tickets for many services in quick succession —
is the precursor to offline cracking of service account credentials, and it is quiet
at the domain controller unless something is watching for the pattern.
Onboarding: MANAGE-ENGINE-ADAUDIT-PLUS is ingested via Syslog (KV) (Bloo extractor 830).
Integration guide: https://bloo.io/docs/hypercloud/syslog-connector
BQL (Bloo Query Language):
stream=win-audit where sourcename='MANAGE-ENGINE-ADAUDIT-PLUS'
and action='KERBEROS_AUTHENTICATION_TICKET_REQUESTED'
| duration 1h
| groupby user, domain
| select user, domain, count(*) as cnt
| having cnt > 20
Detects mail being redirected to an external recipient. Redirection rules are the
classic persistence mechanism on a compromised mailbox: they survive password resets,
require no further access, and quietly copy correspondence to the attacker for as
long as they remain in place.
This is among the most under-monitored controls in most estates, because the rule is
set once and never fires an alert again.
Onboarding: MS-EXCHANGE is ingested via Syslog (Bloo extractor 142).
Integration guide: https://bloo.io/docs/hypercloud/syslog-connector
BQL (Bloo Query Language):
stream=email-gateway where sourcename='MS-EXCHANGE'
and action='EMAIL_REDIRECTED'
| groupby sender, recipient, direction, remoteip
classic persistence mechanism on a compromised mailbox: they survive password resets,
require no further access, and quietly copy correspondence to the attacker for as
long as they remain in place.
This is among the most under-monitored controls in most estates, because the rule is
set once and never fires an alert again.
Onboarding: MS-EXCHANGE is ingested via Syslog (Bloo extractor 142).
Integration guide: https://bloo.io/docs/hypercloud/syslog-connector
BQL (Bloo Query Language):
stream=email-gateway where sourcename='MS-EXCHANGE'
and action='EMAIL_REDIRECTED'
| groupby sender, recipient, direction, remoteip
This rule detects devices with a BIOS release date older than 730 days (2 years), which could indicate unpatched or outdated firmware posing security and stability risks.
Generic rule content from file: Iranian APT - Blinder Tunnel - MicrosoftRuntime Run Key Persistence.cql
This rule performs a sweep across device file and network events for indicators of compromise (IOCs) associated with the UAT-11587/Antino campaign. It detects malicious file hashes, specific C2 domain connections, and known lure URLs (HTA/WSF) identified by Cisco Talos.
Detects a renamed PSF-signed pythonw.exe (with an original file name of pythonw.exe but a different on-disk name) launched from a user-writable path under Users. The command line consists only of its own path, which is consistent with ._pth based path configuration abuse for loading attacker code stealthily.
Detects when a single rules or all of the rules have been deleted from the Windows Defender Firewall
Detects msiexec.exe executing an MSI package named update_ms.msi
staged in ProgramData. Chaos ransomware disguises this installer's properties
and filename to impersonate a legitimate Windows Update package. On execution,
a custom action (CA_Run_EA2AEBC3) loads an embedded DLL (Bin_lib_EA2AEBC3,
lib.dll) directly into memory, deploying the msaRAT payload. This rule sees
the installer execution only; the in-memory module load is not observed here
and would need a separate PROCESS_MODULE_LOAD rule.
staged in ProgramData. Chaos ransomware disguises this installer's properties
and filename to impersonate a legitimate Windows Update package. On execution,
a custom action (CA_Run_EA2AEBC3) loads an embedded DLL (Bin_lib_EA2AEBC3,
lib.dll) directly into memory, deploying the msaRAT payload. This rule sees
the installer execution only; the in-memory module load is not observed here
and would need a separate PROCESS_MODULE_LOAD rule.
Detects Chrome or Edge being launched in headless mode with the
remote debugging port flag enabled. msaRAT (Chaos ransomware) uses this to spawn
a hidden browser instance it then manipulates via Chrome DevTools Protocol (CDP)
to inject JavaScript, hijack browser functionality, and build a covert WebRTC
C2 channel that never touches the network directly from the malware process.
remote debugging port flag enabled. msaRAT (Chaos ransomware) uses this to spawn
a hidden browser instance it then manipulates via Chrome DevTools Protocol (CDP)
to inject JavaScript, hijack browser functionality, and build a covert WebRTC
C2 channel that never touches the network directly from the malware process.
Page 26 of 1907