I just solved PingPong from Hack the Box
PingPong Machine Summary
PingPong is an insane-difficulty Windows Active Directory machine on Hack The Box that focuses on enterprise Active Directory exploitation, Kerberos authentication, Active Directory Certificate Services (AD CS), cross-forest trust abuse, delegated permissions, Group Managed Service Accounts (gMSAs), Just Enough Administration (JEA) bypass, Resource-Based Constrained Delegation (RBCD), SQL Server abuse, privilege escalation through SeImpersonatePrivilege, certificate template misconfigurations, and multi-domain compromise. The machine demonstrates how individually low-risk Active Directory misconfigurations can be chained across two trusted domains to achieve complete compromise of an enterprise environment.
The attack began with Nmap enumeration, which identified the target as a Domain Controller exposing several Active Directory services. After performing host configuration, I authenticated to SMB and LDAP, configured my Kerberos environment, synchronized my system time with the Domain Controller, requested a Kerberos Ticket Granting Ticket (TGT), and verified the issued ticket before enumerating domain users through LDAP. I then collected Active Directory data with BloodHound, whose analysis revealed the initial privilege escalation path. Further enumeration of Active Directory Certificate Services exposed a vulnerable certificate template that I abused to request a certificate and perform certificate-based authentication, providing my initial foothold on the domain. After gaining access, I performed initial user, system, network, and domain trust enumeration, revealing the existence of a trusted second domain that became the next objective.
To reach the internal domain, I uploaded an internal network scanner and performed network reconnaissance to identify additional hosts and services. I then established a pivot using Ligolo-ng by deploying its agent on the compromised host, configuring the proxy, and creating a tunnel into the isolated network segment. After verifying connectivity, I generated and updated a new Kerberos configuration for the trusted domain and requested cross-realm Kerberos service tickets, allowing authenticated communication across the forest trust. A second round of BloodHound enumeration uncovered a complex privilege escalation path involving delegated permissions. By converting object ownership into GenericAll, modifying security group scopes, converting a global group into a Domain-Local group, and adding a cross-domain principal as a member, I successfully expanded my privileges across the trust boundary. This enabled me to retrieve the password of a Group Managed Service Account (gMSA), obtain a new Kerberos TGT, and authenticate using the service account.
The gMSA account was restricted by a Just Enough Administration (JEA) endpoint, preventing direct administrative actions. To bypass these restrictions, I analyzed the available PowerShell commands, verified the execution context, prepared and executed an encoded PowerShell payload, and escaped the constrained JEA session. I then enumerated the JEA configuration files, reviewed the assigned role capabilities and session configuration, and eventually recovered credentials stored in the PowerShell command history. Using these credentials, I authenticated as C.Carlssen, configured a new Kerberos environment, requested service tickets for the second Domain Controller, and authenticated to DC2 via WinRM.
With administrative access to the second domain, I configured Resource-Based Constrained Delegation (RBCD) and abused the S4U2Self/S4U2Proxy Kerberos extensions to impersonate a privileged account. This granted access to Microsoft SQL Server, where I enabled xp_cmdshell to execute operating system commands. After confirming that the SQL Server service account possessed the SeImpersonatePrivilege, I transferred the GodPotato privilege escalation tool and exploited the privilege to impersonate NT AUTHORITY\SYSTEM, adding my user to the local Administrators group. This granted full administrative access to DC2, allowing me to capture the user flag and extract the Domain Controller's secrets, including the NTDS.DIT, LSA secrets, Kerberos keys, and account hashes.
The extracted credential material provided AES Kerberos keys for multiple privileged accounts, which I used to request additional Kerberos TGTs without requiring plaintext passwords. After verifying cross-realm Kerberos authentication, I returned to the original domain and abused excessive permissions over an AD CS certificate template by modifying its configuration and granting GenericAll permissions to Authenticated Users. This transformed the template into an ESC4-style certificate abuse path, allowing me to request a certificate for the Administrator account. Using Certipy, I authenticated as the domain Administrator, obtained a valid Kerberos TGT and NT hash, and finally authenticated to DC1 via WinRM. From there, I accessed the Administrator's Desktop and captured the root flag, completing a full compromise of both the PING.HTB and PONG.HTB Active Directory domains.
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:
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:
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.
BloodHound Analysis
After importing the BloodHound data, I analyzed the relationships between users, groups, certificate templates, and trusted domains to identify potential attack paths. The graph revealed that PING.HTB and PONG.HTB shared a two-way trust relationship, meaning that compromise opportunities could extend beyond a single domain and affect the entire forest.
The analysis also showed that my account, C.Roberts, was a member of the IT@PING.HTB group and, through the default Domain Users group, was permitted to enroll in the TemporaryWinRM certificate template. More importantly, BloodHound identified an ESC4 attack path where the CA Managers group had WriteOwner, WriteDacl, and GenericWrite permissions over the SmartcardAuthentication certificate template, indicating that modifying the template could eventually be leveraged for certificate-based privilege escalation.
Kerberos Environment Configuration
Before proceeding with the cross-domain attack, I configured my environment to use the previously generated Kerberos configuration file and cached Ticket Granting Ticket (TGT). This ensured that all subsequent Kerberos-aware tools would automatically authenticate using my existing credentials.
To configure the Kerberos environment and verify that the ticket cache was loaded correctly, I ran the following commands:
The output confirmed that the c.roberts@PING.HTB TGT was successfully loaded from the local cache and remained valid for authentication. With the Kerberos environment correctly configured, I was ready to perform the upcoming cross-domain operations without supplying credentials repeatedly.
Active Directory Certificate Services Enumeration
With Kerberos authentication already configured, I enumerated the Active Directory Certificate Services (AD CS) environment using Certipy to identify certificate templates and potential misconfigurations that could be abused for privilege escalation. AD CS is a common attack surface in Active Directory environments, making it an important component to assess.
To enumerate the certificate infrastructure, I ran the following command:
Certipy successfully authenticated with Kerberos and discovered 35 certificate templates, 13 enabled templates, and a single Certificate Authority (ping-DC1-CA). Although retrieving the CA configuration and web enrollment details timed out, the enumeration results were successfully exported in both TXT and JSON formats for offline analysis, providing a foundation for identifying potential AD CS attack paths later in the assessment.
Certificate Request
After identifying a usable certificate template during the AD CS enumeration, I requested a certificate for the C.Roberts account using Certipy. A successful enrollment would provide an alternative authentication method that could later be used for Kerberos-based authentication without relying on the account password.
To request the certificate from the Enterprise Certificate Authority, I ran the following command:
The certificate request completed successfully, and the CA issued a certificate containing the C.Roberts@ping.htb UPN. Certipy saved both the certificate and its private key as c.roberts.pfx, giving me a certificate-based credential that I could use for subsequent Kerberos authentication and privilege escalation activities.
Certificate Authentication
After obtaining a valid client certificate, I authenticated to Active Directory using certificate-based authentication instead of a password. This allowed me to request a fresh Kerberos Ticket Granting Ticket (TGT) and recover the account's NTLM hash for alternative authentication methods.
To authenticate with the issued certificate, I ran the following command:
Certipy successfully authenticated as c.roberts@ping.htb, obtained a new Kerberos TGT, and updated my local c.roberts.ccache file. It also recovered the account's NTLM hash, providing an additional credential that could be used for pass-the-hash authentication and other Kerberos-based operations during the remainder of the engagement.
Initial Shell Access
After obtaining a valid Kerberos ticket, I used it to authenticate to the target over WinRM and establish an interactive PowerShell session. Since WinRM supports Kerberos authentication, I did not need to provide the account password or NTLM hash.
To configure the Kerberos environment and connect to the target, I ran the following commands:
Evil-WinRM successfully authenticated using the cached Kerberos ticket and established a remote PowerShell session as PING\C.Roberts. With interactive access to the domain controller, I could begin local enumeration to identify user privileges, accessible resources, and potential paths for privilege escalation.
Initial User Enumeration
After obtaining an interactive PowerShell session, I enumerated the privileges and group memberships assigned to the current user to understand the level of access available. This helped identify permissions and security groups that could potentially be leveraged for privilege escalation.
To inspect the current user's privileges and group memberships, I ran the following commands:
The output showed that C.Roberts possessed the SeMachineAccountPrivilege, allowing the creation of computer accounts in the domain, and was a member of the IT and TempWinRMAccess groups. These findings aligned with the BloodHound results and confirmed that the account had delegated permissions worth investigating further, particularly the IT group's relationship with gMSA Managers in the trusted PONG domain.
User Enumeration
With an interactive PowerShell session established, I enumerated the local user profiles on the system to identify available accounts and look for anything unusual that could assist with privilege escalation. This also helped me verify whether any service or managed accounts were present on the host.
To list the user profile directories, I ran the following commands:
The output revealed the expected Administrator, C.Roberts, and Public directories, but also exposed a profile named Pong_gMSA$. The presence of a Group Managed Service Account (gMSA) profile was particularly interesting, as it aligned with the BloodHound findings and reinforced that compromising this account could become a key step toward achieving higher privileges.
Network Enumeration
After completing the initial user enumeration, I inspected the network configuration to identify additional interfaces and determine whether the host had connectivity to other internal networks. Discovering multiple network adapters can often reveal opportunities for pivoting into otherwise inaccessible segments.
To enumerate the network interfaces, I ran the following command:
The output revealed two network adapters: the external interface on 10.129.245.56 and an additional vEthernet interface on the 192.168.2.0/24 subnet. The presence of this internal network indicated that the domain controller had access to another isolated segment, suggesting that network pivoting would likely be required to reach additional hosts later in the engagement.
Trust Enumeration
After identifying a second internal network, I enumerated the domain trust relationships to determine whether the current domain had access to any additional Active Directory forests. This would help identify potential opportunities for cross-domain attacks and lateral movement.
To enumerate the domain trusts and locate the remote domain controller, I ran the following commands:
The output confirmed a bidirectional forest trust between PING.HTB and PONG.HTB and identified DC2.pong.htb as the domain controller for the trusted domain at 192.168.2.2. Since the trusted domain resided on the previously discovered internal 192.168.2.0/24 network, I shifted my focus toward pivoting into that network to continue the assessment against the PONG environment.
Host Configuration
After discovering the trusted PONG domain and identifying its domain controller, I updated my local /etc/hosts file to ensure the new hostnames could be resolved correctly. This would allow Kerberos, LDAP, SMB, and other tools to communicate with the trusted domain without relying on external DNS resolution.
To add the newly discovered domain controller and domain names, I ran the following command:
By mapping 192.168.2.2 to dc2.pong.htb, dc2, and pong.htb, I prepared my attack machine for seamless interaction with the trusted domain. With hostname resolution in place, I was ready to begin enumeration and exploitation of the PONG Active Directory environment.
Internal Scanner Preparation
To enumerate the newly discovered internal network from the compromised Windows host, I prepared Fscan, a lightweight network scanner capable of identifying live hosts, open ports, and common services. Since my foothold was on a Windows machine, I compiled a Windows-compatible executable on my attack machine.
To install the required dependencies, download the source code, and build the scanner, I ran the following commands:
The build completed successfully and produced fscan.exe, which I could transfer to the compromised host for internal reconnaissance. With a Windows-native scanner prepared, I was ready to enumerate the 192.168.2.0/24 network and identify additional systems reachable from the domain controller.
Tool Transfer
After preparing the Windows version of Fscan, I transferred it to the compromised host so I could perform internal network reconnaissance from within the target environment. I chose the C:\ProgramData directory because it is writable by standard users and is commonly used to stage tools during post-exploitation.
To upload the scanner and verify that it had been transferred successfully, I ran the following commands:
The upload completed successfully, and the file was present in C:\ProgramData with the expected size, confirming its integrity. With fscan.exe now available on the compromised system, I was ready to enumerate the internal 192.168.2.0/24 network directly from the domain controller.
Internal Network Enumeration
With Fscan deployed on the compromised host, I enumerated the internal 192.168.2.0/24 network to identify reachable systems and exposed services. Running the scan from the domain controller provided visibility into hosts that were inaccessible from my attack machine.
To scan the internal subnet, I ran the following command:
The scan identified two live hosts: 192.168.2.1 (DC1) and 192.168.2.2 (DC2). It confirmed that DC2 exposed several Active Directory services, including SMB, LDAP, LDAPS, DNS, Kerberos, WinRM, and Microsoft SQL Server (1433). These findings verified that the trusted PONG domain controller was reachable from the compromised host, providing the foothold needed to continue the cross-domain attack against DC2.
Pivoting Preparation
After confirming that the trusted PONG domain was only reachable through the compromised host, I prepared Ligolo-ng to create a tunnel into the internal 192.168.2.0/24 network. This would allow me to access internal services directly from my attack machine without relying on remote command execution.
To download and extract the Windows agent that would run on the compromised host, I ran the following commands:
The download completed successfully, and extracting the archive produced the agent.exe binary required for the Windows target. With the Ligolo-ng agent ready, I could transfer it to the compromised system and establish a pivot into the trusted PONG domain for continued enumeration.
Ligolo-ng Agent Transfer
After preparing the Ligolo-ng agent on my attack machine, I transferred it to the compromised Windows host so I could establish a tunnel into the internal 192.168.2.0/24 network. Running the agent from the compromised system would enable me to pivot into the trusted PONG domain from my local machine.
To upload the Ligolo-ng agent, I ran the following command:
The upload completed successfully, and agent.exe was saved to C:\ProgramData on the target. With the pivoting agent now in place, I was ready to launch it and establish a Ligolo-ng tunnel for direct access to the internal network.
Ligolo-ng Proxy Preparation
To prepare for pivoting into the trusted PONG domain, I downloaded and extracted the Ligolo-ng proxy on my attack machine. The proxy acts as the server component that accepts connections from the Windows agent, enabling me to route traffic through the compromised host.
To download, extract, and verify the proxy binary, I ran the following commands:
The archive extracted successfully and produced the proxy executable alongside the previously collected assessment artifacts. With both the proxy on my attack machine and the agent on the compromised host, I had everything required to establish a Ligolo-ng tunnel and begin interacting directly with systems in the internal 192.168.2.0/24 network.
Ligolo-ng Proxy Configuration
With the proxy downloaded, I started the Ligolo-ng server on my attack machine and configured a dedicated tunnel interface for the internal 192.168.2.0/24 network. This would allow traffic destined for the trusted PONG domain to be routed transparently through the compromised host once the agent connected.
To start the proxy, create the tunnel interface, and add the internal route, I ran the following commands:
The proxy began listening for incoming agent connections on port 11601, after which I created a new ligolo tunnel interface and added a route for the 192.168.2.0/24 subnet. With the routing configuration in place, the only remaining step was to launch the Ligolo-ng agent on the compromised Windows host and establish the pivot into the trusted PONG domain.
Establishing the Ligolo-ng Tunnel
With the proxy configured, I launched the Ligolo-ng agent on the compromised Windows host and connected it back to my attack machine. This established a pivot into the internal network, allowing me to route traffic to systems in the trusted PONG domain as though they were directly accessible.
To start the agent and activate the tunnel, I ran the following commands:
On Ligolo-ng, I ran:
The agent successfully connected to the proxy, where I selected the active session and started the tunnel. Although the connection occasionally dropped due to keepalive timeouts, Ligolo-ng automatically re-established the session and restored the tunnel, providing reliable access to the 192.168.2.0/24 network for the remainder of the assessment.
Tunnel Verification
After establishing the Ligolo-ng tunnel, I verified that I could reach the internal PONG domain controller directly from my attack machine. Confirming network connectivity ensured that the pivot was functioning correctly before continuing with further enumeration.
To test connectivity to the internal host, I ran the following command:
The target responded successfully to each ICMP request, confirming that traffic was being routed through the Ligolo-ng tunnel. With end-to-end connectivity to DC2 verified, I could proceed with enumerating and interacting with services on the trusted PONG domain from my local machine.
Kerberos Configuration for the Trusted Domain
After confirming connectivity to DC2, I generated a dedicated Kerberos configuration file for the trusted PONG domain. This ensured that my Kerberos-aware tools would communicate with the correct Key Distribution Center (KDC) during authentication and enumeration.
To generate the Kerberos configuration file, I ran the following command:
The scan identified DC2 as the domain controller for pong.htb and automatically created a krb5_dc2.conf file containing the appropriate Kerberos realm configuration. With this configuration in place, I could direct subsequent Kerberos authentication requests to the trusted PONG domain and continue the cross-domain assessment.
Kerberos Configuration Verification
Before continuing with cross-domain authentication, I verified the Kerberos configuration files for both the PING and PONG domains. Reviewing these files confirmed that each Kerberos realm pointed to the correct domain controller and would be used during subsequent authentication requests.
To inspect the existing Kerberos configurations, I ran the following commands:
The output showed that krb5.conf was configured for the PING.HTB realm using dc1.ping.htb, while krb5_dc2.conf targeted the PONG.HTB realm using dc2.pong.htb. With both configurations verified, I was ready to switch between the two realms as needed during the trusted domain enumeration.
Kerberos Environment Configuration
To simplify authentication across the trusted PING and PONG domains, I consolidated both Kerberos realms into a single configuration file and configured my environment to use it. I also pointed my session to the existing Kerberos ticket cache so that subsequent tools could authenticate without prompting for credentials.
To configure the Kerberos environment, I ran the following commands:
The updated configuration contained entries for both PING.HTB and PONG.HTB, while klist confirmed that my Kerberos ticket cache for c.roberts@PING.HTB was loaded successfully. With the environment configured, I could seamlessly perform Kerberos-authenticated enumeration and access resources across the trusted domains.
Consolidating the Kerberos Configuration
After generating a separate Kerberos configuration for the trusted PONG domain, I compared it with my existing PING configuration and merged both realms into a single krb5.conf file. This allowed me to authenticate against either domain without switching configuration files during the assessment.
To review the original and updated Kerberos configurations, I ran the following commands:
The updated krb5.conf contained entries for both PING.HTB and PONG.HTB, with each realm mapped to its respective domain controller and DNS domain. This unified configuration streamlined Kerberos authentication and made it easier to perform cross-domain enumeration throughout the remainder of the engagement.
Cross-Domain Kerberos Authentication
With the Kerberos environment configured, I requested a service ticket for the LDAP service running on DC2 in the trusted PONG domain. This verified that the trust relationship between the two domains was functioning correctly and that I could authenticate to services hosted on the remote domain controller.
To request the service ticket and verify the Kerberos cache, I ran the following commands:
The kvno command successfully obtained a service ticket for ldap/dc2.pong.htb, and klist confirmed that the new ticket had been added to my Kerberos cache. This demonstrated that I could leverage my PING.HTB credentials to authenticate to LDAP services in the trusted PONG.HTB domain, enabling the next phase of cross-domain enumeration.
BloodHound Enumeration
After obtaining a Kerberos service ticket for the trusted PONG domain, I enumerated the Active Directory environment with BloodHound using Kerberos authentication. This allowed me to collect domain objects and identify relationships, privileges, and potential attack paths without requiring a password.
To collect the Active Directory data, I ran the following command:
BloodHound successfully authenticated through the established trust and connected to the PONG.HTB domain, collecting information on users, groups, computers, GPOs, OUs, and other Active Directory objects. The results were compressed into a ZIP archive, which I later imported into the BloodHound interface to analyze privilege relationships and identify the next attack path.
BloodHound Analysis
After importing the BloodHound data, I analyzed the privilege relationships between the PING and PONG domains to identify a path for privilege escalation. The graph revealed that my compromised account already possessed an indirect but highly valuable privilege over a cross-domain security group.
The analysis showed that C.Roberts was a member of IT@PING.HTB, and this group owned the gMSA Managers@PONG.HTB group. Because gMSA Managers had the ReadGMSAPassword privilege over PONG_gMSA$ (and also gMSA$@PING.HTB), my next objective was to convert the Owns relationship into effective control by granting GenericAll permissions. Since C.Roberts belongs to a different domain, I would reference the account by its SID rather than its sAMAccountName when modifying the PONG domain object, ultimately allowing me to retrieve the managed password of the target gMSA account.
Modifying Group Permissions
Based on the BloodHound analysis, I leveraged the Owns relationship to grant my compromised account full control over the gMSA Managers group in the trusted PONG domain. Because C.Roberts belonged to the PING domain, I referenced the account by its SID instead of its sAMAccountName to perform the cross-domain modification.
To grant GenericAll permissions on the target group, I ran the following command:
The command completed successfully and granted GenericAll over the gMSA Managers group to my account. This converted the inherited ownership into effective write permissions, allowing me to modify the group's attributes and membership as part of the next stage of the cross-domain gMSA attack.
Modifying the Group Type
After obtaining GenericAll over the gMSA Managers group, I modified its groupType attribute to change its scope. Converting the group into a domain-local security group was necessary to make the cross-domain membership effective and ultimately leverage the ReadGMSAPassword privilege against the target gMSA account.
To update the group's groupType attribute, I ran the following command:
The modification completed successfully, confirming that the groupType attribute had been updated. With the group now configured appropriately, I could proceed with adding my account to gMSA Managers and abuse its ReadGMSAPassword permission to retrieve the managed password of the target gMSA account.
Converting the Group to a Domain-Local Security Group
To enable the intended cross-domain group membership, I updated the groupType attribute of gMSA Managers to -2147483644, which represents a domain-local security group. This scope allows accounts from trusted domains to become effective members and inherit the group's assigned permissions.
To modify the group type, I ran the following command:
%20Hack%20The%20Box.jpg "Eloquia (Insane) Hack The Box")
The command completed successfully, confirming that the groupType attribute had been updated. With gMSA Managers now configured as a domain-local security group, I could proceed with adding my cross-domain account and leverage its ReadGMSAPassword privilege to retrieve the credentials of the target PONG_gMSA$ account.
Adding the Cross-Domain Group Member
After converting gMSA Managers into a domain-local security group, I added my compromised account to the group to activate its assigned privileges. Since C.Roberts belongs to the trusted PING domain, I again referenced the account by its SID to perform the cross-domain membership modification.
To add my account to the gMSA Managers group, I ran the following command:
The command completed successfully, confirming that my account had been added to gMSA Managers. As an effective member of the group, I inherited its ReadGMSAPassword privilege, allowing me to retrieve the managed password of the target PONG_gMSA$ account in the next step.
Kerberos Ticket Renewal
After modifying the group membership, I requested a fresh Kerberos Ticket Granting Ticket (TGT) to ensure my session reflected the updated Active Directory permissions. I then configured my environment to use the newly generated ticket cache for subsequent Kerberos-authenticated operations.
To obtain a new TGT and update the Kerberos cache, I ran the following commands:
The request completed successfully, and a new c.roberts.ccache file was created containing the refreshed Kerberos ticket. By exporting the cache through KRB5CCNAME, all subsequent Kerberos-aware tools automatically used the updated credentials, ensuring the newly assigned privileges were available for the next stage of the attack.
Retrieving the gMSA Password
After refreshing my Kerberos ticket, I verified that my newly assigned membership in gMSA Managers had taken effect by attempting to retrieve the managed password of the target PONG_gMSA$ account. Since the group possessed the ReadGMSAPassword privilege, this was the final step in validating the cross-domain privilege escalation.
To enumerate the managed service account password, I ran the following command:
The command authenticated using my Kerberos ticket cache and successfully extracted the NTLM hash of the PONG_gMSA$ account. This confirmed that the cross-domain group manipulation had succeeded, giving me access to the managed service account's credentials and providing a new privileged identity for the next stage of the attack.
Enumerating the gMSA Credentials
To further validate the privilege escalation, I enumerated the PONG_gMSA$ account using ldeep over LDAP. This provided the full set of authentication material associated with the managed service account, including both its NTLM and Kerberos keys.
To enumerate the gMSA credentials, I ran the following command:
The enumeration successfully returned the NTLM, AES128, and AES256 keys for PONG_gMSA$, while also confirming that the gMSA Managers group was authorized to read the account's managed password. These credentials provided multiple authentication options for impersonating the gMSA account during the next stage of the attack.
Authenticating as the gMSA Account
After extracting the AES256 key for PONG_gMSA$, I used it to request a Kerberos Ticket Granting Ticket (TGT) for the managed service account. This allowed me to authenticate as the gMSA account without knowing its plaintext password and verify that the recovered credentials were valid.
To obtain and inspect the Kerberos ticket, I ran the following commands:
The request completed successfully, generating a new Kerberos ticket cache for Pong_gMSA$. Verifying the cache with klist confirmed that I had obtained a valid TGT for the managed service account, allowing me to perform subsequent Kerberos-authenticated actions using its privileges.
Enumerating the JEA Configuration
After authenticating as PONG_gMSA$, I continued enumerating the target to identify how the managed service account interacted with DC1. During this process, I discovered a Just Enough Administration (JEA) configuration, which revealed that the account was intended to access a restricted PowerShell remoting endpoint instead of the default WinRM session.
To inspect the relevant files, I ran the following command:
The enumeration revealed a JEA directory containing a PowerShell session configuration (JEA.pssc) configured with a RestrictedRemoteServer session type and ConstrainedLanguage mode. This indicated that PONG_gMSA$ was expected to authenticate through a restricted PowerShell endpoint rather than the default WinRM endpoint, prompting me to prepare a Kerberos-aware PSRP client and disable hostname canonicalization in krb5.conf for reliable cross-domain authentication.
Requesting the HTTP Service Ticket
Before connecting to the restricted PowerShell endpoint, I requested a Kerberos service ticket for the HTTP service running on DC1. Since PowerShell Remoting (PSRP) relies on the HTTP service principal, obtaining this ticket ensured that Kerberos authentication would succeed when establishing the remote session.
To request the required service ticket, I ran the following command:
The command successfully retrieved a service ticket for HTTP/dc1.ping.htb, confirming that the corresponding SPN was available and accessible. With the ticket cached locally, I was ready to authenticate to the restricted JEA PowerShell endpoint using Kerberos-backed PSRP.
Configuring the PSRP Client
After identifying the restricted JEA endpoint, I configured a pypsrp client to communicate with DC1 over PowerShell Remoting using Kerberos authentication. This allowed me to verify that my Kerberos ticket cache and connection parameters were correctly configured before attempting to access the custom JEA session.
To create the client and validate its configuration, I ran the following commands:
The script successfully initialized a WSMan client and confirmed that it would connect to http://dc1.ping.htb:5985/wsman using Kerberos with the HTTP service principal. Verifying these connection parameters ensured that the client was correctly configured and ready to authenticate to the restricted PowerShell endpoint in the next stage of the attack.
Verifying Access to the Restricted JEA Endpoint
After confirming that the PSRP client was configured correctly, I performed a minimal proof-of-concept against the restricted JEA endpoint discovered earlier. The goal was to verify that I could authenticate successfully and determine which PowerShell functionality was available within the constrained session.
To test the restricted endpoint, I created and executed the following script:
The script successfully authenticated to the restricted PowerShell endpoint and returned the remote PowerShell version, confirming that the JEA session was accessible. However, the failure of the Get-Location cmdlet demonstrated that the endpoint was operating in a RestrictedRemoteServer configuration with Constrained Language Mode, indicating that only a limited set of approved commands could be executed.
Enumerating Available JEA Commands
After confirming access to the restricted JEA endpoint, I enumerated the commands exposed by the session to understand its capabilities. Since Constrained Language Mode blocks most PowerShell functionality, identifying the permitted cmdlets was essential before attempting further interaction.
To list the commands available within the restricted endpoint, I updated the script and executed it:
The output showed that only a small set of cmdlets, including Get-Command, Get-Help, Select-Object, and Measure-Object, were available. This confirmed that the endpoint was heavily restricted, meaning any subsequent exploitation would have to rely solely on the limited functionality intentionally exposed through the JEA session.
Verifying the JEA Execution Context
After enumerating the available cmdlets, I verified the security context under which commands were executed within the restricted JEA session. This confirmed whether my Kerberos authentication as the managed service account had been successfully applied to the remote PowerShell endpoint.
To execute a simple identity check, I updated the script and ran the following commands:
The script executed successfully and returned pong\pong_gmsa$, confirming that commands were running under the PONG_gMSA$ security context despite the restricted JEA environment. This validated that I had successfully authenticated as the managed service account and could continue interacting with the constrained PowerShell endpoint using its privileges.
Preparing the Encoded PowerShell Payload
To prepare for remote code execution through the restricted JEA session, I generated a Base64-encoded PowerShell payload containing my reverse shell. Encoding the payload in UTF-16LE ensured it would be compatible with PowerShell's -EncodedCommand option while avoiding issues with special characters.
To generate the encoded payload, I ran the following command:
The script produced a Base64-encoded version of the reverse shell, which I later used as a PowerShell EncodedCommand. This allowed me to deliver the payload as a single encoded string, making it suitable for execution through the constrained PowerShell environment.
Executing the Encoded PowerShell Payload
After preparing the Base64-encoded PowerShell payload, I updated my pypsrp script to execute it through the restricted JEA endpoint. This allowed me to leverage the authenticated PSRP session while testing whether the constrained environment would permit the execution of an encoded PowerShell command.
To execute the payload through the restricted endpoint, I modified the script and ran the following commands:
The script authenticated to the restricted JEA endpoint using my Kerberos ticket and invoked the encoded PowerShell command through powershell.exe. If successful, the payload would execute under the PONG_gMSA$ security context, providing the next stage of access while bypassing many of the limitations imposed by the constrained PowerShell session.
Gaining an Interactive PowerShell Shell
With the payload prepared, I started a Netcat listener on my attacking machine and executed the pypsrp script against the restricted JEA endpoint. The goal was to trigger the encoded PowerShell payload and establish an interactive reverse shell over the authenticated PSRP session.
To receive the incoming connection and execute the payload, I ran the following command:
A few moments later, the target connected back to my listener and presented an interactive PowerShell prompt running as Pong_gMSA$.
This confirmed that the encoded payload had executed successfully through the restricted JEA endpoint, giving me an interactive shell under the managed service account's security context.
Enumerating the User's Documents
After obtaining an interactive PowerShell session as Pong_gMSA$, I enumerated the user's home directory to identify any files that could reveal additional information about the restricted JEA configuration. Configuration and capability files are often left behind by administrators and can provide valuable insight for privilege escalation.
To inspect the contents of the user's Documents directory, I ran the following command:
The directory contained both ITAccess.psrc and JEAconfig_backup.pssc, which appeared to be JEA role capability and session configuration files. These files were particularly interesting because they could reveal the commands, permissions, and configuration settings exposed through the restricted PowerShell endpoint.
Enumerating the Security Context
After gaining an interactive shell as Pong_gMSA$, I enumerated the account's privileges and group memberships to understand the permissions available to the managed service account. This step helped me identify any privileges or security groups that could be leveraged during post-exploitation.
To enumerate the current security context, I ran the following commands:
The output confirmed that the account possessed SeMachineAccountPrivilege along with several standard privileges and was a member of the Domain Computers group. This established the security context of the compromised account and provided valuable information for identifying potential privilege escalation or lateral movement opportunities in the next stage of the attack.
Reviewing the JEA Role Capability File
After discovering the JEA configuration files, I examined the ITAccess.psrc role capability file to determine which commands and features were intentionally exposed to users of the restricted endpoint. Understanding these restrictions was essential for identifying any functionality that could still be abused.
To inspect the role capability configuration, I ran the following command:
![Hack The Box Reactor [Easy] Full Walkthrough](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjO0q2PCFR-gN9xuE1MonJYroXANbtRxPcSD-AZUe2NMNcLZ9rby9xLpiqVKRPChWUBgxeOxoqP2_N2rmV7fPlhf-8xQ8oUdde_3g-TDfduqNH35RO8CNfXqtgHYvg3-oXHA3D2oPhDlZi_TGPHc6UvXqo-YoWcm54K0J_yy_ZOsBabtmo6ZIR46Q8z2r2a/s1831/Hack%20The%20Box%20Reactor%20%5BEasy%5D%20Full%20Walkthrough.jpg "Hack The Box Reactor [Easy] Full Walkthrough")
The file revealed that the endpoint exposed only a limited set of cmdlets related to services, event logs, networking, and command history, while enforcing NoLanguage mode. It also restricted Restart-Service to the Spooler and W32Time services, confirming that the JEA session was tightly constrained and that any further exploitation would have to rely on the explicitly permitted functionality.
Reviewing the JEA Session Configuration
After examining the role capability file, I inspected the backup JEA session configuration to understand how the restricted endpoint had been deployed. This allowed me to identify additional security settings that were not visible from the role capability file alone.
To review the session configuration, I ran the following command:
The configuration confirmed that the endpoint used the RestrictedRemoteServer session type, stored transcripts under C:\ProgramData\JEAConfiguration\Transcripts, and, most importantly, enabled RunAsVirtualAccount. This meant that approved commands executed through the JEA endpoint would run under a temporary virtual administrator account, making this configuration a key target for further privilege escalation.
Discovering Credentials from PowerShell History
After enumerating the compromised account, I inspected the PSReadLine history file to review commands previously executed by the user. PowerShell history often contains sensitive information, such as credentials or administrative commands, that can be reused during post-exploitation.
To review the PowerShell command history, I ran the following command:
While reviewing the history, I discovered a command that embedded the plaintext password for pong\c.carlssen inside a PSCredential object. Correlating this with my earlier BloodHound analysis, which showed that C.Carlssen was a member of both Remote Management Users and IT Service Admins, confirmed that the recovered credentials could be used to authenticate as a more privileged user and continue the attack.
Authenticating as C.Carlssen
After recovering C.Carlssen's password from the PowerShell history, I confirmed in BloodHound that the account was a member of both the Remote Management Users and IT Service Admins groups. These memberships suggested that the account was intended for remote administration, making it an ideal candidate for Kerberos authentication.
The TGT request completed successfully and was saved as c.carlssen.ccache, which I exported as my active Kerberos credential cache. With a valid ticket for C.Carlssen, I was ready to authenticate to services in the PONG.HTB domain using Kerberos without repeatedly supplying the recovered password.
Configuring the Kerberos Environment
After obtaining a valid TGT for C.Carlssen, I configured my Kerberos environment to use the correct realm configuration and credential cache. This ensured that all subsequent Kerberos-enabled tools would automatically authenticate as the newly compromised user.
The output confirmed that my custom krb5.conf was loaded from the working directory, while c.carlssen.ccache became the active Kerberos ticket cache. With the environment configured, I could seamlessly authenticate to services in the PONG.HTB domain using Kerberos.
Reviewing the Kerberos Configuration
Before continuing with Kerberos authentication, I reviewed my krb5.conf file to verify that both Active Directory forests were configured correctly. This ensured that Kerberos requests would be directed to the appropriate Domain Controller for each realm.
The configuration mapped PING.HTB to dc1.ping.htb and PONG.HTB to dc2.pong.htb, while also defining the corresponding domain-to-realm mappings. With both realms properly configured, I could seamlessly authenticate and request Kerberos tickets across the trusted domains during the remainder of the attack.
Requesting a Service Ticket for DC2
After switching to the C.Carlssen Kerberos ticket, I attempted to request an HTTP service ticket for dc2.pong.htb. This verified whether my current Kerberos context could directly obtain a service ticket for the PONG Domain Controller.
The request failed with KDC policy rejects request, indicating that the KDC refused to issue the service ticket under the current Kerberos context. This showed that additional authentication or a different Kerberos configuration would be required before I could access HTTP services on dc2.pong.htb.
Authenticating to DC2 via WinRM
After obtaining a valid Kerberos ticket for C.Carlssen, I attempted to authenticate to the PONG Domain Controller over WinRM. This allowed me to verify that the recovered credentials provided interactive remote access to dc2.pong.htb.
The authentication succeeded, and I obtained a PowerShell session as C.Carlssen on dc2.pong.htb. This confirmed that the recovered account had remote management privileges, giving me direct administrative access to the PONG domain for further enumeration and privilege escalation.
Configuring Resource-Based Constrained Delegation
After analyzing the BloodHound graph, I found that C.Carlssen, through membership in IT SERVICE ADMINS, had GenericWrite over several service accounts. Since only svc_sql possessed SQLAdmin rights on DC2 and MachineAccountQuota was set to 0, I reused the previously compromised Pong_gMSA$ account instead of creating a new machine account.
The command successfully configured Resource-Based Constrained Delegation (RBCD) by allowing Pong_gMSA$ to impersonate users when accessing svc_sql via S4U2Proxy. This established the delegation relationship required to leverage the SQL service account's privileges and continue the privilege escalation chain toward full compromise of DC2.
Requesting an S4U Service Ticket
After configuring Resource-Based Constrained Delegation, I switched back to the Pong_gMSA$ Kerberos ticket and used it to impersonate another domain user. My goal was to leverage the delegation rights and obtain a service ticket for the MSSQL service running on dc2.pong.htb.
The S4U2Self and S4U2Proxy requests completed successfully, allowing me to impersonate c.adam and obtain a Kerberos service ticket for mssqlsvc/dc2.pong.htb. This ticket provided authenticated access to the SQL service under the impersonated user's identity, enabling the next stage of the privilege escalation.
Authenticating to Microsoft SQL Server
After obtaining the Kerberos service ticket for c.adam, I used it to authenticate directly to the Microsoft SQL Server instance on dc2.pong.htb. This allowed me to verify that the impersonation attack was successful and that I had access to the SQL service.
The connection succeeded over TLS, and I was dropped into an interactive SQL shell as pong\C.Adam with dbo privileges on the master database. This confirmed that the RBCD attack chain had worked, giving me authenticated access to SQL Server and a platform for further privilege escalation on DC2.
Enabling Command Execution via SQL Server
After gaining access to the SQL Server instance, I enabled the xp_cmdshell stored procedure to execute operating system commands from within SQL Server. I then verified the execution context by running the whoami command.
The command returned pong\svc_sql, confirming that operating system commands were executed under the SQL Server service account. This was a significant step because svc_sql possessed the privileges associated with the SQL service, allowing me to leverage the host directly for the next stage of the privilege escalation.
Enumerating the SQL Service Account Privileges
After confirming that xp_cmdshell executed commands as svc_sql, I enumerated the privileges assigned to the SQL Server service account. This allowed me to identify any Windows privileges that could be leveraged for local privilege escalation.
The output showed that svc_sql possessed SeImpersonatePrivilege, a powerful privilege commonly abused to elevate privileges on Windows systems. Although most other privileges were disabled, the presence of SeImpersonatePrivilege provided a clear path toward obtaining NT AUTHORITY\SYSTEM on DC2.
Preparing the Privilege Escalation Tool
After identifying that svc_sql possessed the SeImpersonatePrivilege, I needed a tool capable of abusing this privilege to obtain NT AUTHORITY\SYSTEM. I visited the official GodPotato release page and downloaded the GodPotato-NET4.exe binary, which is compatible with the .NET Framework installed on the target.
With the appropriate GodPotato binary prepared, I was ready to transfer it to DC2 and leverage SeImpersonatePrivilege to elevate from the svc_sql service account to NT AUTHORITY\SYSTEM.
Transferring the Privilege Escalation Tool
After preparing the privilege escalation binary, I transferred GodPotato-NET4.exe to DC2 using my WinRM session. I then moved it to C:\ProgramData and adjusted its permissions so it could be executed by other security contexts on the system.
The upload completed successfully, and the executable was placed in a shared directory with read and execute permissions granted to Everyone. This ensured that the svc_sql service account could access and execute the binary during the upcoming privilege escalation.
Exploiting SeImpersonatePrivilege with GodPotato
After confirming that svc_sql possessed SeImpersonatePrivilege, I executed GodPotato through xp_cmdshell to elevate from the SQL Server service account to NT AUTHORITY\SYSTEM. Instead of spawning a shell, I used the elevated context to add C.Carlssen directly to the local Administrators group.
The output showed that GodPotato successfully impersonated a SYSTEM token and launched the requested command with elevated privileges. The message "The command completed successfully." confirmed that C.Carlssen had been added to the local Administrators group, providing administrative access to DC2 for the next stage of the attack.
Verifying Local Administrator Access
After exploiting GodPotato, I reconnected to the target and verified that the privilege escalation had completed successfully. I enumerated the local Administrators group to confirm that my user had been added.
The output showed that C.Carlssen was now a member of the local Administrators group alongside the built-in Administrator, Domain Admins, and Enterprise Admins. This confirmed that I had successfully obtained administrative privileges on DC2, allowing me to proceed with full system compromise.
Capturing the User Flag
After obtaining administrative access to DC2, I navigated to C.Carlssen's Desktop to check whether the user flag was accessible. I then listed the directory contents and displayed the contents of the flag file.
The Desktop contained the user.txt flag, confirming that I had successfully compromised the C.Carlssen account. Reading the file completed the user portion of the machine and marked the successful completion of the initial objective before moving on to obtaining the root flag.
Dumping Domain Secrets
After obtaining local administrator privileges on DC2, I authenticated with Kerberos as C.Carlssen and used secretsdump to extract credentials from the Domain Controller. Since the target was a DC, this allowed me to retrieve both local secrets and the contents of the Active Directory database.
The dump completed successfully, revealing the local SAM database, LSA secrets, cached credentials, service account passwords, and the full NTDS.DIT database, including the hashes and Kerberos keys for domain users such as Administrator and krbtgt. With complete access to the domain's credential material, I had effectively achieved full compromise of the PONG.HTB Active Directory environment.
Authenticating with the Extracted AES Key
After dumping the domain credentials, I used the recovered AES-256 Kerberos key for R.Martinelli to request a Ticket Granting Ticket (TGT). This allowed me to authenticate without knowing the user's plaintext password.
The request succeeded, and a valid Kerberos TGT was saved in r.martinelli.ccache. Verifying the cache with klist confirmed that I had successfully authenticated as R.Martinelli, enabling me to access domain services using Kerberos under the context of the compromised account.
Configuring the Kerberos Environment
After obtaining a TGT for R.Martinelli, I configured my Kerberos environment to use the new ticket cache and verified that both the Kerberos configuration file and credential cache were correctly loaded. I also reviewed the realm configuration to ensure authentication requests would be routed to the appropriate Domain Controllers.
The output confirmed that the correct configuration file and ticket cache were in use, with both PING.HTB and PONG.HTB realms properly defined. With the Kerberos environment configured, I was ready to authenticate to domain services as R.Martinelli using the cached TGT.
Requesting a Cross-Realm LDAP Service Ticket
After verifying that my Kerberos TGT for R.Martinelli was loaded, I requested a service ticket for the LDAP service on dc1.ping.htb. This tested whether the compromised account could successfully authenticate across the trust relationship between the PONG.HTB and PING.HTB domains.
The kvno request completed successfully and returned a valid service ticket for the LDAP service in the trusted domain. This confirmed that cross-realm Kerberos authentication was working correctly, allowing me to interact with Active Directory services in PING.HTB using the credentials of R.Martinelli.
Verifying Cross-Realm Kerberos Authentication
After requesting the LDAP service ticket, I verified that the Kerberos cache had been updated with the newly issued tickets. I enumerated the cache contents to confirm that authentication across the trust relationship had completed successfully.
The cache now contained the original TGT for PONG.HTB, a cross-realm TGT for PING.HTB, and an LDAP service ticket for dc1.ping.htb. This confirmed that cross-domain Kerberos authentication was functioning correctly, allowing me to access LDAP services in the trusted PING.HTB domain as R.Martinelli.
Confirming the Cross-Realm Service Tickets
After requesting the LDAP service ticket, I repeated the request using the active Kerberos cache and then enumerated the cached tickets to verify that the cross-realm authentication process had completed successfully. This confirmed that my Kerberos configuration and ticket cache were working as expected.
The cache contained the original TGT for PONG.HTB, a cross-realm TGT for PING.HTB, and the LDAP service ticket for dc1.ping.htb. This verified that Kerberos authentication across the trust relationship was fully established, allowing me to authenticate to services in the PING.HTB domain as R.Martinelli.
Modifying the Certificate Template Configuration
After establishing cross-domain access as R.Martinelli, I modified the SmartcardAuthentication certificate template using bloodyAD. I updated the msPKI-Certificate-Name-Flag attribute to enable a certificate enrollment configuration required for the next stage of the attack.
The command completed successfully, confirming that the certificate template had been updated in Active Directory. This change weakened the template's enrollment restrictions, preparing it for abuse in the subsequent certificate-based privilege escalation steps.
Granting GenericAll on the Certificate Template
After modifying the certificate template, I further weakened its security by granting the Authenticated Users group (S-1-5-11) GenericAll permissions over the SmartcardAuthentication template. This ensured that any authenticated domain user could fully control the template's configuration.
GenericAll permissions had been assigned to Authenticated Users. With full control delegated to all authenticated accounts, the certificate template was ready to be abused for certificate-based privilege escalation.Requesting an Administrator Certificate
After weakening the SmartcardAuthentication certificate template, I authenticated with Kerberos as C.Roberts and requested a certificate on behalf of the Administrator account. I specified the Administrator's UPN and SID to obtain a certificate that could later be used for Kerberos authentication.
Administrator@ping.htb, saving both the certificate and private key as administrator.pfx. This provided everything needed to authenticate as the domain Administrator using certificate-based Kerberos authentication.Authenticating as the Domain Administrator
After obtaining the forged Administrator certificate, I authenticated to the domain using Certipy and requested a Kerberos Ticket Granting Ticket (TGT). I then verified the issued ticket to confirm that I had successfully assumed the identity of the Administrator account.
administrator@PING.HTB and recovering the account's NT hash. With a cached Kerberos ticket for the domain Administrator, I had achieved full administrative access to the PING.HTB domain and could authenticate to domain services without requiring the account's password.Authenticating to DC1 as Administrator
After obtaining a Kerberos TGT for the Administrator account, I configured Evil-WinRM to use the cached ticket and authenticated to DC1 over WinRM. This allowed me to access the target without providing a password or NTLM hash.
Administrator on DC1. This confirmed full administrative compromise of the PING.HTB domain and provided unrestricted access to the Domain Controller for the final stage of the attack.Capturing the Root Flag
After authenticating to DC1 as the domain Administrator, I verified my security context and navigated to the Administrator's Desktop. I then enumerated the directory contents and displayed the contents of the root flag.
ping\administrator, and the root.txt flag was present on the Administrator's Desktop. Reading the flag completed the machine and confirmed full compromise of both the PING.HTB and PONG.HTB Active Directory environments.Keywords:
ping.htb
pong.htb
dc1.ping.htb
dc2.pong.htb
pingpong.htb
PingPong - HackTheBox Walkthrough
PingPong - HackTheBox Writeup
I just solved PingPong from Hack the Box
Pingpong htb machine user flag hint
pingpong hack the box machine season 11 root flag hint
pingpong htb writeup
pingpong htb walkthrough
pingpong hack the box writeup
0 Comments