Articles & Blogs
Compromising the Domain Controller using Multiple Misconfigurations
A story of how Security Misconfiguration led to Compromising the Domain Controller
What is an Assured Breach?
Assumed breach, as the name suggests, is when an attacker has already gained access to the internal network or has compromised an employee machine. This means that the attacker has a foothold in the organization.
In our case, the approach used was the Assumed Breach Testing approach, in which the client provided us with similar access that an employee is granted on joining the organization. The target was to use this path to eventually be able to compromise the domain controller.
In short, we had the same privileges as any other employee in the organization.
Finding a Needle in a Haystack
It all began with enumerating the network and understanding the access we had, specifically the ACL group services and local admin privileges on other systems.
During this phase, we were surprised to see that the organization had over 150,000 groups including over 100,000 computer objects. So, performing the enumeration was getting all the more challenging, as the time and resources required to obtain the desired results were high and caused our terminal to crash. Also, since we were overloaded with information, extracting useful information seemed even more complex than we had fathomed.
To work around this issue, we decided to change our approach, and only enumerate current user privileges. We noticed that our current user also had local admin privileges on a different system. We accessed the other system using RDP, dumped the credentials from memory, and gained access as another user.
On further enumerating the privileges of this user, we observed that the user had local admin privilege on yet another system. Using Psexec, we could access other machines and dump credentials for another user.
We noticed this user had forced a password reset for one of the users. We quickly changed the password of this new user and gained access as this new user. While enumerating more about this new user, we realized that our access to these compromised users had been revoked, and all our enumerated accounts were locked by the blue team.
Within minutes, we were back again to Square 1. What do we do now?
New Approach Using Old Learnings
Since the blue team blocked our access to the previously compromised users, we began to enumerate the groups that our test user had been added. Bingo. We discovered that our user was part of a group, that was a member of several other groups. Interestingly, the parent group had LAPS password-read-access on a few systems, which meant we had inherited this LAPS access from the parent group as well. Using this misconfiguration, we could read the system’s clear-text password and able to gain access to systems and dump credentials for later use.
We quickly exploited this misconfiguration and added ourselves to the group. This gave us access to read the LAPS password of all systems. As we started to dump more credentials, we found one of the domain admin clear text credentials in the process. Unfortunately, we were neither able to gain access to the domain controller nor were we able to perform authentication with the credentials.
Using the newly found LAPS access, we did gain access to various other systems but were unsuccessful to gaining access to the Domain Controller, which was our primary objective.
But…
As we were getting ready to accept defeat, we noticed that one of the compromised users was also a part of the “Backup Operators” group. Voila. Backup Operator member users can also perform backup on the Domain Controller. With this back door, we hit Gold! With the machine account, we successfully dumped SAM. Using “secretdump” we dumped all the hashes from the domain controller. After dumping all the hashes, we performed the password cracking operation with our wordlist and cracked around 300 passwords successfully.