Meterpreter offline actions

[NickSampanis]

Greetings, I created this issue in order to discuss with you an extension that i am thinking to implement for offline activities in meterpreter such as keylogging/sniffing (maybe even password cracking :P). You may able to give me some feedback or answer some questions about the technical implementation of the project. The whole idea behind this, is that an attacker should be able to set offline activities and connect back after a period of time being able to get the results of those activities.

Now from the technical point of view(for windows platform). The extension will give you a choice to inject any process by giving the process id. i)When you inject the process with a dll, after the reflective loader runs all the initialization, it should create a namedpipe with a random name provided by the client. ii)the client should store the name of the pipe, somewhere in metasploit's local memory iii)anytime the client should be able to open the pipe and give commands like (run_keylogger, stop_keylogger, dump_keylogger, remove_injected_dll), which will send back to the client an output.

Now some technical questions. i)should i make 2 different dlls? one like priv and one like elevator? because priv doesn't inject it self to the remote process, it rather injects elevator. (after a short irc chat i had with @bcook-r7 he told me that i would be better if the code injecting/removing the dll goes to stdapi or extapi. should i implement the other one in "source/offline" as offline.dll?

ii)do you have any idea where is an appropriate way to store this informations(the random name of the pipe for a specific victim)?

iii)how does the whole thing sounds? @OJ @hmoore-r7 @bcook-r7

[bcook-r7]

I talked to @hmoore-r7 a bit about this yesterday. It seems like a pretty good approach so far. If you want to use a separate extension for this for now, it's not a big deal if we decide to move it around to stdapi later. I suspect there will be some unification of offline facilities later anyway, right now we're just experimenting.

[OJ]

We should move this over to Metasploit Payloads. :+1:

[OJ]

Howdy! Sorry for being late to the party. Just catching up on correspondence now.

The first question that comes to mind here is "what does offline mean?"

Meterpreter already does keylogging, sniffing, clipboard monitoring, etc. all on separate threads of activity. Those activities don't interfere with the mean thread of execution. If a user kicks off a sniffer, or a keylogger, they can continue to talk to Meterpreter while it's doing those other things. If the user decides to put the Meterpreter session to sleep (using the sleep command), this results in the comms channel being closed, and having the main thread of execution wait for a set period of time before firing up again and re-establishing communication to MSF.

Does this functionality not already cover this case? Instead of injecting offline activities into another component, setting up named pipes, etc. would it not be simpler to throw a Meterpreter session into the target PID and then just interact with that directly before putting it to sleep?

Apologies if I'm missing something. I'd hate to see a great deal of work thrown into this if we kind of already have it!

Cheers all.

[NickSampanis]

my whole life was a lie. I wasn't aware of the sleep command, i will close this issue

[OJ]

I feel really bad now! I'm glad I have saved you the work though. I still think adding more async activities that can be abusedutilised in this manner would be great too.

[void-in]

@OJ @NickSampanis @bcook-r7 I was under the impression that offline means when meterpreter can't communicate with the handler but you want it to start doing it's work as soon as it is executed while send the results to the handler when possible. For example a person executing stageless meterpreter on his laptop when not connected to the Internet so meterpreter would start collecting whatever is configured for in the offline mode. As as when the laptop is connected to the Internet, the results start coming in to the handler.

Sleep would still require meterpreter to establish connection to the handler and then it can be put on hold through sleep.

[NickSampanis]

@void-in that could be another scenario of "offline mode", but the main idea behind this was the ability to gain personal informations while you aren't connected. If sleep could do this by connecting one time doesn't make a big difference to me. My only concern is what happens when you sleep for 20s and after that the reverse_shell is unable to connect to your handler. If in that case the meterpreter dies then i would prefer a slightly different approach, where the handler tries to connect every 20s instead of one time after 20s. This would make an attacker able to connect to the user after days. Its almost certain that the user will have internet access when he executes your meterpreter. Either he downloaded a pdf/word or he was running a vulnerable app. Unless a few cases where you might dropped a usb with meterpreter or you have executed it by yourself in to someones pc/mobile.

I was thinking "offline mode" as a transport layer called "offline" that would be different for each platform. This implementation would satisfied your scenario too.

[void-in]

@NickSampanis It won't die as a result of unavailablity of handler. Looking at the excellent documentations put up by @OJ at https://github.com/rapid7/metasploit-framework/wiki/Meterpreter-Sleep-Control, it is mentioned that sleep is implemented as transport switching. This means that after sleep, meterpreter will try to connect to the handler unless either the session is established or the session timeout is reached.