How to find cleartext credentials and weak authentication in a PCAP

Every network has a printer posting its admin password over HTTP, or a backup job logging in to FTP. Anyone who can see the traffic can read those credentials. A capture audit finds them before someone else does, along with the authentication that is encrypted but weak enough to crack.

By Stuart Mathieson8 minute readWireshark + tsharkUpdated 12 October 2026
The quick way

Upload the capture and PCAPNG Analyzer Pro flags the most common exposures for you: passwords over plain HTTP, cleartext LDAP binds, SMB1, RC4 or DES Kerberos tickets and bursts of failed logons, each with how to fix it. Devices & services shows the accounts and workstations involved, and passwords are never stored.

See a sample incident report →
Audit only networks you're responsible for.

Capturing and reading other people's credentials without authorisation is illegal in most places. Treat every credential you find as already compromised, and keep the passwords themselves out of your notes and reports.

In this guide
  1. Start with Wireshark's credentials list
  2. Check web logins
  3. Check legacy clear-text protocols
  4. Find weak authentication
  5. Look for failed logons
  6. Fix and report
  7. Manual vs automated workflow

1. Start with Wireshark's credentials list

Wireshark collects the credentials its dissectors recognise in Tools → Credentials. From the command line:

tshark -r capture.pcapng -q -z credentials

On a test capture it listed an HTTP Basic login and an FTP login, with the packet number for each. It doesn't look inside web forms, so a password posted from a login page won't appear. Run the checks below as well.

2. Check web logins

Over plain HTTP, two kinds of login are readable. Basic authentication sends the user name and password in a header, merely base64-encoded:

http.authbasic

Form logins send them in the request body. This finds posts with a field whose name looks like a password:

http.request.method == "POST" && urlencoded-form.key matches "(?i)pass|pwd"

Passwords in URLs end up in proxy and server logs as well as the capture, so check query strings too: http.request.uri matches "(?i)pass|pwd|token". Over HTTPS none of this is visible, and that's the point: the fix for every hit here is to move the login to HTTPS.

3. Check legacy clear-text protocols

Older protocols send credentials in clear text by design. One filter covers the usual suspects (tshark accepts it as written; in Wireshark’s filter bar, join it into one line):

ftp.request.command in {"USER", "PASS"} || pop.request.command in {"USER", "PASS"}
  || lower(imap.request.command) == "login" || smtp.req.command == "AUTH"
  || snmp.community || ldap.simple || telnet.data

4. Find weak authentication

Some authentication is encrypted but weak enough that a captured exchange can be cracked offline or replayed:

5. Look for failed logons

A burst of failures is either a misconfigured service or someone guessing. These filters find failures in the main Windows authentication protocols:

kerberos.error_code in {6, 24} || ldap.resultCode == 49 || smb2.nt_status == 0xc000006d

Kerberos error 6 is an unknown user name, and 24 a wrong password. LDAP result 49 is invalid credentials, and the SMB status is a logon failure. Many accounts failing from one host suggests password spraying; many unknown names suggests user enumeration; one account failing endlessly is usually a stale saved password.

6. Fix and report

Clean results only cover what you captured.

A device that logs in once a day won't appear in a ten-minute capture, and traffic that never crossed your capture point isn't in the file. Capture at the right place, for long enough to catch scheduled jobs.

Manual method vs PCAPNG Analyzer

Manual method

  1. Read Wireshark's credentials list.
  2. Filter for web logins and legacy clear-text protocols.
  3. Check Kerberos tickets, NTLM and SMB versions.
  4. Filter for failed-logon bursts.
  5. Record each exposure without the secret.

With PCAPNG Analyzer

  1. Upload the capture.
  2. Review the findings for HTTP credentials, LDAP binds, SMB1, weak Kerberos and failed logons, and open Devices & services for the accounts behind them.
  3. Run the legacy-protocol filter in step 3 for FTP, mail, SNMP and Telnet, then share the incident report, which names accounts, not passwords.
What the app checks

The Pro detections cover HTTP form posts with password fields and Basic authentication over plain HTTP, LDAP simple binds on unencrypted connections, SMB1 negotiation, Kerberos tickets encrypted with RC4 or DES, and bursts of failed logons across Kerberos, LDAP and SMB. LDAP passwords are never stored: the app records that a simple bind happened, and the account, not the secret. FTP, Telnet, POP3, IMAP, SMTP AUTH and SNMP community strings aren't flagged, so use the filter in step 3 for those.

Find what your network leaks

Flag cleartext logins and weak authentication in every capture, on a server you control.

Compare Free and ProSelf-host it