Neutrino, one of the world’s most popular exploit kits, will be the base for our Hacks Weekly scenario. Its malicious code can be injected into legitimate resources – like websites – and compromise a computer through various vendor vulnerabilities.  

However, due to NTA, we are able to track Neutrino steps and find the root that has caused the infection. 

Let’s start with our scenario. We have three Windows computers active and at least one of them has an exploit kit injected. Our goal is to check if any of entities were infected. 

We’ll do it by analyzing the pickup file in Wireshark. The pickup file we will be analyzing in this scenario is located in the file CQURE > Wireshark_pcaps > pcaps, and its name is net-analysis-01.pcap.  

After we have opened our Wireshark, we need to determine the hosts. Shortly speaking, we need to identify the endpoints. 

The very first thing to do is clicking on Statistics. Now go to Endpoints. In the IPv4 table, what are the IP addresses of the endpoints that were captured in this pickup file. 

We are interested in one particular network segment – the subnet, which is starting with 192.168.204. We found few addresses, however, note that .255 is obviously the broadcast address. 

What we need at this stage is to check the names of those endpoints (host names). 

We can do it by closing this window and going to the Statistics tab and next clicking Resolved Addresses. Here, in the Resolved Addresses, let’s search for those Ips that start with 192. We can see that in this case we have only one name of a user – User-1-PC.local. This is the only PC which name has been resolved from this subnet. 

What can we do next is applying the display filter. Try to apply a filter: 

 ip.addr==192.168.204.0/24  

Let’s filter our pickup file. 

As a result, if there is an LLMNR protocol found, you can see the names of other PCs. You can note that the IP ending with:  

.137 is called MYHUMPS-PC 

.146 is called WORKSTATION6 

Also, we should see the ROCKETMAN-PC with the ending of .139 

Now we can start with analyzing the traffic from the PC that ends with .137. You can change the display filter from the whole subnet to just the IP address of one endpoint and then scroll up. 

Next, let’s search for the HTTPS communication. In our scenario, we can see TCP requests and we see it is coming from our endpoint to the destination 64.233.168.102. 

The next step is to search for that particular address, for example in the who.is search. We can see that this domain, this IP, actually belongs to Google, which shouldn’t be suspicious. 

However, what can we do as well, is copying this IP address and check the reputation of this address in various places. In the video, we picked up the Barracuda Lookup. After checking the reputation, we can see that currently this IP address is not listed as poor on the Barracuda Reputation System. 

Right now it seems legit, therefore we can move forward and add another display filter. As a result, we won’t see the communication to that legit address. 

To add a filter, let’s add an exclusion: 

ip.addr==192.168.204.137 and !ip.addr==64.233.168.102   

And let’s search. Now let’s search for HTTPS communication again. The most interesting packet for us is the number 2658 with additional info: Client Hello. We can analyze this the same way we did previously. Afterwards, you should be able to confirm that this IP address is also not suspicious. 

So let’s add as well this IP address to our display filter and exclude it from our search. 

ip.addr==192.168.204.137 and !ip.addr==64.233.168.102  and !ip.addr == 64.233.160.105. 

The next packet that is interesting for us is the GET request to the IP address 213.186.33.19. 

This is the first time we will analyze the GET request. See the Hypertext Transfer Protocol details below. We can see that the full host URI is http://www.theopen.be.  

Let’s also go to the response which is in line 2754 here. In our case, we’ve got the response 200 OK. We can expand this section. At the end of the section, you can see that the source was another website col.reganhosting.com/link. This is interesting, so please keep it in mind. 

Next, we will go to the packet 2740. You have to get back a little bit to our GET request and right click on it and next Follow and TCP Stream. 

We also have the information that the host was theopen.be. 

You can go through the whole TCP Stream here. You can deduct if, in your opinion, it is potentially malicious or suspicious, or rather not. 

This time it doesn’t look suspicious. We will exclude the whole TCP Stream 108 from our search. Let’s close this window and add: 

ip.addr==192.168.204.137 and !ip.addr==64.233.168.102  and !ip.addr == 64.233.160.105 and !tcp.stream==108 

Additionally, we can filter out IP address associated with the stream to get less entries. We can also add another exclusion. 

ip.addr==192.168.204.137 and !ip.addr==64.233.168.102  and !ip.addr == 64.233.160.105 and !tcp.stream==108 and !ip.addr==213.186.33.19 

Now the packet that interests us has packet number 2793 and this is another GET request. We can follow the TCP stream again. The server is the nginx. We can also find that the host was col.reganhosting.com but, the referer was theopen.be. 

It may suggest that when a user went to theopen.be website, he got redirected to the col.reganhosting.com. 

We can identify another packet which is 2807 with an HTTP response. Here we can see that there is an iframe with an interesting source and unusual port.  

Now go to the previous filter to this one and let’s include here the weird destination port – the 22780. You can add tcp.dstport==22780 and search.  

ip.addr==192.168.204.137 and !ip.addr==64.233.168.102  and !ip.addr == 64.233.160.105 and !tcp.stream==108 and !ip.addr==213.186.33.19 and tcp.dstport==22780 

As we got two GET requests, we can check both of them.  

So the GET request leads us to the flow destination and to the restless destination. We can modify our filter again to look for HTTP only. 

ip.addr==192.168.204.137 and !ip.addr==64.233.168.102  and !ip.addr == 64.233.160.105 and !tcp.stream==108 and !ip.addr==213.186.33.19 and tcp.dstport==22780 and http 

You should get a really clear view right now. What we will need is another packet that is not visible in this place. We need to go back two steps. Delete the two last parameters.  

ip.addr==192.168.204.137 and !ip.addr==64.233.168.102  and !ip.addr == 64.233.160.105 and !tcp.stream==108 and !ip.addr==213.186.33.19  

What we need is to find number 3178 which is also a response from the server. 

We can see the HTML here – we’ve got some sources from Adobe like get_flash_player.gif, Get Adobe Flash Player and also truncated image source which is encoded in base 64. 

Let’s analyze another packet which will be the 3487. It seems to be a regular GET request to Google APIs. 

Another packet that is 4332. This one looks like a standard download from the Adobe website. You can go further and look at packet 4461. There is another GET request. We can find here a specific line. Let’s go to Follow and TCP stream. 

And that should be interesting for you – we have here a compressed Flash object, which turns out to be the Neutrino Exploit Kit. 

Under normal circumstances and regular investigation, researchers can actually save this file for further analysis. Focusing on analyzing malware is a great topic for another Hacks Weekly video. However, I can show you how to do it. 

You can go to File -> Export Objects -> HTTP and look for the desired packet. 

Now you can save it and once you save that file, you can leave it for further analysis. 

To sum up the whole process of Network Traffic Analysis, we believe that the infection flow began when the user went to the website theopen.be. That website redirected him to another website, which caused the victim to open the connection to a website with a strange port. The website with a strange port contained an embedded flash object which was in fact malicious. 

Finally, we conducted the whole investigation. Now we know what was the root cause of the infection. What are the possible consequences – you can imagine. They can be pretty harmful.  

Please let us know if you have any questions and we absolutely hope to see you in further episodes of the CQURE Hacks Weekly.