Man-in-the-Middle Detection | Tryhackme Write-up

Room Link: https://tryhackme.com/room/mitmdetection

Task 1 Introduction

Man-in-the-middle (MITM) attacks represent one of the most insidious threats in network security. In these attacks, attackers position themselves between legitimate communication endpoints to intercept, modify, or redirect traffic. From a blue team perspective, detecting these attacks requires a multi-layered approach combining network monitoring, certificate validation, and behavioral analysis.

Scenario

A routine network monitoring alert at Acme Corp revealed unusual traffic patterns suggesting a possible Man-in-the-Middle (MITM) attack inside the corporate LAN. Over several days, an attacker quietly intercepted communications, redirected connections, and captured user credentials.
In this room, you’ll step into the role of a SOC Analyst investigating this incident. Using the provided packet capture and logs, you’ll uncover evidence of three chained MITM techniques.

• ARP Spoofing (network interception).

• DNS Spoofing (redirection).

• SSL Stripping (credential capture).

Task 4: Detecting ARP Spoofing

In this scenario, multiple hosts broadcast ARP requests asking “Who has the gateway IP? What is its MAC address?”
The legitimate gateway responds with its correct MAC address, but the attacker also replies, falsely claiming the same gateway IP.
This results in one IP address (gateway) being associated with two different MAC addresses, which is a classic ARP spoofing indicator.

Additionally, the attacker sends Gratuitous ARP replies (unsolicited ARP responses) to many hosts, advertising “192.168.10.1 is at <attacker MAC>”, increasing the poisoning impact.

1. How many ARP packets from the gateway MAC Address were observed?

Ans: 10

This filter shows only valid ARP replies where the gateway IP (192.168.10.1) is correctly associated with its legitimate MAC address (02:aa:bb:cc:00:01), helping distinguish normal gateway behavior

arp && arp.src.proto_ipv4 == 192.168.10.1 && eth.src == 02:aa:bb:cc:00:01

2. What MAC address was used by the attacker to impersonate the gateway?

Ans: 02:fe:fe:fe:55:55

arp.opcode == 2 && arp.src.proto_ipv4 == 192.168.10.1

all ARP reply packets claiming to be the gateway (192.168.10.1).

It includes both the legitimate gateway MAC and unknown (attacker) MAC addresses, making it useful for identifying ARP spoofing attempts.

3. How many Gratuitous ARP replies were observed for 192.168.10.1?

Ans: 2

filtering Gratuitous ARP replies, now for only this IP

4. How many unique MAC addresses claimed the same IP (192.168.10.1)?

Ans: 2

Using the filter ,two different MAC addresses were observed responding for the same IP:

Filter: arp.opcode ==2 && _ws.col.info contains "192.168.10.1 is at”

One MAC address belongs to the legitimate gateway, and the other is the attacker’s MAC, confirming ARP spoofing.

5. How many ARP spoofing packets were observed in total from the attacker?

Ans: 14

arp.duplicate-address-detected || arp.duplicate-address-frame —> duplicate MAC address mappings to a single IP address detected, here all duplicate responses came from same MAC address which is attacker MAC

Task 5: Unmasking DNS Spoofing

dns #only DNS traffic

dns.flags.response == 1 #dns response, not request:  this domain -- is at this IP

dns.flags.response == 1 && ip.src == 8.8.8.8 #responses from legit DNS server

dns.flags.response == 1 && ip.src !== 8.8.8.8 #reponses not from our DNS server

#specific domain
#who is asking for this domain IP
dns && dns.qry.name == "corp-login.acme-corp.local" 
#DNS responses for this domain
dns.flags.response == 1 && dns.qry.name == "corp-login.acme-corp.local"

#reponses,  for this domain request, from our DNS server
dns.flags.response == 1 && dns.qry.name == "corp-login.acme-corp.local" && ip.src == 8.8.8.8 

#responses, for this domain, not from our DNS server
dns.flags.response == 1 && dns.qry.name == "corp-login.acme-corp.local" && ip.src !== 8.8.8.8

1. How many DNS responses were observed for the domain corp-login.acme-corp.local?

Ans: 211

2. How many DNS requests were observed from the IPs other than 8.8.8.8?

Ans: 2

Apart from the legitimate DNS server (8.8.8.8), another IP was observed responding to queries for the domain corp-login.acme-corp.local, falsely claiming that the domain resolves to its own IP address.

The attacker’s goal is to poison DNS responses, causing hosts to send their intended traffic to the attacker-controlled system instead of the legitimate server.

3. What IP did the attacker’s forged DNS response return for the domain?

Ans: 192.168.10.55

Task 6: Spotting SSL Stripping in Action

Answer the questions below

1. How many POST requests were observed for our domain corp-login.acme-corp.local?

Ans: 1

After DNS spoofing, client traffic intended for the legitimate domain is redirected to the attacker’s IP. As a result, HTTP requests are sent to the attacker in cleartext instead of the real server.

2. What's the password of the victim found in the plaintext after successful ssl stripping attack.

Ans: Secret123!

Summary

Let's look at the investigation summary, including the attack timeline.

• ARP Spoofing (cache poisoning):

  • ARP spoof begins, attacker sends unsolicited ARP is-at claiming gateway IP.

• DNS Spoofing (forged DNS responses):

  • Victim DNS query for corp-login.acme-corp.local.

  • Forged DNS response from attacker, answers domain → 192.168.10.55.

• SSL Stripping (TLS downgrade / credential capture):

  • The Victim initiates connection to resolved IP, HTTP to attacker (SSL stripping effect).

  • Credential POST observed (cleartext).

Keep Hunting!