Analysing an ISR–EvilGrade hijacked session

In the previous post, the ISR-EvilGrade tool was used along with msfcli, msfpayload and dnsspoof to conduct a person-in-the middle attack against the update process of Notepad++ application. While gaining access is always interesting, more focused should be placed on the who, what, where, when and how it was done. Every opportunity should be used to understand the process an attacker used to gain and or maintain access. This is the only way mitigation can be put in place to hopefully avert similar future actions.

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.

Beginning with the Windows client, let’s look at it’s ARP cache.

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

Time to revisit the packet capture to see how much we can get out of this

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

Now that we have the DNS information, let’s see what other applications were involved.

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.

Mitigation?!
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.