Written a loader/dropper in C, have a question about Meterpreter

Malware
1

Greetings all,

The forums here look full of great information, very exciting and informative!

I have written a shellcode loader / dropper in C, which uses an encryption scheme and successfully decrypts the payload in memory. The payload bypasses Windows Defender ( Windows 10 is the test environment ) , and i gain a reverse meterpreter shell. The payload i have encrypted is a reverse meterpreter staged payload and like i mentioned, i gain a reverse shell.

When i use certain functions, i.e if you drop into a shell/cmd prompt for example, Windows defender flags it and catches the payload and thus kills the shell.

I do recall a few tutorials and videos mentioning the use of Syswhispers ( i think it was a video on Shhloader and something by F-Secure ) although i cannot find these resources.

Could someone please let me know what i need to look in to , to get this working where by my revershell meterpreter activity is not flagged or caught. I believe it is something to do with the system calls or functions meterpreter uses.

Any help would be greatly appreciated :smile:

Cheers

2 Likes
2

Just use theatcheck on the shellcode to see if it gets flagged, then run something like Loki to check the in-memory payload. I’d recommend just building your own shell. It’s not that difficult and it would be a good exercise for you. As for inline-syscalls, heavens gate, taurus gate, hells gate, recycled gate, etc (all the gate techniques) and other techniques for resolving syscalls at runtime can be looked up easily but here’s a starter.

3 Likes
3

Thank you! That is exactly what i needed , and great info :slight_smile:

Theatcheck, i may use that, but the payload successfully decrypts in memory and does not get flagged, it connects back to my listener without any issues. I can run basic commands until i believe a syscall of some sort triggers Defender to act ( and quarantine the .exe )

Thanks, i am looking into the *Gate techniques and i am familiar with one of them ( heavens gate ) .

I am going to build the implant with the added SysWhispers3 headers and files, hopefully that works.

Thank you so much, i just did not know what i was looking for :smiley:

1 Like
4

Just another update on this, i have traced my implant in a debugger, there does not seem to be any userland hooking being applied to syscalls and functions such as :

CreateProcessW
CreateRemoteThreadEx

But these functions are what trigger the AV to flag once i drop into shell from a meterpreter prompt.

I am assuming i would need to hook this functions dynamically, and call the Native API alternatives instead so that they do not get flagged?

Cheers

1 Like
5

So there are other ways to bypass defender, like making the thread stack so large that defender gives up, making sure the entropy of the shellcode is around 3/4 (readable text), putting code that makes your program stall which might trip the time allotted to scan your binary, if you mix that with legitimate Win32 API calls that have no meaning (junk code) you might end up being more successful.

It also has to be mentioned that AMSI bypasses are still hot, so if you can just turn your loader into shellcode, bypass AMSI and self-inject, to run the real payload stored somewhere else, you’ll probably have a better chance.

There are ObRegisterCallbacks, and ETW event (providers) sources and (consumers) sinks that allow for hook-less monitoring of processes. Since MsMpng.exe has PPL protections, is signed, and has a driver to back it up it’s safe to say that when dealing with defender most of the detections are going to be User Defined Behavior that result in triggers. Detecting process injection, Bypassing overview with OPSEC

“As an example, Defender logs most remote thread creations as labeled events, but low file prevalence is not good enough of an indicator to trigger an alert, and there is more advanced logic in play - true for most decent EDRs.” - https://blog.redbluepurple.io/

The most preferred method for injection, if you have to do it, is to self-inject. It’s much rather preferred to set up a type of persistence, drop to disk, then stop executing. Because in the eyes of the A/V or EDR there’s no CreateRemoteThread or NtCreateThreadEx if a process starts up and does no remote injection into another process.

Also making your program look like it belongs on the system helps a lot via PPID spoofing, command arguments spoofing, module stomping, function stomping, encrypted heaps (in tune with using HeapAlloc instead of VirtualAlloc), encrypting return pointers, copying resources from well known binaries and singing those binaries with self-signed certificates that mirror legitimate companies. All help with staying under the threshold of detection.

4 Likes
6

Thank you very much for the detailed response! Looks like i have a long way to go. My implant is working with Meterpreter, how ever its not very sophisticated at the moment and does not incorporate half of what you have written.

Guess i have more work to do :slight_smile:

Also, is there a page on AMSI bypasses that is a good resource. Most of the AMSI bypasses i know are knowlegde from Powershell bypassing such as concatting / splitting strings or function calls and then invoking the expression. I am wondering if this is what you are referring to?

Thanks for the great post again, cheers!

9

The AMSI bypasses were in the one of the articles. Most of the effective AMSI bypasses are still just regular concatenation while patching a couple bytes, or just the jmp.

1 Like
10

@c0z thanks for these resources. really helpful for hardcore red teamers :handshake:

1 Like
11

@c0z , thank you for the resources :metal:

12

cool stuff. thanks a many. booyakasha!

13

This topic was automatically closed after 121 days. New replies are no longer allowed.