How to create a GeoIP map report with Wireshark

We usually need to create an executive report when we are involved in an incident handling. In these cases, a good option could be to include in it a world map with the connections which were established in the incident. Maybe we are interested in showing on a map where the command an control servers are hosted or for example to show which countries the distributed denial of service came from...

To achieve this purpose I am going to show you how to create a map using Wireshark. The last Wireshark version 1.10.2 will be used in this guide.

The first thing we need to do is to  download the GeoIP database: GeoLite City, Country, and ASNum from the link below: http://geolite.maxmind.com/download/geoip/database/ (free download).

Then, we need to put into a folder the files contained in the downloads above, for example "C:\Geoip".

Now, we need to tell Wireshark where the GeoIP files are. To achieve this, we need to open Wireshark and go to Edit -> Preferences - > Name Resolution and click on Edit in the "GeoIP database directories" section...

... and create a New path where the files were saved, in this case "C:\Geoip".

It is necessary to restart Wireshark in order to apply the changes. Now, we only need to load a PCAP file or create a new traffic capture. When we have all the traffic captured and we want to create the map with the connection involved in the incident, we need to go to Statistics -> Endpoints...

... select the IPv4 tab and click on the map bottom. Notice that if for example you have set a filter in Wireshark only with the UDP connections which are related to the malware, you can select "Limit to display filter" in order to only print these connections on the map. Then you click on map.

Finally, we have a dynamic map complete connections on the map. In this case, I've used the PCAP file related to the attack to php.net which can be downloaded from the Barracuda website here.

Read More

The importance of the User-Agent in the Botnets connections

The RFC 1945 says in the 10.15 section:

"The User-Agent request-header field contains information about the user agent originating the request. This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations. Although it is not required, user agents should include this field with requests."

We know that the infected hosts which belong to a botnet make callbacks to the command and control (C&C) server usually through the port 80 which is commonly open in the majority of the networks. Currently the  network security  administrators have "next generation firewalls" which are able to detect if a connection crossing by this port is an standard HTTP connection or not (like a shell on tcp/80 port) in order to allow or drop it. For this reason, some malware developers create malicious binaries with HTTP capabilities and sometimes they use the User-Agent field to send information to the C&C server to achieve their goals. (Notice that if the malware is implementing SSL the next generation firewall administrator would need to configure a SSL decryption in their firewalls if they want to look into these connections)

In this post, I am going to show you some examples which use the User-Agent to transmit information in this HTTP field.

Malware Sample 1

In this example, the malware creates a visual basic script which will be running to connect with the C&C server. We talked about it in the last post Decoding the code encoded. In this case, I could edit the the visual basic in order to change the C&C domain name by the localhost 127.0.0.1 address where I have a netcat listening in the port 80. Netcat will receive the malware connections instead of the C&C server. In the picture below, we can see the result.

1. This line corresponds to Netcat running in the computer where the malware is being analyzed. It is listening "-l" in the 80/tcp port "-p 80".
2. We can see the connection executes a POST request.
3. The malware is sending information about the compromised host in the User-Agent field with no more data in the HTTP body. This is the information which is being send to the C&C server:
   
   User-Agent: {DiskVolumeSerial}<|>{Hostname}<|>{Username}<|>{OS}<|>underworld final<|>{AVProductInstalled or nan-av}<|>{USBSpread: true or false}
   

Malware Sample 2

I sent a malware sample to my Cuckoo Sandbox to analyze its behavior and I got a traffic capture. If we use Wireshark to see the connections in the traffic capture, we can filter by "http.user_agent" to show only the information about the requests made by the malware which contains  this field  in the HTTP connections. You can see these connections in the picture below.

Right-clicking in each HTTP request, we can select "Follow TCP Stream" in order to see the data in like the application layer sees it. In the picture below, we can see the Follow TCP Stream of the first connection.

1. A GET petition including the MAC address of the infected host has been made. Normally the malware sends information with POST connections, but in this case, the malware request a URL with contains the infected computer's  MAC address to send this information to the C&C server in a different way... The MAC address will be register in the remote HTTP server logs.
2. The User-Agent its the same that the name of the malicious executable. Maybe the malware developer has the same malmare hosted in different servers and he wants to trace them or maybe wants to know the malicious program version.
3. In the GET connection, the infected host receives three codes: 1,1,0. We would need to dig on it making a reversing engineer to try to figure out what the malware exactly does with these codes.

The next petition the compromised host does, is to make another GET request to the C&C server.

1. We can see another GET request including the MAC address. Now, the HTTP petition has tree fields: "v1", "v2" and "v3".
2. The connection continues using the same User-Agent.
3. Now, the the host receive the "0" code.

In the picture below, we can see that in the next request made by the malware, the User-Agent has changed.

1. The malware visit "/version" path.
2. The User-Agent has changed. With this name, we can figure out that the malware is trying to check if it has connection to the Internet but it does not make sense, because the malware has received two codes before in two different petitions...
3. We can see four different executables separated by @date| . Maybe it is the date when they were compiled.

The next connections are related with the last request which I have described above. We can see how the malware request the same executables it received before. The question here is why it download them twice each binary.

The malware downloads the four executables and changes its User-Agent again when it is requesting them.

1. The URL path where the malware is hosted.
2. User-Agent is changed to "installer-agent".
3. The executable download.

The last connection the malware does is the same that the second one.

 This malware seems to use the User-Agent like it were a radio announcer.

Malware Sample 3

This example came from the Fireye blog and belongs to the well-know Flamer malware.

In the picture below, which has been taken from the blog mentioned above, we can see that the .NET version used by this malware is NET CLR 1.1.2150. This version has not been released by Microsoft ever. It is really difficult to know what these numbers want to say... It may be the malware version...

Malware Sample 4

This example came from the Fireye blog too.

In the picture below (taken from the Fireye blog) we can see that the User-Agent contains the strings "sleep 300000" and a date"ct:Mon Feb 25 23:11:58 2013". It could be possible that the zombie computer is telling the C&C how much time the malware has been sleeping and from what day or maybe it informs to the C&C sever that it received the sleep command.

Conclusion

In this post we have seen how the malware exchanges information with the command and control servers using the User-Agent and the importance of this HTTP field. Many of them do not modify its User-Agent or implements  a well-known User-Agent to try to be undetectable, but if it changes you can create a custom signature for you IDS (Snort, Suricata...) in order to locate more infected hosts in your network which are making connections with the User-Agent customized by the malware.

Read More