Possible FP on 2044745 (SOMNIRECORD Backdoor CMD Command in DNS Query)?

Rule Signatures
1

Hi,

I’m wondering if there’s a potential false positive on the 2044745 rule submitted yesterday. According to the write-up (Not sleeping anymore: SOMNIRECORD's wake-up call — Elastic Security Labs) this should look for the literal word “-CMD” and it seems like this should be a TXT record:

Upon execution, SOMNIRECORD first generates a random string of three characters used as a unique identifier for the running malware instance. (…) After obtaining the number of commands waiting to be executed, the backdoor retrieves each command individually by sending a DNS query for a TXT record. The backdoor prepends the previously-generated random string to the "-CMD " string before sending the DNS query.

We get a FP on an AAAA query for a hostname that contains the string “-cmd”. Maybe this should have an additional check that looks for type TXT (|00 10|) explicitly?

Could be that the same applies to the other SOMNIRECOROD signatures published in the last update:

2044743 - ET MALWARE SOMNIRECORD CnC Domain in DNS Lookup (dafadfweer .top) (malware.rules)
2044744 - ET MALWARE SOMNIRECORD Backdoor PROBE Command in DNS Query (malware.rules)
2044745 - ET MALWARE SOMNIRECORD Backdoor CMD Command in DNS Query (malware.rules)
2044746 - ET MALWARE SOMNIRECORD Backdoor DATA Command in DNS Query (malware.rules)

–
Marius

2

Thanks for the feedback.

I’ve handed this to the signature author for investigation and we’ll have a response for you soon.

3

Hey folks,

I was responsible for this rule. At the time, the rules I wrote passed our QA battery so I didn’t really think much of it. Sorry for any issues these rules might have caused. So, let me address your inquiries.

2044743 - ET MALWARE SOMNIRECORD CnC Domain in DNS Lookup (dafadfweer .top)

With regards to this rule, I’m electing to make no changes. Why? The dafadweer .top domain is associated with this particular campaign. Any DNS query for this domain is going to be suspicious and require further investigation in this case, not just TXT record queries.

2044744 - ET MALWARE SOMNIRECORD Backdoor PROBE Command in DNS Query (malware.rules)

At first, there wasn’t any evidence I could see in the article to suggest that the PROBE DNS queries were strictly TXT record requests, but then I found the file hash for the implant elastic wrote their blog about - you can find the file hash if you look in the metadata for their yara rule.

So I used that hash, pivoted, and discovered the backdoor had been indexed by virustotal. VirusTotal

I have a VTI account through proofpoint, so I pulled down one of the PCAPS and did confirm that the PROBE DNS query is specifically requesting a TXT record. so I added the logic: content:"|00 00 10"; offset:12; for this rule (for suricata, this content match is OUTSIDE of the dns query sticky buffer). this sequence represents the null terminator at the end of the domain being queried in a DNS request, followed immediately by the value that indicates a query for a DNS TXT record (00 10 = 16). We’re telling the rule engines to start looking for the sequence 12 bytes into the payload. This is AFTER a majority of the DNS headers to avoid possible false positives.

For suricata, I chose to expand the PCRE to: pcre:"/^[a-z0-9]{3}-PROBE/i"; to reduce ambiguity in the pattern we’re looking for in the domain being queried for.

2044745 - ET MALWARE SOMNIRECORD Backdoor CMD Command in DNS Query (malware.rules)

The changes made to this rule are nearly identical to 2044744 – I added the content match to denote the query type as a TXT record, and for suricata, expanded the PCRE a little bit.

2044746 - ET MALWARE SOMNIRECORD Backdoor DATA Command in DNS Query (malware.rules)

This is the only rule by which I am not convinced that the implant sends a TXT record query. Nowhere in the blog post does it denote that this command type uses the TXT record type. On top of that, the pcap pulled from virustotal intelligence doesn’t have any data records (The root domain appears to no longer be responding). Finally on top of all that, I reviewed some of the source code for the open-source project this backdoor was based off of, and it seems to indicate that while TXT records are primarily used, I think I saw references that indicate PTR records are used as well. I’m not sure.

On top of all that, the DATA command indicates that data is being SENT to the C2. It wouldn’t be retrieving a TXT record to send data. The article states that the output from a command is send as a hex encoded string in the -DATA- dns query. So using that, I expanded the PCRE pattern for snort and suricata to: pcre:"/[a-z0-9]{3}-DATA-[a-f0-9]{6}/i"; to indicate that suricata should look for at least six hex characters after finding the -DATA- string.

All of the changes I’ve made to these rules should go live tonight. As always, if false positives continue to be an issue, please let us know.

-Tony