tcpdump Cleartext Credentials: Find Unencrypted Auth (2026)

tcpdump can absolutely snag unencrypted credentials flying across your network, but what you’re seeing isn’t just "unencrypted data," it’s a specific failure of application-level security protocols.

Here’s how to find them and why they’re so exposed:

Common Causes and Fixes

1. Plaintext HTTP Authentication

• Diagnosis: Look for Authorization: Basic headers in tcpdump output. The string following Basic is base64 encoded, but easily decoded.

  sudo tcpdump -ni any 'tcp port 80 and (tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x45746865)' -A
  

  This command filters for TCP traffic on port 80 (HTTP) and then specifically looks for the ASCII bytes that spell out "http" in the TCP header flags. The -A flag displays the packet content in ASCII.
• Fix: Configure your web server to redirect all HTTP traffic to HTTPS, or for the application itself to use HTTPS for authentication.
  • Nginx Example (Redirect):

    server {
        listen 80;
        server_name yourdomain.com;
        return 301 https://$host$request_uri;
    }
    

    This forces all incoming HTTP requests to be reissued as HTTPS requests, encrypting subsequent traffic.
  • Apache Example (Redirect):

    <VirtualHost *:80>
        ServerName yourdomain.com
        Redirect permanent / https://yourdomain.com/
    </VirtualHost>
    

    Similar to Nginx, this directive tells the browser to request the same resource over HTTPS.
• Why it works: HTTPS uses TLS/SSL to encrypt the entire communication channel, including HTTP headers, so credentials are never sent in the clear.

2. Unencrypted FTP Credentials

• Diagnosis: Search for USER and PASS commands in tcpdump output.

  sudo tcpdump -ni any 'tcp port 21' -A | grep -E 'USER|PASS'
  

  This captures traffic on the standard FTP control port (21) and then filters for lines containing USER or PASS, which are the commands sent by FTP clients to log in.
• Fix: Use FTPS (FTP over SSL/TLS) or SFTP (SSH File Transfer Protocol).
  • Configuring FTPS (vsftpd example): In /etc/vsftpd.conf:

    ssl_enable=YES
    allow_anon_ssl=NO
    force_local_data_ssl=YES
    force_local_logins_ssl=YES
    ssl_tlsv1=YES
    ssl_sslv2=NO
    ssl_sslv3=NO
    rsa_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
    rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
    

    Restart vsftpd: sudo systemctl restart vsftpd. This enables SSL/TLS for both control and data connections in FTP.
  • SFTP: This is often enabled by default with SSH. Ensure your SSH server is running (sshd).
• Why it works: FTPS encrypts the FTP control and data channels using TLS, while SFTP is a completely different protocol built on SSH that inherently provides encryption.

3. Unencrypted Telnet Sessions

• Diagnosis: Look for any interactive text traffic on port 23. Telnet is notoriously insecure.

  sudo tcpdump -ni any 'tcp port 23' -A
  

  This captures all traffic on port 23 and displays it in ASCII. You’ll see login prompts and typed credentials directly.
• Fix: Migrate to SSH (Secure Shell).
  • Server-side: Ensure your SSH daemon (sshd) is running and configured. On most Linux systems, it’s enabled by default. Check status with sudo systemctl status sshd.
  • Client-side: Use ssh username@hostname instead of telnet hostname.
• Why it works: SSH encrypts the entire session, including authentication and all data transmitted, providing confidentiality and integrity.

4. Basic Authentication in Other Protocols (e.g., SOAP, older APIs)

• Diagnosis: Similar to HTTP, search for Authorization: Basic in the tcpdump output, but specify the relevant port if it’s not 80 or 443.

  # Example for a custom API on port 8080
  sudo tcpdump -ni any 'tcp port 8080 and (tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x45746865)' -A
  

• Fix: Update the application or client to use an encrypted protocol (like HTTPS) or a more secure authentication mechanism (e.g., token-based authentication over TLS).
• Why it works: Base64 encoding is not encryption; it’s just encoding. Using it over an unencrypted channel means anyone sniffing can easily decode the credentials.

5. SNMPv1/v2c Community Strings

• Diagnosis: Look for UDP packets on port 161 containing community strings. These are essentially passwords.

  sudo tcpdump -ni any 'udp port 161' -A | grep -i 'public\|private'
  

  This captures SNMP traffic and filters for common community strings like "public" (read-only) or "private" (read-write).
• Fix: Upgrade to SNMPv3 or disable SNMP if not strictly necessary.
  • SNMPv3 Configuration: This involves setting up users with authentication (e.g., HMAC-MD5, HMAC-SHA) and optionally privacy (e.g., DES, AES) protocols. Configuration is done on the SNMP agent (device) and the Network Management Station (NMS).
• Why it works: SNMPv3 adds robust authentication and encryption options, preventing credentials (community strings) from being sent in plaintext.

6. Legacy Application Protocols

• Diagnosis: If you have custom or older applications, you might find proprietary protocols that transmit credentials unencrypted. This requires deep packet inspection and knowledge of the specific protocol.

  # Example: Capturing all traffic and then analyzing with Wireshark or a custom script
  sudo tcpdump -ni any -w capture.pcap
  # Then analyze capture.pcap
  

• Fix: Rewrite the application to use modern, secure protocols like TLS-wrapped versions of existing protocols or entirely new secure protocols.
• Why it works: Modern cryptographic protocols are designed to protect sensitive data in transit.

The Next Hurdle

Once you’ve secured all these plaintext credentials, your next challenge will likely be dealing with the implications of certificate management for your newly enforced HTTPS/TLS connections.