Home Grown Red Team: From Workstation To Domain Controller With Havoc C2 and Microsoft EDR
Welcome back! In this blog entry we’ll be facing off with Microsoft’s Defender For Endpoint EDR once again to see if we can go from a low integrity context to Domain Admin and get remote code execution on a Domain Controller!
Over the past couple of months I’ve been diving into different techniques to see what we can do with open source tooling against one of the most popular EDRs out there.
In this blog I’m going to go over some common concepts of getting onto a Domain Controller but with different techniques that I’ve found.
These include:
- UAC Bypass with a UACME custom binary
- Lateral movement with CrackMapExec and SharpWMI.exe
- Session passing to Covenant
- DCSync with Covenant
So let’s get started!
Havoc C2
I’ve already covered how to get Havoc up and running. If you’re unfamiliar with it, you can check out my post Getting System On Windows 11 With Havoc C2.
With my C2 up, I’m going to generate some shellcode and run it through my own shellcode tool, Harriet.
Now that I have a FUD binary, I can transfer it to the first workstation in my AD environment.
As per my previous posts, we have an extremely small AD environment here. For the purposes of time and blog space, we’re going to start off with a known DA in a medium context.
I transfer my implant over to Win11-Blue.blueteam.local and get our initial beacon back.
Let’s check on the EDR and see if initial execution made it through.
All quiet! Okay! We can move on. Doing a simple “whoami” command shows us that Danny is in the DA group.
Running SharpUp tells us that we can do a UAC bypass to get admin privileges.
Custom UACME Binary
In a previous post I used the ComputerDefaults method of getting admin, but that is currently being caught by Defender For Endpoint. We want to get DA without an alerts, so we’re going to do something outrageous: drop something to disk!
On my Windows 11 Development machine, I clone the UACME project.
git clone https://github.com/hfiref0x/UACME.git
We load the sln file and we have our project loaded.
When compiled, the UACME binary is named Akagi, so we’re going to start customizing the files found in that section of the solution explorer.
Expanding the project, we see several sections for header files, resources, ect.
We can start out our process by doing a quick find and replace for common strings found in the project.
Some of the other strings we can replace are below:
Akagi
UACME
UAC
PAYLOAD
If we try to build the solution now, it fails.
It can’t find the icon file because we haven’t changed it’s name. So we need to change it’s name in the Akagi folder.
Once we change the name of the icon, it builds successfully.
Now if we look at the built binary’s details, we see that there are some telling properties.
We do a quick search for APT 92 in our project, we find the Resources.rc file with these descriptions.
Going through the Source files, we see the methods folder.
Each of these method files represents different UAC bypasses to be used in the compiled binary. If we go through each of these methods, we see various comments with the method names. To get past Defender and other AV engines, we need to delete these comments from each method file.
Removing all of the comments from the methods files can take a long time, but we should only have to do it once before having a binary that doesn’t get caught by AV.
And after we have removed all of the comments from the file and recompile, we get our binary. Running it against AntiScan.me we see that we have bypassed several AV vendors.
Scanning it against Windows Defender, we see that it’s not detected.
Getting Admin
Back on Havoc, we just need to upload the binary to our target.
Let’s check in with Microsoft’s EDR to see if we got caught yet.
Doesn’t look like it. Let’s proceed!
With our UACME binary on the target, we need to execute it with our method. Powershell and shell commands could get us caught, so let’s use WMI. Luckily, SharpWMI allows us to run the commands in memory.
But first, we need a method for Windows 11.
59 looks good. Let’s call our method with SharpWMI.
dotnet inline-execute /home/user/Desktop/SharpWMI.exe action=exec computername=WIN11-BLUE.blueteam.local command=”C:\Users\danny\Downloads\Acaji.exe 59 C:\Users\danny\Downloads\Inj3c13.exe”
And we get our Admin beacon back!
Checking back on our EDR, we have no detections.
Great! So now that we have determined that we can get code execution without triggering the EDR, we can use this same method to move across the domain to the DC.
NOTE: Of course you wouldn’t do this in a real world application. We have a DA so we could just DCsync, but we want to see if we can move without alterting the EDR.
Lateral Movement
So on WIN11-BLUE we had the ability to upload our binary, but how do we do this when we don’t have a beacon on the DC?
In a previous post, I proved that we could do this with Powershell and a scheduled task. In this write-up, we’ll use a different method. We’re going to upload our binary to the target using CrackMapExec and then call it with SharpWMI.
Setting Up For Our Attack
So for this POC we’re going to pretend once again that there is a top secret document on the DC that we need to exfil. The first thing we need to do is get either a password or a hash for our user Danny.
Since we’re admin, we can use several methods to get hashes but the easiest for me is to session pass over to Covenant and use their DCsync command.
So on Covenant, we set up our shellcode file and download it to our local system.
For simplicity, I’m going to change the file name to grunt.bin and then I’m going to run it through Harriet. This will encrypt it so we can get past the EDR.
Now that we have a binary, we can use Donut to turn it back into shellcode.
And the last part is to inject it into our Havoc executable’s process.
With the shellcode successfully injected, we go over to Covenant and we have a new grunt checking in.
Let’s take a peek over at the EDR.
Nothing to see here! We can move along!
Back on Covenant, we can use the DCsync command and get Danny’s hash. And after a few seconds, Danny and the domain have been owned.
All right, cool. So we’ve demonstrated that we can get a DA’s hash. But what do you do with it once you have it? Remember, the goal of our execise wasn’t to get domain control, it’s to get the secret document on the DC.
Moving Onto The Domain Controller
We have a FUD executable that we need to upload to the DC. For this, we are going to use CrackMapExec. So here’s our command.
crackmapexec smb 192.168.1.9 -u danny -H 83c4be1a3fd33a182dafc8bd3bf53d00 -d blueteam.local — put-file /home/kali/Desktop/Inj3c13.exe \\WINDOWS\\TEMP\\25N0v3.exe
We are using the SMB module and we have the IP to the domain controller. Then we use the username of danny and enter his NTLM hash. We have the domain and then use the “ — put-file” command with the path to our FUD executable and then directory we want to drop the file to on the DC.
Let’s give it a go.
And just like that, our executable is on the DC! Now we need to call it. We can use SharpWMI.exe to do this in memory just like we did with WIN11-BLUE.
And now we have a beacon in high integrity on the DC!
Let’s find the loot!
After a little enumeration, we find it in Danny’s Documents folder.
Let’s download it.
Before we take a look, let’s check in with the EDR.
What’s this thing even good for?
And here’s the loot!
All right! So in conclusion to this write-up let’s talk a little bit about what we did and how we did it.
We started out with a low integrity beacon and escalated our privs by creating a customized UACME binary that got past Windows Defender and Windows Defender for Endpoint.
We then called the UACME binary with SharpWMI.exe in memory for a more stealthy approach to Powershell or the shell commands.
Once our privs were maximized, we did a session pass over to Covenant to use the DCsync command to get the DA’s NTLM hash. We then used CrackMapExec to upload a beacon onto the DC and called it using SharpWMI.exe.
So, how was this environment rigged for our success? WMI is not turned on by default for Domain Controllers, Windows Servers or Windows 11 workstations.
However, in a modern corporate environment most of these machines will have WMI turned on to give the sysadmins an easier time in troubleshooting. We also started our journey out on a DA’s account, but that was just to make things a little more convenient for the write-up.
It’s also important to understand that we didn’t have any other AV installed on the systems. If you recall, BitDefender saw our UACME binary as malicious. So, be careful when using it on a real pentest.
If you enjoyed this write up and want to see whatever else I’m doing, follow me on here or on Twitter @assume_breach
