Fix WinPEAS In-Memory Execution: Use Compatible .NET Execution Methods Instead of Injection into Notepad on Windows 10 x64 "#20434"

[Wopseeion]

Description
This PR addresses the issue where running the Metasploit command exec -m winpeas.exe -d notepad.exe on Windows 10 x64 causes the error "The parameter is incorrect" or crashes the Meterpreter session.

Problem Summary:
Direct in-memory injection of WinPEAS, a .NET executable, into Notepad fails because Notepad is a native Win32 process that does not load the .NET Common Language Runtime (CLR). This mismatch leads to session instability or execution errors.

Proposed Solution:

1. Replace naive injection attempts into Notepad with usage of the Metasploit post-exploitation module post/windows/manage/execute_dotnet_assembly designed for executing .NET assemblies in-memory.
2. Implement a fallback method using Meterpreter’s PowerShell extension (powershell_import and powershell_execute) to import and run a WinPEAS DLL directly in memory when the primary module is unavailable.
3. Ensure the code respects architecture compatibility (x64 payload on x64 targets) and avoids injecting into incompatible native processes.
4. Provide clear guidance to either execute existing WinPEAS files present on the target or upload and execute them via supported modules without creating unintended files or crashing sessions.

Benefits:

1. Reliable and crash-free execution of WinPEAS on modern Windows 10 x64 environments.
2. Elimination of the "The parameter is incorrect" errors caused by improper process injection.
3. Increased stealth and compatibility by selecting appropriate execution contexts with full .NET support.
4. Aligns with Metasploit best practices for .NET payload execution and process injection.

Testing and Validation:
1)Verified successful in-memory execution of WinPEAS via execute_dotnet_assembly across Windows 10 x64 versions.
2)Confirmed fallback PowerShell method works as intended on targets lacking the post module.
3)Tested architecture checks ensure no cross-bitness mismatches causing crashes.

[bwatters-r7]

Thank you for the PR! I understand this solution, but I think that it might not be the path we would prefer to take- we no longer support scripts (See @sinn3r's documentation here: https://docs.metasploit.com/docs/using-metasploit/advanced/meterpreter/how-to-get-started-with-writing-a-meterpreter-script.html)

Instead, if the root cause for the failure to inject is that the CLR is not loaded and working in the receiving binary, I think the best temporary solution would be to find a way to identify .NET binaries passed to the exec command on the Framework side and if used with the -m option, fail before trying to inject with a warning explaining why and guide the user to the .NET post module.

Alternatively, a cooler, longer-term solution might be expanding the Meterpreter exec command to support .NET binary injection via the same techniques the post module uses.

[Wopseeion]

Hey, what the new change you expect?? could you brief me with an example code and test case scenario too, so that i can get an idea about it

[dledda-r7]

Hello @Wopseeion, as stated by @bwatters-r7, the best first easy solution is to prevent the execution of the execute -m meterpreter command with a .NET binary. this can be done either on framework side or on meterpreter side.

framework side:

metasploit-framework/lib/rex/post/meterpreter/extensions/stdapi/sys/process.rb

Line 127 in 8ad35c0

def Process.execute(path, arguments = '', opts = nil)

metasploit-framework/lib/rex/post/meterpreter/ui/console/command_dispatcher/stdapi/sys.rb

Line 215 in 8ad35c0

def cmd_execute(*args)

or from meterpreter side:

https://github.com/rapid7/metasploit-payloads/blob/aa4c42a63d7cdd9051801d373d5ac37a3dba2077/c/meterpreter/source/extensions/stdapi/server/sys/process/process.c#L279

[bwatters-r7]

@Wopseeion any update on this?