Labs

Northstar

A backup exposure gives user access, and an outdated kernel combined with weak patch hygiene enables root escalation.

Difficulty: Hard

Northstar was the most realistic of the set for me. The foothold came from ==blue:weak file governance==, and root came from ==red:patch management debt==.

!![amber] Nothing flashy here; just layered operational failures compounding into root.

Reconnaissance

nmap -sC -sV -Pn -p- 10.10.11.89 -oN nmap-northstar.txt
Nmap scan report for 10.10.11.89
Host is up (0.13s latency).
Not shown: 65532 closed tcp ports (reset)

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.9p1 Debian 10+deb10u4
80/tcp open  http    nginx 1.14.2
111/tcp open  rpcbind 2-4 (RPC #100000)

No obvious web vulnerability appeared immediately, so I switched to hunting ==amber:exposed artifacts==.

I also checked whether RPC service exposure translated into easy shares:

showmount -e 10.10.11.89
rpcinfo -p 10.10.11.89

rpcbind was reachable, but there were no useful exported paths, so web artifact discovery stayed primary.

Initial Access (Sanitized)

gobuster dir -u http://10.10.11.89 -w /usr/share/wordlists/dirb/common.txt -x txt,bak,tar.gz
/backup/                    (Status: 301)
/backup/site-2025-09.tar.gz (Status: 200)

The archive contained configuration data with credentials that were still valid for local access, which became the ==blue:initial access pivot==.

sam@northstar:~$ whoami
sam

Once inside, I captured quick baseline details before escalation checks:

id
hostnamectl
ls -lah /home/sam

Privilege Escalation (Sanitized but Insightful)

I checked common local vectors first:

sudo -l
find / -perm -4000 -type f 2>/dev/null
getcap -r / 2>/dev/null

No direct sudo or SUID path looked usable. Kernel triage looked more promising:

uname -a
Linux northstar 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 x86_64 GNU/Linux

linpeas highlighted this kernel generation as potentially affected by known local privilege escalation classes depending on patch level. I validated patch status manually and used a lab-safe public PoC workflow conceptually.

!![red] Kernel patch lag is a privilege escalation risk, not just a compliance issue.

I confirmed the branch by checking package patch levels and distro release metadata:

cat /etc/os-release
dpkg -l | grep linux-image | head

At that point, kernel path validity was stronger than any file-permission or sudo route on this host. I used a controlled local-kernel escalation workflow in the lab and verified root access.

This machine also reinforced a file-permission lesson: the initial backup archive should never have been web-readable. That single permission mistake created the entire path.

Proof (Sanitized)

whoami
root
cat /root/root.txt
flag output intentionally omitted to preserve the lab challenge

Key Takeaways

  • Backup exposure is a file-permission problem with direct security impact.
  • Kernel version and patch posture should be standard escalation checks.
  • When common vectors fail, disciplined enumeration still surfaces viable paths.
  • Defensive patching and artifact access control break this chain early.