Tracking down BitTorrent activity with packet captures
We love the exercises at malware-traffic-analysis.net, and occasionally we’ll pick some that we try to solve using CloudShark and its tools.
This time however, we’re going through one armed with tools that we learned from Brad’s class (the author of malware-traffic-analysis) at Sharkfest US 2018, where he gave an in-depth class on using packet captures for malware analysis, as well as a presentation on Analyzing Windows malware traffic.
Sharkfest is an international meeting of packet enthusiasts run by the folks behind Wireshark. You can see the retrospective of Sharkfest US 2018 here.
This exercise is great if you’re in IT or network security and are tasked with finding out who is using peer-to-peer software in your organization, and whether or not they should be!
The Exercise - So someone’s BitTorrenting on your network
This exercise is from July 2018, shortly after Sharkfest that year. The scenario we’re given is that we’re receiving alerts that someone on our network is using the BitTorrent protocol to download files. It might be that we’ve received these alerts from an independent regulatory body like the RIAA, or it may be that our Intrusion Detection System (IDS) is flagging the traffic because of some threat rules.
As part of the exercise, we’re given this packet capture.
We’re told the IP address of the offender (10.0.0.201), though it doesn’t take too much work to find it. Malware-traffic-analysis also gives us the following details about the network environment:
- LAN segment: 10.0.0.0/24 (10.0.0.0 through 10.0.0.255)
- Broadcast address: 10.0.0.255
- Domain controller: 10.0.0.2 (DogOfTheYear-DC)
- Domain: dogoftheyear.net
BitTorrent and IDS
The Suricata threat rules will flag BitTorrent traffic by default. Since BitTorrent is a distributed Peer-to-Peer (P2P) download platform, traffic between each node involved in the transfer gets marked as a threat! When looking at this in CloudShark Threat Assessment, we see over one hundred threat alerts (!) all going to the same target address, in this case, 10.0.0.201, which is seeding the BitTorrent and sharing the file with other peers.
Tracking down the system
The exercise wants us to find several details. First off all is identifying the user and host that is using BitTorrent. For this, Brad asks us to find the MAC address, host name, Windows user account name, and Windows version. This not only helps us identify the offending machine, but also the user logged in while downloading files via BitTorrent.
Most of these can be found with some pretty simple CloudShark filters and packet analysis. For MAC address, we filter out only that traffic that originates from the source IP with the filter ip.src==10.0.0.201. Then we take a look at the first packet:
https://www.cloudshark.org/captures/617b9318ef00?filter=frame.number==1
In the Ethernet II field we see the Src: equal to 00:16:17:18:66:c8.
The host name is a little trickier. Since we know it’s a Windows machine, we can probably count on the nbns (NetBIOS Name Service) protocol to be there, which Windows uses to advertise hosts that make themselves available on the network. We can pull out the nbns traffic with the filter nbns&&ip.addr==10.0.0.201. The info column shows that the first packet is a registration message for the host BLANCO-DESKTOP, but you can see it in the packet decode in packet 34 under NetBIOS Name Service –> Queries:
https://www.cloudshark.org/captures/617b9318ef00?filter=frame.number==34
There happens to also be mdns traffic in this capture, which we could use to find the host name. You can see what that looks like here.
We have to dig pretty deep to find the Windows username. If we assume that we’re in an organization using some sort of authentication system for users, we should see a network authentication protocol like Kerberos. The Kerberos protocol presents the authenticating username in a field called cname, specifically in the CNameString.
Here’s the capture filtered to show only Kerberos traffic with the filter ip.addr == 10.0.0.201 && kerberos.CNameString and !(kerberos.CNameString contains $) (we specifically filter out CNameString values with <emclass="code">$ so that we don’t get extraneous sources like shared drives, etc). Diving down into Kerberos –> as-req –> req-body –> cname –> cname-string in packet 1596 we see that the CNameString value is elmer.blanco, our user.
https://www.cloudshark.org/captures/617b9318ef00?filter=frame.number==1596
Lastly, we want the Windows version. We can actually find this from any HTTP traffic in the capture, since HTTP includes a field called User-Agent in its header. We can find HTTP packets that contain User-Agent with the filter ip.addr == 10.0.0.201 && http.user_agent. Looking at packet 1826 and expanding HTTP we see that the User-Agent field contains “Windows NT 10.0”.
Tracking down the BitTorrent
The next information the exercise wants us to find is the start time of the torrent activity, the file that was downloaded, the name of the torrent client used, and the file that was seeded (shared) by the client. We can use this information to find out if in fact the activity was malicious, or just a user forgetting to turn off a torrent on their laptop when coming into the office.
To find the time, we look for when the BitTorrent handshake begins. This is fairly easy; we can filter for the source IP address and the BitTorrent protocol with ip.addr == 10.0.0.201 && bittorrent.
Look at the “Time” column. By default, CloudShark displays this column as “time since the beginning of the capture”. If we want the time of day, we can change to this view by going to Profile–>Custom Columns and selecting “time of day” as the time display format:
We’ve already changed it for this capture of course, so you can see that the first handshake starts at 04:17 (UTC).
What about the file? We know it’s requested via an HTTP GET, and that torrent files end in “.torrent”. So we can filter on the HTTP request URI with ip.addr == 10.0.0.201 && (http.request.uri contains ".torrent").
This finds one packet, the HTTP GET. You can see it right in the info column, but if you look at packet 4264 you can expand the Hypertext Transfer Protocol field and see that the file requested was named Betty_Boop_Rhythm_on_the_Reservation.avi.torrent. Malware-traffic-analysis uses safe files in their examples, but you never know!
There’s a lot more information we can gather from this HTTP request. Take a look at the “follow HTTP stream” view to see all the details, including the server (www.publicdomaintorrents.com).
How do we find which BitTorrent client is being used? In addition to downloading the file, BitTorrent clients also then share other files (by “seeding”) to the rest of the BitTorrent network. It does this by making an HTTP GET to a specific resource called /announce with some additional parameters. However, this request isn’t made over the default TCP port for HTTP (80), so we can look for other HTTP traffic by using the not (!) operator in the filter ip.addr == 10.0.0.201 && http && !(tcp.port == 80).
Looks like there is some HTTP data there! If we look at the follow HTTP stream view, we see the HTTP GET, which lists the User-Agent in the header. In this case it’s Deluge 1.3.15, a BitTorrent client.
Last but not least, we want to find the “seed” file that is being shared by the BitTorrent client to the rest of the network. This involves finding the unique SHA-1 hash that identifies the seed, which is carried in the protocol handshake. This is dissected as the “info_hash”. Let’s go back to our BitTorrent protocol filter and add that field and look at the first packet (4520):
https://www.cloudshark.org/captures/617b9318ef00?filter=frame.number==4520
If you expand the BitTorrent protocol field, you’ll see a field called SHA1 Hash of info dictionary which contains the hash e4be9e4db876e3e3179778b03e906297be5c8dbe. These hashes are unique, so we can search for it in a search engine. The first hit is from linuxtracker.org, which shows us that the file with that hash is a ubuntu-18.04 desktop distribution.
Key Takeaways
Being able to track down BitTorrent activity is a great skill for identifying either malicious activity, or someone who’s using your network for the wrong reasons (even if it’s innocuous). You may actually want to allow BitTorrent on your network if you have people who use it to download things like the linux distribution that was seeded. You might not want to allow it either, if it means a user is downloading copyrighted material or malware. Keep in mind that Suricata rules will flag every BitTorrent exchange by default, so you might get some rather “alarming” results from your IDS when it sees BitTorrent activity on your network.
What a great exercise! We love doing these and are always grateful to malware-traffic-analysis.net for building these challenges. Do you have one that you’d like to see us tackle in CloudShark? Let us know!
TL;DR If you want a direct link to all of the answers and the filters we used to find them, you can find them all in this CloudShark collection. You can build your own collections and write-ups in CloudShark! Find out more here.
Want articles like this delivered righht to your inbox?
No spam, just good networking
