I find myself doing the same things over and over again, and when that happens it's time to automate! After all a 'fire and forget' script that automatically gets Domain Admin has always been the dream right?
Luckily for me a lot of other awesome people (see the Shout Outs section below) did all the hard stuff already. Additionally, Empire introduced a RESTful API a while ago making the creation of third-party scripts that interact with it a breeze.
Before I continue, I'll take this opportunity for a rant: getting Domain Admin should NOT be the sole scope of your pentest and if it is you are doing it wrong. You should be focusing on post-exploitation, trying to find sensitive PII, documents etc.. anything that can clearly demonstrate to 'management' how much it could have impacted the organization if it were a real world compromise. However, having Domain Admin access does make life easier, provides additional value to the client and tends to make an impression on the Blue Team.
Project goals and implementation
Originally, I wanted something that could just take BloodHounds output, parse it, feed it to Empire and make it follow the 'chain'. However, BloodHound does not take into account (at least to my knowledge) paths that could be achieved using domain privilege escalations such as GPP Passwords in SYSVOL (I personally find that one an almost every engagement).
So I wanted a more 'active' version of BloodHound with 'worm like' behavior. Additionally, Empire has most of the core functionality of BloodHound covered between all of it's modules and anything that BloodHound does functionality wise that Empire currently does not have a module for could be fairly easily implemented with one (e.g. the ACL attack path update, which is insanely awesome by the way)
I decided to just stick with Empire and automate everything using it's RESTful API. This would also give me the freedom to parse a module's output as I see fit and have more control over the overall logic and user feedback.
What's it doing under the hood?
The following flow graph details pretty well (I think) what DeathStar does better than I could ever explain in a blog post.
If you've pentested Active Directory recently, you should be familiar with pretty much everything in that graph. If not, feel free to hit me up and I'll be glad to answer any questions.
Currently, for Death Star to work you're going to have to install my fork of Empire until this pull request gets merged and the changes get pushed to master. The fork contains some API and back-end database fixes for scripts that interact with the RESTful API.
Clone the above Empire repository and install it as you usually would, then run the following:
python empire --rest --username username --password password
That will start Empire's console and RESTful API server.
To get DeathStar up and running:
git clone https://github.com/byt3bl33d3r/DeathStar # Death Star is written in Python 3 pip3 install -r requirements.txt # Supply the username and password you started Empire's RESTful API with ./DeathStar.py -u username -p password
If all goes well Death Star will create a http listener and you should see a 'Polling for Agents' status: this means you're authenticated to Empire's RESTful API and DeathStar is waiting for that first Agent.
All you need now is an Agent on a domain joined machine, how you do that is beyond the scope of this blog post. I'd recommend using CrackMapExec but I'm biased.
What does it look like in action?
Once you get that first Agent, DeathStar will take over and the magic will start.
Here are a couple of videos of DeathStar obtaining Domain Admin in two different scenarios.
In the first video, it elevates Domain privileges using the GPP Passwords in SYSVOL vulnerability, spreads laterally to the machines the GPO is applied to using the decrypted credentials and eventually lands on a machine with a Domain Admin logged in. It then enumerates running processes and PSInject's into a process (explorer.exe by default) running under the Domain Admin account giving us an Agent running under that security context:
In the second video, it actually obtains the Domain Admin's credentials using Mimikatz and abusing local admin relationships:
One thing that I'd like to point out: although these two videos take advantage of credentials in one way or another it is possible for DeathStar to obtain Domain Admin rights simply by using a combination of local admin relationships and PSInject without ever using a set of credentials.
Stuff that I'd like to see added
There is so much more that could be done with DeathStar: more domain privilege escalation techniques could be added, more lateral movement methods, the logic could be fine tuned a bit more, we could do some post-exploitation and SPN shenanigans etc.. The current release is definitely a rough first draft.
The game changer would be SMB Named Pipe pivoting. Once that's in Empire this will truly 'walk and talk' like a worm.
DeathStar demonstrates that automating obtaining Domain Admin rights in an Active Directory environment is a clear possibility using existing open-source toolsets. I expect to see many more tools that do something like this in the near future (I personally know two people who are working on their own versions/implementations which is awesome, and I encourage more people to do so)
One final point I'd like everyone to reflect on: I put this together in 3-4 days. Imagine what a bunch of much more smarter people than me could do/have already done with more time and resources (cough cough nation states cough cough). That's something that I think is particularly interesting.
None of this could be possible without the amazing research and hard work of these people (you seriously should be following them everywhere), and I'd like to personally thank them for their constant support and encouragement :)Go Top