Phantom 5: File Authority — Escalating from Group Membership to Root (A Linux Privilege Escalation CTF Walkthrough)
A writeup from the “Phantom” series of ephemeral container CTF challenges — this one focuses on Linux group misconfigurations and weak password cracking.
Our user belongs to an interesting group. Groups determine what you can access. Some groups should never be given to regular users. Check your groups. Understand what they allow. Read what you should not be able to read. Exactly one account on this box has a weak password. Crack its hash, become that account, and take the flag.
- Firstly I read the the BRIEFING file.
Two clues stood out immediately, As we can see in the above image:
1. Something about my group membership is interesting, implying a misconfiguration.
2. There was exactly one weak password on the box, and cracking it was the path to the flag.
Step 1: Enumerate Group Membership
The first move in any Linux privilege escalation challenge is understanding who you are and what you belong to:
```bash
id
groups
```
Step 2: Understand what those groups grant — look for group-readable files/binaries tied to your groups
Rather than guessing, I pulled /etc/gshadow to see the full group structure and membership map directly. This immediately surfaced the interesting detail: my user, phantom5, was a member of the shadow group.
```
shadow:*::phantom5
```
That’s the misconfiguration. The shadow group exists specifically to control read access to /etc/shadow — the file holding every account’s password hash. On a properly hardened system, regular users should never be in this group. Here it was phantom5.
Step 3: Read What You Shouldn’t Be Able To Read
With shadow group membership confirmed, `/etc/shadow` became directly readable:
```bash
cat /etc/shadow
```
To find crackable accounts, I filtered out locked (`!`) and disabled (`*`) entries, since those can’t be authenticated with a password at all, I went straight and Ran the following Command:
```bash
awk -F: ‘$2 !~ /^[!*]/ {print $1":”$2}’ /etc/shadow
```
This returned exactly two accounts with real hashes: root and phantom5 (myself). Since I already controlled phantom5, the target was clear: root.
Both hashes used the `$y$` prefix — **yescrypt**, the modern default password hashing scheme on many current Linux distributions (replacing SHA-512 as the default in newer glibc/PAM stacks).
Step 4: Cracking the Hash
I moved the root hash line to a cracking box and ran John the Ripper against it:
As John the ripper was not available on this machine, I used My own machine.
```bash
grep ‘^root:’ /etc/shadow > root_hash.txt
john root_hash.txt — wordlist=/usr/share/wordlists/rockyou.txt
```
First attempt: `No password hashes loaded`. Two separate mistakes along the way, both worth documenting since they’re common gotchas:
Mistake 1 : Shell variable expansion. I initially built the hash file with `echo “root:$y$j9T$…”` inside double quotes. Bash interprets `$y`, `$j9T`, etc. as variable references inside double quotes and since none of those variables existed, they silently expanded to nothing, mangling the hash beyond recognition. The fix: use single quotes (or better, `grep` the line directly from `/etc/shadow` to avoid manual transcription entirely).
Mistake 2 : Format detection. Even with the hash intact, John didn’t auto-detect the yescrypt format from a bare `username:hash` line. Restoring the full shadow-file line format (all colon-delimited fields) and explicitly forcing the format solved it:
```bash
john — format=crypt root_hash.txt — wordlist=/usr/share/wordlists/rockyou.txt
```
Result:
Loaded 1 password hash (crypt, generic crypt(3) [?/64])
princess (root)
1g 0:00:00:00 DONE
```
Cracked in under a second — `rockyou.txt` remains devastatingly effective against weak, dictionary-based passwords, regardless of how modern the hashing algorithm protecting them is.
Step 5: Privilege Escalation and Flag Capture
With the cracked credential in hand, escalating was trivial:
```bash
su — root
# password: princess
cat /var/lib/phantom-flags/level5_flag
```
Flag captured.
This challenge was a clean illustration of two independent, compounding failures — either one alone might have been survivable, but together they broke the box wide open:
-Group misconfiguration**: Membership in `shadow` is a privileged trust boundary, not a convenience group. It should be reserved for the small set of tools (like `login`, `passwd`) that legitimately need to read password hashes — never handed to a regular user account.
-Weak password hygiene: Modern hashing algorithms like yescrypt are computationally expensive by design specifically to resist offline cracking. That protection is meaningless if the underlying password is a dictionary word. `princess` didn’t survive one second against rockyou.txt.
Defense in depth means neither failure should be sufficient on its own. Here, the group misconfiguration provided access to the hash, and the weak password provided the key — a good reminder that hardening is rarely about one silver-bullet fix, but about not leaving multiple doors unlocked at once.
This was completed in an isolated, ephemeral container built specifically for practicing privilege escalation techniques — no production systems were involved.
on Medium, where people are continuing the conversation by highlighting and responding to this story.
SOCIAL SHARE CARD GENERATOR