TFTP Honey pot Results – Information Camouflage

My TFTP honey pot
has been running for over a month, continuously on my $5 a month VPS,
and intermittently on my Dell R530 home server.
It’s time to see what surprises it has captured.

When the TFTP honey pot runs, both servers
see between 20 and 50 TFTP packets per day.
Both servers see mostly the same traffic.
I was extremely excited when I got daily UDP port 69 traffic,
most of it in TFTP format.
I was let down when I realized most of the traffic was
regularly scheduled scans
from seven infosec companies.

Infosec company scans

1. Shadow Servers
   • 5 ERROR packets, about 1 every 11 seconds
     1. Code 4, message “Bad Filename”
     2. Code 0, message “Access violation”
     3. Code 4, message “4”, 1 extra bytes “\x05\x00\x044\x00\x00”
     4. Code 5, message “Illegal TID”
     5. Code 4, message “Illegal TFTP operation”
   • RRQ for a.pdf, octet, on a different schedule than the burst of ERROR packets
2. Censys
3. Driftnet
   • RRQ for file named with 8, randomly-chosen letters, netascii
   • File name fist pattern “[a-zA-Z][a-zA-Z][a-zA-Z][a-zA-Z][a-zA-Z][a-zA-Z][a-zA-Z][a-zA-Z]”
   • Sometimes via IPv6
4. Shodan
   • 16 byte non-conforming UDP payload
   • hex representation: 00000417271019800000000000034925
   • Arrives from UDP port 18020 about half the time
   • bursts of 4-6 packets inside of two minutes, from two or more IP addresses
5. Secretive Palo Alto Networks
   • RRQ for /a, netascii, followed by RRQ for file, octet.
6. Netscout
   • RRQ for file name ay9mfwq7xxmd4w6c7\xa0, octet
7. Internet Census
   • RRQ, file name /a, netascii
   • 16 byte non-conforming UDP payload, no two exactly the same
   • hex: 000004172710198000000000xxyyzzww
   • superficially resemble Shodan non-conforming UDP payload

Yes, that’s three companies that regularly request
a file named “a” for download.
I found it tedious to disentangle the requests.
Command line whois doesn’t provide very regular output.
I retrieved CIDR data for each of the three from whois,
and re-extracted log entries based on CIDRs using grepcidr
to double-check that I caught all the log entries of each company,
and assigned log entries to those companies correctly.

These seven companies mostly use IP addresses registered to themselves.
Most of the IP addresses are without A records in DNS.
I was able to find the owners of the addresses via whois.
Shodan is the exception, sometimes using their own IP addresses,
sometimes using Digital Ocean addresses.

I can’t discern any kind of schedule other than “about once a day”
for most of these company’s probes.
Over 35 days, my always-on TFTP honey pot got 35 pairs of probes
from Palo Alto Networks IPv4 addresses.
Requests of each pair arrive about 45 seconds apart.
The first request of the pairs arrives a mean of 24.09 hours apart,
minimum of 14 hours apart, maximum of 33.65 hours apart.

Above, examples of intervals (in hours) between probes
from three of the infosec companies.
Even for Palo Alto Networks and Censys probes,
a median of 24 hours is almost meaningless given the range
of between-probe-intervals.

Cryptic probes: irregular or very infrequent

One more that’s not so easily described:

Five busts of RRQ for y000000000028.cfg, 000000000000.cfg,
y000000000000.boot, ata192.cfg, spa504g.cfg, spa112.cfg
in various combinations,
all with type octet, all from 199.115.115.137.

What’s the point of these scans?

First and foremost, it seems like mere identification of
IP addresses listening on UDP port 69 is a major purpose.
Netscout, Internet Census and Censys seem to be looking for TFTP servers.
Doing an RRQ for a file named /a or 8, randomly-selected characters
can’t lead to more than identifying that a TFTP server listens
on port 69 on a given IP address.
The RRQ for masscan-test seems to be a server existence probe
hiding behind Robert Graham’s masscan,
which is a TCP-only, whole internet scanner.

One of the RRQs asks for a file named r7tftp.txt,
a file requested by the nmap TFTP server ID module.
I don’t believe that RRQ was generated by nmap,
but certainly one of the points of these scans is to identify
which TFTP server runs on which host.
Palo Alto Networks pairs of requests of /a with type “netascii”,
followed by file with type “octet” seem like an attempt to identify
which server software answered the request.
Neither /a nor file are likely to exist,
so servers probably respond with ERROR packets.
Palo Alto Networks must be distinguishing between different server software.
I hypothesize that Shadow Servers’ burst of ERROR packets,
and the pairs of OACK packets must serve the same purpose by different means.

A few of the packets probe for poorly-configured servers.
The single request for ..\\..\\..\\..\\boot.ini
obviously attempts to see if a Windows TFTP server allows directory traversal.
Asking for pxelinux.0 and all the files 199.115.115.137. requests
fall in this category.

I have no idea what Shodan gets from sending bursts of packets that don’t
conform to TFTP.

There are only a few CVEs
for TFTP server.
I don’t think any of the probes are attempts to exploit TFTP server
vulnerabilities.
One of the ironies of this experiment is that most of the TFTP
traffic comes from infosec companies,
not “bad guys” trying to exploit niche software.