Port 512 – REXEC (Remote Execution)

Port 512 is the default port for rexec (Remote Execution), the daemon (rexecd) that runs a command you send on a remote Unix host after checking a username and password. That check is the whole problem: the credentials travel in cleartext, with no encryption at any layer, and the service exists specifically to run commands for whoever authenticates. So an open port 512 is both a sniffable login and a remote-command-execution service by design — worth chasing early on any host that still answers on it. (Note that TCP 512 is exec/rexec; the UDP 512 assignment is biff/comsat, the old mail-notification service — different thing, and not the focus here.)

rexec is one of the Berkeley r-services — the family of rexec (512), rlogin (513), and rsh (514) — that shipped with UNIX in the 1980s and were all replaced by SSH on port 22. Where rexec differs from its siblings is authentication: it always demands a real username and password, whereas rlogin and rsh lean on host-based .rhosts / hosts.equiv trust. That makes 512 the one you brute-force and sniff; the trust-abuse story belongs mostly to 513/514.

Why It’s Open

Before SSH, rexec was a standard way for scripts and admins to fire a command at another UNIX box. It still turns up on legacy Solaris, AIX, HP-UX, and older Linux systems, on appliances and industrial gear running ancient firmware, and in lab images like Metasploitable 2 that ship the r-services on by default. Where port 512 is still listening it usually means an inetd/xinetd entry nobody cleaned up, a forgotten management path, or a box that hasn’t been touched since it was racked. On anything modern you should see SSH instead.

Common Risks

• Cleartext credentials. The username and password are sent unencrypted on every connection — anyone on the path can sniff a full login with tcpdump or Wireshark and replay it.
• Remote command execution by design. rexec’s entire job is to run the command you supply. Valid credentials mean immediate code execution on the host; there’s no extra step to exploit.
• Brute-force friendly. rexecd has no lockout or rate limiting, so password guessing with hydra, medusa, or Metasploit runs unimpeded.
• Sibling trust abuse. rexec ships alongside rlogin (513) and rsh (514), whose .rhosts / hosts.equiv host-based trust can grant a shell with no password at all. Finding 512 open almost always means 513/514 are worth checking too.
• Legacy daemon bugs. Old vendor rexecd builds have their own flaws — see the AIX privilege bug below.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Detect the service and grab the banner

nmap -sV -p 512 <target>

Brute-force with the nmap NSE script

nmap -p 512 --script rexec-brute <target>

Brute-force with Hydra

hydra -L users.txt -P passwords.txt rexec://<target> -s 512 -t 4 -f

Brute-force with Medusa

medusa -h <target> -u root -P passwords.txt -M rexec

Metasploit login scanner

msfconsole -q
use auxiliary/scanner/rservices/rexec_login
set RHOSTS <target>
set USER_FILE users.txt
set PASS_FILE passwords.txt
set STOP_ON_SUCCESS true
run

Run a command with the native client

rexec -l <user> -p <password> <target> id

Log every open port 512 and every credential that works as you go, so the evidence lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

rexecd has a thin service-specific CVE history — its real weakness is design, not a single patchable bug. The cleartext credential exchange, lack of rate limiting, and run-any-command behaviour are the exposure, and they don’t have a fix short of turning the service off. Two entries are still worth citing:

• CVE-1999-0618 — “The rexec service is running.” The legacy scanner finding that flags rexec as present at all, precisely because a plaintext remote-execution daemon is a risk by its nature (CVSS v2 10.0).
• CVE-2004-2388 — rexecd on IBM AIX 4.3.3 doesn’t use a local copy of the pwd structure when calling getpwnam, so the authenticate function can overwrite it and assign privileges to the wrong user — a genuine server-side privilege bug (CVSS v2 10.0).

In practice the “exploit” is authentication itself: brute-force the password with auxiliary/scanner/rservices/rexec_login, hydra, or nmap --script rexec-brute, then run whatever you want. Don’t expect a dramatic memory-corruption CVE here — treat any open rexec as compromised-by-design.

Mitigation

• Disable rexec, rlogin, and rsh entirely. There is no modern reason to run the r-services. Remove or comment out the exec, login, and shell entries in /etc/inetd.conf (or the matching xinetd files) and restart the super-server.
• Migrate to SSH. Move remote command execution to SSH on port 22, which encrypts the whole session and supports key-based auth. ssh user@host command is the direct replacement for rexec.
• Block TCP 512–514 at the host and network firewall so nothing outside a trusted management range can reach the r-services.
• Hunt for trust files. Find and remove stray .rhosts and /etc/hosts.equiv files, which grant passwordless access to rlogin/rsh even after you think the family is locked down.
• Force credential rotation on any account that authenticated over rexec — assume the password was sniffed.

Real-World Example

The r-services are a fixture of the Metasploitable 2 training VM, which leaves rexec (512), rlogin (513), and rsh (514) open with weak defaults. The standard walkthrough is to point auxiliary/scanner/rservices/rexec_login (or hydra rexec://) at port 512, land on msfadmin:msfadmin, and confirm remote command execution — then notice that rlogin/rsh next door trust the attacking host outright via .rhosts, handing over a shell with no password at all. It’s a compact demonstration of why the whole family was retired: cleartext auth on one port, blind host trust on the others, and RCE either way.

FAQ

What is port 512 used for?

TCP port 512 is the default for rexec (Remote Execution), a Berkeley r-service that runs a command on a remote UNIX host after checking a cleartext username and password. It was a pre-SSH way to execute commands between machines and is now considered obsolete and insecure. (Separately, UDP 512 is assigned to biff/comsat, the old mail-notification service.)

Is port 512 dangerous?

Yes on any untrusted network. rexec sends credentials in cleartext so they can be read straight off the wire, has no brute-force protection, and exists to run commands — a valid login is immediate remote code execution. Treat an exposed port 512 as something to close, not to harden.

What service runs on port 512?

The rexec daemon, rexecd, one of the Berkeley r-services alongside rlogin (513) and rsh (514). All three were replaced by SSH on port 22.

How do I close port 512?

Disable the exec entry in inetd/xinetd, migrate remote execution to SSH, firewall TCP 512–514 to a management range, and remove any .rhosts / hosts.equiv files that keep the sibling services trusting other hosts. Rescan with nmap -p 512 <target> to confirm the port is closed.

TL;DR

• Service: rexec (rexecd) — remote command execution, a Berkeley r-service
• Default port: 512/TCP (UDP 512 is the unrelated biff/comsat)
• Biggest risk: cleartext credentials + remote-command-execution by design, with no brute-force protection
• Mitigation: disable rexec/rlogin/rsh, migrate to SSH, firewall 512–514, remove .rhosts / hosts.equiv