search

rapid7 / metasploit-payloads

Unified repository for different Metasploit Framework payloads
Other
1.75k stars 673 forks source link

Alternative Injection methods... #349

Open pussinboots1992 opened 5 years ago

pussinboots1992 commented 5 years ago

Hi all,

Some good AV's are catching reflective dll injection and stagers which makes using meterpreter unfeasible since it is entirely based on it...It would be nice to be able to inject the meterpreter and the subsequent modules using alternative injection methods. Even if they are a little less stealthy and would require obfuscating the dll on disk...

I though using stageless meterpreter's would have been a good alternative but it also uses reflection. I also tried the universal unhooking extension hoping it would remove the hooks that these AV's are setting up but that didn't workout either...

Any thoughts ? @busterb :-) Could "someone" do a little writeup (or at least a summary of how it would be done at a high level) on how a metsrv.64.dll (and auxiliary modules such as priv and stdapi) could be loaded using a different injection technique without using any bootstrap shellcode in the dll's header or a regular stager :

CreateRemoteThread() NtCreateThreadEx() QueueUserAPC SetWindowsHookEx() RtlCreateUserThread() Code cave via SetThreadContext()

Would be awesome ! Could also be an idea for the evasion modules...

PS: How can I debug the reflectiveloader.c using dbgview and dprintf ? Can this be done in this piece of code ?

smcintyre-r7 commented 4 years ago

Well we've made a bunch of changes that would have (temporarily?) addressed any signature based detections on the ReflectiveDLLs and their loaders in version 6 which was just announced on Thursday August 6th, 2020. This should be retested to confirm that it's still relevant.

If it is, I'm afraid we're going to need more information than just "some good AV's". We need to be able to reproduce scenarios under which Metasploit is being caught before we look to make any large scale changes. If you find that Metasploit is still getting caught please let us know how you're running your test(s), and against what AVs it's being caught. I'd also like to avoid over-fitting a solution into the framework for an edge use-case against a single AV, so the more evidence you can provide that would indicate this is the limiting factor and that addressing it would provide a net benefit the higher the chances are we can seriously look at making these changes.

Thanks!