In this blog, I will be installing, configuring, and exploring Snort.
This the second installment to my first home lab setup with Snort.
Here’s a summary of what I have done in this lab project.
- Install and configure Snort
- Performed host enumeration attacks using a script that will automate various Nmap tasks and created rules that will detect those attacks.
- Conducted port enumeration using a script for automation, and applied the pre-built and community rules for detection.
- Exploited Metasploitable2’s vulnerabilities targeting ports 21, 22, 80, and 139.
- For post-exploitation, conducted local machine enumeration and file extraction.
Note: All the scripts I utilized can be found in my Github page.
Disclosure: The scripts are generated with the help of chatgpt.
Disclaimer: The home lab setup I provided here is solely intended for educational and testing purposes. Any unauthorized use or engagement in illegal activities is strictly prohibited. Everyone is encouraged to utilize this setup responsibly and in compliance with all applicable laws and regulations. The purpose of this home lab is for learning, experimentation, and skill development in a safe and controlled environment. Any misuse or improper activities are entirely at the user’s risk. If you want to use this home lab, you agree and acknowledge the importance of ethical and lawful practices.
Installing Snort
Before installing, update the system’s repositories. The commands below will update and then install snort respectively.
sudo apt-get update -ysudo apt-get install snort
Type the interface that snort will be using to intercept network traffics. In my case, it is “ens34”.
I created a copy of Snort’s configuration in case I mess up somewhere in the lab.
I also created another copy of the config file, which I will be using for the host enumeration phase of the attack.
sudo gedit /etc/snort/test_snort.conf
“HOME_NET” refers to the network that Snort will be monitoring for any malicious activities. This is the subnet for Metasploitable2 and Ubuntu.
While in the config file, I configured the path for the local rules. Again, local rules are custom built rules that a user want Snort to apply. The default location of the local rules are in “/etc/snort/rules“.
I also deleted the pre-built rules in Snort so that only my customized rules will be loaded.
Test the rules to ensure there are no errors. There are zero rules as expected because I have not created any rules yet.
sudo snort -T -c /etc/snort/test_snort.conf
Host Scanning
This is the phase of attack where a host is being scanned or enumerated for any active ports, and other information about the target system.
For this attack, the script performs a ping command and then two Nmap scans, “TCP SYN” and “ACK”. The results are then saved in an file.
I then created rules for detecting icmp(ping sweep), and the Nmap scans.
#detect nmap ping sweetalert icmp any any -> $HOME_NET any (msg:"Ping Scan Detected"; icode:0; itype:8; sid:1000001; rev:1;) #detect TCP SYN (-sS)alert tcp any any -> $HOME_NET any (msg:"NMAP TCP SYN Scan Detected"; flags:S; sid:1000002; rev:1;) #detect ACK Scan (-sA)alert tcp any any -> $HOME_NET any (msg:"Nmap ACK Scan Detected"; flags:A; sid:1000004; rev:1;)
For the rules to be deployed, I edited the “test_snort.conf” configuration to include the path to the rules I made.
Testing the rules for errors.
sudo snort -T -c /etc/snort/test_snort.conf
The config looks good. Three detection rules were detected as it should be.
Start Snort and Wireshark. (Wireshark is also listening at “ens34”)
sudo snort -c /etc/snort/test_snort.conf -q -i ens34 -A full -A console -l /var/log/snor/host_enum
Before executing the scrip, I gave permission to it so it can be executed. I then executed the script to start the attack.
sudo chmod +X host_scan.sh
sudo ./host_scan.sh
It can be seen that Wireshark captured the traffic and Snort created an alert for the events generated by the script.
These are the alerts triggered by Snort.
An alert and log files have been created in the default folder for Snort logs.
sudo snort -r snort.log1690380921
In total, 9940 packets where received and analyzed by Snort.
Similar to the script, only 5 pings were recorded.
Port Enumeration
For this phase, I decided to deploy the pre-built and community rules in Snort. The community rules downloaded are from Snort’s website, selecting “snort-2.9.20.tar.gz”.
Test the configuration again.
sudo snort -T -c /etc/snort/snort.conf
I then started Snort and Wireshark.
sudo snort -c /etc/snort/snort.conf -q -i ens34 -A full -A console -l /var/log/snor/port_enum
Also, before running the script, I changed its permission to executable.
sudo ./port_enum.sh
Essentially, the script combines various scanning techniques, including Nmap script scans, banner grabbing, FTP login checks, directory enumeration, and vulnerability scanning using Nikto and enum4linux. Each task aims to gather valuable information about the target system’s open ports, services, and potential vulnerabilities.
Here’s a summary of the actions executed by the script:
- Execute Nmap scans for ports 21, 22, 23, 25, 139, 445, 80, and 3306, and save the results to an output file.
- Perform banner grabbing using various Nmap scripts on specific ports (21, 22, 23, 25, 139, 445, 80, and 3306) and append the results to the output file.
- Attempt anonymous login on the FTP server running on port 21 and save the login response to the output file.
- Perform directory enumeration on the web server running on port 80 using the
dirb
tool and save the results to a separate file. - Enumerate port 445 (SMB) using the
enum4linux
tool and save the results to a separate file. - Execute the Nikto scanner on the web server running on port 80 and save the results.
The following images are the result of running the script.
Detection
With Wireshark, the malicious traffics are being captured.
Snort also displayed alerts on the different actions taken by the script. The below images show banner grabbing on port 23 and 25, SMB share enumeration, and enumeration using nikto.
Alert and log files created by Snort.
sudo snort -r snort.log.1690506280
A total of 3,501 packets were analyzed.
Below are some of the contents of the alert file.
There are 13 Classifications of alerts generated by the attack, with “Web Application Attack” generating the highest number of alerts.
References ofthe rules can also be identified by reading the “alert” file. Here are some of the references. The highest numbers of references were from the MITRE framework and “securityfocus.com”.
Exploitation
Once vulnerabilities have been enumerated, attackers will design their techniques to exploit these vulnerabilities and gain access to the machine or network. In this context, I will be exploiting Metasploitable2’s weaknesses on ports 22, 23, 80, and 139.
Detection Rules
I will be utilizing the pre-built and community rules again.
In testing the configuration file that I will be using, 4057 rules will be applied
sudo snort -T -c /etc/snort/snort.conf
I also started Wireshark to capture the network traffic. Started snort and configure to save the log file to “/var/log/snort/exploitation” folder
sudo snort -c /etc/snort/test_snort.conf -q -i ens34 -A full -A console -l /var/log/snort/exploitation
Issues faced when executing the script.
I faced several issues when testing the exploitation script, particularly when the last exploit was being executed.
In the image below, it seems that port 6200 may have already been used by another shell. This happened for a few times after I run the exploitation script and successfully created a session shell.
So far, the only solution I had for this is to restart Metasploitable2
Another issue I got, is when the script runs successfully but the listening port in my Msfconsole cannot establish a connection because the port is already being used by another session. So far, there are two ways that I think would solve the issue.
Firstly is to edit the exploitation script and change the listening port address. Second, which I chose to do, is to stop all running Msfconsole processes.
The script creates msf scripts or resource scripts (.rc) that it calls to execute during the execution of the exploit script. Every time I execute the script, the Msf resource script is temporarily saved in the current directory. And if the process did not execute properly or I stopped it midway its execution, the msf resource script would still be there. So before I run the exploitation script, I always check and delete the resource script as shown below.
Executing the exploit script.
Again, give the script executable permission before running it.
sudo ./exploit_kit.sh
Wireshark started to capture the traffic.
Snort displaying the alerts.
Here is the run-down of the tasks performed by the script. The script is not fully automated and will require answering prompts.
- FTP Brute Force Attack with Hydra:
- The script will perform an FTP brute force attack using Hydra to find valid FTP credentials.
- Execute the FTP Login:
- Once valid credentials are identified, it will login into the FTP server, utilizing the first set of credentials it found.
- It will then execute the FTP commands (
ls -la
,binary
,prompt
,mget *
,quit
) to enumerate and download all files from current directory of the FTP server. - It can be seen that the credentials of “msfadmin” were used to login.
- No files were downloaded
- Metasploit SSH Login Exploit:
- The script then starts Metasploit with the “
auxiliary/scanner/ssh/ssh_login
” module to perform an SSH login brute-force attack, setting the username and password to the previously identified credentials for the SSH login. - Once a session is established, which was successful in this instance, the script would end the session (sessions -K) after five seconds so that the next exploit will commence.
- For the other exploits to start, the Metasploit process will have to be killed. This is the same for the succeeding exploits.
- The succeeding exploits will employ Metasploit for continuity.
- Type “exit -y” to exit Metasploit
- The script then starts Metasploit with the “
- Metasploit Samba Usermap Script Exploit:
- The script starts Metasploit with “
exploit/multi/samba/usermap_script
” module to exploit the Samba usermap script vulnerability
- The exploit was a success with a session established.
- Type “exit” to end the process and to start the next exploit.
- The script starts Metasploit with “
- Metasploit TWiki History Exploit:
- The script starts Metasploit with the “
exploit/unix/webapp/twiki_history
” module to exploit the TWiki history command execution vulnerability
- No connection established.
- Type “exit” to stop Metasploit and to proceed with the last exploit
- The script starts Metasploit with the “
- The final exploit is “
exploit/unix/ftp/vsftpd_234_backdoo
r” module, exploiting the vsftpd 2.3.4 Backdoor Command Execution vulnerability.
Post-exploitation
Once the backdoor was created I upgraded the shell to meterpreter.
I then uploaded “linpeas” to Metasploitable2 for enumeration.
Exfiltrated “Vulnerable” file to my Kali machine.
Alert and log file
Only 166 packets were analyzed
Three classifications of alerts were detected in the exploitation phase of the attack. It is very interesting to see how most of the attacks were not detect or not correctly classified.
Network Analysis with Wireshark
I merged the pcap files from each attack into one pcap file.
Here is the File Property
Expert Information
Protocol Hierarchy Statistics
Conversation Statistics. Obviously, most packets are from the attacker machine.
HTTP Packet Counter
I will only analyze the NMAP scans and FTP attacks.
NMAP Scans
4361 packets of “TCP connect” scans were captured.
3322 were “SYN” scans.
774 were “SYN-ACK” scans.
FTP
FTP Brute-forcing.
149 attempts were made to brute-force the FTP server
There were 6 successful FTP logins.
Captured Credentials.
Data exfiltration with FTP.
These are the commands executed when “msfadmin” logged in and tried to download all files in the directory but failed.
Lessons learned
With this simple home lab setup, I learned how to configure a machine into promiscuous mode so that it can effectively capture data.
Overall, I gained invaluable hands-on experience in using Snort as an IDS. Throughout the lab project I installed, configured, and explored Snort, a popular open-source intrusion detection and prevention system. I conducted host and port enumeration attacks, exploited vulnerabilities on a target machine (Metasploitable2), and performed post-exploitation activities to test the capabilities of Snort. I learned how to craft custom detection rules, detect suspicious activities, and analyze network traffic using Wireshark. It also made me understand the significance of intrusion detection, and the need for proactively defending network traffics from cyber threats.
Thanks for reading 🙂