Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
2,303 detections
Filters
Last updated
All Time
Detection languages
2,251
22
21
7
2
Contributors
910
584
506
125
48
Categories
20,417
11,806
5,870
5,145
4,864
2,303
Platforms
2,190
209
168
62
61
Products / Services
2,250
2,159
163
32
31
MITRE Techniques
713
422
384
187
184
CVEs
17
12
12
12
10
IDS Classtypes
995
426
281
190
98
IDS Protocols
1,291
401
281
117
45
Detects successful authentication events using known default or low-privileged Cisco Firepower Management Center (FMC) service accounts, or IDS alerts (Snort SID 66883) associated with credential abuse activity potentially related to CVE-2026-20316.
This rule detects network traffic (DNS, TLS, HTTP, and TCP) originating from internal assets to known infrastructure associated with the QTFY proxy botnet/C2 framework. It identifies communication with specific C2 domains, proxy management systems, and associated malicious IP ranges.
Detects HTTP responses containing JavaScript-based anti-bot challenge patterns commonly used by phishing kits to identify and block automated crawlers, security scanners, and headless browsers.
Detects periodic outbound network connections from internal hosts to external networks, consistent with command-and-control beaconing behavior often observed in malware like BabylonRAT.
Detects HTTP response body content indicating the activation of a FlashProxy residential proxy by the GhostCode C2 harvester, based on geoip API responses.
This rule detects network activity associated with GhostCode phishing campaigns. It monitors for suspicious TLS SNI fields and HTTP Host headers matching known device-code phishing subdomain patterns (e.g., [service]-access-[8-chars].[domain]). Additionally, it detects requests to specific known malicious hostnames and high-entropy URI paths indicative of phishing kit redirects.
Detects HTTP traffic patterns associated with C2 infrastructure challenges, specifically looking for anti-bot/anti-scanner responses containing specific JavaScript variables ('badAgents', 'js_enabled=1') and subsequent client-side validation requests containing a specific token structure and 'check=1' parameter.
This rule detects potential BabylonRAT C2 beaconing activity by monitoring for recurring outbound HTTP GET requests using a 'Firefox' User-Agent string on non-standard HTTP ports. The threshold mechanism specifically flags repeated connections within a short time frame, which is characteristic of malware beaconing behavior.
This rule detects network traffic indicative of the PEEP Browser RAT, specifically HTTP beacons targeting the URI path '/api/commands'. It monitors for unique HTTP headers ('X-PEEP-Agent-Id', 'X-PEEP-Agent-Key') and connections to known malicious infrastructure.
Detects HTTP beaconing activity associated with the Kimsuky threat group (Stella_Gary), specifically identifying requests to the /unicorn/ path. This pattern is characteristic of their C2 communication mechanism, which masquerades as legitimate browsing.
Detects HTTP beaconing activity associated with the Kimsuky threat group (Stella_Gary), specifically identifying requests to the /unicorn/ path. This pattern is characteristic of their C2 communication mechanism, which masquerades as legitimate browsing.
Detects HTTP beaconing activity associated with the Kimsuky threat group (Stella_Gary), specifically identifying requests to the /unicorn/ path. This pattern is characteristic of their C2 communication mechanism, which masquerades as legitimate browsing.
Detects established network connections to a known Kimsuky-associated infrastructure (107.172.249.140) on port 443. The rule filters out standard TLS handshakes by inspecting initial packet content, targeting non-standard or custom-protocol traffic, and limits alerts to once per hour per source host to reduce noise.
Detects established network connections to a known Kimsuky-associated infrastructure (107.172.249.140) on port 443. The rule filters out standard TLS handshakes by inspecting initial packet content, targeting non-standard or custom-protocol traffic, and limits alerts to once per hour per source host to reduce noise.
Detects established network connections to a known Kimsuky-associated infrastructure (107.172.249.140) on port 443. The rule filters out standard TLS handshakes by inspecting initial packet content, targeting non-standard or custom-protocol traffic, and limits alerts to once per hour per source host to reduce noise.
Detects HTTP GET requests associated with the Kimsuky threat actor, specifically targeting the retrieval of payloads like uni.txt or files matching the test.bef_fri pattern from the /unicorn/ directory.
Detects HTTP GET requests associated with the Kimsuky threat actor, specifically targeting the retrieval of payloads like uni.txt or files matching the test.bef_fri pattern from the /unicorn/ directory.
Detects HTTP GET requests associated with the Kimsuky threat actor, specifically targeting the retrieval of payloads like uni.txt or files matching the test.bef_fri pattern from the /unicorn/ directory.
Detects outbound WebSocket upgrade requests from internal network assets to known IronToll C2 IP addresses, restricted to requests whose Host header ends in one of the disposable TLDs observed across the campaign's 73+ rotating lookalike domains (.cfd, .sbs, .shop, .icu, .buzz, etc). This narrows the alert to the campaign's actual phishing-domain pattern rather than any WebSocket traffic that happens to reach the same shared Tencent/Alibaba cloud IPs, and a per-source threshold caps repeat alerts from the same host to one per hour.
Detects country-coded lure path requests (/eg, /ma) followed by a cloaking differential response (desktop UA blocked with 404, mobile UA served content). Fixed a regex bug where the original pattern matched any path merely starting with 'eg' or 'ma' (e.g. /egg.jpg, /mail, /manifest.json) instead of the exact path segment.
Detects the Iron Man System kit's known template artifact path, and separately its randomized per-deployment admin-panel path shape combined with a Host header on a disposable TLD. Splitting these and requiring the disposable-TLD host on the generic admin-path rule avoids matching legitimate multi-tenant apps or hardened CMS installs that use similar random-path-plus-/admin/ obfuscation on ordinary domains.
Page 66 of 110