Welcome back, aspiring forensic and incident response investigators.

Today we are going to learn more about a branch of digital forensics that focuses on networks, which is Network Forensics. This field often contains a wealth of valuable evidence. Even though skilled attackers may evade endpoint controls, active network captures are harder to hide. Many of the attacker’s actions generate traffic that is recorded. Intrusion detection and prevention systems (IDS/IPS) can also surface malicious activity quickly, although not every organization deploys them. In this exercise you will see what can be extracted from IDS/IPS logs and a packet capture during a network forensic analysis.

The incident we will investigate today involved a credential-stuffing attempt followed by exploitation of CVE-2022-25237. The attacker abused an API to run commands and establish persistence. Below are the details and later a timeline of the attack.

Intro

Our subject is a fast-growing startup that uses a business management platform. Documentation for that platform is limited, and the startup administrators have not followed strong security practices. For this exercise we act as the security team. Our objective is to confirm the compromise using network packet captures (PCAP) and exported security logs.

We obtained an archive containing the artifacts needed for the investigation. It includes a .pcap network traffic file and a .json file with security events. Wireshark will be our primary analysis tool.

Analysis

Defining Key IP Addresses

The company suspects its management platform was breached. To identify which platform and which hosts are involved, we start with the pcap file. In Wireshark, view the TCP endpoints from the Statistics menu and sort by packet count to see which IP addresses dominate the capture.

This quickly highlights the IP address 172.31.6.44 as a major recipient of traffic. The traffic to that host uses ports 37022, 8080, 61254, 61255, and 22. Common service associations for these ports are: 8080 for HTTP, 22 for SSH, and 37022 as an arbitrary TCP data port that the environment is using.

When you identify heavy talkers in a capture, export their connection lists and timestamps immediately. That gives you a focused subset to work from and preserves the context of later findings.

Analyzing HTTP Traffic

The port usage suggests the management platform is web-based. Filter HTTP traffic in Wireshark with http.request to inspect client requests. The first notable entry is a GET request whose URL and headers match Bonitasoft’s platform, showing the company uses Bonitasoft for business management.

Below that GET request you can see a series of authentication attempts (POST requests) originating from 156.146.62.213. The login attempts include usernames that reveal the attacker has done corporate OSINT and enumerated staff names.

The credentials used for the attack are not generic wordlist guesses, instead the attacker tries a focused set of credentials. That behavior is consistent with credential stuffing: the attacker uses previously leaked username/password pairs (often from other breaches) and tries them against this service, typically automated and sometimes distributed via a botnet to blend with normal traffic.

A credential-stuffing event alone does not prove a successful compromise. The next step is to check whether any of the login attempts produced a successful authentication. Before doing that, we review the IDS/IPS alerts.

Finding the CVE

To inspect the JSON alert file in a shell environment, format it with jq and then see what’s inside. Here is how you can make the json output easier to read:

bash$ > cat alerts.json | jq .

Obviously, the file will be too big, so we will narrow it down to indicators such as CVE:

bash$ > cat alerts.json | jq .

Security tools often map detected signatures to known CVE identifiers. In our case, alert data and correlation with the observed HTTP requests point to repeated attempts to exploit CVE-2022-25237, a vulnerability affecting Bonita Web 2021.2. The exploit abuses insufficient validation in the RestAPIAuthorizationFilter (or related i18n translation logic). By appending crafted data to a URL, an attacker can reach privileged API endpoints, potentially enabling remote code execution or privilege escalation.

Now we verify whether exploitation actually succeeded.

Exploitation

To find successful authentications, filter responses with:

http.response.code >= 200 and http.response.code < 300 and ip.addr == 172.31.6.44

Among the successful responses, HTTP 204 entries stand out because they are less common than HTTP 200. If we follow the HTTP stream for a 204 response, the request stream shows valid credentials followed immediately by a 204 response and cookie assignment. That means he successfully logged in. This is the point where the attacker moves from probing to interacting with privileged endpoints.

After authenticating, the attacker targets the API to exploit the vulnerability. In the traffic we can see an upload of rce_api_extension.zip, which enables remote code execution. Later this zip file will be deleted to remove unnecessary traces.

Following the upload, we can observe commands executed on the server. The attacker reads /etc/passwd and runs whoami. In the output we see access to sensitive system information.

