Write-up LEHACK19
Write-up for the Active Directory Lab I have created for Akerva exhibition stand @ leHACK19 (Paris)
| Title | Description |
|---|---|
| About | About the challenge |
| Reconnaissance | Reconnaissance |
| Initial Foothold | Tomcat's host-manager exploitation |
| Procdump lsass | Procdump lsass process to retrieve credentials |
| Cartography with Bloodhound | AD Cartography with Bloodhound |
| Browsing Shares | Browsing shares to retrieve credentials |
| RBCD Exploitation | RBCD Exploitation |
| Looting | Looting juicy information |
WonkaChall 2 created by Akerva for leHACK19 (Paris) is divided into three parts:
- part 1 (AWS)
- part 2 (Active Directory) <= This write-up deals with the Active Directory part I have created.
- part 3 (Linux)
In the previous part 1, we retrieved a VPN configuration file on a AWS bucket. We can now connect to the wonka internal network with the VPN config file (wonka_internal.ovpn).
When connected, we want to determine what networks we have access to. For that purpose, we can simply look at routes pushed by our VPN.
172.16.42.0/24 subnetwork looks interesting. Let's see what is alive in it by doing a quick nmap ping.
Three machines looks to be UP:
- 172.16.42.5
- 172.16.42.11
- 172.16.42.101
Juding from the listening services, these three machines look to be Windows, and one seems to be a domain controller. We can note the open port 8080 on 172.16.42.11. Could it be a Tomcat, easy prey?
We confirm these three machines are part of a domain FACTORY.LAN.
| Hostname | IP address | OS |
|---|---|---|
| DC01-WW2 | 172.16.42.5 | Windows Server 2019 |
| SRV01-INTRANET | 172.16.42.11 | Windows Server 2019 |
| PC01-DEV | 172.16.42.101 | Windows 10 |
By reaching SRV01-INTRANET's port 8080 with a web browser, we face what looks like an internal wiki of the Wonka organization.
An interesting schema is freely available and give a good sight of the company infrastructure.
We can learn the existence of a subnetwork 172.16.69.0/24 with several machines and that PC01-DEV is the computer of a dev/admin. By reaching an inexistant page, the error betrays the web service is indeed a Tomcat. We are aware Tomcat on Windows are often launched with NT AUTHORITY\SYSTEM privileges.
We then try to reach the Tomcat's manager page to compromise the machine in case of default credentials, but the manager is unavailable.
We launch a GoBuster, and find out that the host-manager page is active.
We go on the web page and face to a basic authentication form. We try tomcat's default credentials « tomcat / tomcat ».
The credentials are valid allowing us to reach the host-manager.
The host-manager exploitation is a simple variant of the manager exploitation. There are many resources on the internet explaining how to exploit default credentials on a Tomcat's host-manager in order to take control of the underlying server. The idea here is to force the Tomcat's host manager to look for a war application on a smb share we control, in order to deploy it. Our war is a webshell allowing us to execute commands as NT AUTHORITY\SYSTEM. From here, we could be able to perform interesting actions like extracting credentials from memory.
Another thing to take into consideration is antivirus detections. A meterpreter war generated by msfvenom will be detected by the server's antivirus, a simple Mimikatz too. A solution is to use a home made war and a procdump from sysinternals to dump lsass process, in order to extract passwords locally with Mimikatz.
Let's put the war and ProcDump into a directory.
Let's start an Impacket's SMB server in our directory.
Then, we can write our SMB server's UNC path on the host-manager, \\10.8.0.42\aka.
akerva.factory.lan must point to the Tomcat's IP address. We edit our /etc/hosts to reflect that.
We click on Add et see the Tomcat retrieving and deploying our war directly on our SMB share.
Our application (web shell) is now available on the host-manager.
We can reach our webshell via: http://akerva.factory.lan:8080/akerva/cmd.jsp. From here, we can enter commands like whoami to verify we are indeed NT AUTHORITY\SYSTEM.
The flag 5 is on the adminServer's Desktop.
We then dump the lsass process thank's to Sysinternal's ProcDump tool.
We bring back our dump.
And we parse it locally to retrieve credentials..
Flag 6 is the SHA256 of the adminServer's password.
Now we have a domain account, we can use Bloodhound to cartography the domain. We carefully take the latest version of Bloodhound and Sharphound. No need to add a Windows machine to the domain to launch Sharphound.
Our Bloodhound does not show domain admin shortest path but a primitive « AddAllowedToAct » between domain account « SvcJoinComputerToDom » and the domain controller catch our attention.
After googling, we gather several resources on Resources-Based Constrained Delegation :
- https://posts.specterops.io/a-case-study-in-wagging-the-dog-computer-takeover-2bcb7f94c783
- https://binged.it/2kaWdnx
- https://beta.hackndo.com/resource-based-constrained-delegation-attack/
Very succintly, the idea is to rewrite the « AllowedToActOnBehalfOfOtherIdentity » property of a machine with a structure based on a SPN account's SID. Then, this SPN account should be able to impersonate any users on the aimed machine, and so, compromise it.
Two conditions are required for this RBCD exploitation:
- To control a SPN account
- To be able to rewrite the « AllowedToActOnBehalfOfOtherIdentity » property of the domain controller
For the first condition, a simple technic is to join a machine to the domain. Indeed, this joined machine will have SPN. By default on Active Directory environment, every domain user can join up to 10 machines to the domain. But it is not the case here because the domain administrator has hardened this configuration. However, a service account SvcJoinComputerToDom seems to have this privilege.
For the second point, our Bloodhound clearly states that SvcJoinComputerToDom has this right.
So, we have to find this SvcJoinComputerToDom. We can imagine this service account was created by the domain administrator in order to delegate the right to join machines to the domain to the adminServer and adminWorkstation, without giving them the domain administrator privilege.
We check to what our adminServer account has access to.
A share « provisioning » looks to be available for adminServer. From this folder, we can retrieve SvcJoinComputerToDom's credentials.
And aldo flag 7.
Everything is in place for our RBCD exploitation. We will need four tools (PowerView, Powermad, Rubeus and Mimikatz).
- https://github.com/PowerShellMafia/PowerSploit/blob/dev/Recon/PowerView.ps1
- https://github.com/Kevin-Robertson/Powermad/blob/master/Powermad.ps1
- https://github.com/GhostPack/Rubeus
- https://github.com/gentilkiwi/mimikatz
First we start by importing PowerView and Powermad, then we specify the domain controller as target. We retrieve the SID of the SvcJoinComputerToDomain account.
Then we can join a machine to the domaine with SvcJoinComputerToDom. We retrieve the joined machine SID, and craft the structure based on that SID. Then we rewrite the domain controller's « AllowedToActOnBehalfOfOtherIdentity » property with that structure.
Now, we can impersonate the domain administrator account on the domain controller with our joined machine account.
Here the Rubeus output.
Our ticket is imported, let's DCSync with Mimikatz the NTLM hash of Administrator and Krbtgt (flag 8).
Since we have retrieved a domain administrator NTLM hash, the domaine is compromised. Since the domain is compromised, we can try to explore machines not exploited yet. For example the dev/admin machine which may hide secrets about the dev subnetwork. For that purpose, we use PSExec with the Administrator NTLM hash but it fails. Probably because Administrator is a domain « Protected Users ».
We think and decide to DCSync the « adminWorkstation » account and try again with PsExec. It works. After enumeration, we can find a WinSCP shortcut on the adminWorkstation's Desktop.
We are aware that WinSCP saves credentials into register, in a reversible manner. We can retrieve these credentials by simple executing the CrackMapExec's Invoke_sessiongopher module.
These credentials allows us to go deeper in the information system of the company. We can now explore a new subnetwork, the dev one... (part 3 of WonkaChall 2).
Thanks for reading this.
I hope you enjoyed it as much as I enjoyed making this Active Directory lab.
Created by Lydéric Lefebvre