Checkpoint HTB

CHECKPOINT HTB Checkpoint is a Windows Active Directory machine that starts with valid domain credentials and requires careful enumeration of AD permissions rather than traditional exploitation. By identifying a deleted user object that could be restored, we gain access to a writable SMB share used for distributing VS Code extensions. Uploading a malicious extension results in code execution as another domain user. From there, Kerberos abuse and the newly introduced dMSA (Delegated Managed Service Account) attack path are used to impersonate a service account and access VM backup files. Finally, memory forensics with Volatility reveals the Administrator NTLM hash, leading to full domain compromise. Attack Overview Enumeration Nmap Scanning Starting with a full Nmap scan against the target. Nmap Analysis The scan reveals a typical Active Directory environment. | Port | Service | |--------|---------| | 53 | DNS | | 88 | Kerberos | | 389 | LDAP | | 445 | SMB | | 5985 | WinRM | The LDAP banner also reveals the domain name: Additionally, the machine appears to be a Domain Controller: Initial Credentials Unlike most HTB machines, this box provides us with a valid set of credentials from the start. Adding the Domain to Hosts Adding the discovered hostnames to /etc/hosts: SMB Enumeration Using the provided credentials to enumerate SMB. Initially, I received a NetBIOS timeout error. This was caused by clock skew issues, so after correcting the time synchronization I reran the command. One share immediately stands out: The description is particularly interesting: At this stage I made a mental note of it because it looked like it might become important later. Kerberos Setup To make Kerberos-based tools easier to use, I generated a krb5.conf file using NetExec. Moving the configuration into place: Obtaining a TGT Requesting a Kerberos Ticket Granting Ticket (TGT): Exporting the ticket: Everything looks good. BloodHound Collection Next, I collected BloodHound data using BloodyAD. After importing the ZIP file into BloodHound, nothing particularly useful stood out. Since BloodHound didn't reveal an obvious attack path, I switched back to manual enumeration. Looking for Writable Objects BloodyAD has a useful function that identifies objects writable by the current user. One entry immediately caught my attention: Interestingly, the object was located inside: which means the user account had been deleted. Restoring Mark Davies Since we have permissions over the deleted object, I attempted to restore it. Output: Success. The user account is now active again. Testing the Restored Account I initially attempted to reset the password but ran into permission issues. Out of curiosity, I tried logging in using Alex Turner's password. Interesting. The restored account is using the exact same password. We now have access as: Enumerating Shares as Mark Davies Checking SMB access again: This time the permissions are different. Most importantly: Remember the description from earlier: Code extensions share for approved .vsix packages compatible with VS Code engine 1.118.0 Now that we have write access to this share, that description suddenly becomes very interesting. Abusing the VS Code Extension Workflow While looking at the DevDrop share, the description kept standing out: Since mark.davies has both READ and WRITE permissions on this share, it strongly suggests that someone or something is automatically reviewing, approving, or installing VS Code extensions uploaded here. At this point, the obvious idea was: I had never created a VS Code extension before, so I spent some time reading about how they work and used AI to help me understand the required structure. Reference: https://dev.to/anupam_kumar/hack-the-editor-craft-your-custom-vs-code-extension-like-a-pro-4dp5 Creating the Extension Creating the project directory: Creating package.json The first file required by every extension is package.json. The extension simply launches a PowerShell reverse shell when activated. My directory structure looked like this: Screenshot 2026-06-15 at 01-39-54 Expected structure: Screenshot 2026-06-15 at 01-40-21 Installing VSCE To package the extension into a .vsix file, install Microsoft's VS Code Extension Manager. Packaging the Extension Generating the extension package: Output: The generated extension is: Uploading the Extension Before uploading the extension, start a listener. Use the same port that was embedded inside the PowerShell payload. Next, connect to the SMB share as mark.davies. Uploading the extension: Awesome. At this point there is nothing else to do except wait and see whether the extension gets processed. Shell as Ryan Brooks Checking the listener a few moments later: Success. The extension was automatically executed and our PowerShell payload ran under the context of: This confirms that the uploaded VS Code extension was processed by a user who had VS Code installed and opened the extension package. User Flag Privilege Escalation to Administrator Earlier, while reviewing the BloodHound data, I marked ryan.brooks as owned and checked the outbound object control. An interesting relationship immediately appeared: Screenshot 2026-06-15 at 01-46-40 BloodHound revealed that: Initially I tried a few traditional GenericWrite abuse techniques, but none of them worked. Since we already had code execution as ryan.brooks, I decided to enumerate the account further using Kerberos-based tooling. Obtaining a TGT for Ryan Brooks To work with Kerberos tickets more easily, I uploaded Rubeus to the target. Running tgtdeleg: Awesome. We now have a Kerberos ticket for: Copying the Base64 blob back to Kali and saving it as: Now convert it to proper kiribi tikcet Converting the Ticket Converting the ticket into ccache format: Exporting the ticket and verfying it : Everything looks good. Enumerating Writable Objects Now let's see what objects ryan.brooks can control. Two entries immediately stood out: At this point I wasn't very familiar with dMSA abuse, so I spent some time researching it. The DMSAHolder OU is used to store delegated Managed Service Accounts (dMSAs), and the combination of: looked very suspicious. Enumerating DMSAHolder Before abusing anything, I wanted to inspect the OU. The output itself isn't particularly exciting, but it confirms that: Combined with the ability to modify svc_deploy, this is exactly what the BloodyAD badSuccessor module abuses. Abusing badSuccessor After some research, I found that BloodyAD provides a helper module specifically for this attack. Running: Awesome. The attack created a delegated managed service account and generated a Kerberos ticket impersonating svc_deploy. We now effectively have a TGT for: Exporting it: Enumerating Shares as svc_deploy Checking available SMB shares: Interesting. A new share has appeared: Exploring VMBackups Connecting with Impacket: Listing shares: Entering the backup share: Navigating deeper: Output: This is where things get interesting. The share contains a virtual machine backup and, more importantly: A .vmem file is effectively a memory dump of the virtual machine. Memory dumps often contain credentials, Kerberos tickets, and other sensitive artifacts. Downloading the Memory Dump Downloading the memory dump: The file is approximately: Have a coffie ................ You can monitor the download progress with: After a coffee break and a few minutes of waiting, the download finally completed. Extracting Hashes with Volatility To analyze the memory dump, I used: Volatility is an open-source memory forensics framework used to analyze memory dumps and extract valuable artifacts such as processes, credentials, network connections, and registry data from memory images. Repository: https://github.com/volatilityfoundation/volatility3 Running the hashdump plugin: We recovered the Administrator NTLM hash: Administrator Access Verifying the hash: The hash is valid. Connecting with Evil-WinRM: Success. We now have Administrator access. Root Flag Interestingly, the flag wasn't stored under the Administrator profile. It was located in: Reading the flag: And with that, the box is fully compromised. Final Thoughts Checkpoint was a very enjoyable machine that focused heavily on Active Directory enumeration and abuse rather than exploiting traditional vulnerabilities. What I liked most about this box was that every step felt realistic and built naturally on the previous one. Starting with a low-privileged user, we restored a deleted account, discovered a writable share used for distributing VS Code extensions, and leveraged it to gain code execution as another domain user. The highlight of the box was definitely the dMSA / badSuccessor attack. It introduced a lesser-known Active Directory abuse technique that many players may not have encountered before, making the machine both educational and challenging. The final stage involving access to VM backups and extracting credentials from a memory dump using Volatility was also a nice touch, showing how valuable backup infrastructure and memory artifacts can be during an engagement. Overall, Checkpoint is an excellent machine for practicing Active Directory enumeration, Kerberos abuse, dMSA attacks, SMB share abuse, and memory forensics in a realistic enterprise environment. Hope you enjoyed the writeup and learned something new along the way. Meet you in the next writeup! ```