Cybersecurity Challenge Write-Ups

Platform: TryHackMe  |  Room: L2 MAC Flooding & ARP Spoofing

Introduction

For this write-up I chose the TryHackMe room "L2 MAC Flooding & ARP Spoofing". I picked this room because it taught me something practical about layer 2 attacks, especially the difference between passive sniffing, MAC flooding, and ARP spoofing. The room starts with simple enumeration and then gradually moves into man-in-the-middle traffic interception and packet manipulation.

Challenge Summary

In this room, the attacker first gains SSH access to a dual-homed Linux host called eve. From there, the internal network connected to eth1 can be explored. The room then moves through four main ideas:

• Discovering live hosts on the internal subnet.
• Passively sniffing traffic and understanding what can be seen without interfering with the network.
• Using MAC flooding to force a switch into a more hub-like behavior and expose additional traffic.
• Using ARP spoofing / ARP poisoning to become a man-in-the-middle and finally manipulating packets to obtain the final flag.

Environment and Tools Used

I completed the room from my Kali VM connected to the TryHackMe VPN. The main tools I used were:

• ssh — for access to the room machine
• sudo su - — to work as root when needed
• ip and nmap — for network discovery
• tcpdump — for packet capture and live sniffing
• Wireshark — for pcap analysis
• macof — for MAC flooding
• ettercap and etterfilter — for ARP spoofing and packet manipulation
• curl and netcat — for testing services and interacting with the target

Step-by-Step Solution

Task 1: Getting Started

The first task was just preparation. I started the room machine and made sure my Kali VM was connected to the TryHackMe VPN. I also waited a few minutes before connecting, because the room specifically mentions that the services may need time to start.

openvpn <your_tryhackme_config>.ovpn

Task 2: Initial Access

After the target IP appeared, I connected to the first machine by SSH using the credentials given in the room. Once I logged in as admin, I switched to root because the room itself suggests using the root user for the remaining steps.

ssh -o StrictHostKeyChecking=accept-new admin@10.128.176.177
sudo su -

At this point the task was simply to confirm that I could gain access. The correct answer for this step was that access was successful.

Task 3: Network Discovery

The next step was to inspect the second network interface, because the room states that the network of interest is connected to eth1. I first checked the interface configuration to find my internal IP address and subnet.

From this output I identified eve's internal address as 192.168.12.66/24. That immediately answered the first two questions: the IP address was 192.168.12.66 and the CIDR prefix was /24.

To discover the other hosts on the subnet, I used an Nmap ping scan. This showed three hosts in total: alice, bob, and eve.

nmap -sn 192.168.12.0/24

Task 4: Passive Network Sniffing

This task focused on passive sniffing — only listening on eth1 without changing any traffic.

I started by watching the traffic live using tcpdump:

tcpdump -i eth1

To get a more readable view of the payload, I also used the ASCII option. The useful part was the first line of each packet, which showed bob sending ICMP echo requests to eve and eve replying.

After that, I wrote the packets to a pcap file so I could inspect them in Wireshark more comfortably:

tcpdump -i eth1 -w /tmp/tcpdump.pcap

Task 5: Sniffing While MAC Flooding

The next idea was to increase the amount of visible traffic by using MAC flooding. The theory is that if the switch's MAC table becomes overloaded, it may temporarily act more like a hub and forward extra frames to other ports. I used two SSH sessions: one to capture, one to flood.

First SSH session:

tcpdump -i eth1 -w /tmp/tcpdump2b.pcap

Second SSH session:

macof -i eth1

After around one minute I stopped both, copied the capture back to Kali, and opened it in Wireshark:

scp admin@10.128.176.177:/tmp/tcpdump2b.pcap .
wireshark tcpdump2b.pcap

I could now see additional ICMP traffic between Alice and Bob. The correct packet type was ICMP and the data size was 1337 bytes. This task also taught me that MAC flooding is noisy, unreliable, and not something a real attacker would prefer if a quieter method is available.

Task 6: Man-In-The-Middle: Intro to ARP Spoofing

Since MAC flooding is noisy, the room moved to ARP spoofing. The idea was to poison the ARP caches of Alice and Bob and place eve in the middle of their communication.

ettercap -T -i eth1 -M arp

