In May of 2014, Microsoft released Security Bulletin MS14-025. The vulnerability described in this disclosure could allow for the elevation of privilege if Active Directory Group Policy is used to distribute local administrator passwords throughout a domain. In this blog post, we will walk through an entire attack scenario centered around the use (and abuse) of this vulnerability.
This is the Active Directory Kill Chain.
Okay, so you have a foothold in an organization. You managed to phish a user on the domain, and you have unprivileged access to a Windows system. You tried every exploit you know, but to your dismay, the system seems to be up to date on patches and configured quite well.
It’s official: You’re stuck.
You could write up your findings as they are. After all, gaining unprivileged access to a system is a good finding, especially if the user is in a role that handles sensitive information, such as accounting or payroll.
What if, though, you could take over the entire domain and show how vulnerable the network truly is? You can say it’s all in the client’s best interest — which is completely true — but let’s not discount how freakin’ awesome this would be!
This guide addresses that: how to transition from unprivileged client access to full domain control. For demonstration’s sake, let’s assume that unprivileged access to a client’s machine has already been achieved. We’ll be working our way through to a file server on the network, and eventually to our domain controller.
One important (and scary!) note about this lab environment is that the domain has been configured exactly following Microsoft’s TechNet Guide. No intentional misconfiguration or vulnerable software has been added for demonstration’s sake.
Start by configuring four systems:
Let’s set the scene …
You have unprivileged access to a client machine (because you’re awesome like that). You currently have a meterpreter session on the machine, running as “John Doe.” You have tried local exploitation and the exploitation of misconfigured services on the machine, but you just can’t escalate to local admin privileges — let alone domain controller access.
Because you read this guide, though, you know that another option for privilege escalation is to see what you can get from the domain controller. You take the following steps:
Now, you have a plan and an unprivileged meterpreter session on the client. Let’s begin!
Now that we have access to the local administrator account that is pushed through group policy to every system on the domain, let’s make this work for you. This section will describe how to pivot through the network using these credentials.
Thus far, you have gone from an unprivileged user to possessing the domain administrator’s credentials. The last steps are to log on to the domain controller and take some compromising screenshots for your report.
Whew! We quickly and realistically went from an unprivileged user to a full domain admin. Keep in mind that the scenario outlined here is common. The only instance in which you may lack the domain administrator’s credentials will be with your first system; otherwise, having the domain administrator’s credentials (you may have to try a few infrastructure servers) is fairly typical. All configuration steps for each system were taken directly from TechNet (Microsoft resources), and the chosen operating systems are not only up to date, but often found in corporate environments.
Unfortunately, there is no direct way to prevent the abuse of Group Policy in this way. This is simply how it works. A few suggestions to work around the Group Policy issues are:
Apart from that, this is a simple question of risk analysis. Hopefully, penetration testers and security engineers alike agree that the risks far outweigh the benefits, and do their due diligence in securing the infrastructure that powers their business.
Kevin Sugihara and Matthew Gleason presented on this topic at the Phoenix Security & Audit Conference 2015 on Sept. 10, 2015.