Timelapse

Windows: Easy

Reconnaissance: NMAP

┌──(kali💀kali)-[~]
└─$ sudo nmap -sC -sV -O 10.10.11.152

53/tcp   open  domain            Simple DNS Plus
88/tcp   open  kerberos-sec      Microsoft Windows Kerberos (server time: 2024-01-19 11:54:58Z)
135/tcp  open  msrpc             Microsoft Windows RPC
139/tcp  open  netbios-ssn       Microsoft Windows netbios-ssn
389/tcp  open  ldap              Microsoft Windows Active Directory LDAP (Domain: timelapse.htb0., Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http        Microsoft Windows RPC over HTTP 1.0
636/tcp  open  ldapssl?
3268/tcp open  ldap              Microsoft Windows Active Directory LDAP (Domain: timelapse.htb0., Site: Default-First-Site-Name)
3269/tcp open  globalcatLDAPssl?

Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running (JUST GUESSING): Microsoft Windows 2019 (88%)
Aggressive OS guesses: Microsoft Windows Server 2019 (88%)
No exact OS matches for host (test conditions non-ideal).
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb2-time: 
|   date: 2024-01-19T11:55:51
|_  start_date: N/A
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required
|_clock-skew: 7h59m56s

This combination of ports (Kerberos + LDAP + DNS + SMB) suggest it is likely a domain controller. This is supported by the hostname identified at the bottom (DC01) and the name on the TLS cert on 5986 (dc01.timelapse.htb). LDAP scripts show a domain name of timelapse.htb as well. It’s a bit odd that no script data came back for SMB (445).

I’ll add a line to my local /etc/hosts file:

In HTB, I’ve regularly run into Windows Remoting / WinRM on TCP 5985. The TLS-wrapped version of that typically runs on TCP 5986, which is what is present here. I’ll be able to interact with it to get a shell if I can find a way to auth.

Enumeration: MSRPC Port 135/tcp

Enumeration: SMB Port 139/445/tcp

I’m not sure why nmap couldn’t get any details out of SMB, but crackmapexec does it with no issue:

As always, with SMB, it pays off to try different tools. crackmapexec isn’t able to list any shares:

But smbclient does (-L to list shares and -N for null authentication):

NETLOGON and SYSVOL are standard for any domain controller (DC). Since it’s custom (and the only one I can read according to CME), I’ll start with Shares:

Dev has a single file, which I’ll grab:

HelpDesk has a few files, all about LAPS:

Local Administrator Password Solution (LAPS) is a method of managing the passwords for the local administrator accounts via the domain. Without laps, it’s very challenging for a support team to manage keeping unique local admin passwords for each system. This leads to shared credentials, which means that when an attacker gets elevated privileges on a system, they can dump the shared cred and use it to get access on other systems.

LAPS also rotates administrator passwords, changing them periodically, such that if they are captured by an attacker, they become invalid after some period of time.

Shell as legacyy

Access winrm_backup.zip: The zip archive from SMB has a single file:

Based on the name, it seems to contain authentication, either for a user named dev or legacyy. A .pfx file typically represents the PKCS#12 format, containing both a public and private key for a user. Given the archive name and this file type, it seems likely that if I can get access to this file, I’ll be able to get a shell over WinRM on Timelapse.

Crack Zip Password Trying to open the downloaded archive requires a password:

I’ll use zip2john to generate a hash that can be brute forced:

The hash format doesn’t match anything on the Hashcat list of example hashes, as hashcat actually can’t brute this kind of hash.

I’ll use john:

It cracks it instantly (even in a VM) to “supremelegacy”. It works to unzip: supremelegacy

Obtain Keys Crack pfx Password This post shows the openssl commands to extract the private key and certificate (public key) from a .pfx file. Unfortunately, this one requires a password:

pfx2john.py will generate a hash for it (piped into tee to both save it to a file and examine the output):

This time it takes john about half a minute to find the password “thuglegacy”:

Extract Keys With the password, I can extract the key and certificate. When extracting the key, it asks for the password (I’ll provide “thuglegacy”), and then a password for the output .pem file (anything I want, must be at least four characters):

I’ll decrypt the key using the password I set above so I don’t have to remember it:

And dump the certificate:

Now both files exist:

Evil-WinRM: evil-winrm is the best tool for connecting to WinRM from a Linux host. Looking at the usage shows how I’ll use these keys to connect:

Shell as svc_deploy

Enumeration: There’s nothing too special about the legacyy user

They are in the “Remote Management Users” group, but I know that because without that group I wouldn’t have been able to execute commands or get a shell over WinRM. The “Development” group could be interesting. I’ll keep an eye out for places that may allow legacyy to go.

No interesting privileges:

PowerShell History: One place I always check on Windows hosts is the PowerShell history file. And it’s present here:

If I didn’t think to check it manually, WinPEAS would also have showed it.

The file contains some history, including connecting to this host using the creds for the svc_deploy user:

Shell: I’ll reconnect with a new evil-winrm session and these creds:

Shell as root

Enumeration No additional privileges as svc_deploy:

There is a really interesting group:

LAPS_Readers seems to imply svc_deploy has access to read from LAPS.

LAPS With LAPS, the DC manages the local administrator passwords for computers on the domain. It is common to create a group of users and give them permissions to read these passwords, allowing the trusted administrators access to all the local admin passwords.

Read Password: To read the LAPS password, I just need to use Get-ADComputer and specifically request the ms-mcs-admpwd property:

The local administrator password for this box is agLB%!fU)ilz!8io+}}10DhW

Evil-WinRM I’ll connect with evil-winrm:

root.txt The root.txt file is missing from C:\Users\Administrator\Desktop:

There’s another user on the box, TRX:

TRX is in the “Domain Admins” group. I’ll check there and find it:

Last updated