Inspect rsync modules and retrieve selected artifacts

Needs: Reachable rsync daemon and a module/path readable by the anonymous or supplied account

Shell commands

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

# 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/

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.

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.

Verify → Verify the module, authentication context, path and retrieved bytes; do not infer write or execution from a visible name.

If it fails → A hidden module list, authentication error and per-path denial are different boundaries. Do not mirror large trees or use remote delete during enumeration. More detail ↓

If → then

A secret-like value, key file, stored hash, challenge response or ticket → Classify the artifact and its identity context
Needs: Artifact provenance and format; possible local/domain/application identity and compatible protocol
A tool/artifact must reach a target that can make an HTTP request → Transfer over HTTP using Linux or Windows clients
Needs: Correct server bind and served directory; target-to-server route, available downloader and writable destination
An SSH service and a known password, private key or agent context → Use SSH passwords, keys and forwarding-capable access
Needs: Compatible authentication method, correct user, accepted key policy and the requested shell/subsystem permission

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Inspect rsync modules and retrieve selected artifacts

USE WHEN: An rsync daemon banner, TCP/873 listener or disclosed rsync module
STARTING ACCESS: A confirmed reachable application; anonymous context or one identified credential
RESULT: A verified module namespace and selected readable configuration, backup, key or source artifact

Recognize the clue

After application identification shows an rsync daemon, list visible modules and inspect one selected namespace before copying data.

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

SYNTHETIC EXAMPLE OUTPUT

Module: backups
Listing: app/config.yml

Means: A visible module and file listing identify an rsync namespace; they do not establish write or execution.

Confirm: Retrieve one selected file and verify its bytes; record anonymous or supplied-account context.

After validation: The selected artifact is readable and useful: inspect it locally and route any credential or path clue.
Ruled out in this context: The module lists but the file read is denied: reject read access for that path/context.
Still inconclusive: No module list may mean hidden modules rather than no rsync service; retain exact application evidence.

Troubleshooting: A hidden module list, authentication error and per-path denial are different boundaries. Do not mirror large trees or use remote delete during enumeration.

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.

Why it works

Rsync daemon syntax uses a double colon or rsync URL. Module listing, file listing, read and write are separate permissions; a writable module is not execution without a useful consumer.

Worked example · hypothetical

Observation: the daemon lists a backup module. Test: list it and retrieve one configuration file. Illustrative output: the bytes contain an application connection string. Interpretation: classify the credential and retain the module's actual read boundary.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