Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,937 detections
Filters
Last updated
All Time
Detection languages
1,930
3
2
1
1
Contributors
592
477
360
250
124
Categories
995
927
834
546
538
Platforms
1,753
214
81
54
41
Products / Services
1,868
1,144
65
51
17
MITRE Techniques
564
412
305
201
175
CVEs
4
4
4
2
2
IDS Classtypes
1,937
503
461
381
236
IDS Protocols
1,098
362
201
171
37
Detects DNS queries and TLS SNI traffic directed towards known malicious domains associated with passkey and SSO phishing campaigns, specifically attributed to Storm-3121 and Storm-3032. These domains are used to deceive users into providing credentials or authentication tokens via fraudulent login portals.
Detects repeated manual HTTP GET requests from many distinct source IPs to a canary token resource. The URI pattern follows a format indicative of a tracked canary token resource, and the threshold of 49 unique source IPs accessing the resource within a prolonged period suggests potential unauthorized reconnaissance or probing activities.
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 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 outbound HTTP requests to known Kimsuky command and control (C2) infrastructure associated with the Stella_Gary campaign. The rule monitors for specific URI patterns ('/unicorn/mort.php' or '/unicorn/uni.txt') commonly used by this threat actor for beaconing.
Detects outbound HTTP requests to known Kimsuky command and control (C2) infrastructure associated with the Stella_Gary campaign. The rule monitors for specific URI patterns ('/unicorn/mort.php' or '/unicorn/uni.txt') commonly used by this threat actor for beaconing.
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 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 the Iron Man System phishing kit via its HTTP fingerprint: a request-header rule (ETag/Server/Via combo) checked on the external server's response, and three request-side rules checking for the kit's hashed asset paths and favicon when an internal host requests them from an external site. Fixed a direction bug on the three request-side rules that had source/destination reversed (they previously required an external host to request the path from an internal server, which would rarely if ever fire).
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.
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 38 of 93