PingPong HTB Walkthrough Premium

I just solved PingPong from Hack the Box

PingPong Machine Summary

Pingpong is an insane difficulty level Windows machine on Hack the Box

PingPong - HackTheBox Season 10 htb writeup machine walkthrough

Protected Page

The first step in owning the PingPong machine like I have always done in my previous writeups is to connect my Kali Linux terminal with Hack the Box server. To establish this connection, I ran the following command in the terminal:

Once the connection between my Kali Linux terminal and Hack the Box server has been established, I started the PingPong machine and I was assigned an IP address (10.129.245.56).

Nmap Enumeration

I began by running an aggressive Nmap scan against the target to identify exposed services, operating system details, and service versions. The initial enumeration quickly indicated that the target was a Windows Active Directory Domain Controller, exposing several services commonly found in enterprise environments.

To gather this information, I ran the following Nmap scan:

The scan revealed DNS, Kerberos, LDAP, SMB, and WinRM services, while LDAP identified the domain as ping.htb and the SSL certificate confirmed the hostname dc1.ping.htb. SMB signing was enabled and required, ruling out certain relay attacks, whereas the presence of WinRM on port 5985 suggested a potential remote management entry point after obtaining valid credentials. Based on these findings, I proceeded with host configuration and Active Directory enumeration to identify users, shares, and possible attack vectors.

Host Configuration

After identifying the domain name and hostname during enumeration, I configured my local /etc/hosts file to ensure the target's Active Directory services could be resolved correctly. This allows tools that rely on DNS resolution, such as Kerberos, LDAP, SMB, and WinRM, to communicate with the domain without requiring an external DNS server.

To achieve this, I added the discovered hostnames and domain names to my local hosts file using the following commands:

By mapping the target IP address to dc1.ping.htb, dc1, ping.htb, and pingpong.htb, I ensured consistent hostname resolution throughout the engagement. With the environment properly configured, I proceeded with Active Directory enumeration against the newly resolved domain.

SMB Authentication

After configuring the target domain, I attempted to authenticate to the SMB service using the supplied domain credentials to verify whether they were valid and supported over NTLM. This also helped determine whether SMB could be used for further enumeration or lateral movement.

To perform the authentication test, I ran the following command:

The target responded with STATUS_NOT_SUPPORTED, indicating that NTLM authentication was not accepted for SMB. The scan also showed that NTLM was disabled while SMB signing was enforced, suggesting that the environment was configured to rely on Kerberos authentication instead. Based on this result, I shifted my focus to obtaining a Kerberos ticket before continuing with domain enumeration.

LDAP Authentication

After the unsuccessful SMB authentication attempt, I tested the same credentials against the LDAP service to determine whether they could be used for directory enumeration. This would confirm whether the domain still accepted NTLM authentication over LDAP.

To verify this, I ran the following command:

The authentication attempt returned STATUS_NOT_SUPPORTED, indicating that NTLM authentication was also disabled for LDAP. Since both SMB and LDAP rejected NTLM while exposing Active Directory services, I concluded that the environment was configured to use Kerberos authentication, prompting me to switch to a Kerberos-based attack path for further enumeration.

Kerberos Configuration

After confirming that the domain relied on Kerberos instead of NTLM, I generated a Kerberos configuration file to ensure my attack machine could communicate correctly with the target realm. This eliminates the need to manually configure the domain, KDC, and realm settings.

To generate and load the Kerberos configuration, I ran the following commands:

NetExec automatically created a krb5.conf file using the domain information obtained from the target and instructed me to export it through the KRB5_CONFIG environment variable. With my Kerberos client now configured for the ping.htb realm, I was ready to request Kerberos tickets and continue Active Directory enumeration using Kerberos authentication.

Time Synchronization

Before requesting Kerberos tickets, I synchronized my attack machine's clock with the domain controller to prevent authentication failures caused by time drift. Since Kerberos is highly sensitive to clock differences, ensuring both systems shared the same time was an essential prerequisite.

To synchronize my system time with the domain controller, I ran the following command:

I just solved PingPong from Hack the Box

The command successfully adjusted my local clock to match the domain controller, correcting a significant time difference. With the clocks now synchronized, I could safely proceed with Kerberos authentication without encountering clock skew errors.

Kerberos Ticket Request

After configuring Kerberos and synchronizing my system time, I requested a Ticket Granting Ticket (TGT) using the provided domain credentials. Successfully obtaining a TGT would confirm that the credentials were valid and enable Kerberos-based authentication for subsequent enumeration.

To request the ticket, I ran the following command:

The request completed successfully, and Impacket saved the Kerberos ticket as c.roberts.ccache. With a valid TGT stored locally, I could authenticate to Active Directory services using Kerberos instead of NTLM and continue the assessment with ticket-based enumeration.

Kerberos Ticket Verification

After requesting the Ticket Granting Ticket (TGT), I verified that it had been successfully saved and was valid before using it for Kerberos authentication. This step confirmed that I had a usable ticket cache for subsequent interactions with the domain.

To inspect the Kerberos ticket cache, I ran the following command:

pingpong hack the box machine season 11 root flag hint

The output confirmed that the cache contained a valid krbtgt/PING.HTB ticket for c.roberts@PING.HTB, along with its validity and renewal period. Having verified the ticket, I proceeded to authenticate to Active Directory services using the Kerberos cache instead of relying on NTLM credentials.

LDAP User Enumeration

After obtaining a valid Kerberos ticket, I configured my environment to use both the Kerberos configuration file and the cached ticket before enumerating domain users through LDAP. This allowed me to authenticate with Kerberos instead of NTLM and perform directory queries successfully.

To configure the Kerberos environment and enumerate the domain users, I ran the following commands:

NetExec successfully authenticated using the cached Kerberos ticket and enumerated 25 Active Directory user accounts, exporting the results to users.txt for offline analysis. The output also disclosed account descriptions and password timestamps, providing valuable information for identifying privileged users and planning subsequent enumeration and attack paths.

BloodHound Enumeration

With a valid Kerberos ticket already cached, I performed a comprehensive Active Directory enumeration using BloodHound to collect information about users, groups, computers, Group Policy Objects, trusts, and privilege relationships. This would allow me to visualize potential attack paths and identify opportunities for privilege escalation.

To collect the Active Directory data, I ran the following command:

BloodHound successfully authenticated using the cached Kerberos ticket and automatically switched to LDAPS after LDAP signing prevented plaintext LDAP authentication. It collected information on the domain's users, groups, computers, GPOs, OUs, containers, and trusts before packaging the results into a ZIP archive for analysis in the BloodHound interface, where I could identify privilege escalation paths and delegated permissions.