Traffic Analysis with Snort

September 14, 2021

Tags: | traffic_analysis | blue | snort |

Read this in "about 6 minutes".

Overview

In this post, we will focus on writing Snort rules to detect real-world attacks based on inspecting and analyzing malicious traffic.

Tools used:

Wireshark.
Snort.
tcpdump.

Introduction to Snort

Snort is an open source IDS and IPS, it can be used as packet sniffer or packet logger. With a set of rules, Snort can inspect all traffic and link malicious traffic that match the rules. Depending on the rule, Snort is able to prevent or log the traffic.

Another powerful function of Snort is custom rules. Primarily, those rules allow users to monitor traffic in a more flexible way.

Let’s us see how to create custom rules in the next sections.

Detect ICMP request & reply with Snort

We start with locating the local.rules file.

$ locate local.rules
/etc/nsm/rules/local.rules

local.rules file is a compilation of custom rules, where we’ll utilize to write our own rules.

Generally, our rule will look like the following:

It’s very simple to detect ICMP request or reply. By default, Snort offers the ability to parse the icmp protocol in Snort rule.

alert icmp any any -> 192.168.1.0/24 any (msg:"ICMP detect!"; sid:10000001; rev:1;)

Let’s apply the rule against a icmp.pcap file.

$ snort -q --daq pcap -A console -c /etc/nsm/rules/local.rules -r icmp.pcap
02/21-22:25:18.329311  [**] [1:10000001:1] ICMP detect! [**] [Priority: 0] {ICMP} 213.16.246.5 -> 192.168.1.2
02/21-22:25:20.717067  [**] [1:10000001:1] ICMP detect! [**] [Priority: 0] {ICMP} 192.168.1.2 -> 192.168.1.6
02/21-22:25:20.717109  [**] [1:10000001:1] ICMP detect! [**] [Priority: 0] {ICMP} 192.168.1.6 -> 192.168.1.2
02/21-22:25:21.395044  [**] [1:10000001:1] ICMP detect! [**] [Priority: 0] {ICMP} 192.168.1.6 -> 192.168.1.2
02/21-22:25:21.722816  [**] [1:10000001:1] ICMP detect! [**] [Priority: 0] {ICMP} 192.168.1.2 -> 192.168.1.6
02/21-22:25:21.722845  [**] [1:10000001:1] ICMP detect! [**] [Priority: 0] {ICMP} 192.168.1.6 -> 192.168.1.2
02/21-22:25:22.729727  [**] [1:10000001:1] ICMP detect! [**] [Priority: 0] {ICMP} 192.168.1.2 -> 192.168.1.6
02/21-22:25:22.729760  [**] [1:10000001:1] ICMP detect! [**] [Priority: 0] {ICMP} 192.168.1.6 -> 192.168.1.2

Just like that, we successfully detect the ICMP packets.

Detect Buffer Overflow attack with Snort

Typically, a Buffer Overflow attack will contain a large number of “A” letters.

Let’s us see that in action utilizing tcpdump.

$ tcpdump -nntttt -A -r eternalblue.pcap "port 445 and src 192.168.1.6 and greater 1000"
...
2019-02-22 17:13:34.451071 IP 192.168.1.6.55018 > 192.168.1.4.445: Flags [P.], seq 2112:6268, ack 40, win 237, options [nop,nop,TS val 325529 ecr 38791], length 4156                         
E..p..@.@.%....................$...........                                                                                                                                                   
...........8.SMB3......H....................    ............8.................................................................................................................................
..............................................................................................................................................................................................
..............................................................................................................................................................................................
..............................................................................................................................................................................................
..............................................................................................................................................................................................
.................................................................................................................................AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
...

With Wireshark, we can also find the same traffic.

→ There is a high possibility of attacker mounted an Eternal Blue BoF exploit against a SMB service.

Generally, the rule is written based on the following characteristics in the traffic:

Destination port: 445.
Content: lots of A letters.

alert tcp any any -> 192.168.1.0/24 445 (msg:"Possible Eternal Blue BoF detect!"; content:"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"; sid:10000002; rev:3;)

Running snort against the eternal.pcap traffic, we’re able to detect the BoF attack.

$ snort -q --daq pcap -A console -c /etc/nsm/rules/local.rules -r eternalblue.pcap -k none
...
02/22-22:13:34.463024  [**] [1:10000002:3] Possible Eternal Blue BoF detect! [**] [Priority: 0] {TCP} 192.168.1.6:55018 -> 192.168.1.4:445
02/22-22:13:34.463414  [**] [1:10000002:3] Possible Eternal Blue BoF detect! [**] [Priority: 0] {TCP} 192.168.1.6:55018 -> 192.168.1.4:445
02/22-22:13:34.487892  [**] [1:10000002:3] Possible Eternal Blue BoF detect! [**] [Priority: 0] {TCP} 192.168.1.6:55018 -> 192.168.1.4:445
02/22-22:13:34.488099  [**] [1:10000002:3] Possible Eternal Blue BoF detect! [**] [Priority: 0] {TCP} 192.168.1.6:55018 -> 192.168.1.4:445
...

The switch -k is to disable checksum.

Detect Heartbleed with Snort

Hearbleed is generally an attack sending a crafted payload with the payload length > actual payload length for a purpose of leaking memory data.

It’s worth noticing that Heartbleed doesn’t have a specific pattern as Eternal Blue we saw previously. However, to mount the attack, the communication protocols mainly used are Heartbeat Request/Response.

This is also where the data is leaked.

Let’s us further analyze the Hearbeat Message (Request).

The output demonstrates two important information:

→ The actual length of payload is: 0 byte

→ The crafted length is: 16386 bytes

Therefore, the packet is spotted as abnormality.

Now, to write a Heartbleed rule, we might rely on the Heartbeat protocol and the port 443.

More explanations of the above image:

Color	Hex	Meaning
Yello	18	Content-Type: Heartbeat
Red	03 02 00	Version: TLS 1.1

Putting everything together, our Snort rule is:

alert tcp any any -> 172.16.121.0/24 443 (msg:"Possible Heartbleed detect!"; content:"|18 03 02 00|"; rawbytes;sid:10000003; rev:1;)

Applying the rule against the traffic, we successfully expose the attack.

$ snort -q -A console --daq pcap -c /etc/nsm/rules/local.rules -k none -r PCAPs/heart.pcap
04/16-12:00:41.512593  [**] [1:10000003:1] Possible Heartbleed detect! [**] [Priority: 0] {TCP} 172.16.121.1:64667 -> 172.16.121.150:443

There are far more advanced Snort rules, the aboves are just some basic of Snort. We probably want to write more complex rules in the future posts with Snort.