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
   • RRQ for /a, netascii
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.

	Min	Median	Max
Palo Alto	14	24.2	33.7
Netscout	31.9	72.7	260
Censys	0	24	60

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

	Count	Name	Type
OACK pairs	5
RRQ	1	startup-config	octet
RRQ	1	masscan-test	netascii
RRQ	2	test.xxx	octet
RRQ	2	test	octet
RRQ	7	file_id.diz	octet
Nonconforming	11	hex: 000010000000000000000000	12 bytes binary
RRQ	1	..\\..\\..\\..\\boot.ini	octet
RRQ	2	test	octet
RRQ	6	pxelinux.0	octet
RRQ	9	config	octet, blksize:1428, tsize:0 options
RRQ	6	a	octet, Alpha Strike Labs
RRQ	1	r7tftp.txt	octet
Nonconforming	1	hex: 68656c700d0a0d0a	8 bytes binary, “help” with 2 crlf end-of-lines
Nonconforming	3	hex: 00000417271019800000000012101111	16 bytes binary

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.