Guest post by team member @taso_x
After posting here some people on Twitter reported that they couldn’t replicate the functionality with Empire and Kaspersky. The current lab workstation i am testing on is a Windows 10 with Windows Defender and Kaspersky Endpoint Security 10.
Since the release of the new Empire a few days ago, getting call backs from hosts with Windows Defender is not a problem as the payload doesn’t get blocked.
Things get interesting when we encounter hosts that have both Windows Defender and Kaspersky Endpoint Security as this was the case during a recent engagement. Kaspersky will gladly block all PowerShell Empire payloads and complain when we try to run them. So what we did to get through this obstacle is what we always do, we replicate the setup in our lab and experiment. We are not trying to find 0-days as that would beat the purpose of a legitimate penetration test / red team engagement but to actually leverage on what we have in hand. We will again use a tool that we really like and that is no other than Invoke-Obfuscation by Daniel Bohannon. The Github page for the project can be found here.
In this scenario, to get the actual beacon call back from the victim we had to obfuscate the empire launcher 2-3 times using Invoke-Obfuscation. If that doesn’t make sense read here
The difference with the previous blog post is that here we don’t do any selective obfuscation, rather we obfuscate the entire thing after we base64 decode it.
Here’s how the decode payload looks like. We only case about the base64 encoded data.
Attempting to run the payload as is results in an access denied error.
To bypass this it is a matter throwing the payload in Invoke-Obfuscation and running COMPRESS/1 a couple of times hoping that this would confuse Kaspersky enough to let the script execute.
The command executes fine and we get a beacon in Empire.
Simple yet effective!