Had this alert come up today and while there was a download of data there wasn’t any malicious malware detected (MS defender) so I am wondering if this md5 hash isn’t accurate?
alert tcp $EXTERNAL_NET 20000: → $HOME_NET 1024: (msg:“ET MALWARE Sourtoff Receiving Simda Payload”; flow:established,from_server; flowbits:isset,ET.TROJAN.Sourtoff; dsize:1300<>1500; content:“|0a c0|”; depth:2; reference:md5,5469af0daa10f8acbe552cd2f1f6a6bb; classtype:trojan-activity; sid:2019313; rev:3; metadata:created_at 2014_09_29, former_category TROJAN, updated_at 2018_01_08;)
I did check the md5 here MD5: 5469AF0DAA10F8ACBE552CD2F1F6A6BB - Anti-Virus Cloud Engine MALWARE: Trojan-Ransom.Win32.Foreign.Ofiz
Is there a known issue with Suricata not detecting file hashes correctly?
Hey @bigjohns97 ,
Do you have a pcap or a eve.json file you can share? This signature includes the hash as a reference as opposed of searching for a file hash in transit. While Suricata has the ability to check file hashes we don’t utilize this functionality in our ruleset.
For this signature to trigger, it relies on the “flowbit” ET.TROJAN.Sourtoff to be set. Essentially, another signature needs to be triggered first to set a flag. If the flag is set and the conditions in this signature match, an alert will be generated. To address a false positive like this, it may be necessary to adjust one or both of these signatures. Any additional information you can provide will help us make the adjustments in the appropriate place.
In signatures you will see the following syntax for handling flowbits:
flowbits:set,<flowbit name> - This will set the flag that other signatures can utilize in their detection logic.
flowbits:isset,<flowbit name> - Signatures will us the isset option to check if the flag is set.
For reference, 2019313 is the signature that sets the flowbit:
alert tcp $HOME_NET ![23,25,80,137,139,445] -> $EXTERNAL_NET 20000: (msg:"ET MALWARE Sourtoff Download Simda Request"; flow:established,to_server; dsize:18; content:"|0a 10|"; depth:2; flowbits:set,ET.TROJAN.Sourtoff; flowbits:noalert; reference:md5,5469af0daa10f8acbe552cd2f1f6a6bb; classtype:trojan-activity; sid:2019312; rev:3; metadata:created_at 2014_09_29, updated_at 2019_01_10;)
Thanks,
Isaac
I do not have eve json logging set in my suricata instance running of pfsense.
I would like to enable this, can you confirm these settings would capture the necessary info should this happen again?
I think that should be perfect but I’m not sure if anything in this section needs to be checked, it should become clear though after your next couple of alerts. This rule is just looking at raw tcp so it wouldn’t fall into any of those categories. It’s been awhile since I’ve used pfsense so let me know if you aren’t seeing any logs after this and I’ll spin up an instance so we can figure it out 
Did some more research from here 15.1.1. Eve JSON Output — Suricata 6.0.0 documentation
Ended up going with the following config.
Should be able to get a packet dump, tracked file md5, as well as any extended TLS data with this setup. I’ll get the needed data next time.