In this first scenario, the hosts were using ARP validation, so ettercap could not establish a proper MITM. The answer to whether MITM could be established was therefore Nay.

Task 7: Man-In-The-Middle: Sniffing

Task 7 introduced a new machine with Alice and Bob running Ubuntu with default ARP behavior, making a successful ARP spoofing attack realistic.

ssh -o StrictHostKeyChecking=accept-new admin@10.129.153.233
sudo su -
ip a s eth1
nmap -sn 192.168.12.0/24

I then scanned both systems for open services:

nmap -sV 192.168.12.10 192.168.12.20

Alice had 4444/tcp open, Bob had 80/tcp open. I tested direct access to Bob's web service:

curl http://192.168.12.20

The server replied with "no auth header received" — the service was reachable but protected.

I then launched ARP spoofing with ettercap and monitored HTTP traffic in a second terminal:

First SSH session:

ettercap -T -i eth1 -M arp

Second SSH session:

tcpdump -i eth1 -A port 80

This time the attack worked. I could see Alice sending HTTP requests to Bob through eve. The request showed the Host header was www.server.bob, the requested file was /test.txt, and the HTTP response body contained OK. I also spotted a Basic Authorization header which decoded to admin:s3cr3t_P4zz.

Using those credentials I was able to retrieve the first flag:

curl -u admin:s3cr3t_P4zz -H "Host: www.server.bob" http://192.168.12.20/user.txt

Flag: THM{wh0s_$n!ff1ng_0ur_cr3ds}

I also observed Bob connecting back to Alice on port 4444, revealing a reverse shell. By watching the stream I saw the commands executed in order: whoami, pwd, and ls. The file of interest was root.txt.

When stopping ettercap with q, the tool gracefully re-ARPed the victims to restore the ARP state.

Task 8: Man-In-The-Middle: Manipulation

The final task moved from passive interception to active packet manipulation. I created an etterfilter source file (whoami.ecf) to replace Alice's whoami command with a reverse shell payload, then compiled it:

etterfilter whoami.ecf -o whoami.ef

I disabled ufw to ensure the incoming reverse shell would not be blocked:

I started a Netcat listener on port 6666, then launched ettercap with the compiled filter:

ettercap -T -i eth1 -M arp /192.168.12.10// /192.168.12.20// -F whoami.ef

The filter worked. Alice's whoami command was replaced by my reverse shell payload, and Bob connected back to my Netcat listener. I had remote shell access as root and found the final flag:

Flag: THM{wh4t_an_ev1l_M!tM_u_R}

What Failed and How I Corrected It

• My Kali VM lost internet access at one point — I had to fix the VMware/NAT setup and restart services on my host before continuing.
• I mistyped eht1 instead of eth1 and forgot the -w option on some tcpdump commands, causing errors until I corrected them.
• When copying pcap files with scp, I first ran the command in the wrong session and had to correct the direction of the file copy.
• In Task 7, I initially wrote down the decoded credentials incorrectly. After inspecting the Authorization: Basic header more carefully, I got the right username and password.
• In Task 8, I mistakenly left the placeholder <reverse_shell> in the filter file instead of replacing it with an actual payload.
• I also initially confused the etterfilter source file (.ecf) with the compiled file (.ef). Ettercap requires the compiled version produced by etterfilter.

What I Learned

• Passive sniffing on a switched network only shows traffic already destined for my interface.
• MAC flooding can expose more traffic but is noisy and unreliable.
• ARP spoofing is a much more practical MITM approach when hosts do not validate ARP replies.
• Packet captures are more useful when you understand exactly which field you are looking at.
• MITM attacks are not only about listening — with the right tool they can also manipulate live network traffic.

Conclusion

Overall, I found this room very useful because it connected networking theory to practical attack behavior. I started by identifying hosts on an internal subnet, then moved to passive analysis, MAC flooding, ARP spoofing, and finally packet manipulation. The room clearly showed the difference between a network where traffic is merely visible and one where the attacker can actively interfere with what two hosts send to each other.

The challenge also reinforced a good lesson as a beginner: solving labs is rarely just about one perfect command. A lot of the work comes from observing outputs carefully, correcting small mistakes, comparing approaches, and understanding why one method fails while another succeeds.