DomainTools Announces Predictive Threat Feeds - Powering Preemptive Exposure Management

Farsight TXT Record

Accessing Darknet Telescope Data via SIE Remote Access (SRA)

Written by:

Joe St Sauver

Published on:

Jun 13, 2016

On This Page

TOC Element

[Editor: This is the second part of a two part series on darknet telescopedata. For part 1, please click

: read traffic from the saved file ch14.pcap

SRA

Last week’s article focused on finding DoS attacks by accessing SIE Channel 14from a blade directly connected to an SIE switch port. However, that’s notthe only way you can access SIE Channel 14 darknet data. SIE users who areauthorized for SIE Remote Access can also access darknet data remotely over anencrypted SRA tunnel. SRA gives you the ability to get a raw data stream fromChannel 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:

To collect a 100,000 record sample, which only takes a few minutes toaccumulate, 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) encryptedtunnel 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, butfor 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 viaSRA, 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,000record darknet sample, and virtually all of those name are “random looking” andunique (with the exception of a couple of names that appeared twice). Thistraffic is likely part of a random subdomain denial of service attack targeting

315ye.zj.cn

‘s authoritative nameservers. 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 randomsubdomain attacks, see section 6.2.16.21 (“Response Rate Limiting”) of theBIND 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 TCPtraffic, even if three ways TCP handshakes aren’t a possibility.

For example, in our sample file, the distribution of protocols in our capturelooked 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 moreclosely at that traffic. Since we started out talking about denial of serviceattacks, maybe that’s what we’re seeing here, too.

TCP SYN Flood State Exhaustion DoS Attack?

One classic type of DoS attack is theTCP SYN flood, where a targetedsystem is repeatedly sent SYNs in an effort to exhaust all available potentialconnections. Might that be what’s behind all that TCP traffic?

Potentially — but remember that in this case (a) you’re looking at darknetdata, and (b) darknet destination IP addresses are not attached to realsystems, which means that darknet IP addresses would make an improbable targetfor a SYN flood attack. We’ll also see that the volume of SYN traffic alsoisn’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 networkreconnaissance tools such as

nmap

(see the TCP SYN scan option). We’ll need to look more closelyat this possibility, because this seems quite likely.

Reflective TCP Amplification Attack?

A third (less common) possibility might be spoofed/randomized traffic that’spart 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 thingsinteresting, 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

-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 number

sort | uniq -c

: sort the IPs and count the number of times each IP appears

sort -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 theautonomous 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 withresearchscan1.eecs.berkeley.edu.That’s academic research scan traffic rather than being a source of malicioustraffic 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 alittle 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 from

46.161.40.120

awk '{print $5}'

: look at just the traffic’s destination IP address, field 5

awk -F. '{print $5}'

: dump the IP address, and just keep the destination port number

sort | 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, wasseen 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 exposedto the Internet.

Why is RDP of interest to third parties? Well, there are many serious knownRDP-related issues, including:

If your systems are running RDP, you should check out “Securing Remote Desktop (RDP) for System Administrators”, an excellent guide to improving RDP securityfor 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 havebeen SYN scanning, and each IP is typically focused on a single destinationport in each case. Sorting by destination port number, we see four of thoseIPs 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 in23/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 interestedin 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 ourmost-seen IP,

208.100.26.228

, which was seen sending SYNs to a wide range ofpopular-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 whynot 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 universityacademic researchers and “Internet superheroes” (those working to combatonline abuse as an uncompensated “labor of love”) can ask to receive lowcost/no cost grant access to SIE, including access to darknet data on Channel14.

Joe St Sauver, Ph.D. is a Scientist with Farsight Security, Inc.

No items found.

Farsight TXT Record

Joe St Sauver