PSExec Classic Module #2001
PSExec Classic Module #2001
Conversation
|
Hey, @jtesta. Could you please fix the msftidy warnings? Thanks. |
|
@jtesta I might have some ideas for the stdin problem. I'll look at the code, and try to catch me IRC as kernelsmith. I haven't been on there much recently but I am more available now |
|
@jtesta , @kernelsmith please feel free to update us if you were able to discuss the problem? thanks! |
|
I'm in the middle of switching to a new development machine so I haven't had a chance to look at it yet |
|
I ran mfstidy and fixed all the warnings. I'll drop by the IRC channel and we can work out the $stdin issue. Or, if its easier, I'd be happy to work on it myself if someone were to point me to some example code to use as a reference. |
|
I haven't checked out your code yet, but the grep command in msfconsole might help as it redirects console output temporarily. To find it just grep for cmd_grep I'll be on IRC in the afternoon and evening US time -Josh On Jun 25, 2013, at 19:11, jtesta [email protected] wrote:
|
|
I took a look at cmd_grep as suggested, but I'm not sure what to do next. Is the idea to somehow read input using the Msf::Ui::Console::Driver object? I don't know how to obtain a reference to that object, either. |
|
Regardless of its other merits, this simply can't be merged with the massive amount of copy-paste from |
|
@jtesta yeah, you'll definitely have to switch to using the Smb::Psexec mixin, but I'm looking now at your stdin issue. My dev env isn't quite back up and running yet, but I can still look at the code. I'll add comments if I see anything. |
|
I would also recommend pulling the psexecsvc stuff out into a mixin. There's some redundant code that could be refactored, and having a module would allow others to easily re-use your code as well as it seems you did some rev engr of the psexec svc and it would be great to have it available to others. I'm not sure of the namespace, but maybe Smb::PsexecSvc or does it belong with DCERPC? I'll look at the code again on that, but it would be very cool if someone could call something like send_dash_s to send the bytes corresponding to the -s switch, and you could have send_magic_ping etc. The whole thing would become much more readable. I will start a gist we can use to discuss the idea if it interests you: https://gist.github.com/kernelsmith/5874810. We can look at the stdin issue that way as well. That issue looks a little more complicated than I was originally thinking it might be. Ideally we could reuse existing code like a multi-handler. |
|
@jlee-r7: do you mean split off the MSRPC calls and put them into lib/msf/core/exploit/smb/psexec.rb? I originally wanted to do that, but I figured that for my first module, I should refrain from making architectural changes. Also note that the "psexec" function in that file would need to be split up too, since it makes the same MSRPC calls. I don't have a problem doing and testing this now... I just want to make sure we're on the same page. |
|
If they are generic enough I would create a new file for the msrpc methods. They shouldn't be specific to psexec and they technically aren't SMB right? @jlee-r7 thoughts? -Josh On Jun 27, 2013, at 14:00, jtesta [email protected] wrote:
|
|
@kernelsmith: Regarding splitting code into Smb::PsexecSvc: sure, we can do that. About the $stdin issue: it would be great if we could make a session background-able, kinda like Meterpreter sessions That would let someone run multiple cmd.exe's (or whatever) across many machines at the same time. No idea how to do this, though... |
|
I think we might need to look at multi/handler to see if we can bridge into that cuz we'd like to make it into a real session so it can be handled like any other session which would give it the functionality u mention -Josh On Jun 27, 2013, at 14:27, jtesta [email protected] wrote:
|
|
So, what do you want to do with this PR, @jtesta? |
|
No one has pointed me to working example code that substitutes for reading from $stdin, so I can't fix that. However, I can split off the MSRPC calls into a new into lib/msf/core/exploit/smb/psexec.rb file. I was waiting for someone to say this was OK, but I suppose I'll just go ahead and do it. I'll have it ready in a few days! |
|
The psexec library already exists! |
…reated new Exploit::Remote::SMB::PsexecSvc mixin as well.
|
I've split the MSRPC service calls into its own module. If this PR is accepted, we can also modify modules/exploits/windows/smb/psexec.rb, lib/msf/core/exploit/smb/psexec.rb, and modules/auxiliary/scanner/smb/psexec_loggedin_users.rb to use these new functions to cut out duplicate code from the codebase. |
|
@jtesta: Ping. |
|
Pong. Sorry for going MIA for so long. I'll update my code within the On 10/10/2013 03:27 PM, wvu-r7 wrote:
|
|
@jtesta: How's it going? |
|
Its going well! How are you? I suppose this is my ping to get moving on my PR, huh? I'll get this On 01/02/2014 12:43 AM, wvu-r7 wrote:
|
|
No worries, mate. There are conflicts, btw. Thanks! |
Conflicts: lib/msf/core/exploit/dcerpc.rb lib/rex/proto/smb/client.rb
|
Have you tried vprint_status? It should be picked up in Msf:: mixins afaik as datastore['VERBOSE'] is a hidden option thingy! |
|
Also dcerpc_services could probably be pushed into Rex::Proto::Dcerpc rather than Msf library as it doesn't have any Msf dependencies? |
|
This isn't working for me in Windows 7 at the moment: [] Creating a new service (PSEXECSVC - "PsExec")... I can see the Named Pipes exist in Process Explorer, but the 'Create AndX Request' for those Paths gives me a STATUS_ACCESS_DENIED PSExec works with same credentials over both SMBv1 and SMBv2 |
|
Hmm! Interesting. I'll take a closer look next chance I get. Thanks On 01/16/2014 12:15 PM, Meatballs1 wrote:
|
|
Is there any way to pull out the necessary stuff generically without having to store a hash of supported files? This is going to be a maintenance nightmare. |
…-server communication. The changes to the code don't look too signficant, but don't let that fool you; getting OpenSSL to play nice with Microsoft's CryptoAPI was HARD. Many, many hours of bit-twiddling were spent.
|
@jlee-r7: I know of no way to generically pull the version info out. As you can see from my latest update, there can be very significant changes in the way PSEXESVC.exe works, necessitating major client updates. Its going to be a maintenance nightmare either way. That's ok, though... I volunteer to be the maintainer for the foreseeable future. It seems like this PR is dependent upon getting #3144 accepted first. Anyone know the status of it? |
|
Looks like #3144 is now closed, this is good for next steps, whatever those may be. |
|
There's a small quirk that prevents it from working on Windows 8, so I On 12/12/2014 02:51 PM, HD Moore wrote:
|
|
Now that the psexec refactor is complete, let's look at landing this since it doesn't get caught by AV. |
|
I keep saying on here (and to myself) that I'll fix it up "soon", but Otherwise, I'm now looking at getting to it in early February. On 01/21/2015 04:26 PM, Brent Cook wrote:
|
|
jtesta, I don't know if you ever reached a conclusion on stdin, but I would look at subclassing Msf::Sessions::CommandShell for your session type. Implement read and write with that. A different but hacky way to do it would be to simply spawn off a generic reverse shell handler listening on localhost and create a socket to connect to it (like Rex's tcp_socket_pair), and spawn a couple threads to forward communications from the remote psexec to your socket and back. But either would be better than listening on stdin, both for everybody who uses other frontends to Metasploit and the ability to background sessions, etc. |
|
Hi @jtesta. First, congrats for having the oldest open PR on Metasploit, now. Sadly, I'm not able to get your module to function. Compare: psexec_commandpsexec_classicThis is using the unmodified version of your module. I have a PR to normalize some of the Ruby, too, with the same results. Care to check it out? I love the idea and want it to work. What can I do to help this along? Target is Windows 7 Professional, SP1, pretty recent patch set. |
|
Note, the library Ruby will also likely need to be reviewed, too, and there are other not-very-Ruby idioms in this PR. I don't mind fixing them up once we hit a reasonable working state, though. |
|
@Meatballs1 it's not like there were merge conflicts -- I tried this PR both in isolation and in a test merge, and the module appears non-functional on Windows 7, where regular psexec_command is fine. IOW. rebasing doesn't appear to be able to solve the functionality or the non-Ruby styles. Do you disagree? |
|
I agree, the last time I tested this it didn't work for me either. :) |
|
Since neither @Meatballs1 nor I were able to get this module to function, let's close out the PR. @jtesta when you have something functional feel free to open a new one, or bug me to reopen this one. |
This module mimics the authentic PsExec program from Microsoft Sysinternals. It extracts the PSEXESVC.EXE code from the authentic PsExec.exe program, sends it to the target, then interacts with it just as PsExec does. The main reasons this module is useful are:
1.) modules/exploits/windows/smb/psexec tends to get caught by AV. This has a better chance of working because PSEXESVC.EXE has a Microsoft signature; blocking it would block Microsoft's PsExec too.
2.) Unlike the authentic PsExec, this lets us take advantage of pass-the-hash, along with running on platforms other than Windows.
3.) Its very convenient for executing interactive processes (like cmd.exe).
At this time, this module does not adhere to the Metasploit's HACKING guide because it reads user commands from $stdin. I tried asking in the IRC channel for pointers on how to fix this, but no one had any suggestions. I'd be happy to revise this module and re-submit once I have sample code to work with!