Finding Cleartext Transfers on Your Network

Somewhere on almost every network, a file transfer is still happening in the clear. A scanner that has uploaded to the same FTP folder for a decade. A backup script nobody has opened since the person who wrote it left. A vendor appliance whose web interface quietly speaks plain HTTP. These are not exotic — they are the sediment of years of "we'll fix it later," and the reason they survive is simple: cleartext transfers work perfectly. They move the file every time. Nothing breaks, no error appears, and the password crosses the wire in plain sight on every single run.

This article is a practical method for finding those transfers on systems you administer, confirming which ones are genuinely exposed, and fixing them in a sensible order. It has two halves: an inventory pass that finds candidates from records you already have, and a spot-check pass that proves exposure by watching your own test traffic. That second half includes reading a packet capture of a test login — your own throwaway credentials, on your own test server — because seeing your password sitting in plaintext in a capture is the demonstration that turns "we should probably fix that" into "we are fixing that this week."

This is part of our Encryption in Transit series. It is the hands-on companion to what encryption in transit doesn't protect: before you can layer protections on a flow, you need to know the base layer — encryption at all — is actually present.

What "Cleartext" Actually Means Here

Cleartext (or plaintext) means the data crosses the network with no encryption, readable by anything positioned to observe it. The observers are not hypothetical: any device on the same network segment, a compromised switch or router along the path, a machine performing ARP spoofing on the local network, or anyone who has quietly enabled port mirroring. What they can read depends on the protocol, and the worst offenders are the defaults of an earlier internet:

• Plain FTP — the login and every command travel in cleartext, so USER and PASS are right there; file contents and listings are exposed too.
• Plain HTTP for uploads, downloads, or admin panels — form fields, session cookies, and file bodies all readable.
• Telnet and other legacy remote-access protocols — every keystroke, passwords included.
• TFTP — no authentication and no encryption at all; often carrying device configurations and firmware (its right and wrong uses are covered in TFTP security and containment).
• SMB and NFS in older/unencrypted configurations — file contents crossing the wire in the clear.
• The half-encrypted trap: FTPS configured to protect the login but not the data channel, which encrypts PASS and then ships the file itself in cleartext. It looks secure in a connection dialog and is not — the mechanics are in how TLS wraps FTP.

The single most valuable thing cleartext leaks is credentials. A file exposed once is one file; a password exposed once is every file that account can ever reach, plus anywhere else that password gets reused. That is why credential exposure sets the priority order later in this article.

Part One: The Inventory Pass

Start with records, not packets — you can find most cleartext from information you already hold, without touching the network. You are building one list: every place files move, and whether each is encrypted. Draw from five sources.

1. The port and service view

Cleartext protocols announce themselves by the ports they listen on. Inventory what is actually listening across your servers — from your configuration management records, your asset inventory, or by checking each host — and flag the usual cleartext ports: 21 (FTP control), 23 (Telnet), 69 (TFTP), 80 (HTTP) where it is carrying transfers or admin access. Seeing port 21 open is not proof of cleartext — the server might enforce FTPS on it — but it is exactly the candidate list you want. Pair this with the firewall view of your protocols, which our firewall view of the transfer protocols article maps out.

2. Server and service configs

For each transfer service you run, read its configuration for the tell-tale settings: is a plain-FTP listener enabled alongside FTPS? Is TLS "optional" rather than "required," which means clients may silently choose cleartext? For FTPS specifically, is the data channel protection enforced, or left to the client? A server that permits cleartext is a cleartext exposure waiting for one misconfigured client.

3. Scripts, scheduled jobs, and automation

This is where the richest findings hide, because automation is written once and runs untouched for years. Search your scripts, scheduled tasks, and job definitions for the fingerprints of plaintext protocols: ftp:// and http:// URLs, command-line ftp and tftp invocations, connection strings that name plain protocols. Inherited automation is the classic case — a job you did not write, doing something important, in the clear. Our inherited FTP automation article is entirely about untangling these safely.

4. Client and partner configurations

Look at the connection profiles in your transfer clients and the agreements with partners. A partner relationship documented as "FTP to their server" is a cleartext flow crossing organizational boundaries — often the highest-stakes kind, because it leaves your control. Note each one for the remediation conversation.

5. The logs

Your existing transfer and firewall logs record which protocols and ports are genuinely in use, cutting the theoretical candidate list down to what is actually running. A plain-FTP listener with no successful logins in living memory is a quick, safe win to switch off; one with nightly traffic is a real flow that needs a migration plan, not a light switch. Reading these logs well is a skill in itself — see transfer logging and audit.

The output of Part One is a table: each flow, its protocol, whether it is encrypted, whether credentials are involved, and whether it crosses a network boundary. That table is your work queue. But an inventory only tells you what should be happening. To know what is actually on the wire, you spot-check.

Part Two: The Packet-Capture Spot Check

A packet capture records the raw traffic on a network interface so you can inspect exactly what crossed it. Used as a self-audit tool, it settles arguments: instead of "we believe that flow is encrypted," you get to see, byte for byte, whether it is. The goal here is narrow and defensive — capture one test login to a server you administer, using a throwaway account, and look at whether the credentials are readable.

Set up a safe test

Do this deliberately and small:

1. Use a test account. Create a throwaway user on the server you are checking — something like audituser with a unique, disposable password that exists nowhere else and protects nothing. You are going to watch this password cross the wire; it must be worthless. Never use a real or reused credential for this.
2. Capture only your own test traffic. Run the capture on a host you control, filtered tightly to the test server's address and the port in question, for the few seconds the test login takes. You are recording your own deliberate connection, nothing else.
3. Make one login, then stop. Connect with the test account, do a trivial action such as listing a directory, disconnect, and stop the capture immediately. A short capture is easier to read and keeps the exercise contained.
4. Read, then delete. Inspect the capture, record the finding, and delete the capture file — it briefly contains a plaintext password even if a worthless one, and there is no reason to keep it.

