I recently completed the Pirate machine on Hack The Box, a hard-difficulty Windows Active Directory challenge that required chaining together multiple AD attack paths, credential abuse techniques, and network pivoting to achieve full domain compromise.
About the Machine
Pirate is a hard difficulty Windows machine on Hack The Box that focuses on advanced Active Directory abuse, including machine account takeover, gMSA credential extraction, NTLM relay, and Kerberos delegation attacks. The machine demonstrates how chaining multiple AD misconfigurations can ultimately lead to full domain compromise.
The attack begins with Nmap enumeration, where I identified a domain controller exposing typical AD services such as SMB, LDAP, Kerberos, and WinRM. I performed SMB authentication to validate access and configured my environment through host configuration, followed by proper Kerberos configuration and time synchronization to ensure ticket-based attacks would function correctly.
I then collected domain data using BloodHound enumeration and performed BloodHound analysis, which revealed attack paths involving delegation and machine account privileges. Although I attempted Kerberoasting, the more viable path involved abusing machine accounts.
Next, I set up pre2k for pre2k enumeration, which allowed me to discover valid machine account credentials. Using these, I performed SMB authentication (machine account) but encountered restrictions, prompting me to abuse the account by resetting its password (machine account abuse) and successfully taking control of it (machine account takeover).
With this access, I deployed gMSADumper and performed gMSA credential dumping, extracting hashes for managed service accounts. I then used these credentials for SMB authentication (gMSA account) and gained WinRM access (gMSA account), establishing a foothold on the system.
From there, I conducted network enumeration and identified an internal subnet. Through internal network enumeration, I discovered an additional host that was not externally accessible. To reach it, I prepared for pivoting by setting up Chisel (pivot preparation) on both Linux and Windows, then established a reverse SOCKS tunnel (pivoting).
Using this tunnel, I performed Nmap enumeration (pivoted network) and gained WinRM access (pivoted host), confirming access with SMB enumeration (pivoted host). At this stage, I launched an NTLM relay attack, combined with authentication coercion, successfully relaying machine account authentication to LDAP.
This allowed me to create a new machine account and configure delegation rights, leading to Kerberos delegation abuse. Using S4U techniques, I impersonated the Administrator account and achieved privilege escalation (SYSTEM via Kerberos).
To solidify access, I updated host configuration (internal mapping) and performed credential dumping (secrets extraction), which revealed additional credentials including plaintext passwords. I then abused these through Active Directory abuse, including password resets and SPN manipulation, enabling another round of Kerberos delegation abuse.
Finally, I leveraged Kerberos ticket usage to authenticate as Administrator against the domain controller. This resulted in full domain controller compromise, where I obtained a SYSTEM shell and retrieved the root flag.
Overall, Pirate is an excellent example of a complex, real-world Active Directory attack chain, combining machine account abuse, gMSA extraction, NTLM relay, coercion, pivoting, and Kerberos delegation to achieve complete domain dominance.
The first step in owning the Pirate 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 Interpreter machine and I was assigned an IP address (10.129.27.101).
Nmap Enumeration
I began by running an aggressive Nmap scan to identify open ports, services, and potential attack surfaces on the target host. This helped me understand the environment before attempting any interaction.
The scan revealed multiple critical services including Kerberos (88), LDAP (389/636/3268/3269), SMB (445), and WinRM (5985), strongly indicating this is a Domain Controller (DC01.pirate.htb) in an Active Directory environment. DNS (53) and RPC services were also exposed, supporting domain operations. IIS on port 80 showed the TRACE method enabled, which could be worth further testing. SMB signing is enforced, limiting relay attacks, while the presence of Kerberos and LDAP opens the door for AD-focused enumeration and attacks like Kerberoasting or AS-REP roasting.
SMB Authentication
After identifying SMB during enumeration, I attempted to authenticate using the provided domain credentials to validate access against the target system.
The authentication was successful, confirming that the credentials pentest:p3nt3st2025!& are valid on the domain pirate.htb. The target is a Windows Server 2019 Domain Controller (DC01) with SMB signing enforced and SMBv1 disabled, indicating a relatively hardened setup. With valid credentials, I can now proceed with deeper SMB enumeration, such as listing shares, users, and potentially accessing sensitive files.
Host Configuration
After gaining initial access, I configured my local /etc/hosts file to ensure proper hostname resolution within the domain environment. This allows tools to interact with services using their fully qualified domain names instead of raw IP addresses.
By mapping these hostnames, I aligned my attack machine with the internal DNS structure of the domain. This is especially important for Kerberos-based authentication and Active Directory interactions, which rely heavily on correct hostname resolution. It also simplifies further enumeration and lateral movement across systems like DC01 and WEB01.
Kerberos Configuration
To proceed with Kerberos-based attacks, I configured my system to properly communicate with the domain’s Key Distribution Center (KDC). This ensures my machine can request and use Kerberos tickets within the target environment.
I updated the configuration to define the realm PIRATE.HTB and pointed both the KDC and admin server to the Domain Controller (10.129.27.101). I also mapped the domain pirate.htb to the Kerberos realm, ensuring proper ticket resolution. With this setup in place, I can now perform Kerberos authentication and attacks such as ticket requests, Kerberoasting, and delegation abuse.
BloodHound Enumeration
With valid domain credentials, I proceeded to enumerate the Active Directory environment using BloodHound to map relationships, permissions, and potential attack paths.
The tool initially attempted Kerberos authentication but failed due to connectivity issues on port 88, so it automatically fell back to NTLM. Despite this, enumeration was successful, revealing domain structure including users, groups, computers, and GPOs. I identified key assets such as DC01 and WEB01, along with 10 users and 54 groups. The collected data was packaged into a .zip file, ready for analysis in BloodHound to uncover privilege escalation paths.
BloodHound Analysis
After collecting the BloodHound data, I imported the .zip file into the interface to visually map out relationships, permissions, and potential attack paths within the domain.
From the graph analysis, I identified multiple interesting attack vectors within the pirate.htb domain. Several Kerberoastable accounts were present, indicating service accounts that could potentially be cracked offline. Notably, the GMSA_ADFS_PROD and GMSA_ADCS_PROD accounts were members of the Remote Management Users group, suggesting possible remote access via WinRM.
I also observed that A.WHITE_ADM had delegation rights over WEB01, which could be abused for lateral movement or impersonation attacks. Additionally, MS01 being part of the Pre-Windows 2000 Compatible Access group hinted at overly permissive legacy configurations that may expose sensitive information.
More importantly, several ACL relationships such as GenericWrite, WriteDACL, and AddKeyCredentialLink were visible, indicating potential privilege escalation paths. These misconfigurations suggest weak access controls and possibly default or poorly managed credentials, giving me a clear direction to pivot further into the domain.
Time Synchronization
Before proceeding with Kerberos-based attacks, I ensured my system time was synchronized with the Domain Controller to avoid authentication issues caused by clock skew.
The output showed a significant time difference (~7 hours), which was corrected by syncing directly with the DC. This step is critical because Kerberos relies on accurate timestamps, and even small mismatches can cause ticket requests to fail. With my system now aligned to the domain time, I was able to proceed with Kerberos authentication and related attacks without errors.
Kerberoasting
With Kerberos properly configured and valid credentials, I attempted to enumerate Service Principal Names (SPNs) to identify accounts vulnerable to Kerberoasting.
The output revealed a service account a.white_adm associated with the SPN ADFS/a.white, indicating it is Kerberoastable. I successfully requested a service ticket (TGS), which was returned as a crackable hash. This hash can now be taken offline and brute-forced to recover the plaintext password. Additionally, the account has constrained delegation enabled, making it even more valuable for potential lateral movement or privilege escalation once compromised.
Hash Cracking Attempt
After obtaining the Kerberos TGS hash, I saved it into a file and attempted to crack it offline using Hashcat with the rockyou wordlist.
However, Hashcat returned a “Separator unmatched” error, meaning the hash format in the file was incorrect or improperly pasted. As a result, no hashes were loaded for cracking. This typically happens when extra spaces, line breaks, or missing $ separators corrupt the hash format. After fixing the formatting, the hash was reloaded and again the hash cracking attempt failed.
Tool Setup (pre2k)
As I progressed further into Active Directory abuse, I needed a specialized tool to target pre-Windows 2000 misconfigurations identified earlier in BloodHound. To achieve this, I cloned and set up the pre2k tool in an isolated Python environment.
The repository was successfully cloned, and I created a virtual environment to avoid conflicts with system-wide Python packages. After activating the environment, I installed the tool along with its dependencies, including Impacket, ldap3, and other required libraries.
During installation, several packages were compiled and built locally, confirming that the environment was properly configured. The process completed without errors, indicating that pre2k is now ready for use.
This setup is particularly useful for exploiting legacy AD configurations such as Pre-Windows 2000 Compatible Access, which I had already identified in BloodHound. These misconfigurations often expose weak permissions or allow enumeration of sensitive domain data.
With the tool installed and environment prepared, I am now positioned to leverage these weaknesses for further enumeration or potential privilege escalation within the domain.
Pre2K Enumeration
After setting up the tool, I leveraged pre2k to test authentication against legacy configurations and identify weak or default credentials within the domain.
The tool successfully returned valid credentials for two machine accounts: MS01$ and EXCH01$, both using predictable default-style passwords. This confirms the presence of weak configurations tied to Pre-Windows 2000 Compatible Access. Machine accounts with such credentials can often be abused for further enumeration or lateral movement. This discovery provided me with additional footholds in the domain, expanding my attack surface beyond the initial user account.
SMB Authentication (Machine Account)
After discovering valid machine account credentials, I attempted to authenticate to SMB using the MS01$ account to verify its usability.
Although the credentials were valid, authentication failed with STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT, indicating this is a machine account restricted to domain-level operations. Such accounts cannot be used for interactive logins like SMB sessions. This behavior is expected, as machine accounts are primarily used for authentication between systems. Despite this limitation, the credentials may still be useful for other attack vectors such as Kerberos abuse or LDAP-based enumeration.
Machine Account Abuse
After confirming the machine account credentials, I attempted to abuse them by changing the account password using Impacket’s RPC functionality.
The operation succeeded, indicating that the MS01$ account had permission to modify its own password via SAMR. This is a common behavior for machine accounts but can be abused if weak credentials are known. By resetting the password, I now have full control over the machine account, allowing me to reliably authenticate using my chosen credentials. This opens up further attack paths such as Kerberos abuse, service ticket requests, or leveraging the account for lateral movement.
SMB Authentication (Machine Account Takeover)
After resetting the machine account password, I attempted to authenticate again using the new credentials to confirm control over the account.
This time, authentication was successful, confirming that the password change took effect. I now have working credentials for the MS01$ machine account under my control. Unlike before, I can reliably authenticate and leverage this account for further domain interactions. This foothold can now be used for deeper enumeration, Kerberos-based attacks, or potential privilege escalation paths within the Active Directory environment.
Tool Setup (gMSADumper)
With control over a machine account, I prepared to target Group Managed Service Accounts (gMSA) by setting up a tool designed to dump their passwords from Active Directory.
The repository was successfully cloned, and I verified the presence of the main script along with its dependencies. This tool is used to extract gMSA passwords when the current account has the required permissions. Since gMSAs were identified earlier in BloodHound, this step sets up the next phase of exploitation. With the tool ready, I can now attempt to retrieve plaintext credentials for high-value service accounts.
gMSA Credential Dumping
With control over the MS01$ machine account, I attempted to dump passwords for Group Managed Service Accounts (gMSAs) using the prepared tool.
The dump was successful, revealing credentials for both gMSA_ADCS_prod$ and gMSA_ADFS_prod$, including NTLM and AES keys. This confirms that MS01$ has permission to read gMSA passwords via the Domain Secure Servers group. These accounts are highly valuable as they often have elevated privileges and service-level access. With these hashes, I can now authenticate as these service accounts or leverage them for Kerberos-based attacks and further lateral movement within the domain.
SMB Authentication (gMSA Account)
After extracting the gMSA credentials, I attempted to authenticate to SMB using the NTLM hash of the GMSA_ADFS_PROD$ account to validate access.
The authentication was successful, confirming that the dumped NTLM hash is valid for the GMSA_ADFS_PROD$ account. This demonstrates a successful pass-the-hash attack using a high-value service account. Since gMSA accounts often have elevated privileges, this foothold significantly increases my access within the domain. With valid authentication confirmed, I can now proceed with deeper enumeration, remote access, or privilege escalation using this account.
WinRM Access (gMSA Account)
With confirmed SMB access using the gMSA account, I attempted to gain remote command execution via WinRM using a pass-the-hash technique.
The connection was successfully established, granting me an interactive PowerShell session as gMSA_ADFS_PROD$ on the Domain Controller. This confirms that the account has remote management privileges, aligning with earlier BloodHound findings. Gaining shell access on a DC with a service account is a significant escalation point. From here, I can begin local enumeration, search for sensitive files, and look for privilege escalation paths within the domain.
Network Enumeration
After gaining a WinRM shell on the Domain Controller, I enumerated the network configuration to understand internal routing and identify additional reachable subnets.
The output revealed two interfaces: one on the external HTB network (10.129.27.101) and another internal interface (192.168.100.1) connected to a virtual switch. This indicates the host is dual-homed, likely bridging into an internal network segment. The absence of a gateway on the internal interface suggests it is used for local communication within that subnet. This discovery is valuable, as it confirms potential pivoting opportunities toward internal hosts such as WEB01 (192.168.100.2).
Internal Network Enumeration
After identifying the internal subnet, I performed a quick sweep from the compromised host to discover other reachable systems within the 192.168.100.0/24 network.
The scan revealed two active hosts: 192.168.100.1 (the current machine) and 192.168.100.2, which aligns with the previously identified WEB01 system. All other addresses timed out, indicating no additional reachable hosts in this subnet. This confirms a limited internal network, making WEB01 the primary pivot target. With this information, I can now focus on lateral movement toward that host.
Pivot Preparation (Chisel Setup)
After discovering an internal network, I prepared for pivoting by downloading a tunneling tool to route traffic through the compromised host. This would allow me to reach internal systems that are not directly accessible from my attacker machine.
Once downloaded, I verified the file was present in my working directory alongside other tools and artifacts.
I then decompressed the binary to make it usable.
To simplify usage, I renamed the binary to chisel.
Finally, I made the binary executable so it could be run on the system.
With Chisel fully prepared, I now have a reliable tool for tunneling traffic through the compromised host. This will allow me to pivot into the internal 192.168.100.0/24 network and interact with systems like WEB01, which are otherwise unreachable externally.
Pivot Preparation (Windows Chisel)
To support pivoting from the compromised Windows host, I downloaded the Windows version of Chisel so it can be executed directly on the target system.
After downloading, I extracted the archive to obtain the executable.
I then verified that the binary was successfully extracted and available for transfer.
The presence of chisel.exe confirms the setup is complete on my attacker machine. This binary can now be uploaded to the compromised host and used to establish a reverse tunnel. With both Linux and Windows versions prepared, I am ready to pivot into the internal network and reach systems like WEB01.
Pivoting (Chisel Tunnel Setup)
With both Linux and Windows versions of Chisel prepared, I set up a pivoting channel to access the internal network through the compromised Domain Controller. First, I hosted the chisel.exe binary on my attacker machine for easy transfer.
From the WinRM shell, I downloaded the binary onto the target system using PowerShell.
Back on my Kali machine, I started a Chisel server in reverse mode to accept incoming connections from the compromised host.
The server successfully initialized, enabling reverse tunneling and listening for incoming sessions.
From the compromised machine, I executed the Chisel client to establish a reverse SOCKS proxy back to my attacker machine.
The connection was successfully established, creating a SOCKS proxy on my local machine (127.0.0.1:1080). This effectively routes traffic through the Domain Controller into the internal network.
With this tunnel in place, I can now proxy tools like proxychains, Nmap, or SMB clients through the compromised host, allowing me to interact with internal systems such as WEB01 (192.168.100.2). This marks a critical pivot point, enabling deeper lateral movement within the isolated network segment.
Nmap Enumeration (Pivoted Network)
After establishing the SOCKS tunnel with Chisel, I routed my traffic through the compromised host to enumerate the internal machine 192.168.100.2. This allowed me to scan a system that is otherwise unreachable externally.
The scan identified the host as RODC01.garfield.htb, suggesting it is a Read-Only Domain Controller within the internal network. However, all scanned ports appeared as filtered, indicating that traffic is being blocked or restricted, likely by a host-based firewall.
This behavior is common when pivoting through a SOCKS proxy, as certain scan techniques (like SYN scans) are not fully supported and may produce limited results. Additionally, internal firewall rules may restrict access to specific services, even from domain-joined systems.
Despite the lack of visible open ports, the host is confirmed alive and reachable through the tunnel. This validates that my pivot is working correctly and that I can interact with internal systems.
At this stage, instead of relying solely on Nmap, I would shift to application-level enumeration (e.g., SMB, WinRM, or LDAP tools via proxychains) to bypass these limitations and identify accessible services on RODC01.
WinRM Access (Pivoted Host)
After confirming connectivity through the SOCKS tunnel, I attempted remote access to the internal host using the previously obtained gMSA credentials via proxychains.
The connection was successfully established through the proxy (127.0.0.1:1080 → 192.168.100.2:5985), confirming that my pivot was working as intended. Once inside, I verified the system identity and discovered the host is WEB01, not RODC01 as previously assumed.
This demonstrates that WinRM is accessible internally even though Nmap showed filtered ports, highlighting the limitations of proxy-based scanning. With an interactive shell on WEB01, I now have a foothold on a second internal system, opening the door for further enumeration and potential privilege escalation.
SMB Enumeration (Pivoted Host)
After gaining WinRM access to the internal system, I further validated my access by authenticating to SMB on WEB01 through the SOCKS tunnel.
The authentication was successful, confirming that the gMSA_ADFS_PROD$ account has valid access on WEB01. Notably, SMB signing is disabled on this host, which could open the door for relay-style attacks under the right conditions.
This also reinforces that my pivot is fully functional, allowing seamless interaction with internal services. With authenticated SMB access, I can now proceed to enumerate shares, users, and potentially sensitive data on WEB01, further expanding my foothold within the environment.
NTLM Relay Attack
With internal access established, I set up ntlmrelayx to relay incoming authentication to LDAP and attempt privilege escalation via delegation abuse.
The attack successfully relayed authentication from WEB01$ to the Domain Controller over LDAPS. Using this access, the tool created a new machine account TNDNSFRT$ with a controlled password. It then modified delegation settings, granting this new account the ability to impersonate users on WEB01 via S4U2Proxy.
This is a critical escalation step, as it allows me to act on behalf of other users (including potentially privileged ones) when accessing services on WEB01. With delegation rights in place, I can now move toward impersonation attacks and further privilege escalation within the domain.
Authentication Coercion
To trigger the NTLM relay path, I installed Coercer and used it to force WEB01 to authenticate back to my attacker machine through the pivot.
After installation, I launched Coercer through proxychains using the gMSA hash for authentication against the internal host.
The tool successfully reached WEB01 over the Chisel SOCKS tunnel and discovered multiple accessible RPC endpoints and named pipes, including eventlog, lsarpc, lsass, netlogon, samr, and spoolss.
Several coercion attempts returned responses like ERROR_BAD_NETPATH, which is useful because it indicates the target attempted to reach my listener path. Other methods returned ACCESS_DENIED or NO_AUTH_RECEIVED, showing that not every coercion method was usable.
Overall, this confirmed that WEB01 exposed multiple RPC interfaces that could be abused for authentication coercion. This step was important because it helped generate the inbound machine authentication needed for the NTLM relay attack against LDAP/LDAPS on the Domain Controller.
Kerberos Delegation Abuse
After successfully configuring delegation rights for the newly created machine account, I requested a service ticket to impersonate Administrator against the CIFS service on WEB01.
The request completed successfully by first obtaining a TGT for TNDNSFRT$, then performing S4U2Self to impersonate Administrator, followed by S4U2Proxy to request access to cifs/web01.pirate.htb.
The resulting Kerberos ticket was saved as Administrator@cifs_web01.pirate.htb@PIRATE.HTB.ccache. This means I now have a valid service ticket that allows me to access WEB01’s CIFS/SMB service as Administrator.
This is a major privilege escalation step because the relayed delegation abuse allowed a controlled machine account to impersonate a privileged user on WEB01. From here, I can export the ticket and use Kerberos authentication to access administrative shares or retrieve sensitive files from the host.
Privilege Escalation (SYSTEM via Kerberos)
After obtaining the forged service ticket, I configured my environment to use it for Kerberos authentication and attempted remote code execution on WEB01.
Using the cached ticket, I executed psexec over the pivot to gain a shell without supplying credentials.
The attack succeeded, allowing me to access the ADMIN$ share, upload a payload, and create a service remotely. Once executed, I obtained a shell as NT AUTHORITY\SYSTEM, confirming full compromise of WEB01.
This final step demonstrates successful abuse of Kerberos delegation, where I escalated privileges from a controlled machine account to full SYSTEM access on an internal host.
User Flag (Post-Exploitation)
After gaining SYSTEM-level access on WEB01, I navigated through the filesystem to locate user-specific data and retrieve the flag.
The whoami command confirmed I was running as NT AUTHORITY\SYSTEM, giving me full control over the machine. I then moved into the a.white user’s Desktop directory, where the user flag is typically stored. Successfully reading the file revealed the user flag, confirming complete compromise of the user-level objective on this host.
Host Configuration (Internal Mapping)
After gaining access to the internal network and identifying WEB01, I ensured proper name resolution from my attacker machine by manually updating my /etc/hosts file.
This entry maps the internal IP 192.168.100.2 to its corresponding hostname web01.pirate.htb, aligning with the domain structure discovered earlier.
In Active Directory environments, correct hostname resolution is critical, especially for Kerberos-based authentication, which relies on Service Principal Names (SPNs). Without this mapping, tools like impacket, evil-winrm, or psexec may fail or behave inconsistently.
By adding this entry, I ensured seamless communication with WEB01 using its fully qualified domain name rather than relying on raw IP addresses. This also improves reliability when performing ticket-based attacks, SMB interactions, and lateral movement.
With this configuration in place, I can now consistently target WEB01 using domain-aware tools, maintaining stability in my attack chain as I continue post-exploitation activities.
Credential Dumping (Secrets Extraction)
With SYSTEM-level access and a valid Kerberos ticket already loaded, I moved to dump credentials from the compromised host using secretsdump in pass-the-ticket mode.
The tool successfully authenticated using the Kerberos ticket and remotely started the RemoteRegistry service to extract sensitive data. I was able to dump local SAM hashes, including the Administrator NTLM hash, as well as cached domain credentials (DCC2). More importantly, LSA secrets revealed high-value data such as the machine account hash, DPAPI keys, and even a plaintext credential for a.white.
This step significantly escalated my foothold, as I now had multiple reusable credentials and secrets for further lateral movement or privilege escalation. At this stage, the domain is essentially compromised, with enough material to pivot, crack passwords, or access additional systems.
Active Directory Abuse
With the plaintext credentials for a.white recovered earlier, I authenticated against the domain controller and attempted to abuse account privileges.
a.white had sufficient privileges to reset another user’s password. I effectively took control of the a.white_adm account by assigning a known password.This demonstrated a clear privilege escalation path through delegated rights within Active Directory.
Active Directory Abuse
After taking control of the a.white_adm account, I authenticated to the domain and began abusing its privileges to manipulate Service Principal Names (SPNs).
HTTP/WEB01.pirate.htb) on both WEB01$ and DC01$. This is a critical misconfiguration, as it allows me to influence Kerberos authentication flows tied to these services. By controlling SPNs, I set the stage for further Kerberos abuse, such as ticket impersonation or delegation attacks. At this point, I was actively shaping the domain’s authentication mechanisms to escalate privileges even further.
Kerberos Delegation Abuse
With control over the modified SPNs, I authenticated as a.white_adm and attempted to abuse Kerberos delegation to impersonate a privileged user.
The request completed successfully, indicating that I was able to impersonate the Administrator account via S4U2Self and S4U2Proxy. I then switched the service ticket from HTTP to CIFS on DC01, effectively granting access to file services as Administrator. The generated .ccache ticket confirms a successful delegation abuse scenario.
At this point, I had forged a Kerberos ticket for a domain admin against the domain controller, achieving full domain compromise.
Kerberos Ticket Usage
After generating the forged Kerberos ticket, I prepared my environment to use it for authenticated access against the domain controller.
Domain Controller Compromise
With the forged Kerberos ticket loaded, I authenticated as Administrator and executed remote commands on the domain controller using PsExec.
I navigated through the filesystem to the Administrator’s Desktop to locate the final flag. After enumerating the directories, I found root.txt and displayed its contents.
Successfully retrieving the root flag marked the completion of the attack chain.
If you enjoy reading my walkthrough, do not forget to like, comment, and subscribe to my YouTube channel and also connect with me on LinkedIn. Also, don't forget to turn on post notification on my YouTube channel and Medium to get notification as soon as I write.
Subscribe to my YouTube channel and Follow me on: LinkedIn | Medium | Twitter | Boltech Twitter | Buy Me a Coffee
Found this walkthrough helpful? Buying me a coffee helps power the late nights spent writing technical walkthroughs and keeping them free for everyone ☕
Keywords:
pirate.htb
pirate hackthebox
pirate htb write up
pirate htb walkthrough
pirate htb season 10 machine write up
hackthebox pirate machine season 10
pirate hack the box write up
pirate hack the box walkthrough
pirate htb hard machine complete solution
dc01.pirate.htb Pirate HTB Season 10 machine pdf walkthrough
pirate user flag htb season 10
HTB Season 10 machine walkthroughs Pirate.htb
logging.htb
logging hackthebox machine solution
logging htb write up
logging htb walkthrough
logging hack the box write up
hackthebox logging HTB machine complete solution pdf
Logging HTB Season 10 Hack the Box Machine Walkthrough Write Up
Silentium HTB Solution
silentium.htb
Silentium Hack the Box Write Up
Silentium htb walkthrough
Silentium Hack the Box Walkthrough
PingPong HTB Machine Solution
HTB boxes
pingpong hackthebox season 10 HTB
PingPong HTB Write Up
pingpong htb writeup
pingpong hack the box write up
pingpong hack the box walkthrough
pingpong htb machine root flag
pingpong htb machine user flag
pirate htb machine root flag
garfield.htb
garfield hackthebox season 10 solved
garfield htb write up
garfield htb walkthrough
garfield hack the box walkthrough
devarea.htb
devarea hackthebox machine HTB season 10
devarea htb write up
devarea htb walkthrough
hackthebox devarea complete pdf solution
0 Comments