Newb payload generation/evasion question

[7MinSec]

Hello!

I'm finding that Windows Defender is gobbling each and every payload I throw from ScareCrow at it, and it feels like I'm doing something wrong. Hope you could sanity check my process? Fair warning: I'm not new to pentesting but new to Cobalt Strike and not very experienced with EDR bypass techniques. In fact, seeing this video on ScareCrow is what inspired me to finally buy Cobalt Strike!

Anyways, I start in Cobalt Strike:

1. Attacks > Packages > Payload Generator > picked my listener > chose output of "raw" > ticked the box for "Use x64 payload" > saved that to ScareCrow folder on Kali VM. I also tried Attacks > Packages > Windows Executable (S) to get the export as well.

2. From Kali VM, tried generating a variety of payloads from Scarecrow. They generate successfully with no errors.

3. From my Win 10 19041 box, tried firing the payloads in several ways (drag and drop directly to disk, fire with msbuild, fire with PowerShell, fire with rundll32, etc.) and Windows Defender happily gobbles them up.

I thought maybe it was just Defender getting wise to some of ScareCrow's shenanigans, but it looks like folks have no problem fooling Defender - at least as of this very recent blog post that I saw someone tweet.

Any ideas?

Thanks! Brian

[Tylous]

So it sounds like it’s your shellcode being caught not the techniques Scarecrow uses. First and foremost always use stageless shellcode, staged is easy to detect. The next thing I can think of is the type of listener your using. If your using http then that could be a problem as the communications is unencrypted. You don’t to have a real cert with cobalt strike you can use a malleable c2 profile to give it a self signed cert.

[7MinSec]

Thanks @Tylous . I bought a domain name, pointed it to my AWS box, then used C2concealer to create a LetsEncrypt cert for me with a malleable c2 profile, which I'm running in CS. I then setup an HTTPS listener and, as mentioned above, have tried a bunch of payload generators out of CS to use in tandem with ScareCrow. So I don't think anything is going unencrypted.

Maybe tomorrow I should try using something like msvenom instead. Any other ideas?

[Tylous]

based on the tool you linked I am pretty sure it's your C2 profile. While I only did a quick look I didn't see some of the IoC's Defender commonly looks for stripped out. I would suggest you look through Mudge's articles and learn a bit more about what you can strip out.

[Tylous]

Closing this due to lack of response. I will be releasing so content shortly on more advanced tradecraft tips.

[7MinSec]

Quick update: I've got good payloads getting generated out of ScareCrow now. My issue (I'm pretty sure) was that my artifact kit was not configured properly, so the payloads coming out of CS were vanilla. Would that make sense? I went through the exercise to, for example, modify the dist-pipe code, loaded the artifact.cna and THEN exported shellcode.bin.

Once I got that part working, a run of Scarecrow -I shellcode.bin -etw -domain www.microsoft.com made a Word.exe that Defender happily ignores! Thanks for such an awesome tool!

[qgrosperrin]

Experiencing a similar thing. I thought it would be my stageless shellcode causing detection, but Defender has a static detection on a dll generated using ./ScareCrow -I blank.bin -Loader dll -etw -domain domain.com -sandbox (where blank.bin is the first line from my stageless shellcode).

So as I understand the shellcode is encrypted anyway, so if Defender is catching the DLL at rest without any execution it must be flagging something on the template.

Any ideas ? I tried removing the -etw and -sandbox options thinking it might be related, but it's still detected.

Do you have any thoughts on using https://github.com/burrowers/garble to obfuscate the build ? Thanks

[Tylous]

Someone was able to provide me a sample and turns there is a bug in the code logic with one of the rules around splitting the shellcode on so it's not one long b64 string. This could be the cause of the alert, as it's firing o the fact something suspicious b64 string. I've pushed an update to the code please let me know if it's resolved for you.

[qgrosperrin]

I can't test right now, but will do in a couple of weeks. Thanks !

[7MinSec]

I just grabbed the latest Scarecrow and tried this...

sudo ./ScareCrow -I rawdog.bin -etw -domain www.microsoft.com -sandbox

....and Defender is eating it up right away.

Not sure it makes a difference, but this is the same shellcode I used for the update I posted a few weeks ago when the exe was not getting caught by AV. Now it looks like the original beacon I made, as well as this newest one tonight, both get eaten by AV.

[Tylous]

@braimee I need more information. Since Defender does not use any EDR hooks, the unhooking component doesn't affect the defender. The patch I was referring to regarding the b64 string only affects CPL and DLL based payloads the command you showed above is generating binaries as a result they were unaffected by this bug. This patch ultimately addressed the Defender alert "Win32/Wacatac/B!ml" (which means there is something suspicious i.e the full b64 string). If your alert is not this thenI think your bug is still 1 of 2 things or a combination of the two. The first being not using stageless payloads the second could be your profile leaving IoC's.

[7MinSec]

Thanks @Tylous, I'll work in the lab on this a bit this weekend. Again I'm newbish to this so I was trying to be helpful for troubleshooting, but now understand my testing wasn't applicable for Defender. Thanks for clearing that up.

I've got a project coming up so I'm going to spin up a new CS server, new domain, new LetsEncrypt cert and new malleable C2 profile and then generate another ScareCrow payload and test detection again.

[qgrosperrin]

The new version did indeed resolve the AV signature issues I was having. Thanks !

[Tylous]

Glad to hear it.