This lab felt different from the earlier Snort exercises I worked on. My first Snort write-up, "Analyzing Network Attacks with Wireshark & Snort: From Visibility to Detection", focused heavily on visibility and basic detection. This time, Snort Challenge 2 pushed me into a more active SOC mindset where I was not just detecting suspicious traffic anymore, but actually stopping malicious activity in real time.

The lab simulated two attack scenarios. The first scenario involved a brute-force attack targeting SSH services, while the second scenario focused on outbound reverse-shell traffic. Instead of relying only on packet captures, this lab forced me to think more like a SOC analyst handling live traffic, detection engineering, IPS deployment, and threat containment.

Throughout the lab, I had to debug rules, understand the difference between IDS and IPS modes, troubleshoot inline mode errors, inspect traffic manually, and finally stop the attacks long enough for the system to generate the flag.

This Snort rules lab became one of the most practical IDS/IPS alert triage experiences I have worked through so far.

What I Saw First

The first thing I noticed was that the challenge was not asking for simple packet inspection anymore. Instead, the focus shifted toward live monitoring and active threat prevention.

The lab immediately mentioned brute-force attacks and reverse shells, which already hinted at two different attack patterns:

• repeated authentication attempts
• suspicious outbound persistent connections

I started by checking the available files and understanding the environment first.

ls

After that, I moved directly into traffic inspection mode.

For the brute-force scenario, I launched Snort in sniffer mode:

sudo snort -dev

At the same time, I also used tcpdump because it gave cleaner visibility for live traffic patterns.

sudo tcpdump -nn

Almost immediately, I started noticing repeated SSH connection attempts targeting port 22.

That was the first major clue. The repeated authentication traffic strongly suggested an SSH brute-force attack.

For the reverse-shell scenario, the outbound traffic pattern looked completely different. Instead of repeated login attempts, I observed persistent outbound communication to an unusual high port.

That traffic pattern immediately felt more dangerous because outbound persistence usually means the attacker already has execution on the target system, as I was taught.

Why It Looked Normal

At first glance, the SSH traffic almost looked harmless.

SSH traffic itself is normal inside most enterprise environments. Administrators connect to systems constantly, so seeing packets moving toward port 22 is not automatically suspicious.

That is exactly why brute-force attacks can sometimes blend into normal operations. The same thing happened during the reverse-shell investigation.

Outbound TCP connections happen all the time:

• software updates
• APIs
• cloud synchronization
• remote services
• monitoring tools

So if someone only looked at traffic volume, the reverse-shell traffic might not immediately stand out.

This is where IDS/IPS alert triage becomes important.

A SOC analyst cannot rely only on whether traffic exists. The real question becomes:

• Is the behavior repetitive?
• Is the destination suspicious?
• Is the communication persistent?
• Is the traffic using ports commonly associated with offensive tooling?

That changed how I approached the investigation.

What Felt Off

The first thing that felt wrong during the brute-force scenario was the repetition pattern. The same source kept attempting connections repeatedly against SSH. That repetitive authentication behavior is one of the classic signs of brute-force activity.

The service under attack was:

SSH

The protocol and port involved were:

TCP/22

Once I confirmed that, I started building a Snort IPS rule to stop the traffic.

I edited the local rules file:

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

Then I created a blocking rule:

drop tcp any any -> any 22 (msg:"SSH Brute Force Blocked"; sid:1000001; rev:1;)

That was my transition from IDS into IPS behavior.

Earlier labs mostly used:

alert

But this lab required:

drop

which actively blocks traffic.

During the reverse shell investigation, another major clue appeared.

The outbound traffic was communicating over:

TCP/4444

That immediately reminded me of Metasploit reverse shell payloads because port 4444 is heavily associated with Meterpreter and reverse_tcp payloads.

The associated tool was:

Metasploit

That was the moment the outbound traffic stopped looking like normal communication and started looking like an active compromise.

Where I Got It Wrong - (Well, there is always where I get it wrong, sorry to break it to you)

One of the biggest mistakes I made during the lab involved Snort IPS mode.

At one point, I tried running inline mode against packet captures directly.

I used commands involving:

-Q

while still attempting to process PCAP files. That immediately produced this error:

ERROR: pcap DAQ does not support inline. Fatal Error, Quitting..

At first, that error confused me. I initially thought the problem was related to my rules.

But after debugging it carefully, I realized the issue was architectural. Snort inline IPS mode only works on live interfaces.

PCAP analysis and inline blocking are two completely different operating modes.

This was the corrected approach: For testing detections:

sudo snort -c /etc/snort/snort.conf -A console

For actual IPS mode:

sudo snort -Q--daq afpacket -i eth0 -c /etc/snort/snort.conf -A full

That distinction became one of the most important lessons in the entire Snort Challenge 2 lab.

Another thing I struggled with was understanding why traffic detection worked differently between packet captures and filtered Snort logs.

Earlier in the Snort labs, I discovered that packet numbering changes depending on whether:

• you inspect the raw PCAP
• you inspect filtered Snort logs
• you inspect alert-generated streams

That completely changed how I debugged traffic analysis later in the room.

What Changed My Thinking

