Topology information from previous post
The victim (IP:10.0.0.53 – MAC: 08:00:27:AF:DA:7A) will be running Windows 2003 with NotePad++ v5.8.2.
The gateway (IP:10.0.0.254 - MAC: 08:00:27:33:3B:10 )
The attacker (IP:10.0.0.50 - MAC: 08:00:27:14:56:63 )
Let’s see what we can learn from the previous attack.
As can be seen we have 2 hosts 10.0.0.50 and 10.0.0.254 both saying they are at 08-00-27-14-56-63. From the topology information, it can be seen that this MAC belongs to the attacker.
Next, let’s look at the ARP cache for the gateway
Once again we see MAC 08-00-27-14-56-63 being reportedly found at 10.0.0.53 and 10.0.0.50. These two ARP cache are clear signs of an ARP Poisoning.Let’s take a look at tshark to see what we can gather from the pcap file
Tshark “arp” filter, shows a number of “duplicate use of IP …”
Moving up the TCP/IP stack, let’s look for established TCP sessions on the Windows system and what it matches with via the “tasklist”
Above shows that the Windows server has an established session with the attacker on port 8080. A tasklist command shows the binary “b.exe” is running with PID 3256
Focusing on the DNS traffic first
This shows in packet 11, that the client at 10.0.0.53 made the DNS request for notepad-plus.sourceforge.net
In packet 12, the attacker at 10.0.0.50 responds claiming notepad-plus.sourceforge.net can be found at its’ IP 10.0.0.50
Looking further into the capture, we see at packet 88, the client starts a connection to port 80 on 10.0.0.50. Once this connection is established, we see that the client at 10.0.0.53 then does a HTTP GET request for “b.exe”. Remember above we showed that b.exe is using process ID 3256.
This brief and quick analysis showed us some of the ways we may be able to detect a person-in-the-middle attack or at least be able to conduct a quick analysis of a packet capture to draw some sound conclusions.
The likelihood of this attack could have been reduced through:
Using static ARP entry – This is much easier said than done, since in most cases our systems learn their ARP entry dynamically. However, if the devices were configured with static ARP entries the ARP spoofing would have more than likely failed. Hence this entire scenario may have failed since we would not have been able to intercept the DNS request using the method in the previous post.