Inspect RPC/NFS exports and effective file identity

Copyrpcinfo -p TARGET
showmount -e TARGET

100003  3  tcp  NFS_PORT  nfs
Export list for TARGET:
/EXPORT CLIENT_SCOPE

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

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

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

Variant — mount read-only first

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

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

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.

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

--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.

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

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.