Dockerized Snort3 for Rule Crafting and Triage Forensics

In this blog post, you'll learn about a dockerized setup of snort3 and its usage for offline and online analyses. I'll demonstrate its usage and value by creating a Snort rule to detect the loader dubbed SVCready.

This setup might be especially helpful to

1. craft and tweak snort rules running it against some .pcap-file,
2. quickly triage a few .pcaps-files for know indicators, or even
3. monitor a small segment of a network that has not been equipped with a NIDS yet.

Find all needed files and documentation in this Github-repo. Using the dockerized Snort installation, is as easy as executing "installing" a shell function to call snort ... or running docker-compose up.

Snort was one of the first network intrusion prevention systems. Shortly after its release in 1999, it became the industry standard for network signatures – the infamous snort rules. Snort was originally authored by Martin Roesch, who was the lead developer of the project. Later Cisco acquired Roesch's company Sourcefire and used Snort as a base for its IPS-products.

snort3 is a multithreaded rewrite of the classical but aged network intrusion detection system snort. Nowadays, Suricata seems to be slightly more popular, e.g., snort3 is (currently) not included in Debian's package archives. However, regarding their performance these two open-source systems they seem to be on par ¹.

Since the end of April 2022, SVCready has been spread via shellcode in properties of Microsoft Office documents by TA551 ⁶.

In the .pcap provided by Brad Duncan from malware-traffic-analysis.net ⁷, we can observe beaconing in regular intervals after infection. Those are POST-requests adressed to the three endpoints starting with the string /xl/gate. Public threat intelligence suggests that they are used for the following tasks ⁸:

/xl/gate/check

Validate domain

/xl/gate

Upload information

/xl/gate/task

Request a task

But not only the URIs are characteristic, some other information in the HTTP-header looks interesting as well, as the following listing illustrates.

POST /xl/gate HTTP/1.1
Accept: */*
Content-Type: application/octet-stream
X-JsonSize: 73
g: 3f070578-177d-f039-564e-f46ef128a461
pr: 3
sg: 0910DCC1-63FA-4433-8D22-5379E6F79F91
Authorization: Bearer {602ED31E-B7A8-4E3A-802F-EDCD33E4D5C8}
User-Agent: svc/1.0
Host: <some host>
Content-Length: 695088
Cache-Control: no-cache

Looking at this exemplary HTTP header, we could infer several suspicious elements that we could use for detection. Beside the API-endpoint used for POSTing some stolen data, the user-agent appears to be rather striking: svc/1.0. Additionally, there are two strings in there that look like UUIDs. Those seem to comprise more or less robust features for detection since fields, like a User-Agent, could be changed rather easily. To validate this hypothesis static binary reversing would be needed.

Nevertheless, based on the information in the HTTP headers of those beaconing requests, we might come up with the following Snort rule:

cat << EOF > svcready.rule
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS
(
    msg:"SVCready-CNC outbound connection";
    flow:to_server,established;
    priority:1;
    service:http;
    http_method;
    content:"POST";
    http_uri:path;
    content:"/xl/gate",nocase;
    http_header;
    content:"User-Agent|3A 20|svc/1.0|0D 0A|";
    pcre:"/[a-zA-Z]{1,2}\x3A\x20[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}\x0D\x0A/";
    classtype:trojan-activity; sid:2000001; rev:1;
)
EOF

Here, Snort should only consider POST-requests (http_method;content:"POST";) from IP-addresses matching $HOME_NET to externals servers after a connection has already been established (flow:to_server,established;). Furthermore, we check the URI-path for the presence of the API-endpoint regardless of case (http_uri:path;content:"/xl/gate",nocase;) and the striking User-Agent svc/1.0. Lastly, we ensure the presence of a UUID after a field-name of one or two letters.

/Note: If you are using Emacs, you might want to check out snort-mode, which is major mode for editing snort rules. Though a little dated, the syntax highlighting and formatting is rather nice ⁹./

Coming back to our dockerized setup, we could check the newly created rule (saved as snort.rules) against B. Duncan's SVCgready-Pcaps in the following way.

First, retrieve the .pcaps:

cd tmp
wget -O ./pcaps/ https://www.malware-traffic-analysis.net/2022/06/08/2022-06-08-SVCready-infection.pcap.zip
unzip -d . -P infected pcaps/2022-06-08-SVCready-infection.pcap.zip

Second, run snort with the newly created rule, which will output some alert_{fast,full,json}.txt-files.

snort -R svcready.rule -r 2022-06-08-SVCready-infection.pcap

Lastly, check the alerts:

jq -s 'length ' alert_json.txt

332

Note that we are using the shell-function which actually calls the Docker container as defined above. To access the files and store the results, the current working directory is mapped to the container's workdir (its /tmp-directory). Alternatively, one could use the "more static" approach with docker-compose filling pre-defined directories.

To ensure that the newly created rule does its job, we can peek into one of the log files produced by snort when applying the rule. Here, we use alert_json.txt and see that it actually matched. We have 332 matches:

Looking at the first entry, we could retrieve the relevant metadata:

jq -s '.[0]' alert_json.txt

{
  "timestamp": "06/08-14:40:25.345040",
  "iface": "2022-06-08-SVCready-infection.pcap",
  "src_addr": "10.6.6.103",
  "src_port": 60868,
  "dst_addr": "XXX.XXX.90.154",
  "dst_port": 80,
  "proto": "TCP",
  "action": "allow",
  "msg": "SVCready-CNC outbound connection",
  "priority": 0,
  "class": "none",
  "sid": 0
}

In this blog post, you learned about setting up and running the intrusion detection system snort3 inside a Docker container. It was shown how to use it both for processing live packets and .pcap-files by setting up a conventient shell function. To illustrate its usage and demonstrate the capabilities of the Docker container, we crafted an exemplifying Snort rule for a new loader malware named SVCready, tested it using the Docker container.