Windows Defender flagging out the dropped DLL

[weejing]

Hi, i tested out this framework recently but it didn't work that well for me.

In my scenario, i made use of the web delivery portion to deliver my javascript payload. When the javascript file was executed, it connects back to my attacking web server to get the shellcode (A http meterpreter payload). However that was where the problem arose. From the Windows Defender log, i could see the DLL (meterpreter stager) being dropped onto the AppData\Local\Temp folder, causing windows defender to flag it out as malicious. I'm not sure what's causing this as based on what i read from the readme, the stager should actually be loaded into memory?

[Arno0x]

Hi,

At the stage where the stager meterpreter shellcode is executed into SharpShooter's memory, that's when this shellcode downloads the meterpreter stage DLL over HTTP. This should all happen in memory, so this problem should not be related to SharpShooter's code at all.

Are you sure it's the meterpreter stage DLL that is written in the AppData\Local\Temp folder ?

I have tested the same scenario you describe, it works, and I don't get any DLL dropped on disk.

[weejing]

Hi, I'm pretty sure it is the meterpreter stager instead of the stage DLL(which should never touch the disk ) base on the windows defender logs. I'm basing this assumption on the information I got from my sysmon event logs as well. Written below is a rough summary of what I have observed from the sysmon logs.

(1) Wscript running the js script file (2)csc.exe compiling the .net dropped file (3) Sending a get request to get expoit.payload(shellcode) from my attacking machine

At this point, i got an alert on my windows defender, informing me that it has found a meterpreter dll dropped onto the AppData\Local\Temp folder. The alarm was tagged as Win64/Meterpreter.D This is most likely the meterpreter stager code that would be used to connect back to my attacker machine to download the stage DLL into memory and reflectively load into a target process. I'm quite sure it's the meterpeter stager code as I don't see any staged DLL being send over from my attacker machine.

The machine that I'm using to test right now is a windows 10 machine but I don't think that should be an issue. May I know what machine are you testing this on?

[Arno0x]

Ok, I get your point.

In my understanding, the stager shellcode is in the bytearray embeded into the C# code compiled with csc.exe. So that might be the resulting .Net assembly (as a DLL), being dropped on temp folder on the disk, containing the meterpreter stager shellcode, and this triggers Windows Defender.

Can you by any means get a version of the DLL that causes the AV alert ?

What you could also do is compile yourself the C# code on another machine without an AV (VM or whatever) and then check that it's this DLL causing the alert.

My understanding of SharpShooter workflow is the following:

1. The JS stager is executed by wscript.exe.
2. It contains an embedded .Net assembly executed in memory thanks to the DotNetToJScript technique.
3. The expoit.payload is downloaded (in the case of a webdelivery), it is then b64 decoded and unzip in memory, which result in a C# code to be compiled at runtime. This C# code contains the meterpreter shellcode as byte array.
4. The C# code is compiled 'on the fly', so csc.exe is executed, and my guess is that the resulting .Net assembly is written on disk in a temp folder.
5. The just compiled .Net assembly is executed, which results in the meterpreter shellcode execution, which will in turn download its meterpreter stage DLL.

If think your AV alert happens at the end of step 4.

On my side I tested all this on a Windows 7 machine with McAfee AV (which sucks at detecting almost everything :-) )

[dmchell]

@Arno0x is absolutely correct, this is the exact workflow.

The resulting .Net DLL is temporarily written to disk as a result of csc compiling the C Sharp code. The actual command that gets executed will look similar to:

csc.exe /t:library /utf8output /R:"mscorlib.dll" /out:"C:\Users\Test\AppData\Local\Temp-1ccu4qb.dll" /debug- /optimize+ /unsafe /platform:x86 "C:\Users\Test\AppData\Local\Temp-1ccu4qb.0.cs"

So you can see the assembly for the shellcode.cs template will temporarily touch disk - this will contain a compiled copy of the meterpreter shellcode, which is probably what Defender is picking up.

So all you need to do is use something that is statically safe from Defender - probably just encoding it with some of the msf encoders may work, e.g. -e x86/shikata_ga_nai -i 10.

Were you using an encoder at all?

[dmchell]

I believe @Arno0x also has a xor shellcode wrapper also which would almost certainly work, you'd just need to patch your shellcode CS template to decode it first.

[Arno0x]

Indeed :-) You can use this tool: https://github.com/Arno0x/ShellcodeWrapper

This will create an CS template with XOR or AES shellcode wrapper. You can use this to patch the SharpShooter template or something like that :-)

[dmchell]

I'm going to close this just on the basis that it's not a SS issue....