Статья Reflection is a medium difficulty Active Directory

Introduction​

Reflection is a medium difficulty Active Directory chain on the Vulnlab’s platform, consisting of 3 machines: DC01, MS01, and WS01. This chain consists of a variety of realistic internal network penetration testing attack vectors and was incredibly enjoyable. The types of attack vectors required for successful exploitation include anonymous SMB bind abuse, MSSQL abuse, NTLM relay attacks, Windows Credential Vault harvesting, Resource-Based Constrained Delegation (RBCD), and finally credential reuse. While none of these attack vectors are particularly complex, the realism experienced when chaining them together in a believable and logical way was insanely rewarding.

Enumeration​

DC01​

From an nmap scan of DC01 we can confirm that it is in fact a domain controller. Most of the output is very standard, except for the fact that a MSSQL server is running on port 1433 and SMB signing is not enforced, potentially meaning an NTLM relay attack of some sort could be possible.

MS01​

The nmap scan of MS01 is also pretty standard, mainly telling us MSSQL is running on port 1433 just like the DC, and RDP on 3389 and WinRM on 5985 are both available for potentially remote control of the device if we gather user credentials.

WS01​

Pretty much the same thing with WS01. The nmap scan looks pretty standard with RDP enabled being the only thing that stands out for the same reason as MS01.

SMB Enumeration​

After a generic nmap scan of each device, I began enumerating each devices SMB service, testing for anonymous access and null bindings. Weirdly enough, Netexec didn’t have permissions to display the SMB shares anonymously, but smbclient was able to.



In the staging share I then found database credentials, likely for the MSSQL service on MS01.



Next I tested the credentials and authenticated to MS01’s MSSQL service.

MSSQL And The Power Of SMB Signing​

Now that we’ve fully authenticated to the MSSQL service, I’ve had the name of the chain: “Reflection” and the fitting fact that signing is disabled on the DC in the back of my head the whole time. I’ve known that some sort of relay attack was going to be required since the beginning, but I wasn’t super sure when.

When enumerating the MSSQL database, I found some testing dev accounts, but when trying them on the domain they were invalid, leading me to realize that I could xp_dirtree to send my attacker host NTLM authentication and relay it to the DC to potentially read SMB share information.

First I set up a relay server with ntlmrelayx:

Then I sent the authentication request



Looking back at the relay server, we’ve received authentication and successfully relayed those credentials to the DC



Now we can use netcat to interact with the SMB service on the DC. There appears to be a production share, with another DB configuration file inside.





We once again find credentials for the MSSQL service, this time on the DC



After we ensure we can successfully authenticate, looking around yields us some users, and as this is a production database its assumed these users are active domain users

Credentialed Domain Enumeration​

After confirming through a tool such as Netexec that these users are truly domain users, we can then use their access to launch a bloodhound scan.

One of the major things that I note is that our current user abbie.smith has generic write over MS01

MS01 Initial Access​

The very first thing which comes to mind is modifying the msDS-AllowedToActOnBehalfOfOtherIdentity to takeover the device, otherwise known as Resource-Based Constrained Delegation (RBCD), but unfortunately RBCD requires an SPN to carry out the full attack, usually a computer account, which I don’t have access to.

I decided to make a bold assumption and guess that the Local Administrator Password Solution (LAPS) is enabled on this domain, and was able to read the local administrator password through the GenericAll permission with Netexec through the abbie.smith account.



When checking our local administrator credentials against MS01 with wmiexec we successfully authenticate

MS01 Post Exploitation​

I knew that I had to use some aspect of MS01 to pivot to the other machines in the chain, so my immediate thought was credential harvesting using tools like Mimikatz. Dumping LSASS and SAM provided me with no further credentials. Although I did end up noticing a scheduled task being executed as the Georgia.Price user. This means their credentials would be stored in the Windows Credential Vault, which can also be dumped with Mimikatz.



Using these credentials with bloodhound conveniently shows that Georgia.Price has GenericAll over the second device in the chain, WS01.

WS01 Initial Access​

The very first thing I attempted was reading the LAPS password on WS01 using Georgia.Price’s credentials, unfortunately, LAPS was not configured on WS01. No matter, because we can utilize the computer account of MS01 that we compromised (A SPN) to exploit Resource-Based Constrained Delegation (RBCD) on WS01.

First write the msDs-AllowedToActOnBehalfOfOtherIdentity LDAP attribute using rbcd.py



Next we have to request a service ticket while impersonating Administrator with getST.py



Now we use this ticket to authenticate with Netexec.

WS01 Post Exploitation​

When quickly dumping LSA secrets from WS01, we find a new users credentials stored: Rhys.Garner

Getting Domain Admin​

This user didn’t have any special domain privileges or anything leading to full domain compromise unfortunately, so I kept looking into credential harvesting on WS01 for a long time yielding nothing. After a while I started looking at general domain information again to try and see anything I might have missed before. That’s when I noticed the domain admin user, dom_rgarner again. For a while I wasn’t sure exactly what this naming convention meant, then I started looking at it in the context of the just compromised Rhys.Garner user.

I realized the dom prefix was short for domain, indicating the span of user privilege, and rgarner being a [firstletter][lastname] format for the Rhys.Garner user. Just out of desperation I tested the underprivileged account credentials on Rhys’s Administrator account and they worked! Rhys had reused their credentials.