What a cleartext login looks like

Following the raw bytes of the test connection to a plain-FTP server, the exposure is not subtle. The credentials appear as literal, human-readable text in the stream:

220 Test FTP server ready
USER audituser
331 Password required for audituser
PASS Disposable-Test-Pw-9471
230 Login successful
SYST
215 UNIX Type: L8
LIST
150 Opening ASCII mode data connection for file list

There is the whole problem in one screen. audituser and Disposable-Test-Pw-9471 are sitting in the capture exactly as typed, because plain FTP never encrypts them. Anyone who could observe that segment during a real login would read a real password with zero effort — no cracking, no cleverness, just reading. If the session had continued into a file transfer, the file's contents would scroll past in the same readable form. This is the demonstration worth doing once in your career: it converts an abstract "cleartext is bad" into the visceral fact of your own test password in plain view.

What an encrypted login looks like

Now the same test against an SFTP or FTPS endpoint. After the initial unencrypted setup lines, the readable content simply stops:

SSH-2.0-ServerId        <-- version banners are visible (this is normal)
SSH-2.0-ClientId
(key exchange bytes)
....p·§µ·ªK···é··«·q··· ···5·········   <-- everything past here is ciphertext
·····ª·········q·····X·············
No USER, no PASS, no file names appear anywhere in the stream.

You see the protocol version banners and the key-exchange setup — those are unencrypted by design and harmless — and then the stream turns to noise. No username, no password, no filenames, no file contents are recoverable. That contrast, seen in your own two captures side by side, is the entire case for encryption in transit made concrete. It is also how you catch the half-encrypted FTPS trap: if the login is noise but the file contents on the data connection come through readable, you have found a PROT C configuration masquerading as secure.

Putting Numbers to It: The Remediation Order

A discovery pass usually turns up more cleartext than you can fix at once, so fix in an order that reduces the most risk first. Rank each finding on two axes — does it expose credentials, and does it cross a network boundary — and work top-down.

Priority 4 deserves an honest note: not every cleartext flow must be encrypted immediately, and pretending otherwise burns credibility. Some legacy devices speak only plain protocols, and some data — public firmware on an isolated boot VLAN — is genuinely not sensitive. The mature move is a documented, contained exception: isolate the flow on a segment where the cleartext cannot be observed by anything that matters, write down why, and set a date to revisit. When plain FTP is defensible and when it is not is argued fully in when plain FTP is acceptable.

Fixing What You Find

Remediation falls into a few repeatable shapes, roughly easiest to hardest:

• Flip a setting. Where a server already supports encryption, require it and disable the plaintext listener. This is the fastest win once you have confirmed nothing depends on the cleartext path — which your log review told you.
• Point a client at the secure endpoint. Often the server already offers FTPS or SFTP and only the client is configured for plain FTP. Reconfiguring the connection profile fixes the flow without touching the server. For FTPS, confirm the client requests data-channel protection so you do not trade full cleartext for the half-encrypted trap.
• Migrate the protocol. Where the plaintext service must be replaced — moving a partner flow from FTP to SFTP or FTPS — plan it as a change: stand up the encrypted endpoint, test with the partner, cut over, then retire the old listener. The full playbook is migrating from FTP to SFTP or FTPS, and retiring the plain service completely is our retiring plain FTP series.
• Contain the exception. For the genuine legacy holdouts, isolate and document as above rather than leaving them on a flat network.

On the server side, consolidating flows onto one endpoint that speaks encrypted protocols by default reduces how many places cleartext can reappear. A server such as Sysax Multi Server can present FTPS, SFTP, and HTTPS from a single service on Windows, so migrating a plain-FTP flow is often a matter of moving the client to the encrypted endpoint already running, then closing the plain listener behind it. For the scripted and scheduled flows the inventory turned up, updating each job's connection profile to a secure protocol — and, in an automation tool like Sysax FTP Automation, storing that profile once so every run inherits it — keeps the fix from quietly regressing the next time the job is copied.

Make It Repeatable

Cleartext creeps back. A new appliance ships with plain HTTP on. A contractor stands up a quick FTP drop "just for this project." An acquired team brings their own habits. A one-time sweep is worth doing; a repeatable one keeps the finding from becoming a recurring surprise. Fold cleartext discovery into work you already do: re-run the inventory pass on a schedule, add "no plaintext transfer protocols" to your build checklist for new servers, and make the packet-capture spot check a standard step when onboarding a new partner flow or commissioning a new transfer service. The discipline connects directly to hardening transfer servers and, at the far end of the journey, the work of retiring plain FTP for good.

The Version to Tell a Colleague

Finding cleartext is two passes. First, inventory from records you already have — listening ports, server and client configs, scripts and scheduled jobs, partner agreements, and logs — to build a list of every flow and whether it is encrypted. Second, spot-check the doubtful ones by capturing a single test login, with a throwaway account, on a server you administer: a plain-FTP capture shows your username and password sitting in readable text, an SFTP capture shows noise, and the contrast ends the debate. Then fix in risk order — credentials over untrusted networks first, contained legacy exceptions last — and bake the check into your routine so it does not silently come back. Always your own systems, your own test credentials; that boundary is not negotiable.

Next, harden what you kept: cipher policy without a cryptography degree makes sure the encrypted endpoints you standardized on are actually configured strongly, and man-in-the-middle attacks and trust failures covers the attack that cleartext makes trivial and encryption is supposed to stop.

Frequently Asked Questions