# FTP Cleartext Credential Transmission

> Identifies FTP services transmitting credentials in cleartext, demonstrating sniffable authentication and the risks of unencrypted legacy file transfer protocols.

- **URL:** https://hackindex.io/services/ftp/vulnerability-discovery/ftp-cleartext-credential-transmission
- **Path:** FTP > Vulnerability Discovery
- **Up:** [Vulnerability Discovery](https://hackindex.io/services/ftp/vulnerability-discovery.md)
- **Published:** 2026-03-16
- **Updated:** 2026-08-11

Standard FTP sends the username and password as plaintext over the wire. Anyone with access to the network path between client and server can capture these credentials with a packet capture tool. FTPS adds TLS to protect the session. When FTPS is absent or optional, credential exposure is confirmed.

This matters most on flat internal networks, shared segments, and anywhere you can position a capture between a legitimate user and the server.

- **TLS support check** use nmap ssl-enum-ciphers and openssl s_client to determine whether the server supports AUTH TLS.
- **Packet capture** run tcpdump on the network segment and extract USER/PASS commands from plaintext sessions.
- **Manual confirmation** connect with the ftp client and observe whether TLS negotiation occurs during login.
- **Credential reuse** captured FTP credentials are frequently reused across SSH, SMB, and web application logins.

## Check for TLS Support with nmap

```bash
nmap -sV -p $PORT --script ftp-syst,ssl-enum-ciphers $TARGET_IP
```

If `ssl-enum-ciphers` returns no output for the FTP port, the service does not negotiate TLS. If it returns cipher suites, FTPS is available but may still be optional rather than enforced.

Check explicitly whether the server supports AUTH TLS:

```bash
openssl s_client -connect $TARGET_IP:$PORT -starttls ftp 2>&1 | head -20
```

A successful TLS handshake output with a certificate means FTPS is available. An error like `no protocols available` or a connection drop means TLS is not supported at all.

## Capture Credentials with tcpdump

On a network segment where you can see traffic between a client and the FTP server, capture the session:

```bash
tcpdump -i eth0 -w /tmp/ftp_capture.pcap host $TARGET_IP and port $PORT
```

Read the capture and extract credential exchanges:

```bash
tcpdump -r /tmp/ftp_capture.pcap -A | grep -E "USER|PASS"
```

In a plaintext FTP session the output will contain the literal username and password:

```bash
USER svcadmin
PASS Summer2024!
```

## Confirm with a Manual Connection

Connect and authenticate to confirm the session is unencrypted end to end:

```bash
ftp $TARGET_IP $PORT
```

A standard FTP prompt with no TLS negotiation message confirms cleartext. Any message like `234 AUTH TLS successful` during login indicates TLS is in use.

## What Cleartext FTP Enables

Any legitimate user authenticating to the FTP server over a segment you can sniff or pivot through exposes their credentials. In environments where FTP credentials are reused for SSH, Windows accounts, or web application logins, a single captured session can pivot to other services. Credential reuse testing is covered in the SSH and SMB lateral movement pages.

If you are positioned on the same segment as the server and a client is actively using FTP, this is a passive capture requiring no interaction with the target.

## References

- [ ssl-enum-ciphers NSE Script](https://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html) - Enumerates TLS cipher suites and protocol support on any port including FTP
- [RFC 4217 - Securing FTP with TLS](https://www.rfc-editor.org/rfc/rfc4217) - Specification for FTPS AUTH TLS and the FTPS protocol extension