Stephen Reese

Detecting Tor traffic with Bro network traffic analyzer

January 16, 2016 · By Stephen Reese

Terminology note: Bro was renamed Zeek after this article was published. The commands, paths, log formats, and .bro script extension shown below reflect Bro 2.4 and may differ in current Zeek releases.

This article is part of a series on identifying Tor network traffic with the Bro Network Security Monitor, now Zeek. This article focuses on network detection rather than whether Tor should be permitted. Because some malware families use Tor for command-and-control communications, my goal was to identify Tor activity that might warrant further investigation.

One common method is to compare network traffic with a current list of known Tor relay addresses. Although useful, this method can produce false positives because a relay host may also provide legitimate non-Tor services. The goal was to supplement retrospective relay-IP matching with a protocol-level indicator derived from TLS certificate metadata.

If we take a look at the Tor certificates, we see an interesting pattern in the issuer and subject fields.

Screen Shot

Using tshark, the issuer and subject patterns are more apparent.

$ tshark -r tor.pcap -T fields -R "ssl.handshake.certificate" -e x509af.utcTime -e x509sat.uTF8String 13-10-15 00:00:00 (UTC),14-02-11 23:59:59 (UTC) www.axslhtfqq.com,www.hkkch64skp7am.net
13-12-30 18:32:48 (UTC),14-12-30 18:32:48 (UTC) www.igdpzct5tauwgyqs.com,www.4tdznzbrfuv.net
13-10-04 00:00:00 (UTC),14-04-22 00:00:00 (UTC) www.3pxivyds.com,www.nolspqtib3ix.net
13-11-17 00:00:00 (UTC),14-06-22 00:00:00 (UTC) www.3pzqe4en5.com,www.glk3fwiz6.net
13-06-19 00:00:00 (UTC),14-04-20 00:00:00 (UTC) www.5orbut4ufhohm5rlj47.com,www.orutxjqwf.net
13-06-15 00:00:00 (UTC),14-02-04 00:00:00 (UTC) www.7wdf4rkj5mew.com,www.sd5mkmsmo.net
13-11-19 00:00:00 (UTC),14-02-05 23:59:59 (UTC) www.75ba5lymxpbhw3a2kb.com,www.rnspic4yus5crf6w.net
13-12-30 19:54:02 (UTC),14-12-30 19:54:02 (UTC) www.s5rc22gpzrwt4e.com,www.qzsg2ioaoplbs2gaha5.net
13-08-12 00:00:00 (UTC),14-04-16 23:59:59 (UTC) www.2fwld67ac2.com,www.6suxdq3miwwewq4.net
13-12-18 00:00:00 (UTC),14-02-14 23:59:59 (UTC) www.npmxal2ohuefme26yf.com,www.c7kriuquvh.net
13-10-18 00:00:00 (UTC),14-06-16 00:00:00 (UTC) www.s426lumoi7.com,www.ouzbot23a6lw3vvmszx.net
13-12-31 00:00:00 (UTC),14-02-01 23:59:59 (UTC) www.vywbff5wkza6npkd5l.com,www.ugdrrog5ro5wdfddj.net
13-11-27 00:00:00 (UTC),14-08-13 00:00:00 (UTC) www.ozsx22b4nda.com,www.lr7s5k3n6ber.net
13-03-31 00:00:00 (UTC),14-01-06 23:59:59 (UTC) www.plgx26wgyroot37x3ysj.com,www.xwx5gpj5t2msq3.net
13-12-18 00:00:00 (UTC),14-02-20 00:00:00 (UTC) www.gempmzrnwnk.com,www.6lrz7wtwprz.net
13-08-16 00:00:00 (UTC),14-01-26 23:59:59 (UTC) www.rxy4jiw4wk.com,www.g66mipkcyhjwumywk4h.net

Based on this pattern, I looked for an existing Bro method that identified unusual certificate names. Fortunately, Seth Hall had created the detect-tor.bro script for this purpose. I downloaded the latest Bro 2.4 source package and built it on my Ubuntu VM. I also pulled down the aforementioned detect-tor.bro script. I was greeted with a warning and did not see the expected logs:

$ sudo /usr/local/bro/bin/bro -r tor.pcap detect-tor.bro
warning in /usr/local/bro/share/bro/base/misc/find-checksum-offloading.bro, line 54: Your trace file likely has invalid TCP checksums, most likely from NIC checksum offloading. By default, packets with invalid checksums are discarded by Bro unless using the -C command-line option or toggling the 'ignore_checksums' variable. Alternatively, disable checksum offloading by the network adapter to ensure Bro analyzes the actual checksums that are transmitted.

Because the capture contained invalid checksums caused by capture or checksum-offload artifacts, rerunning Bro with -C allowed it to process those packets. This option should be used only when the checksum errors are understood.

$ sudo /usr/local/bro/bin/bro -C -r tor.pcap detect-tor.bro

After processing the packet capture, Bro generates several log files. At first glance, we see an alert from the detect-tor.bro script. The notice identifies the originating host but does not report a single destination. The script triggers only after the host connects to multiple servers presenting certificates that match the heuristic.

We can reduce the output to the fields relevant to the alert:

$ cat notice.log|/usr/local/bro/bin/bro-cut -c -d note msg src dst actions suppress_for dropped
#separator \x09
#set_separator ,
#empty_field (empty)
#unset_field -
#path notice
#open 2014-01-03-14-12-05
#fields note msg src dst actions suppress_for dropped
#types string string addr addr table[enum] interval bool
DetectTor::Found 10.0.0.126 was found using Tor by connecting to servers with at least 10 unique weird certs 10.0.0.126 - Notice::ACTION_LOG 3600.000000 F

