Accessing Darknet Telescope Data via SIE Remote Access (SRA)

← Blog Home


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


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:

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 -2 -R "dns.flags.response eq 0"  | more

It turns out that there were 849 unique 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’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 (“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]

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 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 the autonomous system number (ASN) that’s announcing each of those IPs:

Count		IP			ASN		ASN Owner
1116		AS32748	Steadfast Networks, Chicago IL
 825		AS48031	XServer-IP-Network-AS, Kharkov, Ukraine
 824		AS27176	DataWagon LLC, Rye NY
 482		AS6830	Liberty Global Operations B.V., Netherlands
 476		AS18881	Global Village Telecom, Brazil
 446		AS25		University of California at Berkeley
 429		AS12735	TurkNet Iletisim Hizmetleri A.S, Turkey
 400		AS4837	CNCGROUP China169, China
 329		AS3462	HINET, Taiwan
 269		AS197569 	Energomontazh Ltd., Russian Federation
Let’s Skip The Academic Research Scan Traffic

One of these and hosts,, is associated with 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,

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,

$ tcpdump -r ch14.pcap -nn -s0 '(tcp[tcpflags] == tcp-syn) and (src host )' | 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 )': look at just SYNs from
  • 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, 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:

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):	482 of 482: 23/tcp (telnet)		476 of 476: 23/tcp (telnet)		429 of 429: 23/tcp (telnet)		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:		400 of 400: 69/tcp (tftp)		269 of 269: 1720/tcp (h.323)		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,, 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.


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.

← Blog Home

Protect against cybercriminal activity in real-time.

Request demo

Email: Phone: +1-650-489-7919