+1 for DNS/TLS SNI alerts. “What triggered the DNS lookup?” is a great question, domain names are human readable, easy to corroborate with other tools, and their detection is difficult to wave away as a false positive due to packet loss. In my experience, it’s easier to find information on the web about malicious domains than other IoCs, too.
That said, I’d like to be able hand a rule signature to someone pushing back on one of my detections, and have the signature be self-evident enough of host compromise to end any debate. I want to be enabling DNS and TLS SNI signatures that prove malicious code is running on an endpoint, rather than detecting a request for malicious code during an intermediate stage of attack (e.g. merely visiting a compromised website). Compromised websites get cleaned up, but if the only known use of a domain is for exfiltrating data, I want to know when something resolves it.
My reading of the Rules Severities article is that domain-based signatures indicating malware running on a host would all be marked “Critical”, is that right?
If that holds, then a look at all ET Open signatures matching on the DNS and TLS protocols, of signature_severity “Critical”, shows they’re broken out into a few different classtypes:
bad-unknown
command-and-control
domain-c2
policy-violation
social-engineering
targeted-activity
trojan-activity
Of these classtypes, the descriptions of “trojan-activity”, “command-and-control”, and “domain-c2” in classification.config sound most like “malicious code running on an endpoint must have made this DNS/request or TLS connection.” Is that right?
Also, in the context of observing a malicious domain name, “domain-c2” and “command-and-control” sound like the same thing. Do you draw a distinction between them when matching on DNS and TLS? Maybe “requests to this domain are part of c2 traffic” versus “this DNS traffic is part of a stealth C2 protocol”?
Thanks!