Labs

Ashrail

A config exposure provides foothold, then PATH hijacking in a privileged maintenance script leads to root.

Difficulty: Medium

Ashrail had a very DevOps-style misconfiguration chain. Nothing was especially exotic, but trusting PATH in a privileged script made the host easy to break. The whole path was ==amber:configuration-heavy== and very realistic.

!![amber] Internal helper scripts can become escalation paths when trust boundaries are weak.

Reconnaissance

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

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.4
80/tcp   open  http    Apache httpd 2.4.52
9090/tcp open  http    SimpleHTTPServer 0.6 (Python 3.10)

Port 9090 looked internal but exposed publicly, so I prioritized it over the main website. That decision paid off quickly.

I did a quick content sanity check on both HTTP services before choosing direction:

curl -i http://10.10.11.74/
curl -i http://10.10.11.74:9090/

The 9090 service looked like a simple file host and exposed operational artifacts with almost no hardening.

Initial Access (Sanitized)

gobuster dir -u http://10.10.11.74:9090 -w /usr/share/wordlists/dirb/common.txt -x txt,bak,conf
/downloads/            (Status: 301)
/downloads/build.conf  (Status: 200)

The config included reusable credentials for a non-root user over SSH, giving a ==blue:clean foothold==.

build@ashrail:~$ whoami
build

From the user shell, I checked local script ownership patterns immediately:

find /usr/local/sbin -maxdepth 1 -type f -perm -111 -ls 2>/dev/null

That helped identify which helper scripts were likely intended for operational automation.

Privilege Escalation (Sanitized but Insightful)

sudo -l returned one permitted script:

sudo -l
User build may run the following commands on ashrail:
    (root) NOPASSWD: /usr/local/sbin/asset-audit

I reviewed script contents:

cat /usr/local/sbin/asset-audit
#!/bin/bash
PATH=/home/build/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
netstat -tulpn > /tmp/audit_ports.txt
uname -a > /tmp/audit_kernel.txt

The issue is ==red:PATH hijacking==: privileged script + relative command calls + attacker-controlled directory first in PATH.

!![red] Root scripts should always use absolute binary paths.

ls -ld /home/build/.local/bin
drwxrwxr-x 2 build build 4096 Feb 20 11:21 /home/build/.local/bin

I confirmed no easier route existed via wildcard sudo rules or writable cron entries:

cat /etc/crontab

With no simpler privilege path available, the PATH trust issue was clearly the escalation vector. I used the standard PATH hijack workflow in a controlled lab context to trigger root execution through the allowed script.

Proof (Sanitized)

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

Key Takeaways

  • Privileged scripts should always use absolute binary paths.
  • If a writable user directory appears early in PATH, treat it as critical.
  • Sudo script review should include both logic and environment assumptions.
  • Auxiliary internal services often leak operational secrets.