Overview
When developing an IDS signature, it is common to ask questions such as: "Does the rule alert as expected on our sensor(s)?", "Why doesn't this rule work?", or “What about this other sensor / version?”. By answering these questions, security analysts can debug and fine-tune their signatures to ensure they accurately identify and alert on threats while minimizing false positives. Therefore, it is crucial to thoroughly test and validate IDS signatures before deploying them in production environments to avoid missed detections or unnecessary alerts.
This is where tools like Dalton come in handy. Developed by Secureworks, Dalton is an open-source system that can quickly and easily create, and test packet captures for intrusion detection systems (e.g Snort and Suricata). It provides an intuitive web-based interface to configure and run IDS engines with user-provided packet captures, rulesets (pre-defined or custom), and configuration files. Dalton also has an API that allows users to retrieve submitted jobs and their results programmatically, making it easy to integrate with existing workflows or automation tools.
Some of the most common use cases for Dalton includes,
- Testing Rulesets/Ruleset Coverage. An organization may use Dalton to test a newly acquired Suricata ruleset against packet captures from their network traffic to ensure that it is effective in detecting any potential threats
- Troubleshooting and Developing Signatures. An organization may use Dalton to create and test a custom signature that detects a specific types of network traffic unique to their organization, as well as to test new signatures against known malicious traffic to verify if the signature triggers an alert
- Testing Variable Changes. An organization may use Dalton to test the impact of changing the threshold of a rule from "1" to "2" to see if it reduces the number of false positives
- Testing Configuration Changes. An organization may use Dalton to test the impact of enabling or disabling certain features in Suricata's configuration file to optimize the detection of network traffic
- Testing specific IDS engine behavior. An organization may use Dalton to test the effectiveness of Suricata and Snort in detecting the same packet capture to determine which engine is better suited for their environment
Installation
Installing Dalton is quite simple. Download the repository from the Dalton’s GitHub page, navigate to the root of the repository, and run the command `./start-dalton.sh`. This will launch Dalton as a group of Docker containers.
git clone https://github.com/secureworks/dalton.git
cd dalton
./start-dalton.shThen navigate to http://<docker-host>/dalton
By default, Dalton installs the latest version Suricata, Suricata 5.0.7, Snort 2.9.18, and Zeek. If you’d like to configure specific sensors or rulesets, you can check Dalton’s documentation.
Information Gathering
In this demonstration, we will perform network analysis to detect malware and develop custom signatures with the help of Dalton. To follow along, you can download the pcap file from this link.
Using Wireshark, we discovered a suspicious HTTP GET request made to /dujok/kevyl.php?l=ranec11.cab.
Following the TCP stream, we identified that the request was sent to the hostname ncznw6a.com and the file was a DOS MZ executable.
Through OSINT, we learned that the malware belongs to the IcedID family, which is a banking Trojan that steals sensitive financial information from infected systems. We also discovered other variants of the malicious request, with the only difference being the number preceding the .cab extension, ranging from 0 to 15.
With all this information, we can now construct our custom signature.
Signature Development
Navigate to Dalton webpage,
(1) select Suricata as sensor
(2) upload the pcap file; you can also upload multiple pcaps if you’d like
(3) select the sensor version
(4) uncheck ‘use a defined ruleset’ since we only want Dalton to run our custom rule
(5) check `use custom rules` and write our rule. Optionally, you can also
(6) ‘check dump buffers’ which will display the buffers contents. This can be useful for troubleshooting signature creation with traffic that may not be parsing as expected.
For revision 1, we will define the protocol, traffic flow, and message of the signature. Although it may have a lot of false positives, it will serve as a template and starting point for creating more robust rules.
# Empty rule
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"Possible IceID Malware Detected (ncznw6a .com)"; flow:established,to_server; sid:1; rev:1;) 
Submit the request. Once finished it will show the following report.
We caught 165 alerts. Since we only care about one, let’s narrow this down. From the current page, go back one page or use ALT-Left arrow button. This preserves our previous configurations options, so we don’t re-upload the PCAP file and re-check everything.
For revision 2, we will use sticky buffers to catch all HTTP GET requests. The workflow is similar, the only difference is this time we need to change the value of the custom rule.
# Detect HTTP GET method
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"Possible IceID Malware Detected (ncznw6a .com)"; flow:established,to_server; http.method; content:"GET"; sid:1; rev:2;) 
We reduced the number of alerts from 165 to 5. Let’s narrow this down even more.
For revision 3, we will improve effectiveness of our rule by using pcre to catch all variants of the string "ranec" followed by a single or double digit number and ending with the file extension ".cab". It's important to note that using pcre can negatively impact performance, so we will use it in combination with the "content" keyword to optimize Suricata's checking process.
# Implement pcre to detect file variant
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"Possible IceID Malware Detected (ncznw6a .com)"; flow:established,to_server; http.method; content:"GET"; http.host; content:"ncznw6a.com"; http.uri; pcre:"/ranec\d{1,2}\.cab$/i"; sid:1; rev:3;) 
To check if the alert generated corresponds to the traffic we want, we can navigate to the Alert Debug page.
While the custom rule we developed may not be optimal, we hope it serves as a useful starting point for anyone looking to create their own signature. We encourage readers to explore and experiment with different approaches to signature development, and to take advantage of tools like Dalton to streamline the process. If you would like to learn more about Dalton, you can visit their GitHub page.
Thank you for reading and feel free to share any input or feedback on this topic.
