VM-Packages
VM-Packages copied to clipboard
Add Suricata package for installation into the FLARE-VM
Details
I'd like to propose the inclusion of Suricata, primariy for the FLARE-VM. Suricata can run in offline mode, allowing for the consumption of PCAP to generate alerts or other network data (i.e. JA3/JA4,etc). This can be used in conjunction with tools like Fakenet, allowing for offline network generation and analysis.
Suricata provides an MSI installer: https://www.openinfosecfoundation.org/download/windows/Suricata-7.0.8-1-64bit.msi.
Rule sets will need to be added to the default rule path, which will be under C:\ProgramFiles\Suricata\rules. There are a few options for open-source/open license rule sets. ET Open is the largest and most popular: https://rules.emergingthreats.net/open/suricata-7.0.3/. AttackDetection is another: https://github.com/ptresearch/AttackDetection. And there are several options from AbuseCH: https://sslbl.abuse.ch/blacklist/.
To get an idea of how Suricata could be used in the FLARE-VM, I have a short video series on YouTube: https://www.youtube.com/playlist?list=PLHJns8WZXCdthheGdEpV4D_NdKTwcd_Xg. This would not only allow for increased detection opportunities, but the foundation of a custom rule writing workflow for those interested in creating their own rules. I hope this request found the right location and appreciate the consideration. Please let me know if you have any questions.
Thanks, Josh
Flare-VM is mainly made for reverse engineering malware and for simulating malware activity already package fakenet-ng is added. Suricata is tool more on the detection side of the work to check whether network behaviour of the malware is detected using the rule or not. It will require some discussion. Thanks for idea. @Ana06 will it be useful to add suricata to the package set?
yes, similar to how we use Yara and its rules to help detect capabilities, families, properties of different static artifacts, Suricata can apply rules to match in network traffic. The primary goal would be that those detections help an analyst more quickly identify malware family/capabilities, or add additional confidence to the static/dynamic analysis they are already doing. It does not need to run as a service (and therefore not become a resource concern), offline mode can be invoked on-demand and even a large rule set is relatively small in size (i.e. what it would consume on disk). Most major sandboxes include network detections (and many use Suricata), so I think it is a long overdue capability to have in the flare-vm :)
Thanks for all the details @jstrosch! I have no experience with Suricata, but @jstrosch is an experienced reverse engineer and if he finds the tool useful, I see no issue in adding a package in VM-Packages for it. If the increase in size is not significant (not sure if the rules are too big), we should also be able to add this package to FLARE-VM default configuration.
Because of the rules requirement, we need to create this package manually.
ππworking on it
I am categorizing this package as Networking.
There are a few options for public rule sets, Emerging Threats Open is the largest. This would be my recommendation for the rule file to download: https://rules.emergingthreats.net/open/suricata-7.0.3/emerging-all.rules. One problem with this approach is that the Suricata configuration through the MSI needs tweaking. Particularly, the file needs to be downloaded to the default rule location, which is C:\Program Files\Suricata\rules and the name of the file added under the rules-files section. We could additionally comment out the rest of the *.rules entries, as those files will only be present if added by the user but will only generate warnings during runtime. It's possible that we work with the Suri team to see if we can get the default configuration in the MSI build changed.
I also have a script that facilitates processing pcaps in offline mode: https://gist.github.com/jstrosch/0001299e348d18fbff51bfa3837125b0. This would be helpful to automate alert generating/development. Sharing in case there is a convenient way to add to the package.
Let me know how I can help!
@Ana06 observed a minor issue with the icon functionality
https://github.com/mandiant/VM-Packages/blob/54f0d4fe6543055bcde6928238023f08891a7c04/packages/common.vm/tools/vm.common/vm.common.psm1#L1757
It takes the ProductName from toolName variable and in this case the toolName is Suricata but in CimInstance list of installed products the tool is registered with name Suricata IDS/IPS 7.0.8-1-64bit as a result unable to get icon.
@PrajeetGuha what about relaxing the way we are looking for installed products to ensure it finds it? I think this code is only used in BinDiff, so as long as both keep working is ok. I recommend you send a PR, it is easier to discuss with the code. π
π€... @Ana06 I thought the code is called by all the packages that uses MSI installer and iconLocation is not provided. The code grabs the identifyingNumber to look for the folder in InstallerCache for possible icon file. We can possibly relax the searching condition by using -match in place of -like.
$installedProducts = Get-CimInstance -Class Win32_Product | Where-Object { $_.Name -match $ProductName }
@PrajeetGuha
I thought the code is called by all the packages that uses MSI installer and iconLocation is not provided. The code grabs the identifyingNumber to look for the folder in InstallerCache for possible icon file. We can possibly relax the searching condition by using -match in place of -like.
You are right, it is called by all packages that use MSI installer if iconLocation is not provided. But if I recall correctly, we introduce this code when introducing BinDiff and I am not sure if we tested the other packages (I think we didn't). I am also more concern about BinDiff because it is part of the FLARE-VM configuration and we are more careful with those packages (as breaking something there confuses many users). We should test this now and would go for the option that works for most packages (either using match or adding *). π
@Ana06, I think it will be better to track this changes in common.vm with a separate issue and I will put a separate PR to address that issue.
@PrajeetGuha the change in common is needed because of the addition of Suricata, so I don't think we need another issue to track it. I also think it is better to address that modification and the addition of Suricata in the same PR. This way we can test the changes together and ensure the modification in common works as expected. Please go ahead and send a PR with the changes so that we can provide feedback π
got carried away with the issue https://github.com/mandiant/VM-Packages/issues/1270, will work on it. π’
@Ana06 I think we can facilitate addition of rules in the same way as we add python libraries, by maintaining a xml configuration file from where the rule url as well as the rule name can be taken. This will allow us to just change the config file whenever we wish to add additional rules. Let me know if there is any other way you want me to approach the rule addition.