Understand why Telnet is a critical security risk, how network sniffing captures unencrypted traffic, and what replacing legacy protocols with SSH achieves.
Telnet and Network Sniffing
Telnet is a network protocol developed in 1969 for remote terminal access. It transmits all data — including usernames, passwords, and commands — in plain cleartext with no encryption. Anyone on the same network segment who can capture packets can read everything typed in a Telnet session.
Network sniffing (packet capture) involves capturing network traffic to analyse its contents. While it has legitimate uses for network troubleshooting, it is also used by attackers on compromised network segments to harvest credentials from insecure protocols like Telnet, FTP, and plain HTTP.
The History of Telnet — Design by a Different Era
To understand why Telnet is so fundamentally insecure, it's essential to understand the context in which it was built. Telnet was defined in RFC 15 in 1969 and later refined in RFC 854 (1983), which remains the canonical standard. It was designed for ARPANET — a small, closed research network connecting a handful of universities and government research labs. The participants were trusted colleagues. The threat model did not include adversaries on the wire.
The original designers made a deliberate choice: simplicity and interoperability were paramount. Telnet's NVT (Network Virtual Terminal) model abstracted differences between diverse host systems by defining a common 7-bit ASCII-based terminal format. It provided basic negotiation through option codes (WILL, WONT, DO, DONT) so that clients and servers could agree on terminal width, character echo, binary mode, and other parameters. This was genuinely clever engineering for 1969 — but none of it had anything to do with authentication or confidentiality.
Throughout the 1970s and 1980s, Telnet became the de facto standard for remote administration of Unix systems, routers, switches, and printers. Network engineers configured Cisco IOS devices over Telnet. System administrators managed servers across campuses the same way. For two decades, this was acceptable because the networks were relatively small and physically controlled. The Internet's explosive growth in the 1990s changed the threat landscape entirely — but Telnet was already deeply embedded in infrastructure by then.
The critical insight here is that Telnet was not broken — it was never designed to be secure. Blaming Telnet for being insecure is like blaming a screen door for not stopping bullets. The failure is organisational: continuing to deploy a protocol whose threat model expired decades ago.
Telnet's Legitimate Use Cases
Despite its security problems, Telnet served real and important purposes throughout computing history and continues to have niche uses today:
- Remote terminal administration — Before SSH, Telnet was the primary way to administer Unix servers, mainframes, routers, and switches from a remote location. It eliminated the need to physically visit machines in different buildings or cities.
- Network device configuration — Cisco, Juniper, HP, and virtually every other network equipment vendor shipped devices with Telnet enabled as the management interface throughout the 1980s and 1990s. Entire enterprise network backbones were configured this way.
- Protocol testing and debugging — Because Telnet is a raw TCP connection to a port with a text interface, network engineers use it today to manually probe other plaintext protocols.
telnet mail.example.com 25connects directly to an SMTP server;telnet web.example.com 80lets you craft raw HTTP requests by hand. This is still a valid diagnostic technique. - BBS (Bulletin Board Systems) — Before the web, Telnet BBSs were online communities. Thousands still operate today as hobby systems, accessible at
telnet://URIs, hosting door games and retro communities. - Industrial control systems (ICS/SCADA) — Many PLCs (Programmable Logic Controllers) and HMIs (Human-Machine Interfaces) deployed in factories, water treatment plants, and power grids in the 1990s and 2000s exposed Telnet interfaces for configuration. Many are still running.
- Embedded systems and IoT devices — Cheap embedded hardware from the 2000s through today often ships with Telnet enabled, either as a management backdoor or because the developer lacked the resources to implement SSH. This remains a pervasive problem.
How Sniffing Captures Credentials
On a shared network segment (or via ARP spoofing on switched networks), a network interface in promiscuous mode captures all packets regardless of destination. Tools like Wireshark or tcpdump decode these packets and display their contents — including Telnet credentials in cleartext.
# What the attacker sees in a packet capture: Source: 192.168.1.50 → Dest: 192.168.1.1 TCP 23 Data: "admin " <-- username in cleartext Data: "P@ssword123 " <-- password in cleartext Data: "show running-config "
The Packet-Level Reality
Understanding why Telnet is so easy to sniff requires understanding how it behaves at the TCP/IP layer. When a user types a character in a Telnet session, most implementations send that character immediately as a single-byte TCP segment (in line mode, entire lines are buffered — but the effect is the same). Each keystroke travels in its own IP packet with no obfuscation whatsoever.
This per-character transmission has a secondary consequence: even without credentials, a passive observer can watch the timing and length of keystrokes to infer what commands are being typed, a technique called traffic analysis. SSH, by contrast, pads packets and uses encrypted tunnels that defeat this analysis.
# Each line below is a SEPARATE TCP packet — one character each IP 10.0.0.5.54821 > 10.0.0.1.23: P, length 1 s IP 10.0.0.5.54821 > 10.0.0.1.23: P, length 1 e IP 10.0.0.5.54821 > 10.0.0.1.23: P, length 1 c # Reassemble: "sec..." — the attacker reconstructs the stream trivially
Wireshark and other tools automate stream reassembly entirely. A single menu click — Follow → TCP Stream — reconstructs the entire session, credentials and all, into a human-readable transcript. There is no decryption step, no key material needed, no computational effort beyond capturing the packets.
Vulnerabilities in Detail
Telnet's vulnerabilities fall into several distinct categories. Each represents a different attack vector and a different class of risk. Understanding them separately is important because they have different mitigations — and different implications for risk prioritisation during a security assessment.
The most obvious vulnerability: everything is transmitted in plaintext. This includes not just the login credentials but every command typed, every command output returned, every file listed or displayed, every configuration viewed. An attacker who captures a single administrative Telnet session may walk away with:
- ›Root or administrative credentials for the device
- ›The complete network topology from
show running-configoutput - ›Other credentials entered during the session (database passwords, API keys)
- ›Internal hostnames, IP addressing schemes, VLAN configurations
- ›File contents if the admin ran
cat,more, or similar commands
Telnet provides no message integrity checking. An attacker performing an active MITM attack (via ARP spoofing, for example) can not only read traffic but inject arbitrary commands into the stream. Because the protocol has no way to detect tampering, the server will execute injected commands as if they came from the legitimate user.
A practical attack scenario: an attacker is performing ARP spoofing between an admin workstation and a router. The admin logs in and issues routine commands. The attacker waits, then injects a command to create a new backdoor user account or disable an ACL before the admin's session ends. The admin sees nothing unusual.
# Conceptual injection during active MITM # Legitimate admin traffic flowing through attacker's machine Admin → Router: "show version\n" ← pass through Attacker injects: "username backdoor secret P@ss\n" Admin → Router: "show ip interface brief\n" ← pass through # Router creates backdoor account silently
Telnet has no mechanism to verify that the server you're connecting to is actually the device you intend to reach. An attacker who can intercept or redirect your connection (through ARP poisoning, BGP hijacking, rogue DHCP, or simply plugging in a laptop) can present a fake Telnet login prompt. The user, seeing the familiar login: prompt, types their credentials — which the attacker now possesses. The attacker can simultaneously relay the connection to the real server so the user sees a normal session.
SSH solves this with host key fingerprinting: the first time you connect, you store the server's public key, and every subsequent connection verifies it matches. Telnet has no equivalent. There is no way to know if the device you're talking to is authentic.
Because Telnet sessions are cleartext and contain no session-specific tokens or timestamps, a recorded session can potentially be replayed. More practically, captured credentials can be directly reused — there is no challenge-response mechanism, no one-time tokens, no cryptographic proof that the credentials are being used by the original legitimate user at this moment in time.
This is qualitatively different from protocols that use token-based or cryptographic authentication: even if you capture the exchange, you cannot reuse it. With Telnet, you capture the plaintext credentials and simply log in yourself.
Sniffing in Practice
tcpdump captures packets matching a filter. Port 23 is Telnet. The -A flag prints packet contents in ASCII, making credentials immediately readable. The -w flag saves to a file for later analysis in Wireshark.
# Live capture on eth0, port 23, ASCII output tcpdump -i eth0 port 23 -A IP 192.168.1.50.54321 > 192.168.1.1.23: Flags [P.] [email protected]......... admin IP 192.168.1.50.54321 > 192.168.1.1.23: Flags [P.] P@ssword123 # Save capture to file for Wireshark analysis tcpdump -i eth0 port 23 -w telnet_capture.pcap # Read saved capture tcpdump -r telnet_capture.pcap -A
In Wireshark, filter for Telnet traffic and follow the TCP stream to read the full session. The "Follow TCP Stream" function is the key tool — it reassembles the bidirectional session into a readable transcript, clearly distinguishing client-sent data (typically blue) from server-sent data (typically red).
# Wireshark display filter — show only Telnet telnet # Alternative: filter by port directly tcp.port == 23 # Right-click any Telnet packet → Follow → TCP Stream Ubuntu 22.04 LTS router1 ttyS0 login: admin Password: CiscoAdmin2024! router1#show ip route Codes: C - connected, S - static, R - RIP ... 10.0.0.0/8 is variably subnetted C 10.10.1.0/24 is directly connected, GigabitEthernet0/1 # Full network topology now visible to attacker
On modern switched networks, traffic is only forwarded to the intended port. ARP spoofing (also called ARP cache poisoning) exploits the stateless, unauthenticated nature of ARP to poison the ARP caches of both the victim and the gateway, routing traffic through the attacker's machine. This is a prerequisite for sniffing Telnet on most modern networks.
# Enable IP forwarding so we relay traffic (victim stays connected) echo 1 > /proc/sys/net/ipv4/ip_forward # Poison victim's ARP cache: tell .50 that the gateway (.1) is us arpspoof -i eth0 -t 192.168.1.50 192.168.1.1 # Poison gateway's ARP cache: tell .1 that .50's MAC is ours arpspoof -i eth0 -t 192.168.1.1 192.168.1.50 # Now all traffic between .50 and .1 passes through us # Capture Telnet session simultaneously tcpdump -i eth0 host 192.168.1.50 and port 23 -A
Tools like ettercap and bettercap combine ARP spoofing and credential harvesting into a single automated workflow, significantly lowering the skill threshold for this attack.
SSH provides functionally identical remote access to Telnet but wraps everything in an encrypted tunnel. The contrast between what a sniffer sees for each protocol illustrates why encryption is non-negotiable.
# TELNET — everything in cleartext, immediately readable login: admin | Password: SuperSecret99! ← readable on wire router1# show running-config ← all commands visible # SSH — same session, encrypted SSH-2.0-OpenSSH_9.0 ← version banner only Encrypted payload: \xd3\x8f\x2a\x11... ← unreadable ciphertext # Disabling Telnet and enabling SSH on a Cisco device: Router(config)# no service telnet Router(config)# line vty 0 4 Router(config-line)# transport input ssh Router(config-line)# login local Router(config)# ip ssh version 2 Router(config)# crypto key generate rsa modulus 2048
Before sniffing, a penetration tester or attacker first identifies which hosts on the network are running Telnet. Nmap is the standard tool for this. Finding port 23 open is itself a finding — the sniffing attack is what turns that finding into credential compromise.
# Scan entire subnet for Telnet (port 23) nmap -p 23 --open 192.168.1.0/24 PORT STATE SERVICE 23/tcp open telnet MAC Address: 00:1A:2B:3C:4D:5E (Cisco Systems) # Service version detection — identify device type nmap -p 23 -sV 192.168.1.1 23/tcp open telnet Cisco router telnetd # Banner grab — read the login prompt manually nc 192.168.1.1 23 Authorised users only. This system is monitored. User Access Verification Username:
Infrastructure Risk Scenarios
The abstract vulnerability becomes concrete when mapped to real network environments. The following scenarios represent the types of situations encountered during penetration tests and incident response investigations. Each illustrates a distinct risk profile.
Consider a mid-size enterprise that upgraded its core routing infrastructure to modern hardware but retained older distribution-layer switches purchased in 2008. These switches have SSH disabled (the SSH module was never licensed or configured) and are managed exclusively via Telnet. The network team connects to them regularly from a Windows admin workstation on the same VLAN.
An attacker who compromises any single host on that management VLAN — perhaps through a phishing email that executes malware — can run ARP spoofing silently in the background. Every subsequent Telnet session from the admin workstation to any of those switches passes through the attacker's machine. Within days, the attacker has credentials to the entire distribution layer, the VLANs those switches serve, and potentially the routing tables of the entire campus network.
A water treatment facility uses PLCs (Programmable Logic Controllers) installed in 2004 that expose a Telnet management interface. These devices run a proprietary embedded OS that cannot be updated or patched; the vendor went out of business. The SCADA network was originally air-gapped but a "temporary" connection to the corporate network was made in 2015 for remote monitoring and was never removed.
The Telnet credentials for the PLCs were never changed from factory defaults (a common finding: admin/admin or root/root). Any employee on the corporate network — or any attacker who reaches the corporate network — can reach the SCADA network. There is no encryption, no authentication hardening, and no monitoring of Telnet sessions.
This scenario closely mirrors the 2021 Oldsmar water treatment facility incident, where an attacker accessed SCADA systems remotely and attempted to increase sodium hydroxide levels to dangerous concentrations. While that specific incident involved TeamViewer rather than Telnet, the underlying principle — legacy industrial systems with no meaningful authentication or encryption on the management plane — is identical.
A hotel's network team manages its property management system (PMS) and building automation systems over a flat internal network. Several legacy door-lock controllers and the building HVAC management interface expose Telnet. A disgruntled IT contractor who retains network access after their engagement ends connects remotely via VPN and runs a passive capture during business hours.
Because the network is flat (no VLAN segmentation between management and guest networks), the contractor can also observe cleartext traffic from guests who connect to the internal corporate wireless network that shares the same broadcast domain. FTP transfers of financial documents, plain-HTTP internal applications, and Telnet admin sessions are all visible simultaneously.
This scenario highlights a compounding risk: Telnet is not just dangerous in isolation. It is catastrophic when combined with poor network segmentation, which is a ubiquitous finding in assessments of hospitality, retail, and small-to-mid enterprise environments.
A warehouse deploys 200 network-enabled label printers, barcode scanners, and environmental sensors from a single vendor. The devices ship with Telnet enabled on port 23 and a hardcoded default password admin/1234. The IT team deploys them without reviewing their management interfaces, because "they're just printers."
The 2016 Mirai botnet demonstrated exactly this attack at scale: it scanned the public internet for devices with default Telnet credentials, compromised them automatically, and assembled them into a botnet responsible for the largest DDoS attack in history at the time (1.2 Tbps against Dyn DNS). Mirai's source code, released publicly, hard-coded 62 default username/password pairs specifically targeting Telnet-enabled IoT devices.
# Mirai-style credential scanning (conceptual — do not replicate) # Mirai tried combinations like these against port 23: admin:admin | root:root | admin:1234 | root:vizxv admin: | admin:password | root:12345 | guest:guest ubnt:ubnt | support:support | user:user # Any match = compromised node added to botnet
The lesson is that Telnet risk is not limited to traditional IT environments. Any device category — printer, camera, sensor, HVAC controller — that exposes Telnet with default credentials is an entry point.
What Telnet Means for Network Security Posture
When a security assessor finds Telnet enabled in a production environment, it is not just a single finding — it is an indicator of broader security culture and hygiene problems. The presence of Telnet in 2025 typically implies one or more of the following systemic issues:
- No protocol security standards or hardening baselines — Organisations with mature security programs have documented standards (CIS Benchmarks, DISA STIGs, NIST SP 800-53) that explicitly prohibit cleartext management protocols. Finding Telnet suggests these standards either don't exist or aren't enforced.
- No network segmentation of management traffic — Management interfaces (OOB management VLANs, jump hosts, bastion hosts) isolate administrative access from user traffic. Telnet on a device accessible from the production LAN indicates this architecture is absent.
- Inadequate change management or asset inventory — If an organisation doesn't know which devices are running Telnet, it doesn't have a complete asset inventory. This in turn means they don't know their attack surface.
- Vendor or procurement security gaps — Devices that ship with Telnet enabled and defaults unchanged indicate the procurement process doesn't include security validation of new equipment before deployment.
- Likely presence of other cleartext protocols — Telnet is rarely found alone. Environments that use Telnet often also use FTP (port 21), SNMP v1/v2c (UDP 161), HTTP for management interfaces, and plain POP3/IMAP for email. Each represents the same class of risk.
Credential Re-Use and Lateral Movement
One of the most consequential downstream effects of Telnet credential theft is not the device itself being compromised — it's what happens next. In most organisations, administrators reuse passwords across multiple devices, or use a common administrative password standard. Stealing credentials from one router or switch via Telnet often yields access to dozens or hundreds of other devices.
Furthermore, if the administrator uses the same password for their Windows domain account as for network device administration (a common and explicitly prohibited practice that is nonetheless widespread), credential theft from a Telnet session becomes domain compromise. The attacker moves from capturing packets to owning Active Directory — from a network foothold to full enterprise compromise.
# Step 1: Capture Telnet credentials from legacy switch Captured: admin / NetAdmin2023! # Step 2: Try the same credentials on other management interfaces ssh [email protected] SUCCESS ssh [email protected] SUCCESS ssh [email protected] SUCCESS # Step 3: Try against Windows domain controller crackmapexec smb 10.0.0.5 -u admin -p 'NetAdmin2023!' SMB 10.0.0.5 [+] DOMAIN\admin:NetAdmin2023! (Pwn3d!) # Domain Admin access achieved from one Telnet session
Mitigation and Remediation Strategies
Addressing Telnet risk requires a layered approach. The ideal solution is elimination, but where that is not immediately possible, compensating controls reduce exposure. The following strategies are listed in order of effectiveness.
The only complete remediation is to disable Telnet and enable SSH. SSH v2 with strong ciphers (AES-256, ECDH key exchange, SHA-2 MAC) provides encryption, integrity, and server authentication. SSH key-based authentication eliminates the password entirely, removing credential theft as an attack vector.
# Linux — disable telnetd, enable sshd sudo systemctl stop telnet.socket sudo systemctl disable telnet.socket sudo systemctl enable ssh --now # Cisco IOS — force SSH only on VTY lines Router(config)# line vty 0 15 Router(config-line)# transport input ssh Router(config-line)# exec-timeout 5 0 Router(config)# no service telnet Router(config)# ip ssh version 2 Router(config)# ip ssh time-out 60 Router(config)# ip ssh authentication-retries 3 # Verify Telnet is no longer reachable nmap -p 23 192.168.1.1 23/tcp closed telnet
Where devices cannot be migrated from Telnet (end-of-life hardware, ICS/OT systems, devices with no SSH support), the risk must be managed through network controls. Isolate the device on a dedicated management VLAN accessible only from a jump host or bastion server. Apply strict ACLs that permit Telnet only from specific source IPs.
# Cisco ACL — permit Telnet only from jump host (10.0.0.254) Router(config)# ip access-list extended MGMT-TELNET Router(config-ext-nacl)# permit tcp host 10.0.0.254 any eq 23 Router(config-ext-nacl)# deny tcp any any eq 23 log Router(config-ext-nacl)# permit ip any any Router(config)# interface GigabitEthernet0/0 Router(config-if)# ip access-group MGMT-TELNET in # The jump host itself must use SSH or MFA to connect # This doesn't encrypt Telnet — it limits who can attempt it
This is a compensating control, not a fix. Telnet traffic from the jump host to the device is still cleartext. The jump host becomes a high-value target. Document this as a residual risk and schedule hardware replacement.
In environments where Telnet cannot be immediately eliminated, configure network monitoring and SIEM alerting to detect any Telnet sessions. If Telnet must exist, every session should be a known, expected event — an unexpected Telnet connection is an immediate incident.
# Snort/Suricata rule — alert on any Telnet connection attempt alert tcp any any -> any 23 (msg:"TELNET connection attempt"; flow:to_server,established; sid:1000001; rev:1;) # Splunk SPL — detect Telnet in network flow data index=network dest_port=23 | stats count by src_ip, dest_ip, dest_port | where count > 0 # Zeek (Bro) — log all Telnet sessions automatically # Zeek logs to telnet.log with src, dst, user, password fields
What You Need to Know
You've covered the theory. Now apply it hands-on in the simulated environment.
Start Lab — Telnet Sniffing →← Return to all labs