NFS and Unix RPC Enumeration

← Stage index · Cheatsheet | Strategy map | Study methods: Extract opportunities from services

Recognize: rpcbind commonly appears on TCP/UDP 111 and NFS on TCP/UDP 2049, with additional dynamically assigned RPC ports. Goal: find exports, allowed client ranges and effective UID/GID-based permissions.

Baseline: list RPC services and exports

rpcinfo -p TARGET
showmount -e TARGET

Decisive output: rpcinfo maps RPC programs to versions/transports/ports. showmount -e returns exports and apparent allowed clients, but NFSv4-only servers may not expose the mount service and showmount completeness varies by implementation.

Variant — Nmap without mounting

nmap -sV -p 111,2049 --script nfs-showmount,nfs-ls,nfs-statfs TARGET

The scripts can list exports, file attributes and access flags. Confirm access manually when a finding matters.

Variant — mount read-only first

sudo mkdir -p /mnt/nfs-audit
sudo mount -t nfs -o ro,vers=3,nolock TARGET:/EXPORT /mnt/nfs-audit
find /mnt/nfs-audit -maxdepth 3 -ls
sudo umount /mnt/nfs-audit

If version 3 fails and version 4 is advertised, retry with -o ro,vers=4. NFSv4 may present a pseudo-filesystem whose export path differs from showmount output.

Variant — inspect numeric ownership

ls -lan /mnt/nfs-audit
find /mnt/nfs-audit -maxdepth 3 -type f -readable -ls

NFS commonly authorizes Unix identities by numeric UID/GID. A matching local username is irrelevant if its number differs. root_squash usually maps remote UID 0 to an unprivileged identity; no_root_squash is dangerous but still requires a useful writable object and privileged consumption path.

Variant — bounded write verification

sudo mount -t nfs -o rw,vers=3,nolock TARGET:/EXPORT /mnt/nfs-audit
touch /mnt/nfs-audit/probe-file
ls -ln /mnt/nfs-audit/probe-file
rm /mnt/nfs-audit/probe-file
sudo umount /mnt/nfs-audit

Use a unique harmless name only when write validation is needed and authorized. Record the resulting numeric owner/group. Success proves write in that directory, not execution or privileged ownership.

Failure cues: showmount failure does not rule out NFSv4. access denied by server can mean export client restrictions or wrong path/version. permission denied after mounting is file authorization, not network failure. Do not change local UIDs or write to an export during concept study.

Next action: inspect readable backups, home data, keys and configuration; record numeric ownership and actual write boundaries; send a writable/privileged-consumer hypothesis to the escalation block.

Rsync daemon — list modules before copying

Recognize: an rsync daemon normally listens on TCP/873, although the application can use another port. The daemon namespace uses HOST::MODULE or rsync://HOST/MODULE; a single colon is SSH/remote-shell syntax and is a different access path.

nmap -sV -p 873 --script rsync-list-modules TARGET
rsync rsync://TARGET/
rsync --list-only rsync://TARGET/MODULE/

Decisive output: a named module and a file listing establish only that the current anonymous or supplied account can enumerate that namespace. Read access is proven by retrieving selected bytes, not by the module name.

Variant — retrieve a selected file or a reviewed module

# One selected artifact
rsync -av rsync://TARGET/MODULE/path/FILE ./FILE

# A reviewed module into a dedicated local evidence directory
mkdir -p ./rsync-MODULE
rsync -av --safe-links rsync://TARGET/MODULE/ ./rsync-MODULE/

--safe-links ignores symbolic links that point outside the copied tree. Review module size and content first; do not mirror a large tree by default. If authentication is required, let rsync prompt or use a protected --password-file rather than putting a password on the command line.

Failure cues: no listed modules can mean the daemon hides its module list; @ERROR: auth failed is an authentication boundary; @ERROR: Unknown module is a namespace error; a listed module can still deny individual reads or writes.

Next action: inspect selected readable backups, keys, source and configuration locally. Treat a writable module as file placement only until a specific consumer, destination identity and trigger are proven. Do not use --delete against a remote module during enumeration.

TFTP — known-name retrieval only

Recognize: TFTP normally uses UDP/69 for the initial request and has no directory-listing or login model. It is useful only when configuration, source, boot metadata or another service gives a plausible filename.

tftp TARGET
tftp> binary
tftp> get FILE
tftp> quit

Decisive output: a completed transfer plus recognizable local bytes establishes read access to that exact name. A timeout is ambiguous because the UDP request, server policy, transfer port or filename can fail without a useful error.

Variant — bounded write check only when the objective requires it

printf '%s\n' 'TFTP_WRITE_CANARY' > tftp-probe.txt

tftp TARGET
tftp> binary
tftp> put tftp-probe.txt
tftp> quit

Use a unique harmless filename and only when write capability changes the next decision. TFTP normally offers no remote delete operation; do not create a probe unless you already have an authorized cleanup route.

Next action: inspect a retrieved artifact and follow only evidence-backed filenames. A successful upload is not execution; prove the server-side path and consumer separately.

Sources

Rsync current manual, Nmap rsync-list-modules documentation, GNU Inetutils TFTP client manual, and the current OSCP+ exam guide, which permits Nmap and its scripting engine while prohibiting automatic exploitation, mass vulnerability scanning and spoofing.