TFTP Honey Pot Results

# TFTP Honey pot Results - Information Camouflage Source: [https://bruceediger.com/posts/tftp-honeypot-results/](https://bruceediger.com/posts/tftp-honeypot-results/) My[TFTP honey pot](https://bruceediger.com/posts/tftp-honeypot/)has been running for over a month, continuously on my $5 a month VPS, and intermittently on my[Dell R530](https://bruceediger.com/posts/homelab/)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](https://www.shadowserver.org/)- 5`ERROR`packets, about 1 every 11 seconds1. 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](https://platform.censys.io/home)- RRQ for`/a`, netascii 3. [Driftnet](https://driftnet.io/)- 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](https://www.shodan.io/)- 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](https://www.netscout.com/arbor)- RRQ for file name`ay9mfwq7xxmd4w6c7\\xa0`, octet 7. [Internet Census](https://www.internet-census.org/home.html)- 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](https://github.com/jrlevine/grepcidr3)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\. MinMedianMax**Palo Alto**1424\.233\.7**Netscout**31\.972\.7260**Censys**02460Above, 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 CountNameTypeOACK pairs5RRQ1`startup\-config`octetRRQ1`masscan\-test`netasciiRRQ2`test\.xxx`octetRRQ2`test`octetRRQ7`file\_id\.diz`octetNonconforming11hex:`000010000000000000000000`12 bytes binaryRRQ1`\.\.\\\\\.\.\\\\\.\.\\\\\.\.\\\\boot\.ini`octetRRQ2`test`octetRRQ6`pxelinux\.0`octetRRQ9`config`octet, blksize:1428, tsize:0 optionsRRQ6`a`octet,[Alpha Strike Labs](https://www.alphastrike.io/about/)RRQ1`r7tftp\.txt`octetNonconforming1hex:`68656c700d0a0d0a`8 bytes binary, “help” with 2 crlf end\-of\-linesNonconforming3hex:`00000417271019800000000012101111`16 bytes binaryOne 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](https://github.com/robertdavidgraham/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](https://app.opencve.io/cve/?vendor=tftp)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\.