Some of these might be overkill but let me know if you need anything from it. I think some of it is useful but I put more in than might be needed to grab as much as possible from the PCAP.
I am also interested in any documentation that might be helpful for me to start doing the Snort conversions myself so it’s not something all of you have to do for my sigs.
Thanks once again for a fantastic set of rule submissions. I’ve taken a look at your rules and I’ve made some modifications, and have some feedback to offer, but first, the changes I’ve made:
So most of the changes I’ve made to the rules above are mainly cosmetic and I guess are what you’d call ET syntax/style:
With the flow keyword, we typically either use to_server or to_client
With the reference metadata keyword, we usually remove the http|https:// portion of a reference URL
We typically use the ET MALWARE category for general malware as opposed to ET Trojan
Renamed sid 1 and 4 to CnC Checkin M1 and M2 (respectively)
Renamed sid 2 to Payload retrieval attempt
With the minor stuff out of the way, lets get into some more details:
Unfortunately, I don’t think we’ll be able to make very good use of sid number 3. If at all possible, we like to make sure a rule has a good candidate for fast_pattern matching, and this rule really doesn’t have a good candidate – For suricata 4 and 5, we can use the http.header_names/http_header_names buffer to make a fast_pattern for this rule, but for Snort 2.9.x, this is going to end up being a PCRE, and you can’t make fast_pattern matches out of PCRE on snort.
Additionally, while this combination of header names from the server seemed to test okay among our quality assurance pcaps, I don’t know that it’ll be a particularly unique set of HTTP headers in the real-world. I suspect it has the potential to be false-positive prone.
However, the good news is that we have a very similar rule in the ETPRO ruleset that triggers on the return traffic, using a different method – we chose to focus on the filename field of the Content-Disposition header in the server’s response. Today, we will be moving this rule to the ETOPEN ruleset.
That brings me to sid number 5: While I definitely saw the URI pattern in the Virustotal IP addresses/pivots, this URI pattern was not observed in the sandbox run. Some of the IP addresses had comments in which users seemed to have observed the IP addresses having been used as Vidar stealer C2 addresses as well, so for the time being, I decided change the message to Potential CnC Checkin.
For all of the submissions here, I did a bunch of QA and performance testing. I found in my testing that for suricata 5, that the rules performed better when I used the http.method and http.uri buffers, instead of http.request_line However, its hard for me to say whether or not this resulted in better rule performance, or if it was…
For sids 1, 2, and 5, I noticed the user-agent of OK was used as the fast_pattern match. This resulted in a couple of checks in my QA analysis, so I decided to experiment with setting the fast_pattern match to the http.uri string instead for sids 1, 2, 4, and 5. This removed checks/alerts in our QA datasets for all of the rules except for sid 3, and I noticed in performance testing that between moving the fast_pattern, and using the http.method and http.uri buffers, I got some natty perf gainz.
I will be submitting sids 1,2,4, and 5 to the ETOPEN ruleset, and be changing sid 2852925 from ETPRO to ETOPEN (instead of using sid number 3).
So that’s my feedback, and why I made the changes I’ve made. Once again, thank you very much for sharing your research, and I hope to collaborate with you in the future.