Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
2,588 detections
Filters
Last updated
All Time
Detection languages
1,194
459
310
204
161
Contributors
487
455
323
171
123
Categories
1,884
937
415
400
360
Platforms
1,349
560
343
329
257
Products / Services
601
314
306
286
271
MITRE Techniques
18,116
15,638
12,585
8,395
6,225
2,588
CVEs
9
5
5
5
2
IDS Classtypes
142
96
49
11
6
IDS Protocols
177
49
44
17
4
This rule detects outbound network connections to a predefined list of suspicious cloud storage and file-sharing services. These services are often used by adversaries for exfiltration of collected data, providing a covert channel due to their common use and potential for SSL/TLS encryption. The rule specifically looks for `RemoteUrl` containing any of the domains listed in `suspiciousexfildomains`.
Detects the use of Rclone to exfiltrate data to a Wasabi cloud storage bucket. This technique was observed being used by the Iranian APT group Seedworm.
This rule detects network connections to known pastebin and text storage sites initiated by processes that are not common web browsers. This could indicate data exfiltration, staging of malicious code, or command and control activity where sensitive information is uploaded or retrieved by non-standard applications.
Detects the use of curl.exe where the User-Agent string contains a URL pointing to temp.sh. This specific TTP was observed in the Notepad++ supply chain attack (Chrysalis infection chain) to exfiltrate system information and signal the uploaded file's location to the C2 server.
This rule detects network communication with known AI model providers by checking `RemoteUrl` against a list of AI API URLs from an external CSV file. It aims to identify potential unauthorized use of AI services, data exfiltration to AI models, or to monitor AI usage within an environment.
This rule is meant to help analysts quickly spot a high-confidence indicator related to Google ShinyHunters SaaS Defense Guidance. It is written to be easy to understand and to keep false alarms low by focusing on a very specific match: rclone used with copy/sync style commands to move data to a remote destination. A match does not automatically prove an attacker is currently active, and it does not prove a file was executed, but it does mean the event is important because it lines up with a public threat intelligence source. When this triggers, start by identifying the host, user, and timeframe involved, then decide whether the activity is expected for that system. If it is unexpected, preserve the related logs and any files, and look for nearby events that could explain how the indicator appeared, such as a download, a new process, or a new connection. If the same indicator appears on multiple systems, treat it as a scoping signal and expand the investigation window. Use the reference link (https://cloud.google.com/blog/topics/threat- intelligence/defense-against-shinyhunters-cybercrime-saas) to document where the indicator came from and to support incident notes and reporting.
This rule is meant to help analysts quickly spot a high-confidence indicator related to Google ShinyHunters SaaS Defense Guidance. It is written to be easy to understand and to keep false alarms low by focusing on a very specific match: AWS CLI performing S3 sync or copy commands that can be used for bulk export. A match does not automatically prove an attacker is currently active, and it does not prove a file was executed, but it does mean the event is important because it lines up with a public threat intelligence source. When this triggers, start by identifying the host, user, and timeframe involved, then decide whether the activity is expected for that system. If it is unexpected, preserve the related logs and any files, and look for nearby events that could explain how the indicator appeared, such as a download, a new process, or a new connection. If the same indicator appears on multiple systems, treat it as a scoping signal and expand the investigation window. Use the reference link (https://cloud.google.com/blog/topics/threat- intelligence/defense-against-shinyhunters-cybercrime-saas) to document where the indicator came from and to support incident notes and reporting.
With OAuth 2.0 Device Code Flow phishing campaigns actively targeting M365 environments in financial services and beyond, I built a cross-phase KQL detection rule that moves beyond the obvious deviceCode protocol filter — because the real damage happens in tables most hunts never look at.
The rule correlates three phases across both SigninLogs and AADNonInteractiveUserSignInLogs:
Phase 1 catches victim-side device code authentications, filtering out primaryRefreshToken (enrolled devices) and known low-risk resources to cut noise at the source.
Phase 2 surfaces non-interactive single-factor token replay activity — this is where the attacker's stolen OAuth token actually appears, silently blending into background API traffic.
Phase 3 identifies post-compromise Graph/mail resource access across anomalous IP counts — the data exfiltration and BEC staging layer.
The key design decisions that make it production-ready: a cross-phase inner join so only users appearing in Phase 1 and Phase 2 surface at all, a MinutesToReplay temporal constraint (>= 0 and <= 2880) to eliminate false correlations where phases are coincidental rather than causal, and a composite risk score with banded severity output.
Tested against 90 days of real tenant data. Came back clean after tuning — which is the outcome you want before deploying as a scheduled analytics rule.
The rule correlates three phases across both SigninLogs and AADNonInteractiveUserSignInLogs:
Phase 1 catches victim-side device code authentications, filtering out primaryRefreshToken (enrolled devices) and known low-risk resources to cut noise at the source.
Phase 2 surfaces non-interactive single-factor token replay activity — this is where the attacker's stolen OAuth token actually appears, silently blending into background API traffic.
Phase 3 identifies post-compromise Graph/mail resource access across anomalous IP counts — the data exfiltration and BEC staging layer.
The key design decisions that make it production-ready: a cross-phase inner join so only users appearing in Phase 1 and Phase 2 surface at all, a MinutesToReplay temporal constraint (>= 0 and <= 2880) to eliminate false correlations where phases are coincidental rather than causal, and a composite risk score with banded severity output.
Tested against 90 days of real tenant data. Came back clean after tuning — which is the outcome you want before deploying as a scheduled analytics rule.
Detects network connections from the Claude Code CLI ('claude' or 'claude.exe') to a destination other than the official 'api.anthropic.com' endpoint. This indicates that the 'ANTHROPIC_BASE_URL' environment variable has likely been overridden by a malicious '.claude/settings.json' configuration file in an attempt to intercept and exfiltrate API keys, as described in CVE-2026-21852.
Detects network traffic to a known StegaBin C2 IP address or specific URI paths used for data exfiltration. This activity is associated with multiple modules of the StegaBin infostealer toolkit.
Detects the execution of rsync using GSocket-based user-space tunnels (gs-dbus, gs-netcat) as the transport shell. This is a core, stealthy exfiltration technique used by the ShadowHS framework to bypass traditional network inspection and firewall rules.
This rule detects various indicators associated with a developer-targeting campaign, including Node.js fetching remote JavaScript from untrusted PaaS domains, dynamic loader behavior in next.config.js, repeated beaconing to C2 paths, detached child Node interpreters, directory enumeration and exfiltration behavior, and suspicious access to sensitive files on developer machines.
This rule set detects various stages of activity related to the 'OpenClaw' malware family and associated campaigns. It includes detection for OpenClaw process execution, exposure of a specific administrative port, execution of shell commands via curl (ClawHavoc delivery), outbound webhook exfiltration, and infostealer access to OpenClaw configuration files.
Detects network connections to known Command and Control (C2) infrastructure associated with the APT37 Ruby Jumper campaign. This includes the C2 IP address for the FOOTWINE backdoor and the Zoho WorkDrive Client ID used by the RESTLEAF implant for exfiltration.
Detects non-browser processes making outbound connections to specific Google Sheets API endpoints used by the GRIDTIDE backdoor for command and control. This activity is indicative of the malware using legitimate cloud services to disguise its C2 traffic.
This rule detects PowerShell commands used to encode data (like hostnames) into hexadecimal strings and exfiltrate it via DNS queries to known Out-of-Band Application Security Testing (OAST) domains. This technique is used by attackers to bypass egress filtering and confirm system compromise, as seen in the exploitation of CVE-2026-1731.
Detects archiving of OpenClaw workspace data which may contain plaintext conversations and secrets, consistent with collection and staging for exfiltration.
Detects the creation of files within hidden folders on removable media that are designed to mimic the Windows Recycle Bin ($RECYCLE.BIN or $RECYCLE.BIN.USER). This technique is used by APT37's THUMBSBD and VIRUSTASK malware to stage malicious files (.rb, .dat) for bridging air-gapped networks.
Detects outbound network traffic to a known Atomic macOS Stealer (AMOS) command and control (C2) server. This activity is associated with the exfiltration of stolen data, such as credentials, browser data, and system information, compressed into a ZIP archive.
Detects outbound SMTP connections from processes that are not typical mail clients, a technique used by malware like Agent Tesla to exfiltrate stolen data. This rule specifically looks for .NET utilities known to be abused in process hollowing attacks.
This rule detects various stages of the CastleLoader malware activity, including C2 communication, process hollowing using AutoIt and jsc.exe, and known malware hashes. It correlates network traffic to a specific C2 server, identifies suspicious process creation patterns where AutoIt launches jsc.exe, and sweeps for known SHA256 hashes associated with CastleLoader.
Page 87 of 124