Tracking down BitTorrent activity with packet captures
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
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.
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
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
Then we take a look at the first packet:
Ethernet II field we see the
Src: equal to
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
The info column shows that the first packet is a registration message for
BLANCO-DESKTOP, but you can see it in the packet decode in packet 34
under NetBIOS Name Service –> Queries:
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
specifically in the
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
$ 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.
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
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
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
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
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 (
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
/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
we see the HTTP GET, which lists the
User-Agent in the header. In this case
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):
If you expand the BitTorrent protocol field, you’ll see a field called
SHA1 Hash of info dictionary which contains the hash
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.
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.
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!