# Telnet Credential Attacks

- **URL:** https://hackindex.io/services/telnet/exploitation/telnet-credential-attacks
- **Path:** Telnet > Exploitation
- **Up:** [Exploitation](https://hackindex.io/services/telnet/exploitation.md)
- **Published:** 2026-01-03
- **Updated:** 2026-03-11

Telnet sends credentials plaintext. Success grants shell access on legacy devices or servers. Watch for lockouts; start conservative.

Telnet has no encryption layer. Credentials travel the wire as ASCII text. Any network capture confirms what was sent. Legacy routers, switches, and IoT devices still run Telnet on port 23. Some embedded systems run it on non-standard ports. Check your scan results for those before assuming the standard port is the only target.

Before attacking, confirm the service actually requires credentials. Some Telnet banners drop directly to a shell. Others present a menu-driven interface instead of a UNIX prompt. Both indicate successful authentication. The banner itself often reveals the device vendor, model, and firmware version, which narrows your default credential list.

## Manual Authentication Testing

Connect and attempt login:

- Manual Authentication Testing
- Password Spraying with Hydra
- Controlled Brute Force with Hydra
- Nmap Brute Force Script

```bash
telnet $TARGET_IP 23
```

Prompts for login/password. Valid creds drop to shell or menu.

The login prompt typically says `login:` or `Username:`. The password field hides input on most implementations. If the system echoes the password back, that is a misconfiguration worth noting separately. A valid login often produces a hostname prompt like `router>` or a standard UNIX `$`. Some devices show a numbered menu instead of a shell. Either confirms access. Observe the exact wording of both the success and failure responses before running automated tools.

Single credential validation:

```bash
telnet $TARGET_IP 23
# login: $USERNAME
# password: $PASSWORD
```

Success shows shell prompt or banner change. Failure returns login prompt.

A failed login usually returns the same `login:` prompt after a short pause. Some implementations add a fixed delay after each failure to slow brute-forcing. Multiple failed attempts in quick succession may trigger a lockout or disconnect. Note the exact failure message. If the message changes depending on whether the username exists, use that difference for user enumeration before committing to a full brute force. Some systems also limit the number of concurrent Telnet sessions. If you connect and receive no prompt, another session may be holding the slot. Disconnect and reconnect after a delay.

## Password Spraying with Hydra

Low-and-slow to avoid detection:

```bash
hydra -L users.txt -p Password123 telnet://$TARGET_IP
```

Single common password across users. Success lines show "login: user password: Password123".

Spray before brute-forcing. A single password across a full user list generates fewer per-account attempts. This avoids per-account lockout thresholds on systems that track failures per user. If the target enforces a global lockout instead, even a spray will trigger it. Start with one attempt per user, then stop and assess.

Common default passwords for network devices include `admin`, `password`, `cisco`, and `enable`. Check vendor documentation for the specific device type visible in the banner. Default credentials appear more often than weak custom passwords on embedded systems and unmanaged hardware.

## Controlled Brute Force with Hydra

Higher risk; use small lists:

```bash
hydra -L users.txt -P passwords.txt telnet://$TARGET_IP -t 4
```

Parallel tasks limited to avoid lockout. Valid hits appear immediately.

Keep `-t 4` or lower for Telnet. The protocol does not handle high connection rates well. Too many parallel connections cause the service to hang or drop connections silently. Hydra prints valid credentials in green with `host` on the left side of the output line. Validate each hit manually before assuming access. False positives occur when the service returns unexpected responses that Hydra misreads as success.

Username enumeration via invalid password:

```bash
hydra -L users.txt -p invalid telnet://$TARGET_IP -t 1
```

Different failure messages or delays indicate valid users.

Watch for two signals. Timing: valid usernames often cause a longer pause before the failure response. Message content: some implementations respond with "Login incorrect" for a wrong password and "Login failed" for an unknown user. These differences are subtle. If Hydra output is ambiguous, capture a raw Telnet session with Wireshark and compare the server responses byte-for-byte. Timing differences are easier to spot in a packet capture than in terminal output.

Rate limiting test:

```bash
hydra -l testuser -P small.txt telnet://$TARGET_IP -t 1 -W 5
```

Wait time reveals lockout thresholds.

If the service disconnects after three failures, your window per connection is three attempts. Structure attacks around that limit. Set `-t 1` and increase `-W` between sessions to allow any temporary lockout to reset. On devices with no lockout at all, speed is constrained only by network latency and the service's connection handling capacity. Map the threshold before scaling up.

## Nmap Brute Force Script

Built-in library:

```bash
nmap -p 23 --script telnet-brute --script-args userdb=users.txt,passdb=passwords.txt $TARGET_IP
```

Reports valid combos. Slower but integrated with scanning.

The `telnet-brute` script outputs valid credentials in the Nmap host report under port 23. It also captures the login banner, which can reveal device type and firmware version. Use this approach when you want scan and credential data in a single output file. For targeted attacks against large wordlists, Hydra is significantly faster. The Nmap script is most useful for quick checks against multiple hosts in one pass, where you are already running a broader scan.

Credential reuse check:

```bash
hydra -l $USERNAME -p $PASSWORD telnet://$TARGET_IP
```

Quick validation after success elsewhere. Shell access enables pivoting or config dumps.

After getting a shell, run `whoami` or `id` to confirm the identity. On network devices, run `show running-config` or the vendor equivalent to dump the full configuration. Credentials stored in configs often work on other devices in the same environment. Telnet sessions are unencrypted, so any credential you send is visible on the wire. Avoid re-entering known passwords from a monitored segment.

If authentication succeeds but the shell is restricted, look for escape options. Pressing Ctrl+] drops to a Telnet client escape prompt where you can issue local commands. Some network devices expose a debug shell through undocumented vendor commands. If the login lands in a menu interface, check for a hidden shell option or an admin escape sequence documented in vendor advisories.

Telnet may fail to authenticate if the target requires specific option negotiation your client does not support. Try connecting with `nc` directly and observe the raw byte exchange to determine what the server expects before the login prompt appears.

## References

- [THC Hydra](https://github.com/vanhauser-thc/thc-hydra) - Network login cracker supporting telnet and 50+ protocols
- [Nmap: telnet-brute](https://nmap.org/nsedoc/scripts/telnet-brute.html) - Nmap NSE script for telnet credential brute forcing