Cybersecurity Challenge Write-Ups

Group Project

Ali — Man-In-The-Middle Attack: ARP Spoofing

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:

Environment and Tools Used

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

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
VPN terminal output VPN connection command Room instructions to start machine

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.

SSH login and root access

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.

eth1 interface configuration

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
Nmap scan showing alice, bob, eve Task 3 answers

Task 4: Passive Network Sniffing

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

Network topology diagram

I started by watching the traffic live using tcpdump:

tcpdump -i eth1
tcpdump live capture showing ICMP traffic

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.

tcpdump ASCII output

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
tcpdump writing to pcap SCP file transfer Wireshark showing ping packets Correct answers for Task 4

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
SCP copy of 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.

Answer: 1337 bytes

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

ARP cache poisoning diagram

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.

Ettercap output with ARP validation Task 6 answers

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
Nmap scan showing two hosts IP addresses of Alice and Bob

I then scanned both systems for open services:

nmap -sV 192.168.12.10 192.168.12.20
Nmap service scan results

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
curl response: no auth header received

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

Task answer: Nay

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
Passive tcpdump before ARP spoofing

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.

HTTP request visible after ARP spoofing HTTP response body Authorization header captured

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}

Flag: user.txt

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.

TCP stream showing whoami Connection between 192.168.12.10 and 192.168.12.20 ls command in reverse shell stream

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

Ettercap graceful shutdown Task 7 answers part 1 Task 7 answers part 2

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:

whoami.ecf filter source
etterfilter whoami.ecf -o whoami.ef
etterfilter compilation output

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

ufw disabled

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:

Netcat listener

Flag: THM{wh4t_an_ev1l_M!tM_u_R}

Root shell with final flag

What Failed and How I Corrected It

What I Learned

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.

Bozhidar

Write your challenge write-up here.

Danil

Write your challenge write-up here.

Mateusz

Write your challenge write-up here.

Nikita

Write your challenge write-up here.