How to create rules for network traffic for a future threat

How to create rules for network traffic to address a future threat 🤨

This was discussed this week in China during the third cybersecurity summit, which included the sixth international antivirus conference, shared Ksenia Naumova, a senior specialist in the network expertise department of the PT ESC antivirus laboratory. In the channel, we share details from the report 🍸

A fairly significant part of a network traffic analyst’s work in malware analysis involves writing detection signature logic to identify specific malware samples in network traffic.

Exact signatures have one undeniable advantage — they catch exactly the malicious samples they were written for, but this is also their main weakness: even a slight change to any component of network interaction causes the rules to stop triggering.

We decided that this ailment can safely be turned into an advantage: signatures can catch not only exact malware but also the anomalous behavior that these samples generate.

What can constitute the anomaly we’re interested in?

➡️ Unusual packet sizes;
➡️ unknown protocols;
➡️ suspicious DNS queries / suspicious TLDs in DNS;
➡️ traffic spikes / delays;
➡️ RFC violations;
➡️ use of obfuscation, encoding, encryption;
➡️ and much more…

We conducted a brief analysis of existing anomaly detection rules in the open-source Emerging Threats signature set — HUNTING (screenshot 1):

➡️ ~510 rules for XOR encryption of HTTP requests;
➡️ ~50 rules for Base64-encoded data;
➡️ ~50 rules for suspicious TLDs in DNS;
➡️ rules for content in ZIP, exfiltration, etc.

A telling example of a successful hunting rule:

alert http $HOME_NET any -> $EXTERNAL_NET any (sid: 2027117; msg:"ET HUNTING Suspicious POST with Common Windows Process Names - Possible Process List Exfiltration"; flow:established,to_server; http.method; content:"POST"; http.request_body; content:"csrss.exe"; content:"explorer.exe"; fast_pattern; content:"svchost.exe"; content:"lsass.exe"; ...)

And screenshot 2 shows an example of such suspicious traffic.

However, anomalies can be hunted not only with open rules but also independently — for example, RFC violations, specifically RFC 2616, which defines the HTTP protocol (screenshot 3). You can search for HTTP requests whose Referer header doesn’t contain a scheme:

alert http any any -> any any (msg: "SUSPICIOUS [PTsecurity] HTTP header Referer RFC2616 violation"; flow: established, to_server; content: "Referer|3a|"; http_header; content: !"Referer|3a 20|http"; http_header; ...)

The backdoor EAGERBEE and other interesting samples made their way into our networks (screenshot 4).

Or, for example, you can search for a simple PING command inside GZIP (screenshot 5):

alert tcp any any -> any any (msg: "SUSPICIOUS [PTsecurity] Generic Ping command inside Gzip"; flow: established, to_server; content: "|1f 8b 08 00 00 00 00 00 04 00 0b c8 cc 4b 07 00 c3 92 e7 85 04 00 00 00|"; ...)

Based on the triggered alerts and further research, SheetRAT and zgRAT made their way to us (screenshot 6).

But the main idea captured in the report is the use of correlating their triggers. Correlation of triggers is not a new concept, but in the context of network traffic it is still rarely applied; sometimes people go for more complex protection implementations and forget about simple yet effective approaches.

🫵 The conclusions are simple: generic rules, especially when correlated with each other, can significantly help in detecting both long-known and completely new threats that nobody knows about yet. You can use open network signature sets — ET Open, PT Open, or you can confidently write your own.

Happy hunting!

#suricata #network #signature #rules #hunt #detect
@ptescalator