TFTP (Port 69/UDP): Enumeration, Exploitation, and Security

TFTP: Port 69/UDP Enumeration and Exploitation #

TFTP (Trivial File Transfer Protocol) is a file transfer protocol over UDP, port 69, that requires no authentication : anyone who accesses the service can download (and often upload) files without providing credentials. It has almost disappeared from the public web, but it remains ubiquitous within corporate networks—VoIP phones, switches, routers, and embedded systems still use it today to download configurations and firmware at startup.

What is TFTP and why does it still exist? #

TFTP was born in the 80s (RFC 1350) with a specific goal: to be the simplest possible file transfer protocol, designed for devices with very little memory that need to download a file at startup without having to manage logins, encryption, or complex sessions. No usernames, no passwords, no encryption: the client requests a file, the server sends it, period.

This very simplicity is why it's rare to find it exposed on the Internet today, yet it remains very common within internal networks: Cisco IP phones and VoIP in general, switches and routers that download their configuration at startup, embedded devices, and industrial IoT. If you're running an internal pentest or an HTB/VulnLab machine with "old-school" network architecture, open port 69/UDP is almost always a sign of this type of infrastructure.

First rule: TFTP runs over UDP, not TCP. #

A common mistake beginners make is to scan TFTP as if it were just any TCP service. UDP has no handshake, so Nmap has to do a different job to determine if the port is actually open:

nmap -sU -p 69 --script tftp-enum TARGET

One detail to keep in mind: on a generic UDP scan, port 69 often appears open|filtered — because in the absence of a response, Nmap cannot distinguish “closed port” from “filtered port by a firewall.” The script tftp-enum It resolves the ambiguity by actually trying to download files from a list of common paths, and if something responds, you have confirmation that the service is alive.

Enumeration: TFTP does not list files, but you can guess #

The biggest limitation of TFTP, from the point of view of an attacker who just wants to snoop, is that the protocol it does not provide a command to list the available filesYou need to know the exact name of the file you want to download. That's why the enumeration is based on guessing common names: tftp-enum Nmap tests typical paths (VoIP configuration files like SIPDefault.cnf, SEPDefault.cnf, syncinfo.xml), which is often sufficient because many devices use standard vendor names.

nmap -Pn -sU -p69 --script tftp-enum TARGET

Metasploit has a dedicated module that does more or less the same thing in an automated way, trying a wordlist of paths:

msf6 > use auxiliary/scanner/tftp/tftpbrute
msf6 auxiliary(scanner/tftp/tftpbrute) > set RHOSTS TARGET
msf6 auxiliary(scanner/tftp/tftpbrute) > run

Downloading and uploading files with the TFTP client #

Once you have a plausible file name (or found it with enumeration), the client tftp included in almost every system is enough to interact with the service:

tftp TARGET
tftp> get nome-del-file-di-configurazione

If the server also allows uploading (not all implementations do, but many default configurations do), you can also write:

tftp> put file-locale.txt

The uploadability is what makes TFTP interesting beyond just reading: a device that automatically downloads its configuration from a TFTP server, if you can write a file with the same name in there, could load your configuration on the next reboot.

What do you really find in downloaded files? #

The practical value of TFTP in a pentest is almost always in the contents of the configuration files you can download, not in the protocol itself:

grep -i "password\|secret\|username" config-scaricato.txt

Cisco devices, for example, often use "Type 7" passwords, a very weak encryption designed solely to prevent the password from being readable by someone looking over their shoulder. It's not designed to resist access by someone who already has the file, and online tools and services have been available for years that can instantly decrypt it. Juniper and other vendor configurations may contain SSH keys or SNMP community strings, which are equally useful for accessing other systems on the same network.

Intercept and modify TFTP traffic #

Because TFTP doesn't encrypt anything and doesn't verify the identity of the responder, traffic is also susceptible to manipulation in transit. On a network where you can gain access (for example, with ARP spoofing, as we explain in the Scapy guide ), you can read in plain text what a device is downloading—or, in more advanced scenarios, replace the file it receives with your own. It's the same principle that, on a network distributing firmware or configurations via TFTP without any other protection, whoever controls the traffic effectively controls what that device will run on its next boot.

Some known vulnerabilities, to give a concrete idea #

In addition to the protocol's structural weaknesses, some specific TFTP server implementations have developed more serious bugs over time: servers like SolarWinds TFTP Server have had vulnerabilities that allowed arbitrary files to be uploaded using incorrect path management, while other implementations have suffered from directory traversal, capable of allowing files to be read or written outside the server's intended directory. The common thread is always the same: a protocol that doesn't verify anything leaves the burden of checking what is legal to read or write to the individual server software, and not all servers do this well.

Detection & Defense #

• TFTP should not May be reachable from untrusted networks or the Internet: if a device needs to download configurations via TFTP, keep it on a dedicated, isolated VLAN
• If the use case allows, replace it with alternatives that offer at least some authentication or encryption (SCP, SFTP, HTTPS for firmware distribution)
• Monitor UDP traffic on port 69 - In many corporate networks this is a service that should only appear during scheduled maintenance windows, not continuously.
• If you can't eliminate it, strictly limit which hosts can contact the TFTP server and which files are actually exposed — avoid leaving the entire configuration directory reachable.

FAQ #

Does TFTP require credentials? No, by definition: that's one of the reasons the protocol exists, designed for devices that need to download a file at startup as simply as possible.

Why does Nmap often mark port 69 as open|filtered? Because UDP has no handshake: without an explicit response, Nmap cannot distinguish a closed port from a filtered one. A script like tftp-enum, which actually tries to interact with the service, gives a more reliable response.

Is TFTP still in production today? Yes, especially in internal networks with VoIP devices, switches/routers that download configurations at startup, and embedded systems—much less on the public web, where the lack of authentication makes it too risky to expose.

To learn more #

• HackTricks — 69/UDP TFTP — complete technical reference on enumeration and special cases
• Our guide to scapey Shows how to construct and intercept packets such as TFTP when you need complete control over the traffic.

This article is for educational purposes only. Techniques tested on authorized environments such as HackTheBox, VulnLab, and personal labs.