A story about research and development in 3 parts. Part 1 - research.
There are many beeches - there is even more benefit.
In the course of pentesting and RedTeam campaigns, it is not always possible to use Customer’s standard tools, such as VPN, RDP, Citrix, etc. as a fixation for entering the internal network. Somewhere a regular VPN works on MFA and the iron token is used as the second factor, somewhere it is monitored severely and our VPN input immediately becomes visible, as they say - with all the consequences, but somewhere there is simply no such means.
In such cases, we constantly have to do so-called “reverse tunnels” - connections from the internal network to an external resource or a server controlled by us. Within such a tunnel, we can already work with the internal resources of the Customers.
There are several variations of such reverse tunnels. The most famous of them, of course, is the Meterpreter. Also in great demand among the popular hacker masses are SSH tunnels with reverse forwarding of ports. Reverse tunneling has a lot of means and many of them are well studied and described.
Of course, for their part, the developers of protective solutions do not stand aside and actively detect such actions.
For example, MSF-sessions are successfully detected by modern IPS from Cisco or Positive Tech, and the reverse SSH-tunnel can be detected with almost any normal normal firewall.
Therefore, in order to go unnoticed in a good RedTeam campaign, we need to build a reverse tunnel with non-standard means and as closely as possible adjust to the real network operation mode.
Let's try to find or invent something like that.
Before you invent something you need to understand what result we want to achieve, what functions our development should perform. What are the requirements for the tunnel so that we can work in the mode of maximum secrecy?
It is clear that for each case such requirements may vary greatly, but according to work experience, you can identify the main ones:
- work on Windows-7-10. Since most corporate networks use Windows;
- the client connects to the server via SSL to prevent stupid listening with ips;
- when connecting, the client must support work through a proxy server with authorization, because In many companies, access to the Internet occurs through a proxy. In fact, the client machine may not even know about it, and the proxy is used in a transparent mode. But we should put such functionality;
- The client must be concise and portable;
It is clear that to work within the Customer’s network, you can install OpenVPN on a client machine and raise a full-fledged tunnel to your server (since openvpn clients can work through a proxy). But, firstly, it does not always work out, since we may not be local administrators there, and secondly, it will cause so much noise that a decent SIEM or HIPS will immediately “trick it on us” on us. Ideally, our client should be a so-called inline command, such as many bash shells are implemented, and run via the command line, for example, when executing commands from a word macro.
- our tunnel must be multi-threaded and support multiple connections at the same time;
- the client-server connection must have any authorization so that the tunnel is established only for our client, and not for everyone who comes to us to the server at the specified address and port. Ideally, for "third-party users", a landing page should be opened with cats or professionally related to the source domain.
For example, if the Customer is a medical organization, then the information security administrator, who decided to check the resource that the clinic employee addressed, should open a page with pharmaceutical products, Wikipedia describing the diagnosis or Dr. Komarovsky’s blog, etc.
Analysis of Existing Tools
Before reinventing your bike, you need to make an analysis of existing bikes and understand whether we really need it and, probably, not only we thought about the need for such a functional bike.
Googling on the Internet (we google it seems to be normal), as well as a search on the github for the keyword "reverse socks" did not give very many results. Basically, it all comes down to building ssh-tunnels with reverse port forwarding and everything connected with it. In addition to SSH tunnels, there are several solutions:
Old implementation of the reverse tunnel from the guys from Kaspersky Lab. By name it is clear what this script is for. Implemented in Python 2.7, the tunnel works in cleartext mode (as it is fashionable to say now, hello RCH)
Another implementation on python, also in cleartext, but more features. Written as a module and there is an API for integrating the solution into your projects.
The first link is the original version of the implementation of the socks reverse on the goal (not supported by the developer).
The second link is our refinement with additional chips, also on the goal. In our version, we implemented SSL, working through a proxy with NTLM authorization, authorization on the client, landing page with the wrong password (or rather, redirecting to the landing page), multi-threaded mode (ie, several people can work with the tunnel at the same time) , the client's ping system for whether it is live or not.
The implementation of reverse socks from our "Chinese friends" on python. In the same place for the lazy and "immortal" is already ready binary (exe), assembled by the Chinese and ready for use. Here only one Chinese god knows that in this binary there may be more than the main functionality, so use at your own risk.
Quite an interesting C ++ project for the implementation of reverse socks and more. In addition to the reverse tunnel, it can do port forwarding, create a command shell, etc.
Here, as they say, no comment. All more or less educated hackers are perfectly familiar with this thing and understand how easy it is to detect defenses.
All the above tools work on a similar technology: on a machine inside the network, a previously prepared executable binary module is launched that establishes a connection with an external server. The server runs SOCKS4/5 server, which accepts connections and transmits them to the client.
The disadvantage of all of the above tools is that either Python or Golang is installed on the client machine (have you often seen installed Python on machines, for example, a company director or office workers?), Or you need to drag a pre-assembled binary into this machine (in fact, python and the script in one bottle) and run this binary is already there. And downloading an exe and then launching it is another signature for a local antivirus or HIPS.
In general, the conclusion suggests itself - we need a solution for powershell.Now tomatoes will fly into us - they say powershell - this is all beaten, it is monitored, blocked, etc. etc. In fact - not everywhere. Responsibly declare. By the way, there are a lot of ways to bypass the blocking (here again a fashionable phrase about hello RKN :)), starting from the blunt renaming of powershell.exe - & gt; cmdd.exe and ending with powerdll, etc.
Getting started to invent
It is clear that at first we will look in Google and ... we will not find anything on this topic (if someone found it - throw links in the comments). There is only a implementation
of Socks5 on powershell, but this is the usual "direct" sox, which has some of its drawbacks (we'll talk about them later). You can, of course, turn it into a reverse movement with a slight movement of your hand, but this will be just a single-threaded sox, which is not exactly what we need.
So, we did not find anything ready, so we still have to reinvent our bicycle. We take the our development
of the reverse socks on the goal, and implement the client to it using powershell.
So how does rsockstun work?
The basis of RsocksTun (hereinafter referred to as rs) is based on two software components - Yamux and Socks5 server. Socks5 server is the usual local socks5, it runs on the client. And the multiplexing of connections to it (remember about multithreading?) Is provided using yamux ( yet another multiplexer
). This scheme allows you to run several client socks5 servers and distribute external connections to them, forwarding them through a single TCP connection (almost as in meterpreter) from client to server, thereby implementing a multi-threaded mode, without which we simply cannot work fully in the internal network.
The essence of yamux’s work is that it introduces an additional network level of streams, implementing it in the form of a 12-byte header for each packet. (Here we intentionally use the word “stream”, not the stream, so as not to confuse the reader with the program thread “thread” - we will also use this concept in this article). Inside the yamux header contains the stream number, flags for setting/terminating the stream, the number of bytes transmitted, the size of the transmission window.
In addition to installing/terminating a stream, a keepalive mechanism is implemented in yamux, allowing you to monitor the performance of an established communication channel. The mechanism of the keeplive-messages is configured when creating a Yamux session. Actually, from the settings there are only two parameters: enable/disable and the frequency of sending packets in seconds. Keepalive messages can be sent by the yamux server, so the yamux client. When a keepalive message is received, the remote side is obliged to respond to it by sending the exact same message identifier (actually a number) that it accepted. In general, keepalive is the same ping, only for yamux.
In detail, the whole multiplexer technique: package types, installation flags and connection terminations; the data transfer mechanism is described in the specifications
Conclusion to the first part
So, in the first part of the article we met with some tools for organizing reverse tunnels, looked at their advantages and disadvantages, studied the mechanism of operation of the Yamux multiplexer and described the main requirements for the newly created powershell module. In the next part, we will develop the module itself, practically from scratch. To be continued. Do not switch:)