metasploit-framework
metasploit-framework copied to clipboard
Msfvenom fails to generate stageless meterpreter dll
When generating a stageless meterpreter dll with msfvenom it fails with the following error:
msfvenom -p windows/meterpreter_reverse_tcp -f dll
No platform was selected, choosing Msf::Module::Platform::Windows from the payload
No Arch selected, selecting Arch: x86 from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 885806 bytes
The EXE generator now has a max size of 2048 bytes, please fix the calling module
Other formats seem to work fine.
@Slurpgeit as a temporary workaround, please do:
./msfvenom -p windows/meterpreter/reverse_tcp -f dll
So it looks like some payload modules have a CachedSize, and that probably should be used instead of the hardcoded max_length value (2048). I just heard from @bcook-r7 that CachedSize is being changed to an actual min/max value, so maybe we need to wait for that to happen before implementing a fix for this one.
This is more of a request for enhancement.
This sounds like a similar issue to the one we had when we first worked on the exe format stuff. @hmoore-r7 is in a better position to comment than I :)
Stageless DLL support is not currently implemented (the stage is too big for existing templates/methods).
I ran across this on a pentest where for some reason stageless meterpreters would get past their detection, but the same payload in a normal staged meterpreter would get caught. When we tried building a DLL, it failed. We ended up having to scrap the method we were using :(
Even though we had to make sometimes 4-11MB payloads (once they were encoded in a verbose format), it was SUPER useful to have. It'd be nice if DLLs would work the same way.
All in good time my friend, all in good time! :)
Stageless does indeed seem to be a winner for AV bypass. One thing I think we should probably add the ability to do is specify the name of the new section that is used when the exe is generated. Because $REASONS.
Are there any plans for progress on this?
Edit: A workaround for others with this issue. You can recompile the .dll found in the templates directory (search for "template.c"), and use that as a template with msfvenom.
- Change SCSIZE to a value large enough for your payload
- Compile the dll (I used build.sh for an x86 one)
- Modify the size check in msf/util/exe.rb
- Use msfvenom and specify your new dll as a template
Still an issue in 2021
Still an issue in 2022
still an issue in 2023
@smcintyre-r7 are we good to close this one now?
I can't believe my eyes! 😄
Going to go ahead and close this since the original issue reported here should now be fixed with the changes above, which I went ahead and tested as part of landing this PR. Support for doing this with non-default DLLs however has not been fixed. If support for this is desired we should track this in a separate issue.
If I've made any mistakes though feel free to reopen this issue and clarify things 👍