The biggest mindset shift during this lab was understanding the difference between:

• visibility
• detection
• prevention

In earlier traffic analysis labs, I mainly focused on identifying suspicious traffic.

This challenge forced me to think about containment. Stopping the attack became just as important as identifying it.

For the brute-force scenario, detection alone was not enough. The attack continued until the IPS rule successfully dropped the packets. The same happened with the reverse shell.

Seeing outbound traffic on port 4444 changed my thinking completely because reverse-shell detection focuses on post-compromise behavior.

That is a completely different SOC mindset.

Inbound attacks ask:

"Can the attacker get in?"

Outbound reverse-shell detection asks:

"Is the attacker already inside?"

That distinction made this lab feel far more realistic.

I also started appreciating why SOC analysts monitor egress traffic so aggressively.

A lot of organizations focus heavily on perimeter defense but forget that outbound communication often exposes:

• C2 activity
• malware callbacks
• reverse shells
• data exfiltration
• persistence

This lab made that concept feel practical instead of theoretical.

My Final Conclusion

Snort Challenge 2 pushed me beyond simple IDS monitoring into active IPS traffic blocking and detection engineering. Thanks to THM

The lab combined:

• IDS/IPS alert triage
• brute-force detection
• reverse shell detection
• live traffic inspection
• inline packet blocking
• rule troubleshooting
• SOC-style investigation workflows

The brute-force scenario taught me how to identify repeated authentication attempts and stop malicious SSH traffic using Snort IPS rules.

The reverse-shell scenario taught me how outbound persistent connections can reveal active compromise, especially when the traffic involves ports heavily associated with offensive tooling like Metasploit.

One of the most valuable parts of this lab was learning the operational difference between:

• offline PCAP analysis
• live IDS monitoring
• inline IPS blocking

That distinction matters a lot in real-world environments.

This Snort Challenge 2 lab felt much closer to how an actual SOC analyst would investigate and contain suspicious traffic inside a production network.

What I Would Do in a Real SOC

If this happened in a real SOC environment, I would not stop at simply blocking the traffic.

For the SSH brute-force activity, I would:

• identify the attacking IPs
• review authentication logs
• verify whether any credentials were compromised
• check for successful logins
• enforce MFA if possible
• review exposed services
• investigate whether password spraying occurred across multiple systems

For the reverse-shell activity, I would treat the host as potentially compromised immediately.

My next steps would include:

• isolating the endpoint
• collecting volatile evidence
• reviewing outbound connection history
• checking persistence locations
• analyzing running processes
• searching for command-and-control indicators
• reviewing EDR telemetry
• identifying lateral movement attempts

I would also investigate whether the attacker used:

• Metasploit payloads
• Meterpreter sessions
• encoded PowerShell
• suspicious scheduled tasks
• persistence scripts

Most importantly, I would document:

• attack timeline
• IOC evidence
• affected systems
• blocked indicators
• detection gaps
• containment actions

because detection without documentation creates problems later during incident response reviews.

This lab really helped connect traffic analysis with real SOC operations, and it made Snort feel less like a classroom tool and more like an operational defensive system.

One thing I genuinely liked about this room was how much troubleshooting it forced me to do. I struggled with IPS inline mode errors, packet interpretation differences, and rule debugging several times before getting stable detections. That debugging process actually helped me first with a lot of Dopamine, and also understand Snort much better than simply copying working rules.

And honestly, that is probably the biggest lesson I took away from this Snort Challenge 2 walkthrough.

Snort Rules and Signatures That Worked

HTTP Detection

alert tcp any 80 -> any any (msg:"TCP Port 80 inbound traffic detected"; sid:1000001; rev:1;)

alert tcp any any -> any 80 (msg:"TCP Port 80 outbound traffic detected"; sid:1000002; rev:1;)

FTP Failed Login Detection

alert tcp any 21 -> any any (msg:"FTP Failed Login"; content:"530"; sid:1000003; rev:1;)

FTP Successful Login Detection

alert tcp any 21 -> any any (msg:"FTP Successful Login"; content:"230"; sid:1000004; rev:1;)

PNG File Detection

alert tcp any any -> any any (msg:"PNG File Detected"; content:"|89 50 4E 47|"; sid:1000001; rev:1;)

GIF Detection

alert tcp any any -> any any (msg:"GIF File Detected"; content:"GIF89a"; sid:1000002; rev:1;)

Torrent Metafile Detection

alert tcp any any -> any any (msg:"Torrent Metafile Detected"; content:"application/x-bittorrent"; sid:1000001; rev:1;)

MS17-010 SMB Detection

alert tcp any any -> any 445 (msg:"IPC Share Access Detected"; content:"\\IPC$"; sid:1000001; rev:1;)

Reverse Shell Blocking Rule

drop tcp any any -> any 4444 (msg:"Reverse Shell Blocked"; sid:1000001; rev:1;)

HTTP GET Detection

alert tcp any any <> any 80 (msg:"GET Request Found"; content:"GET"; sid:1000001; rev:1;)

Payload Size Detection

alert tcp any any -> any any (msg:"Suspicious Payload Size"; dsize:770<>855; sid:1000001; rev:1

Visit my everyday playground here