{"id":89,"date":"2022-07-22T14:45:29","date_gmt":"2022-07-22T14:45:29","guid":{"rendered":"https:\/\/idstower.com\/blog\/?p=89"},"modified":"2026-10-19T02:52:28","modified_gmt":"2026-10-19T02:52:28","slug":"configuring-suricata-ids-to-alert-on-malicious-file-hashes","status":"publish","type":"post","link":"https:\/\/idstower.com\/blog\/configuring-suricata-ids-to-alert-on-malicious-file-hashes\/","title":{"rendered":"Configuring Suricata IDS to alert on Malicious File Hashes"},"content":{"rendered":"\n
\n

Updated October 2026:<\/strong> ThreatFox now requires a free Auth-Key and returns at most the last seven days of IOCs.<\/p>\n<\/blockquote>\n\n\n\n

Continuing our posts on why<\/a> and how to alert on Indicators of Compromise with Suricata’s Datasets<\/a>, this post shows how to alert on known-malicious files seen on the network, using SHA256 hashes published by abuse.ch ThreatFox<\/a>.<\/p>\n\n\n\n

But first: why use hashes as IOCs at all, when attackers can change them so easily?<\/p>\n\n\n\n

Why hash IOCs are still relevant today<\/h2>\n\n\n\n

Relying only on malicious file hashes won’t make a solid defence, but as an extra detection angle they help, for three reasons.<\/p>\n\n\n\n

1. Hash IOCs are everywhere<\/h3>\n\n\n\n

Most, if not all, commercial and free threat intelligence feeds publish hash IOCs. Traditionally they go into EDR and antivirus tools to block malicious files on endpoints. Suricata lets you do the same at the network level, which also covers servers, IoT devices and anything else without an EDR agent.<\/p>\n\n\n\n

2. Not every attacker is that advanced<\/h3>\n\n\n\n

Once a system is on the internet, it will see threats of every kind. Some may come from a real APT, but most will be opportunistic attacks by criminals who reuse published malware and tools without changing their hashes. That’s a detection opportunity: attackers aren’t invincible, and we should use that.<\/p>\n\n\n\n

3. Hashes have no false positives<\/h3>\n\n\n\n

Unlike IDS signatures, which can produce false positives for many reasons, a file’s hash either matches a known-bad hash or it doesn’t. As long as you trust your feed, a match means you saw that exact file.<\/p>\n\n\n\n

How Suricata detects files by hash<\/h2>\n\n\n\n

Suricata extracts files<\/a> from several protocols, including HTTP, HTTP\/2, SMTP, FTP, SMB and NFS, and can hash them as they pass. Rules then match the hash with the filemd5<\/code>, filesha1<\/code> and filesha256<\/code> keywords<\/a>. Which one you use depends on the hashes your feeds publish. This post sticks to SHA256, today’s standard.<\/p>\n\n\n\n

We used Ubuntu 24.04 with Suricata 8.0 (Ubuntu install guide<\/a>), and ran the same steps on Suricata 7.0.<\/p>\n\n\n\n

Before you start: get a ThreatFox Auth-Key<\/h2>\n\n\n\n

ThreatFox requires an Auth-Key<\/code> header on every API request; without one, the API answers 401 Unauthorized<\/code>. Keys are free: sign in to the abuse.ch Authentication Portal<\/a> and generate one from your profile.<\/p>\n\n\n\n

You’ll also need curl<\/code> and jq<\/code>:<\/p>\n\n\n\n

sudo apt install -y curl jq<\/code><\/pre>\n\n\n\n
Preparing the hash list<\/h2>\n\n\n\n
Put your key in a variable, then download the last seven days of IOCs from the ThreatFox API<\/a>:<\/p>\n\n\n\n
export THREATFOX_AUTH_KEY='your-auth-key'\n\ncurl -s -X POST https:\/\/threatfox-api.abuse.ch\/api\/v1\/ \\\n  -H \"Auth-Key: ${THREATFOX_AUTH_KEY}\" \\\n  -d '{ \"query\": \"get_iocs\", \"days\": 7 }' > iocs_list.json<\/code><\/pre>\n\n\n\n
days<\/code> accepts 1 to 7; any other value returns illegal_days<\/code>. For older indicators, ThreatFox publishes export files<\/a>, which need the same key.<\/p>\n\n\n\n
Check that ThreatFox accepted the request. Without a key you get {\"error\": \"Unauthorized\"}<\/code>, and with a key ThreatFox doesn’t recognise, {\"query_status\": \"unknown_auth_key\"}<\/code>; neither contains any IOCs:<\/p>\n\n\n\n
jq -e '.query_status == \"ok\"' iocs_list.json<\/code><\/pre>\n\n\n\n
Then extract the SHA256 hashes and copy the list next to your rules:<\/p>\n\n\n\n
jq -r '.data[] | select(.ioc_type == \"sha256_hash\") | .ioc' iocs_list.json | sort -u > threatfox_sha256.lst\nwc -l threatfox_sha256.lst\n\nsudo mkdir -p \/etc\/suricata\/rules\nsudo install -m 644 threatfox_sha256.lst \/etc\/suricata\/rules\/<\/code><\/pre>\n\n\n\n
Make sure the list isn’t empty: Suricata refuses to load a filesha256<\/code> rule whose list has no entries.<\/p>\n\n\n\n
Creating the Suricata rule<\/h2>\n\n\n\n
alert http any any -> any any (msg:\"ThreatFox IOC: malicious file transferred over HTTP\"; flow:established; filesha256:\/etc\/suricata\/rules\/threatfox_sha256.lst; classtype:trojan-activity; sid:1000002; rev:1;)<\/code><\/pre>\n\n\n\n
The rule alerts when a file whose SHA256 is in the list crosses the network over HTTP, in either direction. The filesha256<\/code> keyword also makes Suricata compute the hash, so nothing else needs switching on. To cover other protocols, copy the rule and change http<\/code> to http2<\/code>, smtp<\/code>, ftp-data<\/code>, smb<\/code> or nfs<\/code>, giving each copy its own sid<\/code>.<\/p>\n\n\n\n
Save the rule in its own file:<\/p>\n\n\n\n
sudo tee \/etc\/suricata\/rules\/iocs.rules > \/dev\/null <<'EOF'\nalert http any any -> any any (msg:\"ThreatFox IOC: malicious file transferred over HTTP\"; flow:established; filesha256:\/etc\/suricata\/rules\/threatfox_sha256.lst; classtype:trojan-activity; sid:1000002; rev:1;)\nEOF<\/code><\/pre>\n\n\n\n
Then add that file to rule-files<\/code> in \/etc\/suricata\/suricata.yaml<\/code>. Use its absolute path and leave default-rule-path<\/code> as it is, because suricata-update<\/code> keeps writing suricata.rules<\/code> there (\/var\/lib\/suricata\/rules<\/code> on current packages):<\/p>\n\n\n\n
default-rule-path: \/var\/lib\/suricata\/rules\n\nrule-files:\n  - suricata.rules\n  - \/etc\/suricata\/rules\/iocs.rules<\/code><\/pre>\n\n\n\n
Let Suricata see whole files<\/h2>\n\n\n\n
This is the step the first version of this post missed. Suricata can only hash a file it has seen from start to finish, and two default settings cut files short:<\/p>\n\n\n\n