Hackthebox - Timelapse writeup
Timelapse is an easy windows box, that tests basic skills in enumeration of typical windows services, however, in saying that, this box has taught me a fair bit. Let’s get to hacking!
To know that we know what we know, and to know that we do not know what we do not know, that is true knowledge — Nicolaus Copernicus
Discovery
As always the first step is to check what ports are open as well as taking a look at the services running on those ports, this gives us an attack surface.
nmap -sV -A -O 10.129.190.127
We also scan for all ports in the event we missed something.
nmap -p- 10.129.190.127
Looking at the results, nothing seemed completely out of the ordinary, these results are what you would expect from a Windows server, so we move on to enumerating individual services.
Enumeration
One of the easiest vectors to compromise a windows host is through SMB, often this service is incorrectly configured and can leak very interesting info, so it is a good practice to start windows pen testing by targeting SMB.
Enumeration of SMB can be done quiet easily with tools such as smbmap and smbclient. Our first step would be to check for Guest or null sessions.
smbmap -u “” -p “” -P 445 -H 10.129.190.127 && smbmap -u “guest” -p “” -P 445 -H 10.129.190.127The above command will try to connect to both null and guest sessions and further attempt to list shares.
Looking at the output, it is apparent that the Shares folder has read access, we use this info to connect to the Shares folder using smbclient. It will prompt you for a password, which you should leave blank.
smbclient \\\\10.129.190.127\\Shares
We begin digging into these folders.
You can download these files using the get command.
get filename.txtLets do the same for the other folder in Shares.
This file catches my attention. However lets slow it down a bit, I go ahead and do some research on the LAPS documentation, and immediately receive results containing information about privilege escalation, so we have to bookmark that for later!
We now need to see what this zip file contains, but of course, it’s never that easy, the file is password protected!
After doing a lot of enumeration, and not gaining any ground, it became quite obvious that winrm was the way in, so I turned back to the zip, but now, attempted to find its password. In hindsight I should have done this first.
To do this we make use of a zip cracking utility known as fcrackzip, all we have to do is supply it with a wordlist and of course, the zip file.
fcrackzip -u -D -p rockyou.txt winrm_backup.zip
Alright awesome! extracting the file gives us a PFX file which is a certificate bundle in PKCS#12 format, this means that this bundle contains a private key. We do some research to figure out how to convert this file into a private key, and come across a good article on the conversion using openssl.
Extracting the certificate and keys from a .pfx file — IBM Documentation
The first thing we try to do is convert the PFX file into a PEM file.
openssl rsa -in legacyy_dev_auth.pfx -outform PEM -out legacyy_dev_auth.pemHowever we are confronted by another password prompt…
Alright after some soul searching, we find a tool on GitHub to crack the password on a PFX certificate bundle.
Just like Fcrackzip we need to specify a wordlist and of course the PFX file.
crackpkcs12 -d rockyou.txt legacyy_dev_auth.pfxAfter some time the password is found!
Alright lets jump back to openssl and perform the conversion.
openssl rsa -in legacyy_dev_auth.pfx -outform PEM -out legacyy_dev_auth.pemThe password works, so we move on to converting the PFX file to a private key.
openssl pkcs12 -in legacyy_dev_auth.pfx -nocerts -out legacyy_dev_auth.keyNice, we now have a cert and private key! But what exactly are we supposed to do with them?
Leveraging the initial file name, that mentions WinRM. We dig a bit and find out that it is possible to authenticate with certificates. The below link is a good read on this topic.
Certificate (password-less) based authentication in WinRM — Hurry Up and Wait!
In order for us to log in, we make use of a popular Linux tool known as Evil-WinRM, this tool is the windows equivalent with a bit of tweaks. Reading its usage documentation:
Hackplayers/evil-winrm: The ultimate WinRM shell for hacking/pentesting (github.com)
We see that it is possible to use cert based authentication, lets give it a shot…
evil-winrm -i timelapse.htb -S -c legacyy_dev_auth.pem -k legacyy_dev_auth.key
The user flag can be found in C:\Users\legacyy\Desktop.
All that is great, but we aren't done just yet.
Privilege Escalation
I took a large amount of time trying to figure this one out, I make use of PayloadsAllTheThings to run through a whole bunch of checks.
Eventually I came across some rather interesting content when viewing the PowerShell history for our current user.
It seemed to be using the password for svc_deploy, another user on the system.
Lets try to log into the user using evil-winrm like before.
evil-winrm -i timelapse.htb -u ‘svc_deploy’ -p ‘PASSWORD’ -S
Alright, this is good, but we’ve now got to start enumeration from the top!
To Root
Doing some basic identification, we notice that svc_deploy is a part of a very important group.
whoami /all
This user has the ability to read the password created by LAPS whenever it is rotated. This is so that a group of users are always aware of the Administrators password changes.
Like I mentioned earlier, I did some research on LAPS, and found that it is a common vector for privilege escalation. I used the below link.
Dump LAPS password in clear text — Akijosberry (wordpress.com)
Following the article, we run the PowerShell query's in our svc_deploy session.
Import-Module activedirectory
Get-ADComputer -Idenity dc01 -Properties *This will return a lot of information, however we are looking for the value of ms-Mcs-AdmPwd.
As you can see, the cleartext password is given to us, because of our user having read access to the ms-Mcs-AdmPwd attribute.
Same as before, we use evil-winrm to log in as Administrator.
Nice! OWNE…wait, where is the flag?
The creator of this box mentioned that due to some testing that had been done, the flag was not where it usually is.
This can be resolved easily with a PowerShell query to locate the file.
Get-Childitem -Path C:\ -Include *root.txt* -Recurse -ErrorAction SilentlyContinue
The flag was found in C:\Users\TRX\Desktop.
Conclusion
That wraps this box up, this was purely on enumeration, but teaches you the importance of checking everything you find thoroughly.
If you made it this far, thanks for reading! Remember to always keep learning and never stop hacking.
