Welcome! This is a great place to submit sigs and thanks for submitting this one!
I wanted to dig into this as much as possible, it looks pretty interesting! I’ve detailed my analysis and tweaks to your rule!
Analysis
I took a look at the URI pattern you’ve included in your rule and I was able to find additional user agents which were not covered by your version and based on VT information, I was able to find some other URI patterns as well! It looks like the hash you linked to was actually the payload downloaded by Valyria, so I focused my time into how that payload was delivered.
VT Analysis
As we’re working with the payload downloaded, I first looked at the “Execution Parents” on VirusTotal. I noticed the PDF and LNK.
I first took a look at the LNK file and noticed it actually had an “Execution Parent” of the PDF. So, it would seem the PDF is the original source
When we look at the “Contacted URLs” for the PDF we can see the following request which contains a slightly different URI.
hxxp://185.246.220[.]65/iit/IMG07601208.exe
Over to Any.Run
Using the IP address from VT, I searched for samples reaching out that IP in Any.Run
I was able to find a pretty good example which matches your traffic/rule exactly.
In this example, it looks like the Valyria MalDoc delivered FormBook as it’s payload.
As I continued to look at sample, I was able to find an additional filename pattern
hxxp://185.246.220[.]65/lee/IMG-07-94103.exe
Here we have additional - within the filename, though the lee directory from your original sample is still used! Pretty cool!
Rule Tweaks
- Sticky Buffers
The first item I noticed in your rule was the lack of sticky buffers which are used within Suricata 5.0+. Sticky buffers are a great addition to the rule language and are preferred when available.
- PCRE Optimizations
-
Add static components of the PCRE as
content matches
As the PCRE enforces the .exe part of the URI, we can also add this as a static content match. This will save time by not invoking the PCRE if .exe is not to be found in the URI.
-
Anchor the PCREs were possible
We can make use of the ^ and $ to “anchor” the PCRE to the start/end of a buffer. This allows the PCRE engine to optimize where it searches and decreases the amount of time required to evaluate the PCRE. In this case, this can be applied to the PCRE for both http.uri and http.host.
- Negation on common HTTP Headers
A request for an EXE without a Referer Header is commonly observed when they are downloaded via maldocs and other “downloaders”. To reduce possible False Positives or Benign alerts, we can add a negation to ensure that these headers are missing from the HTTP Request. We can use the http.header_names buffer to accomplish this task.
- Remove the directory path
As we’ve already observed multiple directories within the URI, I went ahead and focused on the /IMG part of the URI and dropped the /lee component all together. I think the filename PCRE an IP based Host header should allow the sig to maintain a respectable ratio of True Positives to False Positives.
Final Tweaked Rules
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET MALWARE Win32/Valyria Maldoc Payload Request M1"; flow:established,to_server; http.uri; content:"/IMG"; fast_pattern; content:".exe"; endswith; pcre:"/\/IMG[-_]?[0-9\-]{7,9}\.exe$/"; http.user_agent; content:"Microsoft-CryptoAPI/"; startswith; http.host; pcre:"/^[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}$/"; http.header_names; content:!"|0d 0a|Referer|0d 0a|"; reference:url,www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?Name=Trojan:VBS/Valyria; reference:url,community.emergingthreats.net/t/new-signature-for-valyria/203; sid:1; rev:1;)
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET MALWARE Win32/Valyria Maldoc Payload Request M2"; flow:established,to_server; http.uri; content:"/IMG"; fast_pattern; content:".exe"; endswith; pcre:"/\/IMG[-_]?[0-9\-]{7,9}\.exe$/"; http.user_agent; content:"CertUtil URL Agent"; bsize:18; http.host; pcre:"/^[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}$/"; http.header_names; content:!"|0d 0a|Referer|0d 0a|"; reference:url,www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?Name=Trojan:VBS/Valyria; reference:url,community.emergingthreats.net/t/new-signature-for-valyria/203; sid:2; rev:1;)
Again, thanks for posting a very fun and interesting sample. Please keep more sigs coming, we always love suggestions from the community and will always try to provide meaningful feedback!