During a forensic investigation you should extract the uploaded files from the capture or request the original file from the source system (if available). Analyzing the uploaded code is essential to understand the artifact of compromise and to find indicators of lateral movement or backdoors

Persistence

After initial control, attackers typically establish persistence. In this incident, all attacker activity is over HTTP, so we follow subsequent HTTP requests to find persistence mechanisms.

The attacker downloads a script hosted on a paste service (pastes.io), named bx6gcr0et8, which then retrieves another snippet hffgra4unv, appending its output to /home/ubuntu/.ssh/authorized_keys when executed. The attacker restarts SSH to apply the new key.

A few lines below we can see that the first script was executed via bash, completing the persistence setup.

Appending keys to authorized_keys allows SSH access for the attacker’s key pair and doesn’t require a password. It’s a stealthy persistence technique that avoids adding new files that antivirus might flag. In this case the attacker relied on built-in Linux mechanisms rather than installing malware.

When you find modifications to authorized_keys, pull the exact key material from the capture and compare it with known attacker keys or with subsequent SSH connection fingerprints. That helps attribute later logins to this initial persistence action.

Post-Exploitation

Further examination of the pcap shows the server reaching out to Ubuntu repositories to download a .deb package that contains Nmap. 

Shortly after SSH access is obtained, we see traffic from a second IP address, 95.181.232.30, connecting over port 22. Correlating timestamps shows the command to download the .deb package was issued from that SSH session. Once Nmap is present, the attacker performs a port scan of 34.207.150.13.

This sequence, adding an SSH key, then using SSH to install reconnaissance tools and scan other hosts fits a common post-exploitation pattern. Hackers establish persistent access, stage tools, and then enumerate the network for lateral movement opportunities.

During forensic investigations, save the sequence of timestamps that link file downloads, package installation, and scanning activity. Those correlations are important for incident timelines and for identifying which sessions performed which actions.

Timeline

At the start, the attacker attempted credential stuffing against the management server. Successful login occurred with the credentials seb.broom / g0vernm3nt. After authentication, the attacker exploited CVE-2022-25237 in Bonita Web 2021.2 to reach privileged API endpoints and uploaded rce_api_extension.zip. They then executed commands such as whoami and cat /etc/passwd to confirm privileges and enumerate users.

The attacker removed rce_api_extension.zip from the web server to reduce obvious traces. Using pastes.io from IP 138.199.59.221, the attacker executed a bash script that appended data to /home/ubuntu/.ssh/authorized_keys, enabling SSH persistence (MITRE ATT&CK: SSH Authorized Keys, T1098.004). Shortly after persistence was established, an SSH connection from 95.181.232.30 issued commands to download a .deb package containing Nmap. The attacker used Nmap to scan 34.207.150.13 and then terminated the SSH session.

Conclusion

During our network forensics exercise we saw how packet captures and IDS/IPS logs can reveal the flow of a compromise, from credential stuffing, through exploitation of a web-application vulnerability, to command execution and persistence via SSH keys. We practiced using Wireshark to trace HTTP streams, observed credential stuffing in action, and followed the attacker’s persistence mechanism.

Although our class focused on analysis, in real incidents you should always preserve originals and record every artifact with exact timestamps. Create cryptographic hashes of artifacts, maintain a chain of custody, and work only on copies. These steps protect the integrity of evidence and are essential if the incident leads to legal action.

For those of you interested in deepening your digital forensics skills, we will be running a practical SCADA forensics course soon in November. This intensive, hands-on course teaches forensic techniques specific to Industrial Control Systems and SCADA environments showing you how to collect and preserve evidence from PLCs, RTUs, HMIs and engineering workstations, reconstruct attack chains, and identify indicators of compromise in OT networks. Its focus on real-world labs and breach simulations will make your CV stand out. Practical OT/SCADA skills are rare and highly valued, so completing a course like this is definitely going to make your CV stand out. 

We also offer digital forensics services for organizations and individuals. Contact us to discuss your case and which services suit your needs.

Learn more: https://hackersarise.thinkific.com/courses/scada-forensics

The post Network Forensics: Analyzing a Server Compromise (CVE-2022-25237) 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 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.

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.

moth // Recently, BHIS penetration tester Dale Hobbs was on an Internal Network Penetration Test and came across an RPC-based arbitrary command execution vulnerability in his vulnerability scan results.  I […]

The post Exploit Development – A Sincere Form of Flattery appeared first on Black Hills Information Security.