A story about research and development in 3 parts. Part 1 — the research phase.
There are many books — even more usefulness.
Task Definition
During the course of penetration tests and Red Team campaigns, it's not always possible to utilize the standard tools of the clients, such as VPN, RDP, Citrix, etc., as a means to gain access to the internal network. In some cases, the standard VPN operates under MFA with a hardware token as the second factor, in others, it is closely monitored, and our entry via VPN is immediately visible, as they say — with all the repercussions, and in some instances, such tools simply do not exist.
In such cases, we constantly have to create so-called 'reverse tunnels' — connections from the internal network to an external resource or a server controlled by us. Inside such a tunnel, we can work with the internal resources of the clients.
There are several varieties of these reverse tunnels. The most well-known is, of course, Meterpreter. SSH tunnels with reverse port forwarding are also quite popular among the hacking community. There are many tools available for implementing reverse tunneling, and many of them are well studied and documented.
Of course, the developers of security solutions do not remain idle and actively detect such actions.
For instance, MSF sessions are effectively detected by modern IPS systems from Cisco or Positive Tech, and a reverse SSH tunnel can be detected by practically any decent firewall.
Therefore, to remain unnoticed in a quality Red Team campaign — we need to build a reverse tunnel using non-standard methods and adjust as closely as possible to the actual operational mode of the network.
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 requirements will there be for the tunnel so that we can operate with maximum stealth?
Clearly, these requirements can vary significantly for each case, but from experience, we can highlight the main ones:
- operating on Windows 7-10, as most corporate networks use Windows.
- The client connects to the server via SSL to prevent eavesdropping by IPS tools;
- When connecting, the client must support operation through an authenticated proxy server, as in many companies, internet access is achieved through a proxy. In fact, the client machine may not even be aware of this, as the proxy operates in transparent mode. However, we must incorporate such functionality;
- The client part should be concise and portable;
It is clear that to work within the customer's network on the client machine, OpenVPN can be installed to establish a full tunnel to its server (especially since OpenVPN clients can work through proxies). But, firstly, it may not always be possible, as we might not be local admins there, and secondly, it will create so much noise that a proper SIEM or HIPS will immediately flag us. Ideally, our client should function as an inline command, similar to how many bash shells are implemented, and be executed via the command line, for example, when executing commands from a Word macro. - Our tunnel must be multithreaded and support multiple connections simultaneously;
- The client-server connection must have some form 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, a landing page featuring cats or a theme professionally related to the origin domain should open for 'external users.'
For instance, if the customer is a medical organization, the security administrator seeking to check the resource accessed by a clinic employee should see a page featuring pharmaceutical products, a Wikipedia entry on the diagnosis, or a blog by Dr. Komarovsky, etc.
Analysis of existing tools
Before inventing your own bicycle, it is necessary to analyze existing bicycles and understand whether we truly need it, as we are likely not the only ones who have considered the necessity of such a functional bicycle.
Searching the internet (we seem to do it quite well) and looking on GitHub with the keywords "reverse socks" didn't yield many results. Mostly, everything boils down to building SSH tunnels with reverse port forwarding and everything related to that. In addition to SSH tunnels, there are several solutions worth noting:
An old implementation of a reverse tunnel from the Kaspersky Lab team. The script's purpose is clear from its name. It is implemented in Python 2.7, and the tunnel operates in cleartext mode (as is popular to say now — greetings to the Russian Federal Service for Surveillance of Communications, Information Technology and Mass Media).
Another Python implementation, also in cleartext, but with more capabilities. It is written as a module and has 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 our enhancement with additional features, also in Golang. In our version, we implemented SSL, proxy support with NTLM authentication, client authorization, a landing page for incorrect passwords (rather, a redirect to the landing page), multi-threading (i.e., multiple users can work with the tunnel simultaneously), and a system to ping the client to check if it is alive or not.
A reverse socks implementation from our "Chinese friends" in Python. For the lazy and the "immortal," there's also a ready-to-use binary (exe) compiled by the Chinese. Here, only the Chinese god knows what else might be in this binary besides the main functionality, so use it at your own risk.
A rather interesting project in C++ for implementing reverse socks and more. Besides reverse tunneling, it can do port forwarding, shell execution, etc.
MSF meterpreter
As they say, no comments needed. Any reasonably educated hacker is well acquainted with this tool and understands how easily it can be detected by security measures.
All of the tools described above operate on similar technology: a pre-prepared executable binary module is launched on a machine within the network, establishing a connection with an external server. A SOCKS4/5 server runs on the server, accepting connections and relaying them to the client.
The drawback of all the aforementioned tools is that either Python or Golang must be installed on the client machine (how often do you encounter Python installed on the machines of, say, a company director or office workers?), or a precompiled binary (essentially Python and the script in one package) must be transferred to that machine and executed there. Loading an exe and then running it poses a significant signature for local antivirus or HIPS.
Overall, the conclusion is obvious—we need a solution in PowerShell. At this point, we might get tomatoes thrown at us for saying that PowerShell is already outdated, monitored, blocked, etc. In reality, this is not the case everywhere. We affirm this responsibly. By the way, there are countless ways to bypass blocks (again, a popular phrase greeting the RKN 🙂), from simply renaming powershell.exe to cmdd.exe to techniques like powerdll.
Let's start inventing.
It's clear that first, we will look on Google and… find absolutely nothing on this topic (if anyone has found something—please share links in the comments). There is only Socks5 in PowerShell, but this is just a standard "direct" SOCKS, which has its own set of drawbacks (we'll discuss those later). Of course, with a simple trick, we can turn it into a reverse proxy, but it would only be a single-threaded SOCKS, which isn't quite what we need.
So, we found nothing ready-made, hence we will have to invent our own bicycle. The basis of our bicycle will be of a reverse SOCKS in Golang, and we will implement the client for it in PowerShell.
RSocksTun
So, how does rsockstun work?
The operation of RsocksTun (hereinafter referred to as rs) is based on two software components—Yamux and a SOCKS5 server. The SOCKS5 server is a standard local SOCKS5, which runs on the client. Connection multiplexing to it (remember about multithreading?) is handled using Yamux (). This scheme allows you to run multiple client SOCKS5 servers and distribute external connections to them, routing them through a single TCP connection (almost like in meterpreter) from the client to the server, thus implementing a multithreaded mode without which we simply cannot operate effectively within the internal network.
The essence of Yamux's operation lies in the introduction of an additional network layer of streams, implemented as a 12-byte header for each packet. (Here we deliberately use the word 'stream' and not ' потока' to avoid confusing the reader with the programming term 'thread' — this concept will also be used in this article.) Inside the Yamux header, there are the stream number, flags for establishing/terminating the stream, the number of bytes transmitted, and the size of the transmission window.
In addition to establishing/terminating streams, Yamux has a keepalive mechanism that allows monitoring the functionality of an established communication channel. The operation of the keepalive messages mechanism is configured when creating a Yamux session. Actually, there are only two settings: enable/disable and the frequency of sending packets in seconds. Keepalive messages can be sent by either the Yamux server or the Yamux client. Upon receiving a keepalive message, the remote side must respond with a packet containing the exact same message identifier (essentially a number) that it received. In general, keepalive is similar to a ping, but for Yamux.
Detailed techniques for the operation of the multiplexer: types of packets, flags for establishing and terminating connections, and the data transfer mechanism are described in the Yamux documentation.
Conclusion to the first part
So, in the first part of the article, we familiarized ourselves with some tools for organizing reverse tunnels, looked at their advantages and disadvantages, studied the operation of the Yamux multiplexer mechanism, and outlined the main requirements for the newly created PowerShell module. In the next part, we will focus on developing the module itself, practically from scratch. Stay tuned 🙂
Source: habr.com
