Continuation of the previous post, where we’ll start configuring a vulnerable environment to learn how to escalate privileges within an Active Directory scenario abusing insecure configurations.
REQUIREMENTS:
- Two new domain user accounts (Cosme.fulanito and hank.scorpio for me).
- A new local administrator on two hosts (ATENCION01 and TECNOLOGIA01).
- Kali Linux host within the same network segment.
We’ll start our scenario configuration by adding new local administrator accounts for the two Windows hosts “ATENCION01” and “TECNOLOGIA01”.
We login with an administrative account into one of the hosts, in this case, I’m using a Domain Admin account (Insecure practice, never do this on production environments).
We create a new user called “soporte” and add it to the local administrators group through CMD.
Additionally, we add the domain user “cosme.fulanito” to the local administrators group as well.
We create the local user “soporte” on the host “TECNOLOGIA01”.
IMPORTANT: Using the same password for the user “soporte” (or whichever name you decide), is an insecure practice that we’ll be exploiting in this lab.
Additionally, we’ll add another domain user to the local administrators group on the “TECNOLOGIA01” host, in my case, the domain user “hank.scorpio”.
We also add the user “hank.scorpio” to the local administrators group on the “BD01” host.
Finally, make sure to log in into “BD01” as the domain administrator.
EXPLOITATION CHAIN
For this scenario, we’re gonna assume a breach, where somehow the “cosme.fulanito” credentials were obtained by us, impersonating an attacker and we have access to the internal network with our own computer, in this case, the Kali host, and to the “ATENCION01” host.
Since we have access to a domain joined machine, we can use the own operating system tools to start our enumeration process, in this case, we’ll focus on the host itself, by enumerating local users.
We identify users that don’t come with the default installation of Windows, such as “sshd”, “IEUser”, “sshd_server” and “soporte”.
We also observe that our user, “cosme.fulanito”, is a member of the local administrators group, so we can use it to find credentials on the host.
However, since we’re dealing with an Active Directory environment, and we have a valid domain user, it’s strongly recommended to perform domain enumeration tasks, to identify existing users, domain joined computers, password policy, trust relationships, etc.
We obtain the current domain name and the domain controller IP address.
In the weird case where we have a DNS server different from the domain controller (personally, I never saw this case) or there’s more than one domain controller, we can use the “nslookup” to obtain the list of domain controllers.
With this information, we now know where to point our tools to to extract information from the domain controllers through valid authentication.
On our Kali host, we’re gonna use the “ldapdomaindump” tool.
We’ll obtain a number of files that contain useful domain information in different formats.
By opening up one of the files, for example, “domain_users.html” on a browser, we’ll see the following information.
We have a complete list of all the registered domain users, to perform brute force or password spraying attacks.
Browsing the “domain_computers.html” file, we obtain a list of all the domain joined machines, which can save us some time from having to manually scan the entire network.
We’re gonna focus on lateral movement, so this file will be really useful ahead.
Since we know the compromised user is a local administrator on the host “ATENCION01”, we can use the Impacket suite to dump the local user hashes, as well as the LSA cached credentials.
By doing this, we obtain the NTLM hashes for the “Administrator” and “soporte” users.
Now, we have two different paths.
- Use the compromised domain user to authenticate to different domain joined hosts, to see if we have administrative privileges in a different host.
- Attempt a Pass the Hash attack with local users.
For both scenarios, we need a list of targets, using “awk” we can obtain this easily by parsing the “domain_computers.grep” file:
This command will extract the data stored in the respective file, obtaining the information from the DNSHostName column only.
We get 4 different targets, all domain joined machines, where we’ll authenticate and explore our privileges.
To validate the first part of the lab, we use “crackmapexec” to validate our privileges on all of the identified targets.
We observe that our user has administrative privileges on “ATENCION01” only, so we proceed with the Pass the Hash attack.
FIrst, we can use the “Administrator” account to try to login into new hosts, however we see that the account is disabled.
Now we use the “soporte” account, where we see that we have administrative access in a different host, “TECNOLOGIA01”, presenting a typical Pass the Hash attack.
Replicating previous steps, we can obtain the NTLM hashes of the host.
We didn’t get any new local users, however, looking at the cached domain logon information, we can see that, at some point, the domain users “jseclow”, “admin”, “Administrator” and “hank.scorpio” authenticated to this host at some point, which means that its possible that their credentials are still stored in memory.
To extract this information, we need to dump the LSASS process, there are several ways to do so and its a really known technique within Active Directory environments, in this lab, we’ll use “crackmapexec” to do so, specifically the “LSASSY” module.
We get an error when we try to dump the process using this module, that’s usually because of an antivirus/EDR.
For the purpose of this lab and to keep it simple, we can try to disable the antivirus, since we have administrative privilege, we can use “wmiexec” to get a semi-interactive Powershell reverse shell.
(*) Since we’re using a local administrator account, we can put “.” instead of the domain.
We used Powershell to disable the Real Time monitoring feature of Windows defender, through the following cmdlet:
Set-MPPreference -disableRealTimeMonitoring $true
With the antivirus no longer being a concern, we run the “LSASSY” module through “crackmapexec” again, obtaining the NTLM hash for the “hank.scorpio” user.
With this new credential under our control, we can continue our lateral movement by verifying if this user has any special privileges over other hosts.
We use “crackmapexec” to authenticate into the domain hosts, observing we get administrative privileges over “BD01”.
We can use the new found privilege to obtain the available NTLM hashes on the host using the impacket suite.
Since there are no new local users, we see that the only cached domain credential belongs to the “JSEC.LOCAL/Administrator” account, indicating that the domain admin logged on to the host at some point and there’s a chance that it’s credential is still stored in memory.
Dumping LSASS to confirm, we obtain the NTLM hash for a domain admin account.
We validate the hash in the domain controller, obtaining all of the domain users NTLM hashes by dumping the NTDS database, successfully compromising the entire domain.
With this new privilege, we can establish persistence (in a noisy way, just for the lab) by creating a new domain user and adding it to the “Domain Admins” group.
We can confirm the account is working by logging in into the domain controller.
Domain compromised.
This is a basic scenario, however, it is very likely that practices like this are found on corporate environments, specially on larger ones where knowing what the configuration is for every single server is hard due to the amount of them. Personally, I found scenarios like this multiple times as a Pentester, maybe not in such a simple way, given that there were controls that had to be bypassed or the credential harvesting procedure was executed on hundreds of hosts before finding a valuable credential, however, the general idea is the same.