We write Reverse socks5 proxy on powershell. Part 1
The story of research and development in 3 parts. Part 1 - research.
There are many beeches - even more benefits.
During the conduct of pentests and RedTeam campaigns, it is not always possible to use the regular means of customers, such as VPN, RDP, Citrix, etc. as a fix for entering the internal network. Somewhere, a regular VPN works according to MFA and an iron token is used as the second factor, somewhere it is severely monitored and our VPN entry immediately becomes visible, as they say - with all the consequences, but somewhere there are simply no such means.
In such cases, constantly have to do the so-called “reverse tunnels" - connections from the internal network to an external resource or the server we control. Inside such a tunnel, we can already work with the internal resources of customers.
There are several varieties of such reverse tunnels. The most famous of them, of course, is Meterpreter. SSH tunnels with reverse port forwarding are also in great demand among the hacker masses. There are a lot of reverse tunneling tools and many of them are well studied and described.
Of course, for their part, developers of protective solutions do not stand by 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 by almost any small 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 adapt as closely as possible to the real mode of the network.
Let's try to find or invent something similar.
Before you invent something, you 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 differ greatly, but from experience we can distinguish the main ones:
Before inventing your bike, you need to analyze 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 seem to be okay with google), as well as searching the github for the keywords “reverse socks”, did not give much results. Basically, it all comes down to building ssh tunnels with reverse port forwarding and everything connected with it. In addition to SSH tunnels, several solutions can be distinguished:
github.com/klsecservices/rpivot A
long-standing implementation of the reverse tunnel from the guys from Kaspersky Lab. By the name it’s clear what this script is for. Implemented in Python 2.7, the tunnel runs in cleartext mode (as it is fashionable to say now - hello to ILV)
github.com/tonyseek/rsocks
Another python implementation, also in cleartext, but with more options. It is written as a module and there is an API for integrating the solution into your projects.
github.com/llkat/rsockstun
github.com/mis-team/rsockstun
The first link is the initial version of the implementation of reverse socks on the golang (not supported by the developer).
The second link is already our revision with additional chips, also on the golang. In our version, we implemented SSL, work through a proxy with NTLM authorization, client authorization, a landing page with an incorrect password (or rather a redirect to a landing page), multi-threaded mode (i.e. several people can work with the tunnel at the same time) , a client ping system for whether it is alive or not.
github.com/jun7th/tsocks
Reverse Sox implementation from our “Chinese friends” in python. There for the lazy and "immortal" lies the ready-made binar (exe), assembled by the Chinese and ready for use. Here, only the Chinese god knows that there can be more than the main functionality in this binar, so use it at your own peril and risk.
github.com/securesocketfunneling/ssf
Quite an interesting C ++ project for implementing reverse socks 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 the more or less educated hackers are very familiar with this thing and understand how easily it can be detected by protective equipment.
All of the above tools work on a similar technology: on a machine inside the network, a pre-prepared executable binary module is launched, which establishes a connection to an external server. The server starts the SOCKS4 / 5 server, which accepts connections and translates them to the client.
The disadvantage of all of the above tools is that either Python or Golang is required on the client machine (did you often see Python installed on machines, for example, company directors or office workers?), Or you need to drag a pre-assembled binar to this machine (actually python and the script in one bottle) and run this binar already there. And downloading exe with its subsequent launch is also the signature for a local antivirus or HIPS.
In general, the conclusion suggests itself - we need a solution on powershell. Now tomatoes will fly at us - they say powershell - it's all beaten up, it is being monitored, blocked, etc. etc. In fact - not everywhere. We declare responsibly. By the way, there are a lot of ways to bypass the locks (here again the fashionable phrase about hello to the ILV :)), starting from the stupid renaming of powershell.exe -> cmdd.exe and ending with powerdll, etc.
It’s clear that at first we’ll look in Google and ... we won’t find anything on this topic (if someone has found - throw links in comments). There is only an implementation of Socks5 on powershell, but this is the usual “direct” Sox, which has a number of its drawbacks (we will talk about them later). You can, of course, turn it into a reverse with a flick of the wrist, but it will only be a single-threaded sox, which is not exactly what we need for us.
So, we did not find anything ready, so we still have to invent our bike. As the basis of our bike, we take our development of reverse socks on the golang, and we implement the client for it on powershell.
RSocksTun
So, how does rsockstun work?
At the heart of the work of RsocksTun (hereinafter referred to as rs) are 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 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 one single TCP connection (almost like in meterpreter) from the client to the server, thereby realizing multi-threaded mode, without which we simply cannot fully work in the internal network.
The essence of yamux is that it introduces an additional network level of streams, realizing it as a 12-byte header for each packet. (Here we intentionally use the word "stream", not a stream, so as not to confuse the reader with the program thread "thread" - this concept we will also use in this article). Inside the yamux header contains the stream number, flags for setting / ending the stream, the number of bytes transferred, the size of the transfer window.
In addition to installing / completing the stream, yamux implements a keepalive mechanism that allows you to monitor the health of the installed communication channel. The mechanism of 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. The yamux server can send keepalive messages, so the yamux client can. Upon receipt of a keepalive message, the remote party is obliged to respond to it by sending exactly the same message identifier (actually a number) that it has received. In general, keepalive is the same ping, only for yamux.
The entire multiplexer operation technique is in detail: packet types, installation and termination flags, data transfer mechanism is described in the yamux specification .
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 operation 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. Do not switch :)
There are many beeches - even more benefits.
Formulation of the problem
During the conduct of pentests and RedTeam campaigns, it is not always possible to use the regular means of customers, such as VPN, RDP, Citrix, etc. as a fix for entering the internal network. Somewhere, a regular VPN works according to MFA and an iron token is used as the second factor, somewhere it is severely monitored and our VPN entry immediately becomes visible, as they say - with all the consequences, but somewhere there are simply no such means.
In such cases, constantly have to do the so-called “reverse tunnels" - connections from the internal network to an external resource or the server we control. Inside such a tunnel, we can already work with the internal resources of customers.
There are several varieties of such reverse tunnels. The most famous of them, of course, is Meterpreter. SSH tunnels with reverse port forwarding are also in great demand among the hacker masses. There are a lot of reverse tunneling tools and many of them are well studied and described.
Of course, for their part, developers of protective solutions do not stand by 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 by almost any small 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 adapt as closely as possible to the real mode of the network.
Let's try to find or invent something similar.
Before you invent something, you 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 differ greatly, but from experience we can distinguish the main ones:
- work on OS Windows-7-10. Since most corporate networks use Windows;
- the client connects to the server via SSL to prevent stupid listening using ips;
- when connecting, the client must support operation through a proxy server with authorization, as Many companies access the Internet through a proxy. In fact, the client machine may not even know anything about it, and the proxy is used in a transparent mode. But we must lay such functionality;
- the client part should be concise and portable;
It is clear that for working inside the Customer’s network on the client machine, you can install OpenVPN and raise a full-fledged tunnel to your server (since openvpn clients can work through proxies). But, firstly, this does 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 “knock on us”. Ideally, our client should be a so-called inline command, such as many bash shells, for example, and run through the command line, for example, when executing commands from a word macro. - our tunnel must be multithreaded 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 seals or professional topics related to the source domain should open.
For example, if the Customer is a medical organization, then for the information security administrator who decided to check the resource that the clinic employee used, a page with pharmaceutical goods, a wikipedia with a description of the diagnosis, or a blog of Dr. Komarovsky, etc. should open.
Analysis of existing tools
Before inventing your bike, you need to analyze 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 seem to be okay with google), as well as searching the github for the keywords “reverse socks”, did not give much results. Basically, it all comes down to building ssh tunnels with reverse port forwarding and everything connected with it. In addition to SSH tunnels, several solutions can be distinguished:
github.com/klsecservices/rpivot A
long-standing implementation of the reverse tunnel from the guys from Kaspersky Lab. By the name it’s clear what this script is for. Implemented in Python 2.7, the tunnel runs in cleartext mode (as it is fashionable to say now - hello to ILV)
github.com/tonyseek/rsocks
Another python implementation, also in cleartext, but with more options. It is written as a module and there is an API for integrating the solution into your projects.
github.com/llkat/rsockstun
github.com/mis-team/rsockstun
The first link is the initial version of the implementation of reverse socks on the golang (not supported by the developer).
The second link is already our revision with additional chips, also on the golang. In our version, we implemented SSL, work through a proxy with NTLM authorization, client authorization, a landing page with an incorrect password (or rather a redirect to a landing page), multi-threaded mode (i.e. several people can work with the tunnel at the same time) , a client ping system for whether it is alive or not.
github.com/jun7th/tsocks
Reverse Sox implementation from our “Chinese friends” in python. There for the lazy and "immortal" lies the ready-made binar (exe), assembled by the Chinese and ready for use. Here, only the Chinese god knows that there can be more than the main functionality in this binar, so use it at your own peril and risk.
github.com/securesocketfunneling/ssf
Quite an interesting C ++ project for implementing reverse socks 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 the more or less educated hackers are very familiar with this thing and understand how easily it can be detected by protective equipment.
All of the above tools work on a similar technology: on a machine inside the network, a pre-prepared executable binary module is launched, which establishes a connection to an external server. The server starts the SOCKS4 / 5 server, which accepts connections and translates them to the client.
The disadvantage of all of the above tools is that either Python or Golang is required on the client machine (did you often see Python installed on machines, for example, company directors or office workers?), Or you need to drag a pre-assembled binar to this machine (actually python and the script in one bottle) and run this binar already there. And downloading exe with its subsequent launch is also the signature for a local antivirus or HIPS.
In general, the conclusion suggests itself - we need a solution on powershell. Now tomatoes will fly at us - they say powershell - it's all beaten up, it is being monitored, blocked, etc. etc. In fact - not everywhere. We declare responsibly. By the way, there are a lot of ways to bypass the locks (here again the fashionable phrase about hello to the ILV :)), starting from the stupid renaming of powershell.exe -> cmdd.exe and ending with powerdll, etc.
Start inventing
It’s clear that at first we’ll look in Google and ... we won’t find anything on this topic (if someone has found - throw links in comments). There is only an implementation of Socks5 on powershell, but this is the usual “direct” Sox, which has a number of its drawbacks (we will talk about them later). You can, of course, turn it into a reverse with a flick of the wrist, but it will only be a single-threaded sox, which is not exactly what we need for us.
So, we did not find anything ready, so we still have to invent our bike. As the basis of our bike, we take our development of reverse socks on the golang, and we implement the client for it on powershell.
RSocksTun
So, how does rsockstun work?
At the heart of the work of RsocksTun (hereinafter referred to as rs) are 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 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 one single TCP connection (almost like in meterpreter) from the client to the server, thereby realizing multi-threaded mode, without which we simply cannot fully work in the internal network.
The essence of yamux is that it introduces an additional network level of streams, realizing it as a 12-byte header for each packet. (Here we intentionally use the word "stream", not a stream, so as not to confuse the reader with the program thread "thread" - this concept we will also use in this article). Inside the yamux header contains the stream number, flags for setting / ending the stream, the number of bytes transferred, the size of the transfer window.
In addition to installing / completing the stream, yamux implements a keepalive mechanism that allows you to monitor the health of the installed communication channel. The mechanism of 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. The yamux server can send keepalive messages, so the yamux client can. Upon receipt of a keepalive message, the remote party is obliged to respond to it by sending exactly the same message identifier (actually a number) that it has received. In general, keepalive is the same ping, only for yamux.
The entire multiplexer operation technique is in detail: packet types, installation and termination flags, data transfer mechanism is described in the yamux specification .
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 operation 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. Do not switch :)