A story about research and development in 3 parts. Part 1 - research.
There are many beeches - even more benefits.
Formulation of the problem
During pentests and RedTeam campaigns, it is not always possible to use the regular tools of the Customers, such as VPN, RDP, Citrix, etc. as a pin for entering the internal network. Somewhere a regular VPN works on MFA and an iron token is used as the second factor, somewhere it is brutally monitored and our VPN entrance immediately becomes visible, as they say - with all the consequences, but somewhere there are simply no such funds.
In such cases, we constantly have to make so-called "reverse tunnels" - connections from the internal network to an external resource or server controlled by us. Inside such a tunnel, we can already work with the internal resources of the Customers.
There are several varieties of such reverse tunnels. The most famous of them is, of course, Meterpreter. SSH tunnels with reverse port forwarding are also in great demand among the hacker masses. There are quite a few means of implementing reverse tunneling, and many of them are well studied and described.
Of course, for their part, developers of security 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 a reverse SSH tunnel can be detected by almost any more or less normal firewall.
Therefore, in order to remain unnoticed in a good RedTeam campaign, we need to build a reverse tunnel using non-standard means and adapt as closely as possible to the actual network operation mode.
Let's try to find or invent something similar.
Before inventing something, we need to understand what result we want to achieve, what functions our development should perform. What will be the requirements for the tunnel so that we can work in maximum stealth mode?
It is clear that for each case such requirements can be very different, but according to work experience, the main ones can be distinguished:
- work on OS Windows-7-10. Since most corporate networks use Windows;
- the client connects to the server via SSL to eliminate stupid listening using 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 anything about it, and the proxy is used in transparent mode. But we must provide such functionality;
- the client part should be concise and portable;
It is clear that to work within the Customer's network, you can install OpenVPN on the client machine and raise a full-fledged tunnel to your server (fortunately, openvpn clients can work through a proxy). But, firstly, this will not always work out, since we may not be local admins there, and secondly, it will make so much noise that a decent SIEM or HIPS will immediately "tap on" us where necessary. Ideally, our client should be a so-called inline command, such as many bash shells are implemented, and run through the command line, for example, when executing commands from a word macro. - our tunnel must be multi-threaded and support many connections at the same time;
- the client-server connection must have some kind of authorization so that the tunnel is established only for our client, and not for everyone who comes to our server at the specified address and port. Ideally, for "third-party users" a landing page with cats or professional topics related to the original domain should open.
For example, if the Customer is a medical organization, then an information security administrator who decides to check the resource accessed by a clinic employee should open a page with pharmaceutical products, a Wikipedia with a description of the diagnosis, or Dr. Komarovsky's blog, etc.
Analysis of existing tools
Before inventing your own bicycle, it is necessary to analyze existing bicycles and understand whether we really need it and, probably, not only we thought about the need for such a functional bicycle.
Google on the Internet (we google seems to be fine), as well as a search on the github for the keywords β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:
An old implementation of a reverse tunnel from the guys from Kaspersky Lab. By the name it is clear what this script is intended for. Implemented in Python 2.7, the tunnel works in cleartext mode (as it is fashionable to say now - hello RKN)
Another implementation in python, also in cleartext, but there are more possibilities. 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 reverse socks implementation in golang (not supported by the developer).
The second link is already our revision with additional features, also in golang. In our version, we implemented SSL, working through a proxy with NTLM authorization, authorization on the client, a landing page with an incorrect password (or rather, a redirect to the landing page), multi-threaded mode (i.e. several people can work with the tunnel at the same time) , a system of client pings to determine whether he is alive or not.
Implementation of reverse socks from our "Chinese friends" in python. In the same place, for the lazy and "immortals", there is a ready-made binary (exe), assembled by the Chinese and ready for use. Here, only the Chinese god knows what else can be in this binary besides the main functionality, so use it at your own peril and risk.
Pretty interesting project in C++ to implement reverse stock and more. In addition to the reverse tunnel, it can do port forwarding, create a command shell, etc.
MSF meterpreter
Here, as they say, no comment. All more or less educated hackers are well aware of this thing and understand how easy it is to detect security tools.
All the tools described above work on a similar technology: a pre-prepared executable binary module is launched on a machine inside the network, which establishes a connection with an external server. The SOCKS4/5 server is launched on the server, accepting connections and broadcasting them to the client.
The disadvantage of all of the above tools is that either you need Python or Golang installed on the client machine (have you often seen Python installed on machines, for example, company directors or office workers?), Or you need to drag a pre-built binary to this machine (actually python and a script in one bottle) and run this binary already there. And loading an exe with its subsequent launch is another signature for a local antivirus or HIPS.
In general, the conclusion suggests itself - we need a powershell solution. Now tomatoes will fly at us - they say powershell - this is all beaten up, it is monitored, blocked, etc. and so on. In fact, not everywhere. We declare responsibly. By the way, there are a lot of ways to bypass the locks (here again, a fashionable phrase about hello RKN π), starting from stupid renaming powershell.exe -> cmdd.exe and ending with powerdll, etc.
Starting to invent
It is clear that at first we will look in Google and ... we will not find absolutely anything on this topic (if someone has found it, throw links in the comments). There is only Socks5 on powershell, but this is a normal "straight" socks, which has a number of drawbacks (we'll talk about them later). You can, of course, turn it into a reverse one with a slight movement of your hand, but it will only be a single-threaded Sox, which is not quite what we need for us.
So, we have not found anything ready, so we still have to invent our own wheel. We will take as the basis of our bike backsock on golang, and the client to it is implemented on powershell.
RSocksTun
So how does rsockstun work?
RsocksTun (hereinafter - rs) is based on two software components - Yamux and Socks5 server. Socks5 server is a regular local socks5, it runs on the client. And multiplexing connections to it (remember multithreading?) is provided using yamux (). This scheme allows you to run several client socks5 servers and distribute external connections to them, forwarding them through a single TCP connection (almost like in meterpreter) from the client to the server, thereby implementing a multi-threaded mode, without which we simply cannot fully work in the internal networks.
The essence of yamux's work is that it introduces an additional network layer for streams, implementing it as a 12-byte header for each packet. (Here we deliberately use the word "stream" and not the thread, so as not to confuse the reader with the program thread "thread" - we will also use this concept in this article). The yamux header contains the stream number, flags for setting/ending the stream, the number of bytes to transfer, and the size of the transfer window.
In addition to setting/stopping a stream, yamux implements a keepalive mechanism that allows you to monitor the health of the established communication channel. The operation of the keeplive message mechanism 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, as well as by the yamux client. When a keepalive message is received, the remote party must respond to it by sending exactly the same message identifier (in fact, a number) that it received. In general, keepalive is the same ping, only for yamux.
In detail, the whole technique of the multiplexer: types of packets, flags for setting up and terminating connections, the data transfer mechanism is described in to yamux.
Conclusion to the first part
So, in the first part of the article, we got acquainted with some tools for organizing reverse tunnels, looked at their advantages and disadvantages, studied the mechanism of the Yamux multiplexer and described the basic requirements for the newly created powershell module. In the next part, we will develop the module itself, practically from scratch. To be continued. Don't switch π
Source: habr.com