Reflection - Vulnlab
Reflection is a medium Active Directory chain from Vulnlab, consisting of 3 machines. It involves MSSQL, NTLM relay attacks, reading LAPS password, Resource-Based Constrained Delegation (RBCD), and password reuse.
NMAP
DC01
1 | Nmap scan report for 10.10.185.165 |
Based on the Nmap scan results, it is evident that this machine is a domain controller, as it has DNS, LDAP, and Kerberos services running. Additionally, there is an MSSQL service running on port 1433, which is particularly noteworthy
MS01
1 | Nmap scan report for 10.10.185.166 |
MS01 also has an MSSQL service running on port 1433
WS01
1 | Nmap scan report for 10.10.185.167 |
Finally, there’s WS01, which is nearly identical to MS01, except it doesn’t have the MSSQL service running
Enumeration
SMB
I always prefer to start with SMB enumeration. Let’s run Netexec on the three IPs we have
MS01
It appears that MS01 allows guest authentication. If you’re interested in learning more about guest and null sessions, you can read this article
There is a non-standard share named staging. We can connect to it using Impacket’s smbclient and list the files within the staging share
Great! We’ve obtained some database credentials
MSSQL
We can test these credentials on both DC01 and MS01 (using the --local-auth parameter). Netexec confirms a valid login on MS01
Let’s connect to MSSQL using Impacket’s mssqlclient.
NTLMv2 Hash
Since we’re authenticated to MSSQL, we can attempt to obtain the hash of the user running the database by using the xp_dirtree command. We’ll point it to our machine with a UNC path and then try to crack the hash
As you can see, that was successful. However, the hash couldn’t be cracked. So, what can we do in this situation?
NTLM Relaying
Another approach we can try is relaying the NTLM authentication. But first, we need to verify that SMB signing is disabled
Indeed, SMB signing is disabled on all three machines, including the DC. In this case, we can even relay the authentication to the DC and access its shares.
First, let’s set up a relay server using Impacket’s ntlmrelayx
Next, use the same xp_dirtree command that we used earlier.
As you can see, we’ve successfully received the authentication, and it’s indicating that the attack is targeting the domain controller
Since We used the -socks option with ntlmrelayx, We need to add the following entry to our /etc/proxychains4.conf file
Now, using proxychains, we should be able to list the SMB shares on the DC. There’s a share named prod
We can use smbclient to connect to the prod share and download the prod_db.conf file, which provides us with additional credentials, this time for the prod database
Since the prod share was on the DC, we can attempt to authenticate to the MSSQL instance running on the DC
We can perform some MSSQL enumeration to list the databases and tables. The prod database has a table called users, which contains what appear to be credentials for some domain users
To confirm that these are domain user credentials, we can use Netexec. This confirms that these are indeed valid domain user credentials
With valid credentials in hand, we can run Bloodhound to gain a better understanding of the network and the permissions our users have
GenericAll - 1
The user Abbie.Smith has GenericAll over MS01
I’ve already covered how to abuse GenericAll in my blog. One of the first techniques we can use is Resource-Based Constrained Delegation (RBCD). Unfortunately, MachineAccountQuota is set to 0. However, we can still perform another attack known as SPN-less RBCD, which I also covered in this article. A third option is to read the laps password if laps is enabled on the target, which is the case here.
To achieve this, we can use the --laps option in Netexec. As you can see, we retrieved the local administrator password immediately
Now, we can connect to MS01 using evil-winrm and grab our first flag
Credential Dumps
Let’s attempt to dump the credentials from MS01 using the --lsa option in Netexec. However, nothing of interest was found
Another option we can try is the --dpapi option, which will dump the DPAPI credentials. It appears that there is a scheduled task being executed as the user Georgia.Price, which reveals her credentials
WS01
GenericAll - 2
Reviewing the privileges of this new user, we can see that she has GenericAll permissions over WS01
We can attempt to read the LAPS password again, this time on WS01 as the Georgia.Price user. Unfortunately, LAPS is not configured on WS01. In this situation, we can exploit Resource-Based Constrained Delegation (RBCD) since we already own a machine (MS01), allowing us to use it to carry out our attack
To obtain the machine account hash, we can use Impacket’s secretsdump tool
Another way to retrieve the hash is by using Mimikatz. First, let’s disable Windows Defender and upload Mimikatz
Now, we can run Mimikatz with the following command to dump the machine account hash
Resource-Based Constrained Delegation (RBCD)
I’ve already covered this attack in a previous article, or you can check out this excellent article
We can read the msDs-AllowedToActOnBehalfOfOtherIdentity attribute, but it’s currently empty.
Now, We want to write this attribute using Impacket’s rbcd tool.
Next, we need to request a service ticket while impersonating the Administrator user
Finally, We can use this ticket to authenticate to WS01. which, as you can see, is successful
Credential Dumps
Just like with MS01, we can dump the LSA secrets from WS01, which reveals the credentials for a new domain user named Rhys.Garner
With this new password, we can perform a credential spraying attack to check for any password reuse. First, let’s dump all the domain users
We do a little bit of cleaning
DC01
Next, we perform the password spraying. Fortunately, the Rhys.Garner user has reused his password with another account named dom_rgarner
The latter is a domain admin. We can login via winrm or directly read the flag using Netexec
That concludes this chain. I hope you learned something new! 🐱