After seeing the alert in the notice.log, we look in the ssl.log file as well in order to determine what traffic caused the alert to fire. Again, we can select the fields we want to see in order to minimize output.

$ cat ssl.log|/usr/local/bro/bin/bro-cut -c -d ts uid id.orig_h id.orig_p id.resp_h id.resp_p version cipher server_name subject issuer_subject not_valid_before not_valid_after
#separator \x09
#set_separator ,
#empty_field (empty)
#unset_field -
#path ssl
#open 2014-01-03-14-12-05
#fields ts uid id.orig_h id.orig_p id.resp_h id.resp_p version cipher server_name subject issuer_subject not_valid_before not_valid_after
#types string string addr port addr port string string string string string time string
2013-12-30T15:20:21-0500 CwRHlF31djcMrO7Z98 10.0.0.126 51191 199.36.221.196 9001 TLSv10 TLS_DHE_RSA_WITH_AES_256_CBC_SHA www.wplgkqpnteb.com CN=www.ri6ufvqioii5se5tzbgt.net CN=www.dyyp6enzivlm46.com 2013-12-30T18:48:56-0500 2014-12-30T18:48:56-0500
2013-12-30T15:20:21-0500 Ck1Mgy4ubChMFyneFc 10.0.0.126 38946 198.27.97.223 443 TLSv10 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA www.p65b.com CN=www.hkkch64skp7am.net CN=www.axslhtfqq.com 2013-10-15T00:00:00-0400 2014-02-11T23:59:59-0500
2013-12-30T15:20:21-0500 CZOEio3mxlQgpmVD2i 10.0.0.126 36715 149.9.0.60 9001 TLSv10 TLS_DHE_RSA_WITH_AES_256_CBC_SHA www.dpvdl3n6yzwv.com CN=www.anojueopqlpgsj.net CN=www.u2rsltgpogir6t.com 2013-11-14T00:00:00-0500 2014-04-29T23:59:59-0400
2013-12-30T15:20:21-0500 CnU0VyJcJHaeCaxh8 10.0.0.126 49341 66.18.12.197 443 TLSv10 TLS_DHE_RSA_WITH_AES_256_CBC_SHA www.6kyx72vjlrwxcmxnj4we7n.com CN=www.4tdznzbrfuv.net CN=www.igdpzct5tauwgyqs.com 2013-12-30T18:32:48-0500 2014-12-30T18:32:48-0500
2013-12-30T15:20:21-0500 Cc00yR3kKWb2GstwXf 10.0.0.126 40742 64.62.249.222 443 TLSv10 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA www.de5v2whiex3xxy.com CN=www.glk3fwiz6.net CN=www.3pzqe4en5.com 2013-11-17T00:00:00-0500 2014-06-22T00:00:00-0400
2013-12-30T15:20:21-0500 CuVFNK14saFKjGVhfh 10.0.0.126 54393 50.115.122.68 9001 TLSv10 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA www.ojj4rbje7z7.com CN=www.qexiojanju56.net CN=www.nnfslkrseh.com 2013-12-18T00:00:00-0500 2014-01-21T00:00:00-0500
2013-12-30T15:20:21-0500 CROLl5Vd0jUzvvwn 10.0.0.126 46797 212.83.140.45 443 TLSv10 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA www.esd7jqvwpbwebf.com CN=www.nolspqtib3ix.net CN=www.3pxivyds.com 2013-10-04T00:00:00-0400 2014-04-22T00:00:00-0400
2013-12-30T15:20:21-0500 CXemGQ4G0PFf5DvUf 10.0.0.126 34887 72.52.91.30 5901 TLSv10 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA www.igyewbs5.com CN=www.bnlln35al.net CN=www.henq76fjat2ozl2537.com 2013-08-09T00:00:00-0400 2014-06-27T00:00:00-0400
2013-12-30T15:20:21-0500 CFrNiH22BOLl917zjl 10.0.0.126 56135 144.76.109.178 9081 TLSv10 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA www.57xl.com CN=www.3rvuayihf4t35h.net CN=www.viw7rvktu36ov.com 2013-12-10T00:00:00-0500 2014-01-04T00:00:00-0500
2013-12-30T15:20:21-0500 CxEp7Xmn9AOlkxn0e 10.0.0.126 44997 31.7.186.228 443 TLSv10 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA www.ewrk2xtmr.com CN=www.orutxjqwf.net CN=www.5orbut4ufhohm5rlj47.com 2013-06-19T00:00:00-0400 2014-04-20T00:00:00-0400
2013-12-30T15:20:21-0500 CwzpD92UikR0USUErj 10.0.0.126 58912 91.121.113.70 9001 TLSv10 TLS_DHE_RSA_WITH_AES_256_CBC_SHA www.

The certificate-name heuristic was designed around Tor behavior observed at the time of the capture. It should not be assumed to identify current Tor implementations reliably. Changes to Tor’s TLS behavior can produce false negatives, while unrelated certificates with similar randomized names can produce false positives.

In this historical capture, the script identified a host that connected to multiple servers presenting certificate names matching the Tor heuristic. The alert should be treated as an indicator requiring corroboration rather than proof of Tor use. Corroborating evidence may include relay data valid at the time of capture, destination analysis, endpoint telemetry, and related connection behavior.