Daniel Jeremiah
@daniyyellUnited KingdomTrusted contributorCompletionist
8 followers4,600 downloads2,430 copies68 likes128,312 views
978 detections
Filters
Last updated
All Time
Detection languages
303
179
131
120
97
Categories
317
280
168
139
136
Platforms
669
130
98
61
39
Products / Services
112
54
50
48
38
MITRE Techniques
370
280
196
192
187
CVEs
35
7
4
4
4
IDS Classtypes
11
3
2
1
IDS Protocols
11
2
2
1
1
This rule detects the execution of ELF binaries from user-writable directories within the home folder, specifically targeting paths containing '/.local/bin/'. It aims to identify potentially malicious programs, such as clipboard hijackers, that are dropped and launched by a user. The rule filters out common packaging paths like '/snap/' and '/flatpak/' to reduce false positives.
This rule detects the creation of a scheduled task named 'WSPrint' that executes 'C:\ProgramData\WSPrint\WSPrint.exe' at system startup. This specific pattern is associated with the persistence mechanism described in the Cisco Talos UAT-9244 report. The rule focuses on the 'schtasks.exe' process creating a task with these specific parameters to avoid generic scheduled task alerts.
This rule detects the creation of specific batch files ("non.bat" or "spol.bat") within the Windows Startup folder (`\Microsoft\Windows\Start Menu\Programs\Startup`). This activity is indicative of persistence, as files placed in this location will execute automatically when a user logs in, potentially associated with the VoidGeist malware chain.
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: a DNS lookup to a specific domain mentioned in the report. 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 detects the creation of specific batch files, 'spol.bat' or 'non.bat', within the Windows Startup folder. This activity is indicative of persistence, as these files will execute automatically when a user logs in, allowing an attacker to re-establish control or continue malicious operations. The rule specifically targets these filenames and the Startup folder path to reduce false positives and focus on a known persistence mechanism used by the VoidGeist threat chain.
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 WinRAR CVE-2025-8088 Exploitation. It is written to be easy to understand and to keep false alarms low by focusing on a very specific match: WinRAR launching a command shell or scripting engine. 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/exploiting-critical-winrar- vulnerability) 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 AuraInspector Salesforce Aura Audit. It is written to be easy to understand and to keep false alarms low by focusing on a very specific match: an HTTP POST to a Salesforce /aura endpoint that includes specific Aura method strings. 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/auditing-salesforce-aura-data-exposure) to document where the indicator came from and to support incident notes and reporting.
Detect .NET hollowing technique
Suricata
.NET hollowing technique - external fetch of InstallUtil.exe (rare)
Claude Code project file abuse (CVE-2025-59536)
Page 66 of 98