Binary and dll payloads not working about scarecrow HOT 10 CLOSED

I scanned the control .cpl with a non distributing scanner to check the detection rate, avscan.net. I avoid VirusTotal as they end up creating signatures due to running payloads in sandboxes. You can also use antiscan.me which is free and doesn't distribute.

The major AVs have signatures on the payload. 6/26. I was trying to find the signatures by changing the code but I see a lot is obfuscated already, I'm unsure where the signatures are as it's a big code base.

The control .cpl payload works with Covenant shellcode but the binary and dll payloads don't. I think the issue is the same as the other issue reported as Covenant also uses donut to generate shellcode.

from scarecrow.

Same problem with Beacon too. I generated 10 times and it only worked with WINWORD.exe, other names it seemed to just exit after pointer allocation. Direct clone off github.

from scarecrow.

I am gonna need more information, but my best guess is that it's staged but again I would need more information. I am kind of curious about an endpoint that has 6 AVs from an endpoint performance side. Are you able to provide any information on that front?

from scarecrow.

I can confirm that as well

from scarecrow.

So all of this leads me to believe that it's an issue with the shellcode. All, CPL, DLL, Excel, MSiexec, and Wscript loaders are identical code, the only difference is the file extension and the export function. If CPL worked and DLL didn't then it's something to do with the shellcode used. In the case of the other active issue you mentioned before, all DLL and CPL loaders were working not just one. Being that it could be an issue with donut or as I asked above, "was the shellcode staged stageless?" Please let me know so I can see what's going on to better help you.

Also, do you get the same issues with a different C2 like Mythic?

As for the comment about AV (and please note this is just my belief but sites like anti scan.me are often full of false positives and call things out on these detections sites. Most of them just flag on "something suspicious" like the age of the file (based on the compile-time or length of strings stored) but provide no details. I feel to truly test things, you need to build a testing lab of products or use tools like https://github.com/matterpreter/DefenderCheck. But that's just my thinking on the subject.

from scarecrow.

Am I right in saying the dll payload can be run from cmd.exe with the following command:

rundll32 example.dll

I was trying that with Covenant but I think the shellcode is staged, I will try Mythic today.

As for the AVs the big players like Kaspersky, ESET, Microsoft Defender are all flagging the control .cpl payload as a trojan gen. I will attach a screenshot for you.

from scarecrow.

These are the signature detections for the control .cpl payload. The detections by Kaspersky, ESET, Windows Defender and ZoneAlarm are not likely to be based on the payload age.

I have a lot of experience in AV detections, these will likely be detections on a part of the code. I was tying to figure out what they had the detections on as you use random names for function and variables names, I even tried modifying the Cryptor code to change the random names, these detection persisted though, so some of the code must be static for them to create these detections.

It's a large code base, I spent a few hours trying to find the detections and remove them, but I wasn't successful.

from scarecrow.

After retesting I got it working with Mythic.

from scarecrow.

So a lot to address but here we go.

Rundll32 requires you to specify an export function to run. If you are just typing the command rundll32 example.dll then it will not work. You can try some of the standard export functions like DllRegisterServer, DllGetClassObject, or DllUnregisterServer. The formating would be rundll32 example.dll,DllRegisterServer. If you do not want to use an export function call then I would recommend you try with Regsvr32. With Regsvr32 you just need to run regsvr32 example.dll please keep in mind loading a DLL with Rundll32 or Regsvr32 that has the same name as a valid system DLL will cause problems, in this case, its best to change the name slightly. Regarding the binaries, if you can replicate this try with the -console mode and sending me the output this would help narrow down the problem.

As you mentioned previously you were using staged shellcode, staged shellcode doesn't play nice with Scarecrow which is why I call it out. This is typicaly because the staged shellcode either opens up another process (in which case the EDR unhook mechanism is not present and in some cases crashing the scarecrow process) or creates another thread closing off the existing thread (which scarecrow exits on). If you are still having this issue with stageless for further testing can you try doing this with -injection C:\Windows\System32\notepad.exe (this option handles process injection really well) to see if it is the exit on thread or possibly something to do with allocation. I don't think it's fair to say that the issue is Scarecrow doesn't work with donut. Since up until a couple of months ago it was working fine. code can change and bugs can be introduced it's a matter of fixing said bugs.

Regarding your detection comment, my statement was more so around the accuracy and validation of these results. For example, if you look at your payload where you called covenant based loader (which is what I assume the picture above is from) Windows Defender calls it out as cobaltstrike. If you look at this report from 2020 you will see that many of these products were identified to have numerous False positives. https://www.av-comparatives.org/tests/false-alarm-test-march-2020/. All I am saying is I've been doing this a while and services don't ever give a fully accurate picture of a situation and building an environment to test them in is arguably more reliable.

@vysecurity your issue is quite strange and different than this one as you mentioned you were using cobalt strike's beacon. I'm assuming in all 10 of your test cases you were using the default binary loader mode. If that is the case then it's very odd since the code never changes, only the file attributes chosen to use, which would not cause any issues to the execution flow. If you can replicate this try with the -console mode this should provide a verbose error message when it fails. Would mind confirming that you are using stageless shellcode and if if the same issue happens with you use WScript or control loader or if it happens -injection C:\Windows\System32\notepad.exe.

Please let me know so I can continue to troubleshoot this.

from scarecrow.

Heya mate. I just retested and can confirm the dll Loader is working with Mythic. The issue must have been the staged shellcode from Covenant. Sorry about this.

I agree with you, the signatures AVs give are usually totally wrong.

I will close this issue.

from scarecrow.