No alert triggered on Malicious Files Hashes but found different hash value in eve.json

Rules
,
1

Hello There!
suricata.yaml (73.2 KB)

I am currently working on analyzing PCAP files for potential threats, specifically focusing on rule-triggering behavior. I have encountered an interesting situation.

I have attached two PCAP files with my yaml file and rule for your review:

alert http any any → any any (msg:“testing SHA256 key word”; filesha256:sha256_iocs.list; sid:04;)

The first file, PDF.pcap, was downloaded from the internet(File store of suricata ). After extracting the SHA256 hash from Suricata’s EVE JSON output and adding it to my IOC.list file, I tested the above rule that successfully triggered an alert.

However, when I performed the same process with the Cerber.pcap file, I encountered a different result. Despite extracting a different SHA256 hash from the Cerber.pcap file’s EVE JSON output and adding it to my IOC.list file, the same rule did not trigger an alert.

I conducted additional tests on two more files, extracting their SHA256 hashes using the ‘sha256sum’ command for both ‘.exe’ and ‘.pdf’ files. I added these SHA256 hashes to my IOC.list and tested the rule again.

However, I encountered an issue where the rule did not trigger any alerts. Upon reviewing the EVE JSON output, I noticed that it generated different SHA256 hashes compared to the ones I had extracted using the ‘sha256sum’ command.

In an attempt to resolve this inconsistency, I copied both sets of SHA256 hashes from the EVE JSON output and pasted them into my IOC list. Unfortunately, even after this adjustment, the rule still did not trigger any alerts.

I am currently uncertain about the reason behind this discrepancy. The EVE JSON output shows different hashes from what I extracted externally using ‘sha256sum,’ yet the rule fails to alert as expected. Any insights or guidance on this matter would be greatly appreciated.

Warm regards,
pdf_http_467659.pcap (12.3 KB)
cerberTest12.pcap (698.5 KB)
suricata(1).yaml (73.2 KB)

2

Hi @alee_na !
Thank you for your report! Could you please also share the version of Suricata that you’re running?
Your config file says suricata-6.0.10, is that correct? If yes, I’d request you to please try 6.0.14 as several bug fixes are made in between these releases. Let me know in the same thread if the problem persists.

1 Like
3

No, Its 6.0.14 version.
I conducted some additional tests and reached the conclusion that the rule is working fine for TXT, PDF, and image files. However, it’s not triggering for executable files, and even the SHA-256 hash of the exe file changes in the eve.json output.

Could you also please explain how the “filestore” keyword is saving data to its folder for executable files?

4

I can confirm that the alert does not trigger on Suricata 6.0.14 and Suricata 7.0.1 in my tests. But I can’t confirm the changing sha256 sum. It’s always the same:

{
  "timestamp": "2023-09-13T11:18:50.191835+0200",
  "flow_id": 609891360108033,
  "pcap_cnt": 189,
  "event_type": "fileinfo",
  "src_ip": "192.168.2.148",
  "src_port": 8080,
  "dest_ip": "10.0.2.15",
  "dest_port": 42424,
  "proto": "TCP",
  "pkt_src": "wire/pcap",
  "http": {
    "hostname": "192.168.2.148",
    "http_port": 8080,
    "url": "/download/cerber.exe",
    "http_user_agent": "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/117.0",
    "http_content_type": "application/octet-stream",
    "http_method": "GET",
    "protocol": "HTTP/1.1",
    "status": 200,
    "length": 116446
  },
  "app_proto": "http",
  "fileinfo": {
    "filename": "cerber.exe",
    "gaps": false,
    "state": "TRUNCATED",
    "sha256": "3879613e30b39ee0812aea82a154433b1e9d790b91994c559f3ff0f339fd067e",
    "stored": true,
    "file_id": 1,
    "size": 102400,
    "tx_id": 0
  }
}

If I force filestore and sha256sum the file on the disk, I also get the 3879613e30b39ee0812aea82a154433b1e9d790b91994c559f3ff0f339fd067e hash.

It could be related to the TRUNCATED state.

In the cerberTest12.pcap it did work for

42d84db9818ba4cb09b79ef70551ca9ca81e89ef7bd9726c3059b4c77758a692
cab123d6accaa527e73dec97c087774f16cedab0462ccd4d4c86eb8ee33a8d0f
a705cdaa6bbe0a9730d53ac556f760f43f6464c11e241e8f32db33437bc357a4

Those file events did trigger an alert if the hashes were added. If you look into the fileinfo events for those, they are NOT truncated.

5

Thank you for confirming, Sir. I appreciate your assistance with this.

Since the alert isn’t triggering as expected, I’d like to explore potential solutions or further debugging steps. Could you please share any insights or suggestions you might have for troubleshooting this issue? Your expertise would be extremely helpful in resolving this matter

6

I would recommend creating a bug report at redmine https://redmine.openinfosecfoundation.org/

7

Thank you, Sir.
I also wanted to inform you that I’ve tested my work on the Suricata 5.0 version, and the rule worked perfectly.