[Editor: This is the second part of a two part series on darknet telescope data. For part 1, please click here.
SRA
Last week’s article focused on finding DoS attacks by accessing SIE Channel 14 from a blade directly connected to an SIE switch port. However, that’s not the only way you can access SIE Channel 14 darknet data. SIE users who are authorized for SIE Remote Access can also access darknet data remotely over an encrypted SRA tunnel. SRA gives you the ability to get a raw data stream from Channel 14 just as if you were using a directly connected system at SIE.
If you’re new to SRA, please check out the following article series:
- Farsight’s Advanced Exchange Access, Part One
- Farsight’s Advanced Exchange Access, Part Two
- Farsight’s Advanced Exchange Access, Part Three
To collect a 100,000 record sample, which only takes a few minutes to accumulate, you’d do something like the following:
$ sratunnel -s 'tls:srausername@srahostname' -c 14 -w ch=14 -o pcap:ch14.pcap -C 100000
Decoding that command, we’re creating an SIE Remote Access (SRA) encrypted
tunnel over TLS, connecting to Channel 14 at the SIE, sending our output to
ch14.pcap in pcap format, and saving 100,000 records from that run.
SRA Random Subdomain DoS Attack Example
We used tshark 1.8.2 under Debian Wheezy in the first part of this series, but for the next set of examples we’ll use tshark 2.0.0 under Mac OS X El Capitan.
Inspecting DNS query names in our 100,000 record capture file collected via SRA, we immediately see an obvious pattern for at least some of that data:
$ tshark -r ch14.pcap -T fields -e dns.qry.name -2 -R "dns.flags.response eq 0" | more akckn.315ye.zj.cn odmzwlkpsdst.315ye.zj.cn dxvmkbhuhjp.315ye.zj.cn ygsjhhvrnqltfag.315ye.zj.cn yjkbahwxyp.315ye.zj.cn ygsjhhvrnqltfag.315ye.zj.cn [etc]
It turns out that there were 849 unique 315ye.zj.cn names in this 100,000
record darknet sample, and virtually all of those name are “random looking” and
unique (with the exception of a couple of names that appeared twice). This
traffic is likely part of a random subdomain denial of service attack targeting 315ye.zj.cn‘s authoritative name
servers. Obviously, if you can “swamp” a domain’s authoritative name servers,
all associated domains will be DoS’d.
If you’re running BIND and end up being targeted by attackers using random subdomain attacks, see section 6.2.16.21 (“Response Rate Limiting”) of the BIND Administrator’s Reference Manual for a way to mitigate that attack.
A Lot of The Traffic In Our SRA Darknet Capture Dataset is TCP
While you might expect darknets to largely see unidirectional “fire-and-forget” UDP or ICMP traffic, darknets also often see a surprising amount of TCP traffic, even if three ways TCP handshakes aren’t a possibility.
For example, in our sample file, the distribution of protocols in our capture looked like:
$ tshark -r ch14.pcap -qz "io,phs"
raw frames:100000 bytes:5788444
ip frames:99987 bytes:5787794 [99.9% of all captured frames]
tcp frames:81651 bytes:4354980 [81.6% of all captured frames]
udp frames:16943 bytes:1317842 [16.9% of all captured frames]
[etc]
Anytime that 4/5ths of your traffic is of one type, it’s worth looking more closely at that traffic. Since we started out talking about denial of service attacks, maybe that’s what we’re seeing here, too.
TCP SYN Flood State Exhaustion DoS Attack?
One classic type of DoS attack is the TCP SYN flood, where a targeted system is repeatedly sent SYNs in an effort to exhaust all available potential connections. Might that be what’s behind all that TCP traffic?
Potentially — but remember that in this case (a) you’re looking at darknet data, and (b) darknet destination IP addresses are not attached to real systems, which means that darknet IP addresses would make an improbable target for a SYN flood attack. We’ll also see that the volume of SYN traffic also isn’t particularly high in this case.
Someone Running an nmap SYN Scan?
Another possibility is that we might be seeing a SYN scan, as done by network
reconnaissance tools such as nmap (see the TCP SYN scan option). We’ll need to look more closely
at this possibility, because this seems quite likely.
Reflective TCP Amplification Attack?
A third (less common) possibility might be spoofed/randomized traffic that’s part of a reflective TCP amplification attacks.
To understand how this can work, see the excellent 2014 paper “Hell of a Handshake: Abusing TCP for Reflective Amplification DDoS Attacks”.
Analyzing The IPv4 TCP SYN Data With tcpdump
Anyhow, let’s take a look and find out. This time, just to keep things interesting, let’s use tcpdump instead of tshark.
$ tcpdump -r ch14.pcap -nn -s0 'tcp[tcpflags] == tcp-syn and !ip6' | awk '{print $3}' |
awk -F. '{print $1 "." $2 "." $3 "." $4}' | sort | uniq -c | sort -nr | head -10
Decoding that command, we’re telling tcpdump to:
-r ch14.pcap: read traffic from the saved file ch14.pcap-nn: refrain from trying to resolve IP addresses or port names-s0: look at the full snap length'tcp[tcpflags] == tcp-syn and !ip6': only take TCP SYN packets (and exclude any IPv6)awk '{print $3}': select the third field (which is the apparent source address)awk -F. '{print $1 "." $2 "." $3 "." $4}': just print the four octets of the IPv4 apparent source address, dropping the port numbersort | uniq -c: sort the IPs and count the number of times each IP appearssort -nr | head -10: sort in descending numeric order and display just the top 10
Our results from that command are shown next, manually augmented with the autonomous system number (ASN) that’s announcing each of those IPs:
Count IP ASN ASN Owner 1116 208.100.26.228 AS32748 Steadfast Networks, Chicago IL 825 46.161.40.120 AS48031 XServer-IP-Network-AS, Kharkov, Ukraine 824 104.219.238.10 AS27176 DataWagon LLC, Rye NY 482 109.255.124.126 AS6830 Liberty Global Operations B.V., Netherlands 476 177.133.45.200 AS18881 Global Village Telecom, Brazil 446 169.229.3.91 AS25 University of California at Berkeley 429 159.146.42.245 AS12735 TurkNet Iletisim Hizmetleri A.S, Turkey 400 61.240.144.67 AS4837 CNCGROUP China169, China 329 122.117.58.60 AS3462 HINET, Taiwan 269 91.223.89.130 AS197569 Energomontazh Ltd., Russian Federation
Let’s Skip The Academic Research Scan Traffic
One of these and hosts, 169.229.3.91, is associated with
researchscan1.eecs.berkeley.edu.
That’s academic research scan traffic rather than being a source of malicious
traffic or a site that’s a victim of reflective attack traffic.
Digging Into Traffic Associated With One Of The Other IPs, 46.161.40.120:
To make it easier to see what’s going on with the SYN traffic, let’s dig a
little into the SYN traffic we’re seeing from just one of those IPs,
46.161.40.120:
$ tcpdump -r ch14.pcap -nn -s0 '(tcp[tcpflags] == tcp-syn) and (src host 46.161.40.120 )' | awk '{print $5}' |
awk -F. '{print $5}' | sort | uniq -c | sort -nr
Decoding that command, we’re asking tcpdump to:
-r ch14.pcap: read pcap data from our ch14.pcap capture file-nn: not attempt to resolve IPs or port numbers-s0: process the full snap length'(tcp[tcpflags] == tcp-syn) and (src host 46.161.40.120 )': look at just SYNs from46.161.40.120awk '{print $5}': look at just the traffic’s destination IP address, field 5awk -F. '{print $5}': dump the IP address, and just keep the destination port numbersort | uniq -c | sort -nr: sort the port numbers, count the number of times each one appears, showing the top ports by descending value
That command reports that just one destination port value, port 3389/tcp, was seen for all 825 records…
Port 3389/tcp
Port 3389/tcp is associated with the remote desktop protocol (RDP) service, and is a favorite target of scanners looking for hosts with 3389/tcp exposed to the Internet.
Why is RDP of interest to third parties? Well, there are many serious known RDP-related issues, including:
“Vulnerabilities in RDP Could Allow Remote Code Execution (3080348)” (Important, 11 Aug 2015)
“Vulnerability in RDP Could Allow Remote Code Execution (3073094)” (Critical, 14 Jul 2015)
If your systems are running RDP, you should check out “Securing Remote Desktop (RDP) for System Administrators”, an excellent guide to improving RDP security for system admins.
What Are the Other IPs Poking At With Their SYNs?
All the other attacks in real time, as they take place. IPs appear to also have been SYN scanning, and each IP is typically focused on a single destination port in each case. Sorting by destination port number, we see four of those IPs are interested in port 23 (the port normally associated with telnet):
109.255.124.126 482 of 482: 23/tcp (telnet) 177.133.45.200 476 of 476: 23/tcp (telnet) 159.146.42.245 429 of 429: 23/tcp (telnet) 122.117.58.60 329 of 329: 23/tcp (telnet)
The fact that four of our top ten apparent scanner sources were interested in 23/tcp (telnet) is surprising, but may be related to this vulnerability, an extremely serious vulnerability from 2 March 2016 that’s easily remotely exploitable.
Three of the remaining four IPs from our “top 10” each seemed to be interested in one specific port:
61.240.144.67 400 of 400: 69/tcp (tftp) 91.223.89.130 269 of 269: 1720/tcp (h.323) 104.219.238.10 824 of 824: 8080/tcp (often used for alternate web servers or web proxies)
There was one exception to the just-scanning one port “rule,” and that was our
most-seen IP, 208.100.26.228, which was seen sending SYNs to a wide range of
popular-to-scan-and-often-vulnerable ports such as 161/tcp, 443/tcp, 261/tcp,
445/tcp, 139/tcp, etc.
Conclusion
There’s a lot more that we could look at in our darknet packet captures so why not sign up for access to SIE Channel 14, and see what else is happening yourself?
Commercial users are charged a fee for access to SIE, but university academic researchers and “Internet superheroes” (those working to combat online abuse as an uncompensated “labor of love”) can ask to receive low cost/no cost grant access to SIE, including access to darknet data on Channel 14.
Joe St Sauver, Ph.D. is a Scientist with Farsight Security, Inc.
